7 ms·

> Use Go if you're looking for an easy GC language with max productivity and a decent performance ceiling. Use Rust if you're writing really high performance or

> Use Go if you're looking for an easy GC language with max productivity and a decent performance ceiling. Use Rust if you're writing really high performance or correctness-is-paramount software. I'd add one more addition to use Rust (speaking from an ex-Go dev): Use Rust if you want a robust std lib. Go is good, i used it for ~5 years, but man Rust was a breath of fresh air with the amount of tooling that helped me solve problems. Iterators, are a great example. I also preferred Crates vs Github Repos, but i think that's just personal preference.. not objective.

skrtskrt 4y ago
I think this comes with the caveat that there are a lot more mature libraries for Go just as a function of the age of the language.
- lumost 4y ago
  Agree, you can see this in https://github.com/rust-unofficial/awesome-rust https://github.com/rust-unofficial/awesome-rust vs. https://github.com/avelino/awesome-go https://github.com/avelino/awesome-go I've noticed however that there has been an uptick in great libraries over the last 2 years, with examples like pola.rs, rust-bert, tokenizers etc. starting to build momentum in the ecosystem.
- pdimitar 4y ago
  That might have been true 2-3 years ago but nowadays whatever I can think of, Rust already has a library for it.
  - skrtskrt 4y ago
    Most recently I've run into Hyper not having tracing support
johnisgood 4y ago
When performance and correctness are paramount, I personally stick to Ada/SPARK. Proven to be perfect for the job, and to be honest, Rust is quite a difficult language and I am not sure it is worth learning it considering that Ada/SPARK ticks all boxes when it comes to both low-level and high-level programming for critical systems.
- throwaway894345 4y ago
  I have fond memories of using Ada in college. Unfortunately it didn’t have much of an open source footprint and the community was downright hostile toward newbies (more so than other communities that I had experienced). I’m sure Ada has the stronger story for real-time embedded systems today, but (as I have learned Rust in the interim) I look forward to the day when Rust breaks into the real-time embedded space. In particular, I’m excited about ferrocene and the broader Rust certification efforts. I would really like to write embedded Rust professionally, and I hope certification will boost the number of embedded Rust jobs (no the to Ada, I just don’t particularly want to re-learn it).
  - deagle50 4y ago
    My favorite thing about learning Rust is how helpful the community is.
- kylereeve 4y ago
  Do you work in Ada/SPARK professionally? Curious what industry if so.
throwaway894345 4y ago
I actually don't care as much for iterators as I thought I would. Beyond some simpler map().reduce() stuff they tend to fall over pretty fast, and I end up spending too much time trying to make iterator chains work before defaulting to for loops. I also dislike how anemic Rust's stdlib is. I'm sure there are good reasons, but I like that I can just reach for Go's stdlib for annotating errors or dealing with JSON. Other than that, I like the API design in Rust's stdlib. Here's an example where the iterator-chain version is way more complex: let posts = read_dir(source_directory)? .filter_map(|result| { (|| { let entry = result?; let os_file_name = entry.file_name(); let file_name = os_file_name.to_string_lossy(); if Self::is_bundle(&entry)? { self.parse_post_bundle(&file_name, &entry.path()) .map(Some) } else if file_name.ends_with(MARKDOWN_EXTENSION) { self.parse_post( file_name.trim_end_matches(MARKDOWN_EXTENSION), &mut File::open(&entry.path())?, ) .map(Some) } else { Ok(None) } })() .transpose() }) .collect::<Result<Vec<_>>>()?; Here's the imperative version: let mut posts = Vec::new(); for result in read_dir(source_directory)? { let entry = result?; let os_file_name = entry.file_name(); let file_name = os_file_name.to_string_lossy(); if Self::is_bundle(&entry)? { posts.push(self.parse_post_bundle(&file_name, &entry.path())?); } else if file_name.ends_with(MARKDOWN_EXTENSION) { posts.push(self.parse_post( file_name.trim_end_matches(MARKDOWN_EXTENSION), &mut File::open(&entry.path())?, )?); } }
- SoftTalker 4y ago
  I guess that's subjective, not knowing rust I see a few more lines in the first example but beyond that it does not jump out at me as being "way more complex."
  - throwaway894345 4y ago
    Hah, it took me and a bunch of other people in the Rust discord a fair amount of time to figure out how to get the first example to compile correctly in the first place, and I find the “transpose()” business to be particularly convoluted. I think even Rust people would prefer the imperative version. I also suspect there’s some hindsight benefit at play in that it’s easier to make sense of the first snippet than it was to write it.
