I have to second this as well. What’s even better is if you require more detail on a subject, there’s often a link to another well-written, detailed Go article.
I completely agree - I've worked through most of this as well and I feel it is a really great way to introduce someone to the language. It seems to me that a lot of languages would benefit from this style of tutorial or introduction.
> Receivers always block until there is data to receive. If the channel is unbuffered, the sender blocks until the receiver has received the value. If the channel has a buffer, the sender blocks only until the value has been copied to the buffer; if the buffer is full, this means waiting until some receiver has retrieved a value.
We switched from Python to Go over 2 years ago and it's been an amazing improvement in terms of performance as well as developer productivity for building high traffic endpoints.
That depends -- it defaults to "auto" which means that its enabled outside of $GOPATH but disabled inside it. If you're working on a project that makes use of "go mod vendor" and is built from within your $GOPATH (which is true of quite a few free software Go projects) then you'll need it.
I have made very good experiences with the GTK bindings for go (https://github.com/gotk3/gotk3). As the GTK Api is C-Based, it fits conceptually very good to Go. Actually I consider the Go bindings even better than using GTK from C, as the thin object model GTK uses, translates well to Go structures, most functions become methods on those structures. And the Go garbage collector solves the memory handling of the GTK structures.
I love reading articles like this. I really want to find a good work related reason to learn Go, just not a thing right now.
My main concern with the article is the massive abundance of typos. Like more so than a normal article written by a programmer. They make me stop and double check if I read it wrong, it is a term or something I haven't seen before, or just a typo.
I wosh I had time to learn new languages as I used to... but with 2 kids, one being 4 months it is nearly impossible. How do others devs hungry for knowledge deal with situations like this one?
Go is a language you can pick up in a relatively short amount of time.
The syntax is in the vein of C and Python, so it's probably familiar. The language itself is fairly small, and the focus is on simplicity over expressiveness. If you want to learn new languages but have limited time, my answer is to take a look at Go.
With two young children, try to get enough sleep. All learning is more effective when you get enough sleep.
With that in mind, spaced repetition is a great technique that fits with having limited time in small blocks. Squeezing in some time here and there becomes a strength instead of a weakness.
as my time for learning new programming languages is limited, I would invest it in learning Rust, rather than learning Golang or learning both of them.
IMO the only reason to learn Golang is if your already have a legacy Golang codebase or if you want to contribute to various open source projects written in Go, like for example Kubernetes (my first experience with Golang was trying to compile a patched Hashicorp project).
It's the same as suggesting to a front-end dev, skipping Backbone, Ember and Angular and going straight for React.
There are lots of overlapping technologies in our space and learning all of them is a huge time waste.
> There are lots of overlapping technologies in our space and learning all of them is a huge time waste
I agree.
That's why I invested time into looking at Go over Rust.
Go will be the better choice for most programs most developers will write. Go 2 even more so. Rust is too complex, and for the applications where a garbage collector is acceptable (>99% of them) it isn't worth it.
I agree. I would guess the "why" is that Rust is capable of everything that Golang is capable of, except more and better. Not to mention that Rust has a very supportive community to help each other.
After using Rust for about a year on the side, I get the feeling that it's not quite mature enough yet in some places. On the other hand, I also get the feeling that the development of the language itself has been measured and careful which could also be seen as a bit slow.
On the other hand, I hear good things about Go across lots of people I work with although I've yet to sit down and give it a meaningful try. But I also have concerns about the maturity of a language who has jumped to V2 in what seems like a relatively small amount of time.
I'm inclined to believe both languages have lots of promise and could easily be the future of software development, but I'd be hesitant to pick either for a project that needs to be maintainable for a long time in case the language changes too much and leaves you with technical debt.
> But I also have concerns about the maturity of a language who has jumped to V2 in what seems like a relatively small amount of time.
Where can I download Go v2? Latest is tagged 1.13beta1
Go authors stated multiple times that there are no plans for a Go 2 at the moment. They rather improve the language in small increments breaking as least as possible.
> Go authors stated multiple times that there are no plans for a Go 2 at the moment.
There are plans for Go 2[1], Russ Cox has written blog posts and given talks about design improvements for Go which would go into a Go 2. There isn't a roadmap (yet) but this discussion has been going on for the past year or so[2]. They talk a bit about next steps in the most recent blog post about Go 1.13[3].
They're talking about "Go 2" the brand, not Go 2.0 being a new major version having breaking changes to Go 1.x. There are no plans for a breaking-changes Go 2, only occasional additions to Go 1.x under an ongoing "Go 2" developer relations effort.
There was discussion of a breaking Go 2 in the early days (though it would be opted-into by individual modules -- similar to the Rust edition system but with more significant changes). I think the plan now is to only have minor breaking changes -- the originally-proposed (outright breaking) syntax changes aren't in the current proposals.
But yes, the current Go 2 proposals are much nicer than the originals. But they do still contain some subtle breaking changes (though they have said they'd add vet warnings beforehand so it shouldn't be too bad).
Clearly there's more to it otherwise Go and other languages would be a thing of the past.
This is really not a topic for language flamewars and it's even against HN guidelines. I don't understand why people need to scream rust in every other language post like if it was a religion.
Devil’s advocate here : i think it’s due to the promise rust makes that borrow checkers prevent you from writing unsafe code or race conditions, as well as high level abstractions with zero performance cost.
That set of promises really would make any programmer go crazy i think, and become a zealot.
Rust is definitely on my todo list, i’m just waiting for the language to mature a little bit more, because some edges still seem a git rough. But i am extremely enthusiastic about it.
No language is a thing of the past, since there are lots of projects and codebases written in it. Hell, people still using PHP and Perl. But they are not the first choice for starting a new project.
What will happen is that with time no greenfield project will be started with Golang and it will gradually become a legacy language.
> Go - The most promising programming language. Go started out with a share of 8% in 2017 and now it has reached 18%. In addition, the biggest number of developers (13%) chose Go as a language they would like to adopt or migrate to.
Not really defending the vague statements of the person you're replying to, but I'd take those surveys with a giant grain of salt. There's just too much selection bias at work. I for one struggle to imagine how any company could ever induce me to take one of these surveys, and I doubt I'm that special a snowflake. 49% of devs have used python in the last 12 months? And 50% java? Huh? Who are these people?
Probably the best we can do is analyses such as github's [1], which doesn't rely on people responding to marketing emails to reach a conclusion - but I'd say even that is very far from the big picture. Most large IT organisations still run their version control, for example. Hell, I'm still coming across PHP and JS programmers in 2019 that don't use any source control. Professionals. At agencies. Yeah.
None of this is to rain on golang's parade - it's a solid language IMO, despite the hype around it encouraging many people to, again IMO, optimize prematurely. Just to remind that an output is only as good as its inputs.
Fully agree, but I find surveys better than intuition.
On that matter you'll find plenty of Rust advocates referring to SO's survey stating it's the most loved language. They will however try to downplay surveys which report that Go's adoption is far superior and distancing.
With that said I find comparing Go and Rust an exercise in futility since the usecases rarely intersect.
The only way to know that you have previously had 'good intuitions' about the future would be if you recorded them (memory doesn't cut it) and then compared them with a subsequent events. Then you'd have to find a way of demonstrating that past intuitive success is an indicator of future intuitive success. Unless you've done all this, you only have an intuition that your intuition for future trends is good.
Everything but being easy to learn, and having low complexity.
Don't get me wrong, rust is an amazing alternative for C++, but golang is not targeted at that problem space.
It's aimed at highly concurrent networked applications with a high feature turnover and large teams with varying seniority.
In those areas development speed is more important than execution speed, and I'd take a few GC pauses over fighting the borrow checker any day.
Plus rust ist still lacking a good concurrency story, which is spot on for golang.
I would disagree. Rust and Go occupy very different spaces. This is like saying "skip the car, take a rocket ship." Sure, Rust will go faster in some circumstances, but it's a hell of a commitment.
I think the main takeaway for me from watching the YC Startup School videos was that doing a unicorn-scale startup vs a small business initially takes about the same effort for the founders.
So, why would you choose the latter then?
Developer investing his/her time into learning a more limited programming language is like a founder investing his/her time into a limited upside opportunity.
The initial time investment is roughly the same, the expected upside is very different.
Off-course there are lots of people who are using GoLang (similarly to JS) without learning it properly first, but in the long time it will bite them. In order to truly master any programming language ecosystem one need to invest at least half a year anyways, be it GoLang or Rust.
Similarly some people rushing to start startups without learning entrepreneurship first and/or bothering to research the problem domain and their competition.
I've been learning Go these days and have enjoyed it quite a bit. Rust is also on the menu this year. Aside from the Rust book, do you have any suggestions on learning material?
Go's not existent standard library is almost a deal breaker for me.
The lack of even a dynamic array (c++ vector, Java arraylist) means you write a lot of 2-3 lines of slice notation phrases that require stopping and thinking about indices you wouldn't need to in other languages (and creating a lot of zero length slices for boundary conditions that shouldn't be needed). Also no balanced tree is a big issue (googles side implemention sucks in that the comparator cannot be passed in).
I recently tried to write some small library functions using sqlx to do arbitrary sql queries and then some munging of the results before returning it. It was extremely difficult.
The language feels half done at times. I find it hard to believe that Google used it much internally before releasing it. So many unfinished corners.
Generics would go a long way to fixing some of these issues.
While the ahead of time compilation is nice and had lead to me using it for things that need fast startup (some shell like scripts and literally old school cgi), it often seems like a worse Java.
If you don't like Java's verbosity, go's from my small use is about twice as bad. 300 lines of go does surprisingly little - part of this is gofmt's fault though.
Also, does anybody know of good performance tests between Java and go? I mean like well written and optimised. Most tests over I've are very poorly written and do dumb things like include hotspot startup and compilation times. Hotspot can generate some very slick code, but it just takes 10k passes to get up that point.
I (and seemingly other people) consider https://www.techempower.com/benchmarks to be a good set of performance benchmarks for use cases many people around here would be facing. I guess they haven't been updated in nearing a year though. Go does reasonably well but apparently gets beat by Java.
More generally. I like the idea of community driven benchmarks where each community tries to make representative, performant samples to realistic problems. All too often you get an expert in one language making a benchmark against a language they are not experienced with and getting really improper results.
I don't do any a lot web stuff but most of my go code is quick hacks for data analysis or display but this is still really interesting.
I had a feeling go was slow, but I didn't expect such poor performance numbers. Some of that is probably the heavy reliance in reflection. For example they json parsing you need to go to the bottom of the list to find a go program, and go's json library makes extensive use of reflection and tags to guide the parsing.
It is somewhat ironic that go's big feature was AOT compilation static type checking, but it seems to immediately devolving into reflection and parsing tag key value strings to do anything. I had a typo on one of those they other day and could find the bug for an hour.
The page you link to [1] shows Go at 9th for Plaintext (87.9% of the leader), 21st for JSON (96.8% of the leader). Which is still not ideal, but is a long way from abysmal.
Compare it to the Java standard lib: concurrent data structures, proper generic structures (tries, priority queues, etc.), GUI libraries, annotations (JPA, nullability, etc.), management, sound, etc. and you'll see what's missing.
They are, but also very difficult to work with. For example, removing an element is a copy, followed by a slice notation. Inserting is combination of appends and slice notation. You don't get simple methods like insert(index,item). Also if you are growing the slice in a function, you need to find a way to return the possibly new slice variable since append might need to realloc so you often have to resort to using pointers to slices as inputs. They just aren't easy to deal with.
And you can have memory leak issues if you forget to zero a reference since the backing array still holds the reference. And none of that is efficient. A lot of temps and unnecessary copying going on.
> You don't get simple methods like insert(index,item).
This is by design, to lift the CPU and allocation costs to the foreground. You can argue that was a bad design decision, but it wasn't an oversight, as you imply in the OP.
So the AOT makes that more difficult I'm guessing? I think that go does heavy lto so shouldn't inlining at link time give the same opportunity for that?
Java's escape analysis has always been dodgy to rely on. I've had some very simple code when I couldn't for the life of me figure out why the allocations weren't being hoisted. So I don't know if gos is better or worse.
It most definitely was not an oversight, clearly intentional but I think the issues could have been solved in better ways. Better use of lto and intrinsifying some functions in slices would help a lot.
Vector operations are extremely common. Go's making them difficult to use and refusing to optimize them (lto, intrinsics, etc) just seems poor.
PS: because of the score of my top level comment I've been rate limited pretty aggressively and can't respond anymore.
(edit: exactly what sagi said, only more long-winded) :
Removing an item from a list (that is actually performant enough that you'd want to use it) in Java is also a copy though, unless you're removing the last element. Underneath the hood, there's a copy. Same deal with insert.
Given the number of times I've seen insert or remove used where it really, really shouldn't, I'm not so sure the lack of insert/remove is a bad thing.
But yea I do get that general feeling that golang sort of... distrusts the programmer. Like the opposite of C++, where it assumes you're God, but then happily vaporizes you with God-powered-lasers.
> Given the number of times I've seen insert or remove used where it really, really shouldn't, I'm not so sure the lack of insert/remove is a bad thing.
Heavy reliance on such, as if they were free, is a very scripting-language thing. They hide all the grossness of such operations at the cost of significant memory bloat and inefficiency with simple, known-size structures (in order to make the more dynamic style run semi-fast at all).
There's no magic, and none of it's free, it just feels like it when you're push() and pop() and insert()ing all over the place. Making string manipulation closer to its roots as an array is also nice, in Go. If it's not worth bringing in a whole heavy library to deal with the awkwardness, then it wasn't worth writing the code that way to begin with. Figure out your lengths, resize as little as possible. Abuse and/or ignorance of how this all works is a big part of why we Can't Have Nice Things (performance, battery life) in the Age of Javascript.
Heyyy another thing (and certainly I've done this myself) used incorrectly in such a way that it is extremely expensive. Specifically, concatenating log strings inside a large loop in some handler, and then not actually using those log strings because the production server didn't log down that low - but still incurring the cpu cost of the string concatenation.
0: https://quii.gitbook.io/learn-go-with-tests/