Hacker News Reader

Comment by creatonez | Hacker News Reader

The answer for why folks are so inclined towards doing high-level tasks in Rust... is the type system. Its sensibilities are in a sweet spot that makes it very easy to pull off huge refactors. It was also a lot of people's first introduction to algebraic data types being used in nearly all error handling (its usage of `Result<T, E> where E implements Error` and lack of nulls or exceptions). It makes a lot of progress towards the goal of "make invalid states unrepresentable", which could be really useful for web apps.

View on HN

Most of those people aren't aware that the type system is a feature from most ML derived languages since Standard ML is a thing.

All of them with better ergonomics for Web development.

Do they really have better economics? (EDIT: ergonomics!)

Last time I looked into OCaml, I struggled to find a way to interact with the database in a type-safe way, I never figured out which standard library I was meant to install, I was being encouraged to use 2-3 different project management tools (Dune + Esy + OPAM), and I gave up on writing tests. But at least there's a garbage collector!

I realise these are all problems that I'll wrap my head around over time, and eventually they'll seem completely trivial to me, but the introductory documentation on getting started as a professional (and not as a first-year student doing a French-language compsci degree, which is what most of the documentation assumes), is pretty dire.

Meanwhile, much as I'm sure I overuse `.clone()` and `[A]Rc<_>`, the ownership model of Rust is deeply useful. It's something I often find myself missing in Javascript - not necessarily because I want to produce the most performant code, but because it's useful to understand the lifetimes of the objects I'm keeping around. Am I accidentally storing a reference to something in a closure that I forgot about? When this object gets deleted, have I checked that it's the last possible reference to this object? Etc.

Like, I don't think everyone needs to learn Rust. It's a great language, but there's lots of other great languages out there, depending on your personal and business contexts. But I think this idea that Rust can and should only be a low-level language feels absurd to me. It is a fairly ergonomic language with a fantastic ecosystem, a powerful type system, and an ownership model that will be useful even if you do try and opt partly out of it with GC-like wrapper types.

I guess you mean ergonomics.

Yes they do, unless you get your editor to magically type `.clone()` and `[A]Rc<_>` all over the place.

Not to mention they don't need unsafe, or 3rd party crates to handle graphs.

Additionally, all of them have interpreters and REPLs alongside their compilers, streamlining the code-develop-debug loop.

Thanks for pointing the typo out! I've fixed the comment.

In fairness, I think a lot of this comes down to familiarity. I'm fairly familiar with `.clone()` and Arcs at this point, so they don't really change much in terms of ergonomics. Usually their usage is fairly obvious, and quite often my editor literally does magically type the `.clone()` calls through LSP fix commands. It's the same as, say, OCaml's insistence that recursion is better for complex loops than, say, `while` — it's not necessarily wrong, but if you're unfamiliar with the idea, it's going to feel weird.

More important to me is the ergonomics of the broader ecosystem, and that's something that Rust has done well, that other languages just don't seem to be interested in at all. Things like integrating testing into the standard workflow; working hard on getting the stdlib in good condition; having an excellent ecosystem of well-documented, usable libraries; or designing error messages and lints with a focus on getting people to understand how the language works and not just what they've done wrong this time. I've really missed that stuff whenever I've tried MLs. You mention, for example, REPLs, but a unit test is basically a saved REPL session that you can repeat every time you make a change.

I'm not trying to convince anyone that Rust is the best language in the world or something. I really like it, but I find it helpful to think in terms of object ownership even in non-Rust languages, and I can understand why for other people that sort of approach is unhelpful. But I would love to see other languages embrace its ergonomics more, or new languages created with that as their focus.

A unit test has nothing to do with a REPL, a proper REPL provides something similar to jupiter notebooks in feel, alongside debugging and hot code reload experience.

Maybe we have different understandings of REPLs. For me, a REPL is a tool that I can use to try out some portion of my code, see how it responds to various inputs, see how it handles certain cases, and explore the internals of it via debugging tools.

