It's not _just_ memory safety. In my experience, Rust is also liberating in the sense of mutation safety. With memory safe languages such as Java or Python or JavaScript, I must paranoidly clone stuff when passing stuff to various functions whose behaviour I don't intimately know of, and that is a source of constant stress for me.

Also newtype wrappers.

If you have code that deals e.g. with pounds and kilograms, Dollars and Euros, screen coordinates and window coordinates, plain text and HTML and so on, those values are usually encapsulated in safe wrapper structs instead of being passed as raw ints or floats.

This prevents you from accidentally passing the wrong kind of value into a function, and potentially blowing up your $125 million spacecraft[1].

I also find that such wrappers also make the code far more readable, as there's no confusion exactly what kind of value is expected.

[1] https://www.simscale.com/blog/nasa-mars-climate-orbiter-metr...

As much as I like Rust, I don’t think that it would have solved the Mars Climate Orbiter problem. That was caused by one party writing numbers out into a CSV file in one unit, and a different party reading the CSV file but assuming that the numbers were in a different unit. Both parties could have been using Rust, and using types to encode physical units, and the problem could still have happened.

Yeah, even an extremely powerful units type system like C++ mp-units doesn't fix "I assumed this number was feet and you assumed it was millimetres".

But both the mp-units and this lighter weight Rust approach would at least make you write that down in the software. There's some chance the mistake is realised, whereas when it's just an organisational assumption that just doesn't happen.

W3C CSVW supports per-column schema.

Serialize a dict containing a value with uncertainties and/or Pint (or astropy.units) and complex values to JSON, then read it from JSON back to the same types. Handle datetimes, complex values, and categoricals

"CSVW: CSV on the Web" https://github.com/jazzband/tablib/issues/305

7 Columnar metadata header rows for a CSV: column label, property URI, datatype, quantity/unit, accuracy, precision, significant figures https://wrdrd.github.io/docs/consulting/linkedreproducibilit...

CSV on the Web: A Primer > 6. Advanced Use > 6.1 How do you support units of measure? https://www.w3.org/TR/tabular-data-primer/#units-of-measure

You can specify units in a CSVW file with QUDT, an RDFS schema and vocabulary for Quantities, Units, Dimensions, and Types

Schema.org has StructuredValue and rdfs:subPropertyOf like QuantitativeValue and QuantitativeValueDistribution: https://schema.org/StructuredValue

There are linked data schema for units, and there are various in-code in-RAM typed primitive and compound type serialization libraries for various programming languages; but they're not integrated, so we're unable to share data with units between apps and fall back to CSVW.

There are zero-copy solutions for sharing variables between cells of e.g. a polyglot notebook with input cells written in more than one programing language without reshaping or serializing.

Unless the unit was part of the type, and why wouldn't it be? A unit error is a type error. You don't have to say that something is 5 long, you can say that it's 5 inches long. And the function can be made only to accept a length in inches, and you can implement :Into<Inches> on your length type for an automagic conversion.

That wouldn't be enough unless the csv somehow kept serialized column type in the header and the deserializer knew how to interpret it.

Of course, but that doesn’t solve the problem. The problem here is that two separate organizations with completely different software were communicating via CSV file. There was a contractual obligation between them that required them to use specific units, but no technical collaboration. The problem was not in their software, but in the management and engineering discipline of the two groups.

> prevents you from accidentally passing the wrong kind of value into a function,

You can do this in other languages such as Pascal with subtypes and something functionally equivalent in C# and other object oriented languages.

I do not think the claim was that this is a unique construct to Rust.

