
Why Rust, or a Trip Report from My Satori with Rust and Functional Programming - xena
https://christine.website/blog/why-rust-2020-02-15
======
mlazos
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.

------
thegeekpirate
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.

------
cletus
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
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
> 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
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
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.

------
zelly
"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
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
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.

------
sitzkrieg
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
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.

~~~
awesome_dude
Can someone explain to me (like a five yo) how the borrow checker is different
to Go's -race flag for compilation?

Genuine question.

~~~
zelly
-race detects data races at runtime. Rust's borrow checker works at compile time. Borrow checking prevents data races by making it impossible for two threads to have read/write access to the same memory. (But there are many ways around it.)

------
HacklesRaised
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.

