5 ms·
Rust and Go are not competing with each other. Why do we see so many comparisons of them?
by akerro 10y ago
Rust and Go are not competing with each other. Why do we see so many comparisons of them?
- blub 10y agoBecause they are competing with eachother! Unless Rust wants to position itself as embedded-only it will compete with Go for higher level tasks.
- koffiezet 10y agoNo 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.
- nicoburns 10y agoThe 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.
- Outpox 10y agoJS/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.
- bluejekyll 10y agoKudos to your determination! I hope you find a path where it starts clicking.
- problems 10y ago> 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.
- Ygg2 10y agoInteresting. 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.
- dbaupp 10y ago> 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.
- szemet 10y ago'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/ 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.
- fnord123 10y agoI 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!
- StevePerkins 10y ago> 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 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.
- leshow 10y agoRust 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.
- blub 10y agoOne 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.
- sidlls 10y agoWhy wouldn't a sane person write a "generic web service" in Rust? What does that even mean?
- islon 10y ago> 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.
- jacmoe 10y agoBecause they are not competing with another! :) Taken from Dave Cheney's https://dave.cheney.net/2015/07/02/why-go-and-rust-are-not-competitors 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."
- pjmlp 10y agoWith 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/ http://www.microej.com/).
- pcwalton 10y agoGC 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-911ef4f8bd8e#.low57td4g https://blog.plan99.net/modern-garbage-collection-911ef4f8bd...
- pjmlp 10y agoI 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.
- blub 10y ago
- pjmlp 10y agoBecause they kind of are, even though they are targeted to different set of skilled developers and Go happens to be a bit spartan in features. For any type of application, including user space drivers, that can be developed with the constraints of a sub-millisecond GC pauses, GC is a good language, in spite of its stance on generics. As for kernel space, Go could eventually be used as well, in spite of GC hate, as academia including Microsoft have proven a few times. Me personally, I prefer Rust, but I do see others would think otherwise.
- oconnor663 10y agoThey certainly have a lot in common, either way: - Both compile to native code. - Both care a lot about performance. - Both care a lot about parallelism. - Both care a lot about safety. - Both were invented by a major browser vendor, roughly around the same time. - Both include an unsafe fun zone that lets you play with raw pointers. Maybe some of that was inevitable just by following the trends in the field (safety and parallelism in particular), and we'll see other new languages making the same choices?
- pjmlp 10y ago> we'll see other new languages making the same choices? We are already seeing that, .NET and Java are finally paying more attention to the AOT story on their standard toolchains. And we also have Objective-C and Swift on iDevices.
- MichaelGG 10y agoSafety is hardly a trend is it? GC'ing everything makes safety rather much easier. Go doesn't go beyond Java level safety or really any of many earlier "managed" languages. Does Go offer safety above, say, PHP? Rust not only does all that, it provides data race safety, and does so without a runtime or tracing garbage collector or real performance sacrifices. All while maintaining C linkage for zero cost interop. I can use Rust basically anywhere I could use C, Go, not so much. That seems to put it squarely in a different segment than Go.