It's 2018 user. Why haven't you learned Go yet?

It's 2018 user. Why haven't you learned Go yet?

Attached: 0*fyyS1OHEaQ2il8Tg.png (607x318, 52K)

Other urls found in this thread:

github.com/golang/go/wiki#getting-started-with-go
gobyexample.com
github.com/mmcloughlin/globe
github.com/concourse/concourse
github.com/redox-os/redox
github.com/grafana/grafana
github.com/influxdata/influxdb
github.com/kubernetes/kubernetes
twitter.com/SFWRedditImages

go back to your grave, uriel

Because Basic already works well enough.

it would have been nice to learn it 38 year ago.

I learned it a few years ago. Couldn't find a viable use case for me. I know Erlang, why would I need Go? Then I tinkered with Rust. I know Haskell, why the fuck would I need that?

You want to feel in the future? Just go functional and never look back.

The fact that you discount rust makes me doubt your opinion a bit. Most of the cool open source projects written in the last two years are either in rust or go.

>I know erlang, why would I need Go?
Because you want something compiled that doesn't have to run under a VM to achieve extensive concurrency and threading?

What's a good book to start learning Go for someone w/ existing programming knowledge.

I don't Go, but perhaps this? github.com/golang/go/wiki#getting-started-with-go

heres one:
1) don't

I wanted to use Rust but async/await is a mess.

I guess I'll indeed give Go a try meanwhile.

This is a weak argument, considering Go uses a very shitty garbage collector.

The Go Programming Language by Donovan and Kernighan (yes, that Kernighan) is the best.

omg this is perfect
i cant believe this book exists

It takes an hour to learn. Why would anyone brag about having learned the language.

I don't see anyone bragging or even suggesting about it.

What is it even good for

Because I already know C

Because it's 2018, not 1918.

>I know a gc purely functional, slow as ass language
>why would I need a non-gc non-purely functional faster than C language?
Hasklelfags logic.

>rust faster than c
lol

>It's 2018 user. Why haven't you learned Go yet?
Because it's a horrible language.

See leaf, collenchyma, ripgrep, the xml parser, and others. Cry moar.

I don't need it in game dev.

It's the best language for servers, bar none.

They are faster on the virtue of using better data structures and algorithms.

Which is in great parts due to being built on a significantly more expressive language with similar performance, thus making it IN PRACTICE (instead of theory/fizzbuzz), faster.

Reminder that no large-scale production project has ever been completed in rust

Attached: 1517346363809.jpg (472x451, 153K)

Ok, point taken.

I use go at work, it's breddy comfy, fun and very readable

I don't want to accept this, because I don't like Rust as a community, and if Rust takes over the market that would mean me having to learn yet another language.

for serious things i'd use java, for trivial things i'd use python, go is at a weird halfway point between those

ttbh

Because Pascal was better except for the concurrency meme. And this was a learning language. Let this sink in for a moment.

Becuase I'm just about to deploy my first CRUD app and learning GO would take to much time, normal frame works work fine