dls2016 4y ago
> but man Rust was a breath of fresh air with the amount of tooling that helped me solve problems The tooling is the #1 reason I'd like to learn rust. I have not kept up with C++ and I'm not sure I ever will... sometimes plain C seems more straightforward. But those languages (C++ especially) have suffered from lack of standard tooling, in my opinion. Even C# being a few years younger than Java seems to have made a huge difference in tooling availability (I'm sure having a single corporate driver during its lifetime made a difference, too). I'm excited by the prospect of a compiled language with modern tooling.
- throwaway894345 4y ago
  Tooling was the reason I left C++. Having to do your own package management and script your own build system was deeply dull work. The IDE story was also pretty miserable, although I think clangd has improved it a bit. Getting decent information out of core dumps also sucked a lot. The language actually didn’t bother me too much after c++11, but everything else was such a bear that I jumped ship. Rust has been very rewarding in that it largely fixes all of C++’s tooling and language problems. It very much is a significantly improved C++.
  - synergy20 4y ago
    I actually filed a ticket at Carbon project saying c++'s top 1 problem is tooling, modern c++ is pretty nice to use already, no need for Carbon there in fact, at least not as needed as tooling.
Thaxll 4y ago
Rust std lib is subpar compared to the Go one, yes you have iterators but that's it, basic things like async are not even provided just the interface so everyone has to use tokyo. Then for real use cases you're missing http/json/compression/crypto etc ... https://pkg.go.dev/std https://pkg.go.dev/std Overall tooling and std lib are better on Go, actually there are not many languages that are on part with Go to that regard. When you see what you can do with the single go command, it's pretty powerful.
- jxf 4y ago
  Quick correction for anyone searching: it's `tokio`, not `tokyo`. [0] [0]: https://tokio.rs/ https://tokio.rs/
- mlindner 4y ago
  I find it really curious how people consider "async" as a "basic thing". Coming from C++, asynchronous runtimes were a thing companies and large open source projects were built around. It's not at all a basic thing. I'd argue it's almost certainly something that should NOT be in the standard library. If anything, the feature was added to Rust too quickly and has way too many rough edges.
- throwaway234566 4y ago
  Agreed 100%. Go doesn't have a standard library problem, it has a userland language problem. * No sum types / algebraic data types in 2022. * No exhaustive pattern matching in 2022 * No move semantics / Uses GC * No borrow checker * Still suffers from nil problem / No type-safe nil / No type-safe Optionals in 2022 -- (I can show you all the nil panics in kubernetes logs if you like) Current go users are already sold so they don't expect more, and that's fine, but further evangelism will require a better host language.
  - foldr 4y ago
    Seems a bit odd to criticize Go for using GC rather than a borrow checker to manage memory. There’s surely a place for GCed languages, even if they’re not the right choice for every domain.

skrtskrt 4y ago

I think this comes with the caveat that there are a lot more mature libraries for Go just as a function of the age of the language.

lumost 4y ago
Agree, you can see this in https://github.com/rust-unofficial/awesome-rust https://github.com/rust-unofficial/awesome-rust vs. https://github.com/avelino/awesome-go https://github.com/avelino/awesome-go I've noticed however that there has been an uptick in great libraries over the last 2 years, with examples like pola.rs, rust-bert, tokenizers etc. starting to build momentum in the ecosystem.
pdimitar 4y ago
That might have been true 2-3 years ago but nowadays whatever I can think of, Rust already has a library for it.
- skrtskrt 4y ago
  Most recently I've run into Hyper not having tracing support

johnisgood 4y ago

When performance and correctness are paramount, I personally stick to Ada/SPARK. Proven to be perfect for the job, and to be honest, Rust is quite a difficult language and I am not sure it is worth learning it considering that Ada/SPARK ticks all boxes when it comes to both low-level and high-level programming for critical systems.

throwaway894345 4y ago
I have fond memories of using Ada in college. Unfortunately it didn’t have much of an open source footprint and the community was downright hostile toward newbies (more so than other communities that I had experienced). I’m sure Ada has the stronger story for real-time embedded systems today, but (as I have learned Rust in the interim) I look forward to the day when Rust breaks into the real-time embedded space. In particular, I’m excited about ferrocene and the broader Rust certification efforts. I would really like to write embedded Rust professionally, and I hope certification will boost the number of embedded Rust jobs (no the to Ada, I just don’t particularly want to re-learn it).
- deagle50 4y ago
  My favorite thing about learning Rust is how helpful the community is.
kylereeve 4y ago
Do you work in Ada/SPARK professionally? Curious what industry if so.

throwaway894345 4y ago

