Hacker News Reader

Comment by blub | Hacker News Reader

Because they are competing with eachother!

Unless Rust wants to position itself as embedded-only it will compete with Go for higher level tasks.

No they're not. Go is very easy to pick up, Rust is not. That point alone should be enough. Without prior knowledge of both, no sane person would consider writing a browser-engine in Go, and yet that's exactly what they're doing with Rust. Just as no sane person would pick up Rust to write generic web services in that scenario.

Put Rust and Go in front of a python coder who wrote dozens of web services using flask - and I am pretty sure I can predict what tool he'll pick. Sure you could write web services in Rust, that's not what I'm arguing, learning Rust for writing stuff like that is simply not worth it for people having to write such services.

Rust's complexity is comparable with C++, and the main reason for this complexity is to address problems that are mainly seen in C/C++ applications. Rust's reason for existing is simple: modern low-level language with built-in (memory) safety with no performance trade-offs (implying concurrency support etc). That makes it squarely aimed at C++, where developers accept the complexity as a trade-off for performance.

Go's reason of existence and goals are completely different, it addresses the gap that existed between compiled and interpreted languages. It wants to be a simple, safe, easy to deploy language that offers more performance over classic scripting languages and thus is able to address more performance-critical issues. It's main target is clear: servers and networking services, where a GC's impact less important due to the I/O bottlenecks in most scenario's.

> Just as no sane person would pick up Rust to write generic web services in that scenario.

I agree, but that's the thing... people DO advocate for that!

http://www.arewewebyet.org

Of course, there's a lot of double-talk on the subject. "You can TOTALLY do it today!" ... "Eh, but maybe you wouldn't want to use it PRODUCTION today" ... "But we're just a FEW more crates away from being there!"", etc. The Rust community is great, but they seem they hedge their bets too much and are murky with the messaging.

Right or wrong, Rust and Go compete because there are a LOT of web and microservice developers out there (including me) who:

1. Love what Go brings to the table in terms of of type safety, and AOT compilation to single-file native executables...

2. ... but wish that Go had more functional-style constructs (filter, map, immutability, etc), generics, a contemporary package system that doesn't involve putting Git URL's in your actual source code... or any of Rob Pike's other stubborn alien quirks that people don't like.

Rust can't quite figure out whether it wants to market to this crowd or not. Sadly, due its learning curve, I DON'T believe that Rust is the answer for the "Go, but with more popular features" problem. But enough people aren't ready to concede that yet.

Rust absolutely does want to market to the web services crowd. They said as much during their year-end conference. The whole push with futures is partly because of that. This year you'll see a lot more development in the web arena. I realise this messaging is probably what you've heard already, but I believe when futures are integrated into the backend frameworks you'll see some really competitive offerings.

The question of Go or Rust for something like web services is not as clear cut in my opinion. I have JavaScript/PHP background, and have recently learnt Rust for just this use case. Rust is slightly more complex (but really not that much, nothing close to as bad as C++), but also offers more correctness guarantees. Both are good choices, hence these discussions.

Long time C++ developer here, have written a few toy programs in Rust, and am in the process of re-writing some stuff at work in Rust (from python).

My opinion is that Rust is at least as complicated as C++. They have different complexities, but one isn't "easier" than the other. I enjoy Rust a lot. More than C++, at this point, but that may be the "newness" factor creating bias. I think Rust is likely a better language for people new to systems programming to pick up. It's complexities are largely up-front: a novice will learn how to program well in Rust by having the compiler break his teeth a few times, while for C++ she'd either have to have high-quality mentoring or else learn the hard way (by long experience).

Even if Rust were as complicated as C++, with its ridiculous number of interacting features and backwards compatibility constraints, it manifests very differently: the Rust compiler keeps track of the complexity and tells you when things go wrong, while the programmer has to do pretty much all of this manually in C++. Many of the constraints Rust requires are constraints that people often try to do manually in C++ (e.g. avoiding dangling references and use-after-move), hoping that they get it correct.

> but really not that much, nothing close to as bad as C++

C++ dev here. Rust's borrow checking system is crazy and even after a week of trying I couldn't understand it in a way that I could reliably use the language.

In C++ everything is fairly straight forward and well documented, in Rust it feels like I'm inserting random symbols in hopes that something will compile. The syntax is verbose and ugly, maybe not as bad as C++ template code can get sometimes, but it's nasty in its own right.

I want to like Rust, I really do, but this just really turned me off it.

> fairly straight forward

This is a rosy-eyed view of C++ if I ever saw one. C++ has a lot of accidental complexity from layers and layers of features and backwards compatibility concerns: maybe some of the features are "straight forward" in isolation, but its interactions with the rest of the language rarely are.