But... that's what I do in a unit test anyway. A unit test is essentially a REPL session that I've frozen in time, can replay whenever I want, can debug, can trigger a fresh run whenever changes occur (which isn't quite hot reloading, but often a darn sight more useful), and can keep track of and share with my team. Which means I'm not just able to explore things on my own, but I can see the explorations that other people have made with their code.

For me the REPL is the experience similar to Lisp Machines, Smalltalk kind of experience, which is loosely captured in Jupiter Notebooks.

As for unit tests being more usefull, depends on how much one is willing to wait for them to run in Rust, given its compile times.

Typing in modern days is effectively moving the task of debugging to compile/ide annotations process instead of testing for correctness.

Albeit it makes the process easier compared to a really shittly written code without strict typing, but against good codebases, it takes the same amount of time.

I strongly disagree on the principle that tests and types have a 100% overlap in the problems they're solving.

Why not?

If you think about correctness of a program, (i.e for any combination of given input , it changes a state in a determinstic way, including no state change for invalid input).

Strict typing is one way to accomplish this. The cpu does not give a shit about types. It cares about memory registers and locations. The unique code built into the compliers/transpilers is the thing that validates the correctness of the program in this case.

You can move that code into the testing suite without relying on the complier, and just do testing. Generally, given competent programming skills, this takes about the same amount of time as designing a well structured program - your tests are pretty much your design document for the thing itself.

You can not test for the absence of behavior. You can design type systems to ensure the absence of specific behaviors.

What do you mean by absence?

This is a very anti-pragmatic way of looking at things in my opinion. The program is not a snapshot that exists in a vacuum. Most programs are going to grow over time and have things added and removed in various places by many people. They're going to have many interfaces and operations.

I think you're arguing that tests and types can both be used to check a particular case for correctness. Sure, this is true. However "moving type checking code into the test suite" means nothing—that would just be type checking.

When you make a code change, there's a difference in the kinds of feedback you get from your tests and your types. Tests usually cover business logic or stories—things that you want or don't want. Types ideally cover everything. They check every operation applied to a given piece of data. Of course types are rarely precise enough that they can catch every logic bug (e.g. strings with semantics not encoded in types, like email addresses).

This is just scratching the surface. You might just have to try out both to get a better sense of how they feel to work with.

So at one of my older jobs, we worked primarily with C code that ran on a mini linux box inside a plane, and interfaces with a sensor pacakge. We wanted to make sure that the software was 100% correct cause any errors would mean an aborted flight test

We basically ended up creating a tool+language spec that would let us define the mapping of input to output sequences. We wrote it in such a way where we sat with scientists and pretty much mapped all the possible cases that they could think of for valid inputs and what the code should produce.

Then this tool would basically write automated tests for us, in such a way as to not only test correct behavior, but also do combinations of inputs out of order, fuzz testing, and so on. We ended up making it also check memory state, to ensure that there was no memory leaks, and analyze the memory space for required data or data that should not be there.

In the end, whenever someone was developing anything for this software, they would basically just run the tests, and it would be very good at catching possible errors, mostly on the negative side (i.e for a fuzzed input, it would result in an output that should be an error).

We could have done the same thing with a typed language, but it would have to be very strict typing to the point of something like CoQ, and it would have taken us probably the same amount of time to write that.

Hey, that's awesome. Seems like a great case for verifying things that way! I'm thinking of different cases I think, where you've got something like a distributed system or a web application and it's just harder to fuzz. But I agree, that seems a lot more practical than formally verifying it when that's the kind of testing you need.

Types [1] can only reason about categories of values, not about values. Tests and types do have an overlap, but the best option is both. Especially when combined with fuzzing, types can exclude large number of cases, making it even more efficient at covering a huge range of code paths.

[1] yeah, there are type systems like lean, coq that can do both, but the proving process is just currently not realistic for everyday applications

> instead of testing for correctness.

Except you can’t test for correctness. Tests can’t prove the absence of bugs.

> it takes the same amount of time

in my experience it doesn't

1. refactoring are in my experience still much faster (and reliable doable) with rust compared to e.g. Js/Python even in presence of a lot of tests. This is a bit less of an point with Java/TS/C# etc. through I had some very bad (and also some good) experiences with refactoring in TS. And to be clear I don't just mean pure refactoring but any larger changes affecting many places in code which might be needed to idk. impl. some feature.

2. especially with Js,Py and similar there are way to many edge cases you can have to test for all of them. Sure most times this mainly matters when writing libraries but on larger projects does apply too. Stupid stuff like you expecting a `list[int]` and someone (externally i.e. outside of your tests) passes a `dict[int, int]` and that happens to work as you current impl. is only linearly iterating it as if it's a `Iterable[int]` but then you change the impl to require a `Sequence[int]` as you access it by index in some corner case and now you customer has really strange subtle bugs. Can't be caught by your tests as the problem is the customer but still breaks the customer which is always bad and can't happen with rust. Sure also won't happen if everyone uses type annotations and mypy correctly and strictly. Through you can't rely on your customer using mypy, but you can rely on your customer running compiler checks (as it's the only way to build the code). Also while mypy is much much much better then pylance it is still prone to issues as both `cast` and `ignore[..]` are things you sometimes need but which easily can hide bugs if the code changes (cast doesn't pin the "from" type and ignore is scoped by place not by what is wrong)

People who say copilot is useless.... I can only imagine they're in a dynamically typed language. Copilot + Rust makes boilerplate go fast. Strong typing is force multiplier for code gen.

I suspect that’s true. I never blindingly copy LLM generated code (that would be recklessly stupid), but I often only quick skim rust code generated this way, just to make sure the general task it is solving is what I asked for. If there is an unhandled edge case or or memory handling bug, rust will catch it.

It's also easier to implement a generate_code -> check_for_errors -> give_error_to_llm -> fix_code loop, because the errors that rust throws at you are most of the time really well thought out, and as succint as usefully possible. Comparing it with python, where you have to write custom parsing to trim it down and even then it's hit and miss on where the actual error lies, it's not even funny.

Rust’s compiler errors is definitely one of the selling points of the language.

>Result<T, E> where E implements Error` and lack of nulls or exceptions

This all goes out the window when people throw “unwrap” all over the place because “this should always succeed”.

Rust does not skirt around the fundamentals. You can still handle errors however you want, you can still blast side effects all over the place, and you still have to uphold an arbitrary set of invariants specific to the task at hand. But the ecosystem as a whole is filled with things being done the right way because the language and its linters have always been quite helpful.

In any program there are errors you can handle and errors you can't, errors whose vary existence suggests something has gone horribly wrong. What else should you do in that situation but panic?

I see unwrap used all of the time on things that could be recoverable if people bothered to write the control flow. “Meh, let the program crash” is easier because unwrap is much less verbose than the match unpacking or carrying results to callers.

Rust has exceptions, they are just named Result and people just as frequently decide not to handle error results as not catch exceptions in my experience.

Typed exceptions are just as good as what rust offers IMO.

> The answer for why folks are so inclined towards doing high-level tasks in Rust... is the type system.

TypeScript has an equally powerful type system.

Python's type system is almost as good.

Both have are significantly more productive when it comes to writing software, and have bigger ecosystems and lower learning curves.

> It makes a lot of progress towards the goal of "make invalid states unrepresentable", which could be really useful for web apps.

TypeScript and Elm are both good at this while being useful for web development today.

> TypeScript has an equally powerful type system.

How does TypeScript's type system prevent shared mutable state?

When did threading get added to JavaScript?

And does Rust have type unions and intersections, interfaces, and mapped and conditional types?

> When did threading get added to JavaScript?

Shared mutable state is a problem even in single threaded code (for example, modifying a collection you're iterating over)

> And does Rust have type unions and intersections, interfaces, and mapped and conditional types?

You can typically accomplish the same thing with enums/proc macros/traits of course—with the additional benefit that the type system is designed to be sound. Soundness is an explicit non-goal of TypeScript[1], so once you start layering on those kinds of overly-clever types, you soon reach a point where you're just lulling yourself into a false sense of security.

[1]: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi...

> Shared mutable state is a problem even in single threaded code (for example, modifying a collection you're iterating over)

...which is an extremely rare source of bugs. The vast majority of errors caused by shared mutable state are related to concurrency.

> usually

So, not always. That is - TypeScript's type system contains features that Rust's does not have.

> which is an extremely rare source of bugs

Confidently asserted, but very debatable.

> The vast majority of errors caused by shared mutable state are related to concurrency.

Concurrency, like async-await, you mean?

> TypeScript's type system contains features that Rust's does not have

Sure, and likewise Rust's type system contains features TypeScript's does not have—for example, just try expressing anything close to traits with TS's type-erased generics. Since the feature sets aren't the same, I suppose it's a matter of opinion which type system is preferable. But I know which one is more helpful for me for sure (especially considering the aforementioned soundness issues).

> which is an extremely rare source of bugs. The vast majority of errors caused by shared mutable state are related to concurrency.

Simply so untrue I’m not going to elaborate further

JS has concurrency (but not parallelism) despite being single-threaded, though.

If you ever put an await anywhere in your code, an arbitrary amount of random stuff might run between the time you await and the time the awaiting finishes.

Same applies to older mechanisms like callbacks and promises.

Race conditions are more rare there because as long as you aren't doing any IO, there is indeed no concurrency, so you can't e.g. get two threads trying to increment a single variable at the same time. They can still happen, though, especially if you accidentally do a partial change to an object, put it in an illegal state, and do IO before you finish that change.

> When did threading get added to JavaScript?

idk. many years ago through stuff like service workers, having shared memory through TypedArrays and similar.

But for the discussion more relevant is that shared mutability constraints do not only matter with threading, they matter with any form of concurrency (like JS async/await/promises and before that callbacks). And even without that you still have other single threaded and single tasked concurrency with the classic being changing a collection while iterating over it. So even without classical forms multi threaded concurrency still very helpful.

> And does Rust have type unions and intersections, interfaces, and mapped and conditional types?

Rusts type system is mainly nominal typed while TS is mainly structural types so it's a bit hard to compare. Like if you nitpick then you could maybe argue that based on TS type system having "features rust types system doesn't have" it's more powerful (but you also could argue the other way around it depends on how you count them). But that would be misleading as it ignores that not only are they two fundamentally different approaches to typing it also ignores that some features are implemented through other means outside of the type system.

Practically having used both I can say that while TS has some things in the typing which are a bit cumbersome to do in rust when it comes to helping me having correct code in context of changes, especially larger changes, and especially libraries Rust still yields better results in my experience. Naturally assuming you don't abuse the TS in either case.

(and to technically answer the question, type unions == yes but different, intersection == no but also make little sense in rust, interfaces == yes but different, mapped types ~= depends on the aspect in some yes and better then TS in other no but implicitly through derives so worse then TS, conditional type ~= again handled through different features depending on usage either associated types or feature gates)

That is done by the compiler, not the type system

How does Rust's type system prevent shared mutable state for out-of-process data common in distributed computing?

It doesn't.

Just curious, which programming language allows preventing shared mutable state for out-of-process data?

None.

As someone who loves both TS and Rust: you couldn't be more wrong. TS is not even half as good at making invalid states unrepresentable.

A simple example of the (many) things you can't do in TS:

    struct StateStart;

    struct StateEnd;

    impl StateStart {
      fn foo(self) -> StateEnd {
        StateEnd
      }
    }

    fn main() {
      let start = StateStart;
      let end = start.foo();
      let another_end = start.foo(); // this won't compile
    }

Try doing that without a runtime crash in TS. Super useful pattern for state machines (which are the building block of computing).

I miss more features of Rust in TS that features of TS in Rust. All the time.

Interesting, great example. This kind of compile time safety can't be achieved without borrow checker, I guess? I'm now thinking hard if there's some type magic similar to the exhaustive checks for Typescript discriminated unions ("kind satisfies never" checks in switch statements).

I've been trying to come up with a similar pattern in TS many times but I think you cannot do this due to the lack of moves (bindings do alias, pass by reference).

But TS has so many dark magical patterns that I'm still hoping to be proven wrong.

Reply on news.ycombinator.com