IMO, this is one of the most underrated advantages of Rust over most (all I've used) alternatives. Mutation is explicit/principle-of-least-surprise.

> This is every codebase that doesn’t use a memory safe language.

Many of the same problems — the mentioned underdocumented API assumptions — exist in memory-safe languages like Java and C#. Memory safety is just one among many aspects in interface contracts, and is actually often one of the better documented ones in non-memory-safe languages.

Type-based checking is of course very beneficial, but TFA specifically focuses on the documentation aspect, not on the enforcement, which are in principle orthogonal to each other. TFA draws attention to the fact that the enforcement here also entails better self-documentation. However, it’s limited to whatever aspects the type system enforces.

For project like this one - it would be cumbersome, but proper Java is also solving the problem. Currently we write code without all throws definitions, because those are handled by Spring-like monsters or other libraries, but having method definied with LockedEx, NullPointerEx etc. is even more friendly as doc generation. Funny, but I don’t like Java that much, but it’s one of those languages also solving documentation problems here.

Yes I know it’s "faster-development" to have type instead of additional definition attributes, but I think the problem would be also solved.

The posted link talks about how the types act as documentation, and in turn enforce it. I’d recommend reading the whole thread that someone else posted below.

I was criticizing your incorrect inference “memory-safe language => better-enforced API contract”. The only thing memory-safe languages do in that context is to remove a single aspect from the universe of things that can be ambiguous in an API, and they also don’t cause anything else to be enforced. (Rust does more, but that’s because of properties beyond mere memory-safety.) In other words, “memory-safe language” doesn’t mean what you want it to mean.

Jeez, there’s a whole comment above that explaining the context and caveating it with the needs of robust type system too.

If you’re pedantically holding on to one sentence as a gotcha, because I didn’t caveat everything, then fine. But seems a bit much to then say I’m forcing a definition just because you ignore the rest.

The way I like to think of it is as follows:

There is a space of all possible programs that can be written. Every time you add a restriction like the borrow checker, more expressive data types, or immutability, you are shrinking the space of all possible programs you can write. Sure, some of those programs are correct but 99.9999% repeating are incorrect.

Right, we can and in some domains we absolutely should, prefer languages which are specialised to only be able to express programs which match some simple model of what we intended. You cannot invent a wholly new idea this way, but you often don't want new ideas.

WUFFS is an example of this, the WUFFS JPEG decoder decodes JPEGs, duh, but even if you deliberately sabotaged it, your sabotaged decoder just... decodes JPEGs wrong, maybe now they all decode to the Goatse image. It not only can't escape to execute arbitrary code, it can't do much of anything outside of the task we intended, all the resulting runtime bugs (for which you need unit tests) are things like oops the grass is blue, or the decoder rejects this 1x1 image even though it's valid. No "Segfault" no "Ooh it truncated the file instead of reading it", those aren't things we want, so no need to be able to express them.

For example I think a lot of big data work could use such a language. Data goes in, processing happens, data comes out. No "Oops, it wiped the hard disk on nodes 6, 18 and 24, I wonder why". No weird interactions with the OS that weren't catered for, just data in, processing, data out, which is what the people using these things always want.

I didn't know rust was able to tell when a method is thread safe. Where can I read more about that/try it out?

It’s probably more correct if I say that data types themselves are thread safe or not.

https://doc.rust-lang.org/nomicon/send-and-sync.html

So therefore a function can’t do things that invalidate that type level contract.

Send and Sync are the keywords to search for.

Isn’t anything with Arc thread safe?

No. Just because something’s behind an Arc<T> doesn’t mean two threads can hold it at once. Arc just ensures that it is freed (dropped) when no threads are using it any more. T itself has to be Send+Sync for Arc to be.

To a first approximation, Arc<Mutex<T>> is what you want when you want a blob of mutable stuff to just work between threads, but you still have to worry about terrible performance if you hold the mutexes too long, etc. (Not to mention mutexes are just slower in general than having types which are natively Send+Sync.)

> Not to mention mutexes are just slower in general than having types which are natively Send+Sync

Without knowing the implementation, how would you know this statement is true?

I could just stick the Arc<Mutex<T>> within my abstraction and say it is send+sync and it would have the exact same performance, and that might be the most efficient solution possible on the given hardware.

Telling when a thing is thread safe is hardly the same as telling when something isn’t.

Race conditions within rust are technically impossible :)

Safe Rust prevents data races, but not race conditions in general.

Though arguably, the fact that in order to mutate data from multiple threads, the compiler,forces you to use some synchronization primitive, results in you having to think about how you are going to synchronize access, which should lower the chance of race condition bugs overall.

The analogy I find helpful for this is, you let the cat out your front door and close it. You walk to the back door and close that too.

A race condition (which safe Rust can have) is a normal phenemenon in our world. If we put the cat out the front door, then walk to the kitchen and close that door by the time we reached the back door maybe the cat had run around the outside of the building and come inside again, closing the doors in the wrong order introduced the opportunity for a race - be very careful.

A data race (which safe Rust does not have) is a weird thing caused by the mismatch between how you think the computer works and how it actually works. What happens if Alice tries the put the cat out the front door at the same time Bob tries to put it out the back door? Well, in the real world that cannot happen, either Alice has the cat or Bob does. But for many languages† this sort of nonsense can happen and when it does that's a disaster

† In safe Rust it can't happen, in Java, OCaml and Go it can happen, but it may not be a disaster (the details are different for each, it is a bug though).

Interesting analogy.

That’s why I said inside rust. If you bring in external factors then of course it can/will happen.

Hmmm, no.

https://stackoverflow.com/questions/31912781/why-doesnt-the-...