I actually don't care as much for iterators as I thought I would. Beyond some simpler map().reduce() stuff they tend to fall over pretty fast, and I end up spending too much time trying to make iterator chains work before defaulting to for loops. I also dislike how anemic Rust's stdlib is. I'm sure there are good reasons, but I like that I can just reach for Go's stdlib for annotating errors or dealing with JSON. Other than that, I like the API design in Rust's stdlib. Here's an example where the iterator-chain version is way more complex: let posts = read_dir(source_directory)? .filter_map(|result| { (|| { let entry = result?; let os_file_name = entry.file_name(); let file_name = os_file_name.to_string_lossy(); if Self::is_bundle(&entry)? { self.parse_post_bundle(&file_name, &entry.path()) .map(Some) } else if file_name.ends_with(MARKDOWN_EXTENSION) { self.parse_post( file_name.trim_end_matches(MARKDOWN_EXTENSION), &mut File::open(&entry.path())?, ) .map(Some) } else { Ok(None) } })() .transpose() }) .collect::<Result<Vec<_>>>()?; Here's the imperative version: let mut posts = Vec::new(); for result in read_dir(source_directory)? { let entry = result?; let os_file_name = entry.file_name(); let file_name = os_file_name.to_string_lossy(); if Self::is_bundle(&entry)? { posts.push(self.parse_post_bundle(&file_name, &entry.path())?); } else if file_name.ends_with(MARKDOWN_EXTENSION) { posts.push(self.parse_post( file_name.trim_end_matches(MARKDOWN_EXTENSION), &mut File::open(&entry.path())?, )?); } }

SoftTalker 4y ago
I guess that's subjective, not knowing rust I see a few more lines in the first example but beyond that it does not jump out at me as being "way more complex."
- throwaway894345 4y ago
  Hah, it took me and a bunch of other people in the Rust discord a fair amount of time to figure out how to get the first example to compile correctly in the first place, and I find the “transpose()” business to be particularly convoluted. I think even Rust people would prefer the imperative version. I also suspect there’s some hindsight benefit at play in that it’s easier to make sense of the first snippet than it was to write it.

dls2016 4y ago

> but man Rust was a breath of fresh air with the amount of tooling that helped me solve problems The tooling is the #1 reason I'd like to learn rust. I have not kept up with C++ and I'm not sure I ever will... sometimes plain C seems more straightforward. But those languages (C++ especially) have suffered from lack of standard tooling, in my opinion. Even C# being a few years younger than Java seems to have made a huge difference in tooling availability (I'm sure having a single corporate driver during its lifetime made a difference, too). I'm excited by the prospect of a compiled language with modern tooling.

throwaway894345 4y ago
Tooling was the reason I left C++. Having to do your own package management and script your own build system was deeply dull work. The IDE story was also pretty miserable, although I think clangd has improved it a bit. Getting decent information out of core dumps also sucked a lot. The language actually didn’t bother me too much after c++11, but everything else was such a bear that I jumped ship. Rust has been very rewarding in that it largely fixes all of C++’s tooling and language problems. It very much is a significantly improved C++.
- synergy20 4y ago
  I actually filed a ticket at Carbon project saying c++'s top 1 problem is tooling, modern c++ is pretty nice to use already, no need for Carbon there in fact, at least not as needed as tooling.

Thaxll 4y ago

Rust std lib is subpar compared to the Go one, yes you have iterators but that's it, basic things like async are not even provided just the interface so everyone has to use tokyo. Then for real use cases you're missing http/json/compression/crypto etc ... https://pkg.go.dev/std https://pkg.go.dev/std Overall tooling and std lib are better on Go, actually there are not many languages that are on part with Go to that regard. When you see what you can do with the single go command, it's pretty powerful.

jxf 4y ago
Quick correction for anyone searching: it's `tokio`, not `tokyo`. [0] [0]: https://tokio.rs/ https://tokio.rs/
mlindner 4y ago
I find it really curious how people consider "async" as a "basic thing". Coming from C++, asynchronous runtimes were a thing companies and large open source projects were built around. It's not at all a basic thing. I'd argue it's almost certainly something that should NOT be in the standard library. If anything, the feature was added to Rust too quickly and has way too many rough edges.
throwaway234566 4y ago
Agreed 100%. Go doesn't have a standard library problem, it has a userland language problem. * No sum types / algebraic data types in 2022. * No exhaustive pattern matching in 2022 * No move semantics / Uses GC * No borrow checker * Still suffers from nil problem / No type-safe nil / No type-safe Optionals in 2022 -- (I can show you all the nil panics in kubernetes logs if you like) Current go users are already sold so they don't expect more, and that's fine, but further evangelism will require a better host language.
- foldr 4y ago
  Seems a bit odd to criticize Go for using GC rather than a borrow checker to manage memory. There’s surely a place for GCed languages, even if they’re not the right choice for every domain.