Hacker News Reader

Comment by brigadier132 | Hacker News Reader

> Rust doesn't stop you from writing bugs into your code

Obviously. It's not about Rust specifically. It's about accurately representing state which is extremely difficult to do in programming languages that do not have algebraic data types.

In Golang how do I represent that a type is either type A or type B and then in a type safe way perform logic if it's type A or perform logic if it's type B? Algebraic data types also allow for things like the result and option type.

Throw in the borrow checker which prevents a host of aliasing and concurrency bugs (not all). You are more likely to write correct Rust than other languages.

> You'd better stop interacting with technology then, because the vast majority of it is still running something compiled from C.

Thank you for another lesson I already know. I clearly meant I don't think it's suitable for use in new programs. People will still use it regardless as they are free to do so.

View on HN

> extremely difficult to do in programming languages that do not have algebraic data types.

And this is why people like me avoid ML based languages, type astronauts, and shiny new toys. You're misrepresenting inconveniences as fatal flaws when we've been successfully running all of modern society on kernels written in C for fifty years. Most of the kernel subsystem maintainers aren't even considering Rust as anything more than an experiment at this point. No one cares about ADTs and the perfect representation of state transitions in the type system when we have actual problems to solve, and we can and have been solving them in C.

> And this is why people like me avoid ML based languages, type astronauts, and shiny new toys

Instead you get things like this in GO

`var _ litestream.ReplicaClient = (*ReplicaClient)(nil)`

And every single variable is implicitly Type or null because obviously the alternative is more complex

> And this is why people like me avoid ML based languages, type astronauts, and shiny new toys.

There's nothing new or shiny about the ML family. And the growing interest in ADT's is about their very real advantages in representing state and solving real problems in a less error prone manner than C

Don’t argue with him. He is just and old man doing what all old man do: find excuses to not learn new stuff and convince himself that he didn’t have to do it

Yeah I find it really hard to see how they're being charitable. Just an old fart arguing for the continued relevance of curmudgeon-y technology instead of actually responding to the points being argued.

What people who still care about writing C are doing is starting to use tools to bring some of what Rust offers to C, because they acknowledge that avoiding entire categories of bugs is actually really good, despite which language you use. But... no mention of that here, it seems.

> successfully running all of modern society on kernels written in C for fifty years.

No we haven't. C is successful despite its major flaws (seg faults based on memory errors are not mere "inconveniences"). Microsoft mentioned for example that around 25-33% of all bugs in Windows were based on memory errors. They are currently cutting those down to 0% via Rust.

> In Golang how do I represent that a type is either type A or type B

generics provide one approach to this, but, in general, you don't -- you find another solution to your problem

Reply on news.ycombinator.com