Hacker News Reader

Comment by hardwaresofton | Hacker News Reader

While rust is the safer, and more featureful language, I think Go is quite possibly the better pick for large corporations just due to it's simplicity. Rust to me is the more interesting language, but it definitely offers more power and more choice -- they probably did the right thing by going for Go IMO.

Also really cool to see all the tooling they've built up -- all of the things mentioned seem really cool, "who's gonna clean up all the stale branches" is definitely a question that gets asked (and answered) at more companies that it probably should.

View on HN

I'm a big fan of doing fancy things on CI, so I'm always looking for cool ideas there. This talk seems to mostly be about tooling around dependencies, though, so your comparison to Rust is interesting: Rust's cargo is all-around wonderful IMHO and seems to support everything DO needed and built themselves (incl. multiple versions of dependencies, tooling for mono-repo workspaces, etc.).

Yeah my bet was that they decided on the language first then built the tooling afterwards. Rust person was probably saying the same thing as it was happening...

Rust can be really daunting to look at, and if you compare the rust book to the go language tour, the easiest one to learn is pretty clear -- I get the feeling they won't even regret the choice because the things rust protects you from go sidesteps by giving you slow-but-safe-and-restrictive channels. Go's data race detector also is probably gonna be good-enough for a long time.

Rust wasn't a stable language until much later, when we (DO) were already pretty far along in our Go practice.

Another possible reason: my understanding is that Go works really well for web apps (including the standard library covering http and templates), while Rust isn't as strong there. But I might just have seen less web-focused Rust; are there any good frameworks for web apps in Rust?

In my experience Rust works well as a C/C++ replacement. As a high level language much less so. Go is clearly the better choice for web apps and probably will remain so.

I'd definitely agree that Go is currently clearly the better choice for web apps. I'm not so sure it will stay that way though. Rust has some really powerful abstraction abilities, which can make for super nice apis.

I reckon it will end up like the choice between python/js/php/ruby on the backend, where each have their strength and weaknesses, but none are universally better.

I agree and disagree, for the reason you stated. I think Rust is a good language for web apps, with the caveat that you must understand the syntax and the power afforded first. That makes the language harder to learn, but for the purposes of webapps that makes it better.

If you start from bare micro-framework (set a route, attach a handler), you're eventually going to write some generic function that fetches an entity from a data store. In Go, this becomes a bit of a kludge (interface{} + casting + etc), but in rust it's robustly supported (traits/generic functions).

Of course, if you pick the right library for the database you wouldn't have that issue, but that's just the kind of abstraction/complexity-hiding problem you run into building webapps (from scratch at least) that I think rust is the better tool for. Like I mentoined in another post, basically all the micro-frameworks have the same shape to me at this point: add route(s), add handler function(s), and start the server.

There's a bunch of stuff! https://crates.io/categories/web-programming::http-server

However, it's still very much in early days, so there's no particular consensus, other than Tokio being the async I/O component. Much less mature than Go. We'll get there!

The first one I ever saw was iron (https://github.com/iron/iron) -- weirdly enough, it's not on the list @ https://crates.io/categories/web-programming::http-server.

I wouldn't think that web frameworks were the reason -- at this point, almost all the frameworks that aren't django/rails size are the same, set up a route, add a handler, do whatever you need to in the handler, start the server.

python's flask/ruby's sinatra/go's http.server/rust's iron/haskell's servant/clojure's ring are all the same to me at this point, and generally what I'm comfortable starting with (I pick those micro-frameworks over 'batteries-included' django/rails)

It's not on the list because the categories feature is new, and Iron has had maintainership issues, where people have not been able to publish a new version. So it hasn't had a publish including the category since categories were introduced.

Many big companies are shipping Rust. There's ones we know about, like Oracle, and there's ones we've only heard whispers of, like a poster on the Reddit who claims they are shipping Rust at a Fortune 500 company.

That said, Go makes sense for a lot of the things DO does.

What's Oracle doing with Rust?

Writing container runtimes https://blogs.oracle.com/developers/building-a-container-run... (Github link at the end there)

and https://github.com/oracle/crashcart

Neat! Oracle, being the epitome of Enterprise, is the last company I would have expected to see using Rust and containers; nice to be proven wrong :)

EDIT: typo

Well Oracle was the last big company to join Cloud Native foundation. They have realized that Kubernetes, containers are becoming new standard layer of infrastructure. Combined with fact Oracle donated JavaEE to Eclipse foundation, effectively washing their hands of legacy tech.

I also think Rust is the more interesting choice, but the company I work for went with Go. It does seem to be the more popular choice.

Yeah, Go being stable earlier, plus being so simple is great for its adoption. That said, Rust and Go have some overlap, but also areas where each is clearly the better choice. There's no reason this needs to be a zero-sum thing!

Yeah, they both have their use cases and they can both be popular equally. It's all about looking at the problem in hand and deciding what do you need to solve that problem.

Go is becoming the new Java from what I can tell so it's good to know enough to find your way around and patch a Go project if needed. Being the new Java, despite being less expressive, explains the uptake in the enterprise and startups.

Pity it is the new Java 1.0, instead of being the new Java 9.

If Java had good AOT and fast startup coupled with comparable initial GC heap sizes, it could have had a better chance at fighting off Go. Java will not go away and many teams that adopt Go also migrate to other languages at some point if their projects outgrow the capabilities of Go and the pain gets too strong.

I'm partial to GHC's language extension model over a cornucopia of Go pre- and post-processing tools like Java had (e.g. AspectJ and all the tools making use of annotations? or Go processors using comments). It will be easier to improve GHC's GC or complete OCaml's multicore branch than bring Go to the current century of proven programming language features. Go has found a niche as a replacement for C and Python in network programming, which is great. It just doesn't scale as well with project and team size. OCaml's multicore project also introduces algebraic effects (comprehensive alternative to monadic programming) to the mainstream, so I can't wait for OCaml multicore to land in mainline.

Java has had AOT support since version 1.0, available to anyone that understands the value of paying for our tools, just like in any other profession.

For those that rather get everything for free, OpenJDK has initial support of Linux x64, with other platforms being already available on OpenJDK 10 master.

Go has become pretty big in China, and it will only grow around from now on. I wish Rust will reach the same critical mass.

Reply on news.ycombinator.com