5 ms·

This is one of the biggest advantages of the newer wave of more expressively typed languages like Rust and Swift. They remove a lot of ambiguity in how somethi

• helltone 2y ago
  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?
  • remexre 2y ago
    Send and Sync are the keywords to search for.
  • metaltyphoon 2y ago
    Isn’t anything with Arc thread safe?
    • ab5tract 2y ago
      Telling when a thing is thread safe is hardly the same as telling when something isn’t.
    • ninkendo 2y ago
      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.)
      • jpc0 2y ago
        > 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.
        • deleted 2y ago
          [deleted]
  • aaomidi 2y ago
    Race conditions within rust are technically impossible :)
    • jrpelkonen 2y ago
      Safe Rust prevents data races, but not race conditions in general.
      • CryZe 2y ago
        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.
      • tialaramex 2y ago
        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).
        • irundebian 2y ago
          Interesting analogy.
      • aaomidi 2y ago
  • dagmx 2y ago
    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 https://doc.rust-lang.org/nomicon/send-and-sync.html So therefore a function can’t do things that invalidate that type level contract.
• layer8 2y ago
  > 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.
  • dagmx 2y ago
    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.
    • layer8 2y ago
      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.
      • dagmx 2y ago
        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.
  • misiek08 2y ago
    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.
• GolDDranks 2y ago
  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.
  • miki123211 2y ago
    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-metric/ https://www.simscale.com/blog/nasa-mars-climate-orbiter-metr...
    • db48x 2y ago
      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.
      • pessimizer 2y ago
        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.
        • 2y ago
• brigadier132 2y ago
  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.
  • tialaramex 2y ago
    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.