7 ms·

Why Rust, or a Trip Report from My Satori with Rust and Functional Programming

42 points by xena 7y ago

mlazos 7y ago
I honestly didn’t find anything of interest in this post. If you already know that rust / fp in general tend to have safe and sound type systems which enable developers to encode complex relationships in the type system to prevent race conditions and catch memory leaks at compile time then there is not much for you here. I suspect a lot of HNers who would be interested in this post already know that.
- hermanradtke 7y ago
  I honestly didn’t find anything of interest in this comment.
- deleted 7y ago
  [deleted]
cletus 7y ago
So I found this analogy a little shallow. The tl;dr is: Some languages are dynamic (Lua being ht example here but obviously there are many others eg Python). The author then chooses to differentiate types of statically typed languages to those with generics (Rust being the example) and those that don't (Go being the example). I'm not sure that's a useful distinction because all type systems have limitations and there are many orthogonal dimensions. A language can have (or not) generic types while separately being able to define enumerated types (or not), as just one example. The interesting thing (at least to me) about Rust is that Rust goes beyond describing types to describing (at compile-time) ownership of data. There is a developer cost to this and a compile-time cost. Personally my view is: - Compile time errors are cheaper to debug and fix than run-time errors. That's the whole point of having a type system: to catch errors at compile-time. Better that than a segfault. Rust is novel in that it eliminates a whole class of problems with data ownership, lifetimes and access. Not every problem of course. - Memory-safety is just too important such that Rust will increasingly fill a niche because this is just too easy to get wrong in, say, C/C++. You do have to jump through hoops go properly describe ownership semantics so the Rust compiler can satisfy safety constraints. Like a type system, there are limitations to this and you can intuitively come up with examples that you know are safe but are hard if not impossible to describe to Rust. Rust does get better with this as time goes on. Whatever the case, I'm very bullish on Rust.
- rvz 7y ago
  Well as much as Rust covers all the main benefits and features compared to other languages, some companies can afford to switch to it but others think more carefully if such a switch is more trouble that it’s worth. It no doubt that the barrier to reading / learning Rust is still higher compared to other languages despite the languages safety guarantees and performance. It is still a new language that some large companies can afford to invest their time using it. However if a senior dev that pushes for a rust codebase and ends up leaving the project, the team would probably revert back to the second-best language that everyone knows rather than continue. It doesn’t make any sense to use Rust for the sake of Rust or even strangely: “because everyone else is using it”. Even as a Rust user myself, the author has failed to mention about the quality of the crates ecosystem which mostly still have pre-1.0 libraries and aren’t even stable yet and even a popular few had and still have unsafely issues. In a typical production software house of 2025 for new server-side software, I would use Rust over C++ and JavaScript (Node). But for 2020? Kotlin/Kotlin Native sounds like a safer bet for some companies over Rust due to leveraging the existing Java ecosystem and being a safer alternative to Java.
  - zelly 7y ago
    > But for 2020? Kotlin/Kotlin Native sounds like a safer bet for some companies over Rust due to leveraging the existing Java ecosystem and being a safer alternative to Java. You should consider plain Java tbh. Java 15+ is basically Kotlin anyway at this point. It's much easier to hire or outsource Java developers.
    - carlmr 7y ago
      It's easier to find Java devs, but whenever I've been in contact with any they're also on average the lowest quality developers you can find. It's the language everybody learned at uni, so you get a lot of people that never did more than the bare minimum.
      - pjmlp 7y ago
        Just like any other language. Are you aware that there are outsourcing projects doing Haskell, Scala and C++ as well. Hint, the deliverables aren't usually what one would expect from the skill levels usually required by average users of those languages.
sitzkrieg 7y ago
the first example is ok, everyone knows this is by design in go though. second one is grasping, what if you want different metadata on each property? it will end up looking similar, albeit more strongly typed than a string. its a little myopic rust task force feeling though
zerr 7y ago
AFAIK the only unique feature of Rust is a borrow checker, right? (compared to other feature-full languages, i.e. not Go) Regarding the main example of author, it's great that the progressive side of Go team won, so generics are coming in Go 2.
- littlestymaar 7y ago
  The “unique feature” thing isn't quite useful when comparing programming languages: the only “unique feature” of a plane are its wings but the implications of having that feature are quite big!