C++ is deceptive, in that the compiler barely keeps track of anything for the programmer, so there are many cases when code should have "random symbols" (or something equivalent) added, but isn't, just being broken instead. The Rust compiler front-loads this: trying to turn runtime brokenness into compile-time errors, which does make it annoying to get code that runs, but it makes it less annoying to get code that actually works correctly.

> In C++ everything is fairly straight forward and well documented

Wow! C++ is full of undocumented and documented, but non-obvious, behavior. I guess that speaks volumes about your experience with C++: given enough time, anything is straightforward.

Rust has a steep learning curve (I'm still climbing it), but it is nowhere even close to C++. C++ gives you a false sense of security, in the sense that code will often compile, but be obviously wrong (for someone knowledgeable). The Rust compiler will not stop complaining until you correct your program.

It's even worse for beginners. Rust learners will get frustrated because their programs are not compiling. C++ learners will get frustrated because their programs will segfault. Often because of some obscure issue, such as someone who forgot to implement copy constructors or assignment operators. I've been there, these issues are completely non-trivial to debug.

I would rather have a compiler yelling at me, but that's me.

Also, since you mentioned that you've been trying for a week: do you think a novice C++ programmer would be able to actually do anything coherent in C++ after a week? Heck, I don't think that's enough time to even go through the spec!

Interesting.

I as Java developer had some hurdles, but most of the time, me and borrow checker get along. My greatest improvement came from compiler lifetime elison in one of the pre-1.0 versions of Rust.

As for syntax being ugly, I do somewhat agree, but mostly, when it reminds me of C++ (e.g. T<U<Vec<u8>>>). I hate tire-tracks and Type::static_method() definitions.

JS/Php dev here as well, I've been learning Rust for some weeks now and it is hard for me. I've never really done any C/C++ (only Java in my school) so a lot of concept are quite new. I'm currently working on an API wrapper in Rust to improve myself, it's been a week already and I'm still working on it whereas I could have done it in 30mn in JS.

Kudos to your determination! I hope you find a path where it starts clicking.

'Put Rust and Go in front of a python coder who wrote dozens of web services using flask - and I am pretty sure I can predict what tool he'll pick'

It depends what part you show. For example Rust has an experimental flask/sinatra/... inspired library (https://rocket.rs/overview/), and although Go has similar things you can't cut boilerplate that much:

So in the end it may depend why someone likes python in the first place: because of the concise high level constructs or because of ease of use.

I have a dream that one day rustc will be able to output go-mangled-symbols with lifetimes integrating into the Go GC. My dream is that we can flesh out a project in Go for good performance and then extend it in Rust without stack swapping. Then we can bash out projects in Go and still have face melting performance with zero overhead abstractions. Go and Rust should be besties!

One can split hairs like you do, but in the end they're both part of a new generation of statically typed languages aiming for good performance.

People looking for such a language will take a look at them and pick one.

Why wouldn't a sane person write a "generic web service" in Rust? What does that even mean?

Because they are not competing with another! :)

Taken from Dave Cheney's https://dave.cheney.net/2015/07/02/why-go-and-rust-are-not-c... ->

"Rust competes for mindshare with C++ and D for programmers who are prepared to accept more complex syntax and semantics (and presumably higher readability costs) in return for the maximum possible performance. For example, micro controllers, AAA game engines, and web rendering engines."

"Go competes for mindshare in the post 2006 Internet 2.0 generation of companies who have outgrown languages like Ruby, Python, and Node.js (v8) and have lost patience with the high deployment costs of JVM based languages."

With a sub-millisecond GC pauses there are many overlapping use cases.

For example, while you might need Rust to target a PIC or a ESP-32 class processor, Go will run perfectly fine on a ARM Cortex-M3 which also has hardware vendors selling Java compilers, e.g. MicroEJ OS (http://www.microej.com/).

GC pause time is not the only criterion, and focusing on it to the exclusion of all else is problematic.

I used to have to explain this in a HN comment every time it came up, but now Mike Hearn has written up [1] better than I ever could, so I can just link there :)

[1]: https://blog.plan99.net/modern-garbage-collection-911ef4f8bd...

I agree, but still Go can be usable in quite a few scenarios.

Sure it has quite a spartan type system and I would rather use something else for my own work.

On the other hand, as an ex-Oberon user I am aware of many use cases that Go can easily fulfil and like to make people aware of it, more Go less C is good.

There are many things that are not AAA games, browser engines and micro controllers where C++ is used and where the Rust community would like Rust to be used.

Rust and Go might compete in that area, assuming that Go programmers will have interest in such projects.

It's not in the interest of the leaders of each community to admit that though.

> Unless Rust wants to position itself as embedded-only it will compete with Go for higher level tasks.

But that is true for any fast-enough high-level language like Java, Scala, C#, OCaml, Haskell, F#, Kotlin, etc.

So it's not Rust vs Go, it's Rust (and Go) vs the world.

Reply on news.ycombinator.com