there seems to be quite a few people suggesting that go is the correct choice for every task. the article is a sorely needed voice in the HN echo chamber.
personally i'm waiting for rust, go is nice but not better enough than python to justify switching - especially when you consider maturity of third-party libraries.
> the article is a sorely needed voice in the HN echo chamber.
> personally i'm waiting for rust
See, this seems weird to me because Go is actually a language that you can build nice things with right now. Check out coreos's etcd[1] for example.
Rust on the other hand gets a lot of adulation in this echo chamber but is so, so far from completion that you're going to be waiting like a decade or so before you can do anything networking related with it. And personally the varying clumsy degrees to do the same thing many different ways in Rust (the various boxing and unboxing and other memory handling options) are a real turn off.
Comparing Go to Java is fair, and of course Java will come out on top given its maturity, but Go offers a lot of good things. Comparing Go to Rust is not, Rust is not ready for any kind of real world use.
you're going to be waiting like a decade or so before you can do anything networking related with it
Not true. My 'learn rust' project is pcap-based and has a trivial websocket implementation, and (after the basic learning hump) it's dirt easy. Aside from how simple it is to interact with C, Rust's current networking stack is libuv under the hood (i.e. same as node), and if you don't want libuv, native implementations are landing now.
I'm going to go ahead and be sceptical of a repo with 3 stars and more tests than working code. I doubt it works, but I didn't try it. It looks like it just wraps open-ssh libraries. It's probably going take more the 3 lines of go it takes now to create a secure wss websocket connection if you use that. I'm going to guess you'll be doing all of your own cert validations and what not once it does work.
EDIT:
It's not petty to point out that a brand new repo that doesn't look like it works, has zero documentation has been seen by a handful of people is not a good example. This is for secure code. SSL. It's pretty important to get right. This isn't a a repo for a JavaScript accordion widget. It's SSL in Rust. I'd like to see SSL in Rust. I want Rust to do well, there's nothing petty, you're reading my tone wrong. It's hard to read intention over text, assume better than you are. I've been sitting in #rust on mozilla IRC for nearly a year watching them develop the language. I'm not just catching up on the latest by reading HN.
As for jfager's a decade vs more than 3 lines rebuttal: read my other responses where I specifically qualify on using C libraries. I am going to going to go ahead and guess you haven't done much raw SSL stuff. It is a ton of work. We're not talking 5 more lines of code. We're talking thousands of lines of code, and that it will be a decade before rust catches up with go. That's just an anonymous commenter making a shitty prediction that nobody will call me out on. My point is that Rust isn't ready. Go is. Stop comparing Go to Rust. Rust doesn't work yet. Don't use it unless you want to help develop the language. All you're going to learn is how to work with a specific half implemented language that can't do basic things yet. Read my original post. I don't hate Rust, I am contrasting the HN echo chamber to love of a language that you should not be using for anything right now. This is not a controversial statement, it's right there in a big highlighted disclaimer on the rust reference manual[1].
Yes, it's just bindings to open-ssl. Yes, it's probably a little clunky to use. But we just went from "a decade or so before you can do anything networking related" to "ssl takes more than 3 lines". I can live with that.
Yeah opening up TCP connections and reading plain text http isn't hard, but there's no way to do any kind of SSL https requests with servo, which is kind of a nice thing right. And that's going to be a long long time before you ever see SSL. Have fun with those C libraries.
> See, this seems weird to me because Go is actually a language that you can build nice things with right now.
i'm not denying that! in fact, i've written a couple KLOC of go code to make sure my gut feeling is right. it's a nice language and i kind of like it, but i'm much more productive in python where pretty much everything has a library written for it.
(python would certainly benefit a lot from channels/select as a langauge construct, if the GIL could be worked around.)
What is really weird is how often Go and Rust are compared, period. Their designs seem to be different in almost all ways and, as you say, they don't even coincide when it comes to maturity.
Not even that, but you can't compare the main devs with Go to Rust in terms of personal accomplishment. Rob Pike who made an entire operating system at Bell Labs and has published quite a bit. Every programmer should go read Rob Pike's regular expression parser, that he wrote in like an hour and is published and annotated in the book Beautiful Code. Brad Fitzpatrick who made memcached, openid, and uh LiveJournal, Russ Cox also from Bell Labs, and many others. It's an all-star team operating under Google's demanding auspices in an ivory tower of unfathomable wealth, servers, needs and technology. These guys aren't novices, they're not going to make a shitty programming language. If you are unhappy with some part of Go (as I am actually, I'd like interfaces to know about properties as well as methods but maybe that's weird) they've probably thought about it and have a good reason for whatever choice they made.
too true, if you want a fast, simple scalable network thing then look at GO, otherwise don't.
I would also say if your handing over code to another team to support and they don't know the language and the only reason you are allowed to do it in that language is they couldn't think of any objections that you can't bypass then don't use that language!
