Summary: “Go is not Rust”
The author is correct. However I did not find anything more useful in the article than that summary. The article is not an objective comparison of the pro’s and con’s of each language. Nor does it explain or link to any detailed rationale for Go.
Nevertheless, it persisted… in keeping me reading.
I don’t think it was attempting to be an objective comparison of the languages, but instead a look at how a more expressive language with similar anti-C++ values could produce solutions more in line with how they solve problems.
Still, there’s nothing novel here, but the same can (and should) be said about Go. It’s not novel, and it’s mostly a pain in the ass to work with, but nevertheless, it persisted… in acquiring more and more developers.
It’s like Perl in the 90s. Fills just enough gaps for people to adopt for serious work, will power more and more of the Internet, but will ultimately be replaced by something that provides more expressiveness with better safety guarantees. That may or may not be Rust, or some other not yet mainstream lang, of course.
mostly a pain in the ass to work with
Exactly how I feel about modern elaborately typed languages. Horses for courses.
Agreed, hopefully all of today’s languages, Go and Rust included, will be replaced by things far, far better.
tl;dr: another go “does it wrong” post, with the ever repeating same points: “nil is bad”, and “i want generics”.
and it feels a bit like the rust evangelism strike force (http://n-gate.com/).
[Comment removed by author]
Though I hate n-gate very much (it has a predictable, boring, insulting kind of humor that often doesn’t have a point, only a target to put down), I felt very honored that Rusts active blogging and speaking community is a target of their hate :).
Sorry, haters, our marketing is good and that’s no accident :). (And yes, sometimes people write not-so-stellar blog posts. Comes with people writing a lot.)
Sorry, haters, our marketing is good and that’s no accident :)
Mentioning Rust at every blog post remotely related to programming languages is more annoying than marketing. It was the same with Rails before. (For the record, I don’t hate Rust, I just have no use for it as the niche where Rust is genuinely useful is quite small)
I actually like n-gate, because it shows how self-inflated posts on Hacker News often are, where people celebrate the most trivial things. It goes to the extreme for comedic effect, but I liked it more than lkml.wtf.
We don’t write the blog posts. Sorry for the high interest from people to mention it.
i guess the insulting kind of humor is more targeted to the not-so-stellar blog posts than at people just enjoying rust.
at least that’s how i read it.
Read, for example, the FOSDEM section of the page. It’s full of bile. Example?
JRuby in 2017 […]
I don’t know what kind of psychopath deliberately chooses to interact with Java, Ruby, and Rails at the same time, > but it’s probably not a coincidence that the speaker’s name is listed as “Nutter.”
Haha. No, that hasn’t the slightest bit of “making fun of poor blog posts”.
i skipped through the fosdem section, some things made me laugh, others not, some are full of bile. picking on ones name isn’t good style, i agree.
the rust evangelism strike force wasn’t my idea, it’s from n-gate.com. credit where credit’s due ;)
I read that as “rust evangelion strike force”, and my mind went to…weird…places.
seems i was late with my rant ;)
Thanks for link to n-gate. Hilarious.
If other want to subscribe too, the Atom feed is broken, but RSS is fine.
I can’t wait until this dude makes fun of Unix Fundamentalists. You know, the type that might use a web framework written in the Plan 9 shell. Any day now, I’m sure
On a more serious note, I hope linking that site won’t be the new “relevant XKCD”
I hope that doesn’t sound too bad, but the Go and Rust communities both make me sad. I find both languages super interesting and even use Go for productive work (my day job), but the “Go is not X” people that sometimes jump through hoops to crate libraries and framework to make Go another language is really saddening.
Yes, you might have been overruled by other at your job to program in Go, but trying to make Go Java or Node.js just misses its point and honestly, I think if you are forced to use a programming language you dislike so much that you essentially ignore it you might have a way better live quitting and either joining another company or do your own thing. Doesn’t have to be the next big thing, but even consulting, etc. for what you really understand, like and enjoy.
If you want Rust, that’s totally fine. But saying “X is not Rust” and following with something along the lines of “X should be Rust” is just bad.
I write this cause I really wished that programming languages didn’t have those non-technical wars around them them and that there would be a lot less “X is bad, Y is great”, especially with new stuff. Yes, IT moves quickly, but a programming language that’s less than five or ten years old is new and certainly nothing that won and makes everything else deprecated. Deprecation happens a lot less frequently than a lot of news (often backed by a marketing department) wants you to think.
Now, I wanna make a point by suggesting to look at Google. Yes, they did Go, Kubernetes and all that fancy stuff, but also look at stuff such as BoringSSL or read the Site Reliability Engineering book. This is the opposite of going with all that “Serverlesss Cloud as a Service written in Foo” is about. It’s essentially the same virtues of quality software and quality services (as in System Administration/SRE/DevOps/…) that have been considered good for decades now. It isn’t like automation, reproducible setups, virtualization, monitoring, logging, etc are new.
And back to programming: Yes, Go and Rust are great, but what’s great about both of them is they don’t really invent something new. That might be shocking, but they both are essentially based on the new bits of meanwhile rather old languages that had enough time to be proven great. A lot of what both languages have exists in some way or another in libraries, frameworks, compilers, interpreters, general patterns in other languages for ages now.
People often say Go and Rust are not contenders in certain fields (there are areas where GC is not an option for example), but they are also not contenders for the “one true programming language to rule them all” and the great thing is that its authors seem to realize that, which is also a big reason why former C/C++ only programmers at least look at them. A lot of those people are long enough in the area to have seen many “promising heaven languages” come up and pass away again, or at least not gaining enough traction.
However, in the area of traction at least Go seems to have enough interest to not die quickly(!) again. Does that mean anyone will consider it worthwhile to look at it in 5 to 10 years? I don’t think it’s reasonable to make such a prediction. Same for Rust.
But what I would argue for is to let programming languages go different ways. If the outcome of this decade would be that “all the programming languages in that area kinda tried to make this and that with a little different syntax” that would be pretty saddening, but Rust and Go both lead very different paths and that’s a good thing, so embrace that. And if you don’t care, then what’s the point to write that they are different? As others pointed out a “Go is not Rust” is enough to say the same thing.
In other words: The article is well written and it’s in general a joy to read, but it’s not really getting anywhere. Maybe the title is a bit misleading to, but hey, catches people. :)
Re: lack of compiled-time checks for unhandled errors, there are some third-party checks that are super useful to have around. The Go team’s go vet and golint and the third-party errcheck, ineffasign, and staticcheck pick up some common issues. You can run gometalinter to run a bunch of checks at once (but you’ll have to pick your checks; I find the defaults wonky). Dynamic tools like the race detector, go-fuzz, and the various testing and performance tools are good to know about, too.
Currently the language team is mostly focused on stuff far afield from spec changes. There’re still some big opportunities to improve things like optimization (some inlining work happening now), GC throughput, compile times (move towards Go 1.4 speeds), and official libs and tools. Those can benefit lots of existing users and codebases.
I also like external, community work even when it seems to route around the spec; static analysis and codegen tools and libraries with more abstract concurrency goodies are all cool. The packaging discussion is solving real problems a lot of folks face. Languages widely used in the wild have some good reasons to change their specs very slowly/carefully. The outside work may feel too ad-hoc to be ‘real’ progress, but I think it’s something to embrace.