- genuine_smiles 7y ago
  I’m not away of any language with a feature comparable to its editions. Editions should enable Rust to avoid the bloat of languages like c++, Java, or c# over time while avoiding the Python 2 problem. https://doc.rust-lang.org/edition-guide/editions/index.html https://doc.rust-lang.org/edition-guide/editions/index.html
  - pjmlp 7y ago
    It still remains to be seen, specially if Rust starts supporting distributing binary libraries, and one tries to compile across multiple epochs with them. Java, C# and C++ control it via compiler flags, and also have the ABI issue across language versions.
- deleted 7y ago
  [deleted]
- zelly 7y ago
  Yes, I think that's the only new innovation in Rust. Everything else is just an incremental improvement on what already exists elsewhere. Supposedly the developer experience/ergonomics is a feature, but everyone I have met says the syntax is ugly. In terms of ease of getting started and using tooling, it really can't ever compete with the corporate languages like Go, Swift, Kotlin. I can't for the life of me understand why it keeps getting more popular. Memory safety? Security? C++ had the same safety characteristics for at least a decade with dozens of linters and sanitizers on the market, but people never used them or actively turned them off. Rust forces you to use a linter. Maybe it's for the best.
thegeekpirate 7y ago
This is an incredible basic article, and there's a lot of issues with it to boot which is surprising considering the author has performed talks at Go conferences: Go's equivalent to Rust's Vec should have simply been []int64 instead of using list.List (which is a doubly-linked list, aka std::collections::LinkedList in Rust). And yes, I read the blurb at the end where they say they know slices exist. The issue is that they proved nothing useful by not using them. You don't need to recreate how slices work because _they already exist_, and is well-known it's all currently compiler magic (until they introduce generics). In the JSON unmarshalling example, the reason you need struct tags in Go is because the JSON field name is different from the one given in the Go code. You'd have to do the exact same in Rust if they had named it similarly to the Go example (https://serde.rs/field-attrs.html https://serde.rs/field-attrs.html). The other stuff about catching concurrent issues is true, but working with concurrency in Rust is a testament to one's patience as well (especially when working with multiple processes/threads), so you're trading off usability with safety—and to be frank, it's pretty easy to remember that the only things that work concurrently are either atomic, use locks, or some sort of queue.
zelly 7y ago
"list" in Go is not equivalent to Rust vec. List is a linked list of boxed entities. Of course they can have different types because it is a linked list; each cell lives elsewhere on the heap. The Go equivalent to vec is an array or a slice, which does enforce the type. As for the second example, it's more of a complaint about the library. There are libraries that enforce stricter checking. Or you can code gen or roll your own deserialization logic. > but then the job of ensuring the sanity of the inputs is shunted to runtime rather than stopped before the code gets deployed It's always runtime, even in Rust. You get some blob from the network to deserialize, it will return an error if it's bad, just like in Go if you try to Unmarshal bad input to a struct. Seems like people think Rust has this magical ability to prevent errors. Big expectations lead to big disappointments.
- loopz 7y ago
  The complaint about interface{} is very legit in practice. Author says he deliberately picked on Go stdlib to illustrate. I suspect one had to struggle with the same to really get it. How "stable" is Rust, libs and tooling ecosystem though.
  - zelly 7y ago
    Rust is getting better. It recently got async/await which imo is a much cleaner and undeniably faster way to do concurrency than Go's channels/CSP. It's not really fair to compare Rust's ecosystem to Go's because Rust doesn't have a trillion dollar company's halo effect. For the foreseeable future you will always be more likely to use Go than Rust at work.
HacklesRaised 7y ago
tldr: I am going to present Go in the worst light possible by pretending it doesn't support typed containers. Hopefully you'll gloss over this and support my viewpoint. Rust doesn't need an 'assist' but articles like this will certainly damage the, otherwise sterling, reputation of it's community.

42 points by xena 7y ago

I honestly didn’t find anything of interest in this post. If you already know that rust / fp in general tend to have safe and sound type systems which enable developers to encode complex relationships in the type system to prevent race conditions and catch memory leaks at compile time then there is not much for you here. I suspect a lot of HNers who would be interested in this post already know that.

hermanradtke 7y ago
I honestly didn’t find anything of interest in this comment.
deleted 7y ago
[deleted]

cletus 7y ago

So I found this analogy a little shallow. The tl;dr is: Some languages are dynamic (Lua being ht example here but obviously there are many others eg Python). The author then chooses to differentiate types of statically typed languages to those with generics (Rust being the example) and those that don't (Go being the example). I'm not sure that's a useful distinction because all type systems have limitations and there are many orthogonal dimensions. A language can have (or not) generic types while separately being able to define enumerated types (or not), as just one example. The interesting thing (at least to me) about Rust is that Rust goes beyond describing types to describing (at compile-time) ownership of data. There is a developer cost to this and a compile-time cost. Personally my view is: - Compile time errors are cheaper to debug and fix than run-time errors. That's the whole point of having a type system: to catch errors at compile-time. Better that than a segfault. Rust is novel in that it eliminates a whole class of problems with data ownership, lifetimes and access. Not every problem of course. - Memory-safety is just too important such that Rust will increasingly fill a niche because this is just too easy to get wrong in, say, C/C++. You do have to jump through hoops go properly describe ownership semantics so the Rust compiler can satisfy safety constraints. Like a type system, there are limitations to this and you can intuitively come up with examples that you know are safe but are hard if not impossible to describe to Rust. Rust does get better with this as time goes on. Whatever the case, I'm very bullish on Rust.

rvz 7y ago
Well as much as Rust covers all the main benefits and features compared to other languages, some companies can afford to switch to it but others think more carefully if such a switch is more trouble that it’s worth. It no doubt that the barrier to reading / learning Rust is still higher compared to other languages despite the languages safety guarantees and performance. It is still a new language that some large companies can afford to invest their time using it. However if a senior dev that pushes for a rust codebase and ends up leaving the project, the team would probably revert back to the second-best language that everyone knows rather than continue. It doesn’t make any sense to use Rust for the sake of Rust or even strangely: “because everyone else is using it”. Even as a Rust user myself, the author has failed to mention about the quality of the crates ecosystem which mostly still have pre-1.0 libraries and aren’t even stable yet and even a popular few had and still have unsafely issues. In a typical production software house of 2025 for new server-side software, I would use Rust over C++ and JavaScript (Node). But for 2020? Kotlin/Kotlin Native sounds like a safer bet for some companies over Rust due to leveraging the existing Java ecosystem and being a safer alternative to Java.
- zelly 7y ago
  > But for 2020? Kotlin/Kotlin Native sounds like a safer bet for some companies over Rust due to leveraging the existing Java ecosystem and being a safer alternative to Java. You should consider plain Java tbh. Java 15+ is basically Kotlin anyway at this point. It's much easier to hire or outsource Java developers.
  - carlmr 7y ago
    It's easier to find Java devs, but whenever I've been in contact with any they're also on average the lowest quality developers you can find. It's the language everybody learned at uni, so you get a lot of people that never did more than the bare minimum.
    - pjmlp 7y ago
      Just like any other language. Are you aware that there are outsourcing projects doing Haskell, Scala and C++ as well. Hint, the deliverables aren't usually what one would expect from the skill levels usually required by average users of those languages.

sitzkrieg 7y ago

the first example is ok, everyone knows this is by design in go though. second one is grasping, what if you want different metadata on each property? it will end up looking similar, albeit more strongly typed than a string. its a little myopic rust task force feeling though

zerr 7y ago

AFAIK the only unique feature of Rust is a borrow checker, right? (compared to other feature-full languages, i.e. not Go) Regarding the main example of author, it's great that the progressive side of Go team won, so generics are coming in Go 2.

littlestymaar 7y ago
The “unique feature” thing isn't quite useful when comparing programming languages: the only “unique feature” of a plane are its wings but the implications of having that feature are quite big!
genuine_smiles 7y ago
I’m not away of any language with a feature comparable to its editions. Editions should enable Rust to avoid the bloat of languages like c++, Java, or c# over time while avoiding the Python 2 problem. https://doc.rust-lang.org/edition-guide/editions/index.html https://doc.rust-lang.org/edition-guide/editions/index.html
- pjmlp 7y ago
  It still remains to be seen, specially if Rust starts supporting distributing binary libraries, and one tries to compile across multiple epochs with them. Java, C# and C++ control it via compiler flags, and also have the ABI issue across language versions.
deleted 7y ago
[deleted]
zelly 7y ago
Yes, I think that's the only new innovation in Rust. Everything else is just an incremental improvement on what already exists elsewhere. Supposedly the developer experience/ergonomics is a feature, but everyone I have met says the syntax is ugly. In terms of ease of getting started and using tooling, it really can't ever compete with the corporate languages like Go, Swift, Kotlin. I can't for the life of me understand why it keeps getting more popular. Memory safety? Security? C++ had the same safety characteristics for at least a decade with dozens of linters and sanitizers on the market, but people never used them or actively turned them off. Rust forces you to use a linter. Maybe it's for the best.

thegeekpirate 7y ago

This is an incredible basic article, and there's a lot of issues with it to boot which is surprising considering the author has performed talks at Go conferences: Go's equivalent to Rust's Vec should have simply been []int64 instead of using list.List (which is a doubly-linked list, aka std::collections::LinkedList in Rust). And yes, I read the blurb at the end where they say they know slices exist. The issue is that they proved nothing useful by not using them. You don't need to recreate how slices work because _they already exist_, and is well-known it's all currently compiler magic (until they introduce generics). In the JSON unmarshalling example, the reason you need struct tags in Go is because the JSON field name is different from the one given in the Go code. You'd have to do the exact same in Rust if they had named it similarly to the Go example (https://serde.rs/field-attrs.html https://serde.rs/field-attrs.html). The other stuff about catching concurrent issues is true, but working with concurrency in Rust is a testament to one's patience as well (especially when working with multiple processes/threads), so you're trading off usability with safety—and to be frank, it's pretty easy to remember that the only things that work concurrently are either atomic, use locks, or some sort of queue.

zelly 7y ago

"list" in Go is not equivalent to Rust vec. List is a linked list of boxed entities. Of course they can have different types because it is a linked list; each cell lives elsewhere on the heap. The Go equivalent to vec is an array or a slice, which does enforce the type. As for the second example, it's more of a complaint about the library. There are libraries that enforce stricter checking. Or you can code gen or roll your own deserialization logic. > but then the job of ensuring the sanity of the inputs is shunted to runtime rather than stopped before the code gets deployed It's always runtime, even in Rust. You get some blob from the network to deserialize, it will return an error if it's bad, just like in Go if you try to Unmarshal bad input to a struct. Seems like people think Rust has this magical ability to prevent errors. Big expectations lead to big disappointments.

loopz 7y ago
The complaint about interface{} is very legit in practice. Author says he deliberately picked on Go stdlib to illustrate. I suspect one had to struggle with the same to really get it. How "stable" is Rust, libs and tooling ecosystem though.
- zelly 7y ago
  Rust is getting better. It recently got async/await which imo is a much cleaner and undeniably faster way to do concurrency than Go's channels/CSP. It's not really fair to compare Rust's ecosystem to Go's because Rust doesn't have a trillion dollar company's halo effect. For the foreseeable future you will always be more likely to use Go than Rust at work.

HacklesRaised 7y ago

tldr: I am going to present Go in the worst light possible by pretending it doesn't support typed containers. Hopefully you'll gloss over this and support my viewpoint. Rust doesn't need an 'assist' but articles like this will certainly damage the, otherwise sterling, reputation of it's community.