28 ms·
> A key tradeoff is that Bronze does not guarantee thread safety Not having data races is one of the key benefits of using Rust, “fearless concurrency” and all
by symmetricsaurus 5y ago
> A key tradeoff is that Bronze does not guarantee thread safety
Not having data races is one of the key benefits of using Rust, “fearless concurrency” and all that. So by throwing away a key guarantee of Rust (no aliasing mutable references), it can become easier for learners to program in. It becomes a bit of an apples and oranges situation at that point.
- hawk_ 5y agoYes pretty much like taking a statically typed language, making compile time type annotations optional and claiming victory that it's easier for beginners. Now they would get runtime exceptions instead.
- anaisbetts 5y agoIt's still valuable to have a language that has better semantics and a more modern standard library than C++, even if it didn't get the benefits of strict memory management. That's still a Useful Thing.
- jeremyjh 5y agoOnce you introduce a garbage collector there are plenty of other languages that provide that while still having expressive type systems and modern features, like Kotlin or C#.
- neutronicus 5y agoYeah, Rust's entire value proposition is that it doesn't lock you into GC
- dathinab 5y agoRusts ownership system has benefits beyond memory management. If I'm a situation where having a GC is ok and there is no "major library ecosystem benefit" (or simlilar) for one of the languages I still would choose rust over Python, JS, TS, Java, Kotlin, Dart, Scala (probably C#, idk. as I haven't used it). The borrow checker is something which cost you once time to learn but if you are fairly familiar with it it normally won't cost you much time (if any). Sure there are still situations in which it can be tricky. But most times they are pretty clear and you can just throw a Clone/Rc/Arc at it and it's normally just fine (the borrow checker is still useful even with managed pointers/collections like Rc/Arc, in a certain way it makes them less error-prone to use, especially in case of more complex types like some thread safe Cow optimized manage pointer type you might find in a library).
- nesarkvechnep 5y agoOr… OCaml.
- notriddle 5y agoIsn't that language called D?
- rhdunn 5y agoThere are two forms of optional type annotations: 1. Using a placeholder (let/var/val/auto/...) -- e.g. in modern C#/Java/C++/Kotlin -- and letting the compiler figure out the type, but keep the actual type known at compile time. This will give you compile time errors when using the wrong types, and keeps the variables of a fixed type. 2. Effectively making all types variant types that can hold any value and can change their type -- e.g. in JavaScript/Python/Ruby -- such that they are dynamically typed. This can lead to runtime errors. For languages like C#, Java and the derivatives, they have the concept where all objects are instances of a common type. If you use this -- especially in collections -- you can also get runtime errors. As long as you stick to the generic versions of these, the compiler will enforce the type safety. The statically typed languages have been making types optional where the compiler can deduce them to avoid redundancy and duplication. If there is an ambiguity, the compiler will omit a compiler error. This is the best of both worlds -- type safety without the noise of annotating types everywhere.
- hawk_ 5y agoMy point here was that this was equivalent to using Object type in Java/C#. Here the data race guarantees of rust type system are elided due to this GC.
- vegai_ 5y agoRather it's like taking a statically typed language and making all type annotations inferrable.
- hawk_ 5y agoIf they were made inferrable, it wouldn't cause runtime exceptions. Here the data race guarantees of rust type system are elided instead.
- fearless_monkey 5y agoThis reminds me of C# sharp and their introduction of the unsafe keyword. gc for everything until you need to manage your own pointers for speed or something.
- pjmlp 5y agoData races across threads, Rust type system does nothing to prevent data races across processes.
- berkes 5y agoWhen can data races across processes happen? Are you talking about databases, services or IO and such?
- knuthsat 5y agoI guess the simplest example is shared memory between processes. Even Python has it: https://docs.python.org/3/library/multiprocessing.shared_memory.html https://docs.python.org/3/library/multiprocessing.shared_mem...
- SCHiM 5y agoAccess to raw memory is locked behind the unsafe keyword though. Rust officially already does not guarantee any safety in that scenario even within 1 process.
- pjmlp 5y agoThere is always unsafe at some level on the standard library. The point is that it doesn't protect the user of a crate that only exposes a fully safe API, unless they do digging to validate overall architecture safety.
- KptMarchewa 5y ago>Even Python It's not "even". Python specifically has it because it has no real threading.
- bjourne 5y agoPython has cooperative threading. It's the same threading model used in the Erlang VM, Julia and many other dynamically typed languages. But preemptive threading vs. cooperative threading is orthogonal to whether data races can happen. Java threads are preemptive but data races can still happen.
- luckystarr 5y agoTrue, yet in the context of the experiment that part of the language was not used, so they could compare the two approaches. I think this research highlights a important strategy to make all software safer. A quote from the discussion section: > Encouraging adoption of safer languages by reducing stress.
- MaulingMonkey 5y agoIt appears in this case that they're encouraging adoption of safer languages by making them unsafe and unsound: https://users.rust-lang.org/t/bronze-gc-and-aliasing-problems/65679 https://users.rust-lang.org/t/bronze-gc-and-aliasing-problem...
- Fiahil 5y agoUsually, you don't start learning a new language with multithreaded operations.. In that sense, adding a gc to rust for single threaded programming, is almost useless : it's not helping that much and you're not learning.
- timeon 5y ago> Usually, you don't start learning a new language with multithreaded operations.. When I have started with rust I was not writing stuff with Box/Rc/Arc... or even explicit lifetimes. Not saying that I was cloning everything but for simple stuff you can come long way with just moving and simple borrowing.
- FpUser 5y agoDue to the type of software I do that is exactly how I look at new language: How it handles concurrency, what kind of synchronization primitives it offers, how it manages lifecycle etc. etc. If it does not provide enough facilities in comprehensible way then it essentially useless to me. I do not learn languages just for the f.. of it.
- einpoklum 5y ago> Usually, you don't start learning a new language with multithreaded operations.. Why not? I mean, maybe not your first ever programming language, but - why should you not get used to doling out work to all available threads to begin with?
- Fiahil 5y agoIf you already have the required experience for writing working multithreaded programs, then learning Rust isn't going to be an issue ! If you don't or are unsure about that, then stick to simpler forms of programming or use type-hinted Python instead. This would the recommendation I would make to anyone asking me that question !
- smabie 5y agoBecause multi-threaded programs are largely unnecessary for solving many problems (as the popularity of python has aptly demonstrated).
- civilized 5y agoDoesn't it seem useful to have one language that can be used at several levels of sophistication?
- jacobr1 5y agoDepends on the tradeoffs. Having different levels of abstraction within the same language can be really useful. But you don't want to overcomplicate the language to support that, especially if it makes operating at different levels more complicated. In this case, it seems like an odd tradeoff to make. The less sophisticated user is exactly the same kind of user that is more likely to foot-gun themselves with a memory or thread-safety issue. The "right" answer is probably a thread-safe garbage collector, but that has its owns set of usability and implementation tradeoffs.
- civilized 5y agoHow does Bronze overcomplicate Rust as a language? It's an optional library, not a language extension. I think it's often pretty easy to not footgun yourself with thread or memory issues, because these issues simply don't exist in wide swaths of application.
- dathinab 5y agoIt's locking you into single threaded usage, but you might very easy run into a library which requires Send bounds, as it uses e.g. rayon internally. And for the cases where having managed pointers are better, Rc/Arc are often (not always) good enough.
- dathinab 5y agoAlso it seems to be fundamentally unsound, the borrow checker isn't limited to making memory is freed correctly and safe multi-threading. But also affects assembly generation! (And is used to makes sure that all kinds of thinks work correctly, even without multi-threading). The library seem to allow creating multiple mutable refs, which is instant UB in rust. I.e. having two mutable refs is already UB even if you only use one at a time. While this is just a PoC it means you can't implement it as a library! Only as a compiler extension which furthermore means a lot of optimizations must behave different if the extension used.. which is quite painful to maintain and prone to introduce compiler bugs.
- zamalek 5y ago> Not having data races is one of the key benefits of using Rust Exactly. Lifetimes, borrowing, etc. are the complexity of thread safety. It's like saying that airplanes are easy to fly, if you replace the airplane with a car.