I also dislike rust as a community. But moreover, I even dislike it as a language. It gets a lot of things right, but working with the borrow checker on non-trivial code is an ordeal (in particular, in medium-to-large projects, you'll invariably reach a point where you have to either go unsafe (which snowballs into an unsafe forest) or rewrite the whole thing), and the language features are extremely unstable. Tons of nice things happening with every new version, but makes it really hard to keep up. Finally, its syntax could be a lot nicer. They're working on shittons of syntactic sugar to make it so, which in itself is causing a kind of feature bloat with 20 syntax forms giving the same result.

Despite all that, I remain impressed by what people have accomplished with it especially speed-wise. Mostly, this is interesting because it clearly demonstrates that abstraction DOES matter in real life (a claim many people have made, but basically none have been able to substantiate so far without using purely internal statistics driven by political agendas).
If this results in new language development that results in yet faster languages due to their high-level design while retaining advantages of languages like lisps (with live image patching, homoiconicity, and the powerful repls), it would make rust a huge boon in the world of programming as a whole.

Above all it's important to objectively keep track of good and bad things, even if the good comes from much bad or vice versa. It's the only way forward.

Go has literally nothing to offer. Besides GC, it doesn't do anything you couldn't also do in C or C++

Reminder that Firefox's Servo engine is a thing.

It offers easy scalability.

>it doesn't do anything you couldn't also do in C or C++
This applies to every turing-complete language, dumbass.

This post reinforces in my head, that Rust is the JavaScript of systems languages.

that's niggerlicious

I like this phrase. We should use it more often.

used it for a month and found it to be nearly worthless for most tasks I use.
it's faster than python, however making the program takes 10 times as long so not really worth it

Please tell me what cool open source projects are written in Rust and Go

I used this and only read like a third of it and was writing a program fine: gobyexample.com

I'm reading through the rest so I can improve my style now but it was pretty fun, not a bad language though it's not very compact imo

Be nice, user.

Not him, but the only thing I've ever seen posted on the Internet made in Go is: github.com/mmcloughlin/globe

Duck typing wastes far more time. The difference is that the cost of a verbose, strict typed language is upfront, whereas the cost of a language like python doesn't show up until you're already in production and things inexplicably don't work but don't raise errors.

I love python. But I won't use it for large projects with multiple collaborators. Type hinting may change that, but it's not nearly mature enough yet.

And when it comes to speed and memory overhead, go makes python look silly.

>t's not very compact imo
say what?

Does it have generics already?

C is the most successful language in history and it doesn't have generics.

I said please and anything. I actually like Go, and I think Rust has some cool ideas, but these unpaid newlang missionaries frequently make these dumb fucking unverifiable claims

What? Erlang doesn't have much to do with Go.

Generics encourage code bloat

Here are projects I've used for fun in just the last *24 hours*. I use several of these at work as well.
github.com/concourse/concourse
github.com/redox-os/redox
github.com/grafana/grafana
github.com/influxdata/influxdb

Generics are a code smell. struct{} is more than sufficient for any kind of multi-use abstraction.

Wow dude those are so cool. A CI system nobody uses, a graph software nobody uses, an operating system that nobody uses, and a database that nobody uses.

Very cool!

Every cool open source project that gets written in go seems to get to the 70% mark really quickly, then everyone just leaves the project. Gofucks all have ADD I swear.

Humans are the most successful form of life in history and we fucking suck. Popularity is not synonymous with good.
That said, C is alright.

uhh... make that interface{}

Look at pantsu and see how it's turned out.

I felt like I had to write quite a few lines of code compared to haskell, I'm sure this could be shortened but I just wanted to read one line from a file. This is the worst example it's not much of a complaint but sometimes some pretty basic things seem a little verbose

func getToken() (string, error) {
file, err := os.Open("token.txt")

defer file.Close()

if err != nil {
return "", err
}

reader := bufio.NewReader(file)

line, err := reader.ReadString('\n')

if err != nil {
return "", err
}

line = strings.TrimSuffix(line, "\n")

return line, nil
}

I'm a devops engineer and the rumbling I hear is that people are ditching jenkins for concourse. That's a pretty huge fucking deal.

I'm also using influxdb and grafana in production for a very large corporation.

That's 4 out of the 5 I posted which are already being adopted by large tech companies.

Sorry, for a moment there I thought you meant that the language itself was large

Oh no, I like how pretty simple the language is. To me it feels kinda like a nice spot between c++ and python, low level but with some nice syntax and abstractions, I'm gonna use it on some more projects

I'm a lifelong Firefox user and I wouldn't call them a large-scale project after they've literally had a negative marketshare every year since 2014.

doesn't go have some weird preprocessor/macro tools as a bandaid for their shitty language

cover looks like shit compared to K&R.

I am learning it so far I am liking its procedural nature, I am coming from Java, is it hard later on? like c++? C++ is also quite okay in beginning but than it just becomes too complex

they really need some syntactical sugar for that "if err != nil" stuff like rust's try! macro, i see there are proposals to fix it but i'm guessing the pike cult will have none of it

It makes you handle errors in scope, which is probably a good thing. Although I do miss being able to catch errors from outside the scope of the error. But it leads to sloppy code, so I get it.

How did he kill himself, anyway? Was it painful?

we currently us concourse at my workplace, its shit. It has half the features of Jenkins and in return you get pretty colored boxes/visualized pipelines

almost 90% laziness

>Gofucks all have ADD I swear.
that's a lot of programmers
turns out, it's more fun to start something new than to grind off the rough spots in something old

i'm just talking syntax, a ternary operator would easily fix that 50 character monstrosity

This is the rather jarring difference between professional software development and almost all the the projects on GitHub. Taken to the extreme you end up with the absolute disaster that is web development these days. People learning software right now are being broken and brainwashed to think that dealing with incomprehensible deep magic and relying on 40 dependencies to write hello world is normal.

Meanwhile at my work nobody checks broken shit into master, ever. Our versioning always maintains perfect backwards compatibility, and interfaces are hard contracts that may as well be engraved in granite. You can, with confidence, just pull everything to the latest version and run a build at any time. This is achieved through actually engaging in software engineering rather than just jerking off into a repository. It might feel good to write shit quick, but once you get off you'll realize it's garbage, and to make it not you'll have to do real work. If you abandon your project every time this happens then suddenly you get npm.

Sorry about the rant. This shit has been bothering me for a while.

>Why haven't you learned Go yet?
Cause I know Python and that's all I really need at this current moment. Go isn't preinstalled on any mainstream Linux distro or Mac system, unlike Python

I'm pretty sure you are supposed to defer after you check for the error, otherwise you would be calling close on a nil object.

That's the real problem with having so much boilerplate.

if err ! nil {
// lol no generics
}

still better than exceptions

Go encourages static linking so it doesn't need a preinstalled runtime.

No it's not. It's literally the same thing as having every exception be checked, with more cubersome syntax.

Control flow should be explicit. Exceptions are terrible for reasoning about control flow. Having errors simply be return values makes local reasoning about the behavior of the program much easier.

Checked exceptions are just a shitty version of sum types, which are the ideal error handling mechanism but not particularly mainstream unfortunately.

>muh local reasoning
Same thing with checked exceptions, except they don't erase the stacktrace so you can actually debug what is happening.
But judging from how often I see "if err != nil" even in the standard library, it's obvious that most of the time nothing is ever actually handled and just pushed back up the stack, erasing the context. I'm surprised anyone can use this trash.

>github.com/grafana/grafana
We use grafana at work all the time, and by the stars and forks their github have, I'd say tons of people use it.

Checked exceptions require you inspect the declarations of every procedure you call, it's far more cumbersome than true sum types. It's also more cumbersome than multiple return.

If I see if err != nil {
return nil, err
} in Go, or foo()?; in Rust, I know precisely what is happening in that particular block of code. That's better than the "convenience" of having it hidden away from me in some other module.

KEK. Errors in Go are just fucking strings. How the fuck are you supposed to know what the fuck is happening outside of checking the source code of every possible call downstream?

Literally the same way you do exceptions, by testing a type assertion.

How do you know which subtypes of Error it could possibly be?
So the only advantage is being forced to repeat the same 3 lines of code everywhere just to "be explicit"? Why is there type inference then? They can't even make consistent design decisions. Stockholm syndrome at its finest.

>How do you know which subtypes of Error it could possibly be?
How do you know which exceptions can possibly be thrown?
You can declare that your function returns SomeSpecializedError, or SomeConcreteError. You can build hierarchies exactly like exceptions insist you do, if that's what you're comfortable with.
>Why is there type inference then?
Pretty much every language anyone's using has type inference. Even Java has it now.
Not all types are important to the legibility of your code, so type declarations are optional. Control flow is far more fundamental and obscuring it is much more likely to be a bad idea.

>You can build hierarchies exactly like exceptions insist you do, if that's what you're comfortable with.
Go does not have sum types. You'll have to manually build a type to represent the different types of errors a function can return. Tell me how that is not retarded.


>Control flow is far more fundamental and obscuring it is much more likely to be a bad idea.
You can easily look at a function's signature to see what exceptions it throws, just like how you can look at it to see what it returns when obscured by type inference. Go's error handling obscures it even more by throwing away the context of where the error originally happened. Not to mention obscuring the source code itself by littering it with a bunch of mindless bloat.

If Go had sum types, we'd have a better mechanism for handling errors than multiple return or exceptions. But you take what you can get.

You can capture a stack trace at the instance you create an error. Go has a package for it.

>But you take what you can get.
This only applies if you're working with an old language, not when designing a new one.

Go is deliberately simplistic and familiar. I think it's as useful as it can be while meeting that goal.

My workplace also uses concourse, I find it pretty good personally, it does what you'd expect from it.
The people who maintain it don't seem to complain at all, they say it's better than Jenkins by miles

I don't have a use for it.

github.com/kubernetes/kubernetes
thinking emoji

>nobody uses grafana
don't worry user, one day you'll have a job

Except the concurrency model. CSP vs Actor. Both allow you to spawn millions of threads immediately, though Erlang is battle tested in critical systems, has a nicer syntax and far more scalable

>Erlang doesn't have much to do with go
>Except the concurrency model, CSP vs Actor
literally two different schemes for managing concurrent processes so I think you proved his point

I really like some ideas behind Go, and Go channels are a really great idea.

But consider this Ruby code:
(1..10)
.map {|i| i*i}
.reduce {|acc,i| acc += i}


..and now do this in Go.
Even if we consider strong vs. weak typing and all that, the missing support of any functional features are just a deal breaker for me.

Functional-style programming is so common these days, JS does it, Python does, it, C# does it, even Java started adding functional features recently.

Meanwhile Go tries to hard to "keep it simple and stupid".