Hacker News new | ask | show | jobs
by jpgvm 2240 days ago
Reasonably high. There is a good deal of frustration with Go from experienced programmers that worked with it for several years and grew tired of the tedium involved.

Rust has some obstacles to overcome to supplant Go on a wider scale though. Namely compile time and learning curve - especially in relation to concurrency and async which are key features to replacing Go as it's main draw is it's green runtime.

3 comments

I'm not seeing that. It seems like there's lots of enthusiasm to use Rust, but that people can't justify choosing it over Go probably because Rust is quite a lot more tedious than Go and its strong performance and correctness guarantees aren't worth the tradeoff for very many applications. I'm hopeful that things like rust-analyzer will help close that gap, but I don't think it will ever completely close much less reverse.
This is true. It's worth remembering why Go got it's shot though which is at the time of Docker being written it was originally written in Python. A few members of the container/orchestration community pushed to try writing it in Golang as Golang was also new and combining the enthusiasm of 2 communities was likely to result in greater success (turned out to be correct).

On the other hand Rust hasn't had an oportunity for a killer app, in fact it's main sponsor project Servo/Firefox is pretty much the opposite. It's a browser, the definition of a complex and slow moving behemoth of a project.

I attribute Rust's slow takeoff compared to Go mostly to this phenomenon.

After Docker was written in Go and started popularising containers outside of the lxc/openvz/other hardcore guys doing their own stuff directly on top of the kernel APIs then it was only natural that stuff would want to integrate with Docker and using the same language was a way to capture some of that enthusiasm. This resulted in software like Flynn, Deis and Kubernetes all picking Golang. The resulting network effect is very strong.

To some degree this is also down to the strength of the Go standard library. It has an excellent HTTP and TLS stack, encoding/decoding etc. All of this made it a good fit to write software that is fundamentally fairly "dumb" quite quickly. i.e software the mostly shuffles bytes from one socket to another.

Rust will most likely not find such a killer app so I think people need to be realistic about how long it will take Rust to find a marketshare. The big difference though is one can actually make good arguments to use Rust over C/C++ where you can't in most cases for Go. C is the largest software ecosystem right now and Rust is best positioned to take some of this market share away.

Rust's killer app will come from OS vendors support, like Microsoft and ironically Google (Fuschia and Crostini).

However while I like Rust, it seems that it will become more of a C++ companion than a replacement, as it will take quite some time to get a foothold on systems where C++ is finally replacing C as of the last decade.

Go has no expressiveness to it. You end up either with a large pile of copy pasted code, code generators, or massively error prone runtime introspection. Go blows up the entire idea of Don't Repeat Yourself. The language actively encourages it.
> Go blows up the entire idea of Don't Repeat Yourself.

Yes, this is true. I programm in Go professionally, about 50% of my work time (other half is python). But in many cases, I have found that copying the same code to other places doesn't have that much negative consequences as one would believe.

Refactoring becomes intensely burdensome, often to the point that it is avoided at all costs. Not a great situation when you need to iterate on a design.
So I'm almost certainly in a different industry (embedded) where EEs tend to prolifically copy+paste code. In the end this always makes it so that a change that should take very little time consumes an entire workweek or more. So I have a seething hatred of this practice from past experiences.

I suppose I should say that there's a lot of different types of duplicate code, some of which really don't matter per se. Sometimes two bits of code are basically the same but are completely unrelated and as things change they will diverge, i.e. it was just incidental. Code that is duplicated with a strong functional relationship make changes a nightmare though.

Concurrency and async in Rust has improved a lot as of late. See https://areweasyncyet.rs for an overview of this space.