Hacker News new | past | comments | ask | show | jobs | submit login

Having used both, I admire Rust as an intellectual exercise, but would write back-end web stuff in Go.

Go is an OK language, not a great one. The real advantage is that you have the libraries that Google uses for their own web server side stuff. Those have been pounded on by billions of transactions, and that the special cases have been handled. There's one well-tested library for each major web service related function.

Rust's libraries don't have that volume of use behind them. Look up "http" in the Rust libraries. You find "Note that this crate is still early on in its lifecycle so the support libraries that integrate with the http crate are a work in progress!"[1] (Rust enthusiasts may comment with a complicated excuse for why this isn't a problem, if they like. That's what the official document says.)

[1] https://docs.rs/http/0.1.18/http/




Your point isn't wrong, but you've linked to a weird package to make it; the http crate is an attempt to standardize some of the types used across multiple implementations. That takes longer than actually building the functionality, as the whole point is that you have multiple implementations, and then consolidate afterwards.

It's also not an "official document"; that's just a package that exists. It's not run by the Rust project.


Rust isn't there for http services yet (if you're being conservative). Come back this time next year and things will be different though.

A nice thing about Rust is that there is so much safety is built into the language that even random libraries tend to work quite reliably.


I don’t think it is necessary to integrate http as a standard library. CGI allows using common wed servers, and there is a separate set of ecosystems around those servers.


You still need most of the http libraries for parsing requests and generating responses with CGI. You just skip the TCP bit.


>>Go is an OK language, not a great one.

This is probably the most succinct and accurate description of Go. It's fairly decent and reasonably reliable at small/medium scale (which is why it is popular among the microservices crowd), but has no outstanding features.

IMO by far the biggest reason it became popular is that it is backed by Google (which makes it a "safe" choice). If it weren't, most people would not have heard of it today.


"Decent and reasonable at small/medium scale" is a weird way to sum up Go in a Go vs. Rust discussion, since Go is deployed at drastically larger scales than Rust is currently. I don't think there's any validity to the idea that Go tops out at medium-scale projects; in fact, a more common argument against it is that it makes sacrifices to facilitate large-scale programming that people don't like.


> Go is deployed at drastically larger scales than Rust is currently.

I think it's important to define which "scale" you're talking about here; Go is deployed at a larger scale in the sense of number of deployments, but both are deployed in production inside the largest tech companies in the world. For example, Rust is now at the core of all of AWS Lambda (and Fargate).

That being said, I do think that "decent and reasonable at small/medium scale" is an attempt at damning through faint praise, and is certainly not how I'd characterize Go in any sense.


Go is doing more stuff in large-scale deployments, processing more traffic, doing more transactions, than Rust is. I don't just mean there are a lot more Go backend projects (there are). I mean that some of those projects do a lot more work than Rust does right now --- I don't mean ubiquitous infrastructure things like Docker and k8s, I mean purpose-built components for specific large-scale applications/platforms.

For instance: "Today, most Dropbox infrastructure is written in Go." Or: "Today Go is at the heart of CloudFlare's services". Or: "Rend is a high-performance proxy written in Go with Netflix use cases [ed: all internal memcache] as the primary driver for development". Or: "The search infrastructure on [Soundcloud] Next is driven by Elastic Search, but managed and interfaced with the rest of SoundCloud almost exclusively through Go services." Or: "How We Built Uber Engineering’s Highest Query per Second Service Using Go.". Or: "Handling five billion sessions a day – in real time [at Twitter]".

I don't see where there's room for a "that said" here.

Both languages are obviously capable of scaling.


Yeah, as mentioned, I don't think that's true anymore. Historically, it has, but Rust has had a lot of high-profile, high-traffic deployments in the last year. But honestly, the high order bit is:

> Both languages are obviously capable of scaling.

This is clearly true, and I agree fully. I don't really want to argue "is this deployment really larger than that deployment", as it's kind of silly. The point is that both have demonstrated the ability to scale to the largest workloads, and so knocking either one of Rust or Go on this axis doesn't make sense.


I like Firecracker too, more than I like Docker (which is, obviously, Go). I don't have any problem with Rust. The parent comment, about Go being suited for small/medium scale programming, was wrong.


PHP is doing more by whatever metric you want than Go or Rust. Does that mean it is better?


That's not the question the thread is discussing (thankfully; "better" or "worse" languages is a stupid message board debate to have).


Proof being that almost no one cared about Limbo and Plan 9 keeps being referenced, while forgetting about Inferno.


If rust had all the libraries you needed. Would it be a better language than golang?




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: