This is wrong. https://golang.org/doc/effective_go.html#channels
> 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.
Also there are ways to talk back and forth with Electron for front end.
Full disclosure, have not tried either but just looking around as I get into Go.
I do a lot of web dev so like idea of HTML/JS for front end. I know I know, Electron is awful but maybe less awful if it's light?
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.
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 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.
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.
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.
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.
There are plans for Go 2, 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. They talk a bit about next steps in the most recent blog post about Go 1.13.
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).
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.
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.
I suspect that is one of the reasons why behemoths like Uber, Twitch.tv, Stripe and Walmart chose Go over Rust.
What will happen is that with time no greenfield project will be started with Golang and it will gradually become a legacy language.
Specially when they go against data https://www.jetbrains.com/lp/devecosystem-2019/
> 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.
And this https://research.hackerrank.com/developer-skills/2019
> Go is the language that developers want to learn the most in 2019
Probably the best we can do is analyses such as github's , 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.
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.
Unfortunately I don't have data from the future, but I do have a good intuition about the future trends ;)
It's intuition all the way down.
That's exactly what it is like saying. Sure, some people might not want a rocket ship. That's fine. But that is the logic behind "skip go, take rust".
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.
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.
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 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.
In real code that I write, most projects never import reflect. Sometimes I import it in tests.
golang ranks 108 and 121 in the plaintext and JSON benchmarks, which is quite abysmal.
Are go slices not dynamic arrays? They grow automatically when necessary.
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.
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.
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.
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.
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).
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.
I don't work there, but I don't think it's used internally in any significant manner at all. Most development there is done in C++, Java, and Python.