3 ms·

Rust is becoming less special in this area. Languages such as Dlang, Vlang, and Julia have added optional ownership and borrowing. As these offerings are option

by baranul 6mo ago

Rust is becoming less special in this area. Languages such as Dlang, Vlang, and Julia have added optional ownership and borrowing. As these offerings are optional, many can see this as greater programmer freedom to decide what to use for their projects, with languages that are easier to use or read.

bcjdjsndon 6mo ago
[flagged]
- b40d-48b2-979e 6mo ago
  Rust already has.
- kibwen 6mo ago
  The point of Rust, without counting `unsafe`, is to eliminate memory errors at compile-time. But the point of Rust, when including `unsafe`, is not to entirely eliminate memory errors at compile-time, but to make it feasible to cordon off the unsafe parts into realistically-auditable sections with documented safety invariants. At this it has been dramatically successful, almost beyond anyone's wildest hopes. I have worked on embedded, bare-metal Rust codebases (i.e. the codebases you would most expect to have to do grotty memory faffing) with fewer than 5% of files containing `unsafe` blocks, whereas high-level unsafe code usually has no `unsafe` blocks whatsoever. It's an incredible force multiplier for writing correct low-level code.
  - bcjdjsndon 6mo ago
    > without counting `unsafe`, Well, if you exclude all the bad code people have wrote, c is a safe language... See the point I'm making here? If coders couldn't be trusted multiple times in the past, and we had to invent language level features to correct them, but they still continued to make either the same, or a new, mistakes.... Why is rust any different? I guarantee you we will be complaining about unsafe rust in the future because rust doesnt really bring anything new to the table other than trivial cases that were easy to code in the first place. Rust brings you nothing a c coder couldn't already do in c.... They haven't solved the enduring problems of computer science, they have simply kicked the can down the road
    - reorder9695 6mo ago
      The difference I see there is any line in a C codebase could have these issues, whereas in Rust they're specifically marked as unsafe sections, with the language having a clear list of invariants it expects the programmer to uphold in an unsafe block. Additionally Rust has a culture of developers specifically justifying the unsafe block and why it's correct in comments. It's a massive reduction of the scope of the code that needs audited, that doesn't mean there can't be mistakes in it, just that it's easier to verify certain properties of the whole codebase.
      - bcjdjsndon 6mo ago
        > The difference I see there is any line in a C codebase could have these issues Not true. > Additionally Rust has a culture of developers specifically justifying the unsafe block and why it's correct in comments Yeah, if your on the message board. Wait til rust hits real world levels of usage and shit code begins to emerge.... It's easy to sit on that pedestal when your essentially a novelty language in comparison to amount of legacy code in production
    - kibwen 6mo ago
      > Well, if you exclude all the bad code people have wrote Nobody is doing this. Please read my comment again.
    - filleduchaos 6mo ago
      In general it helps if you read past the first six words of what someone says before responding.
    - imtringued 6mo ago
      Even if you think having better developers would prevent the problem, the average Rust developer is probably better at writing bug free unsafe code than the average C developer.
- zigzag312 6mo ago
  Handling of exceptions is not enforced at compile time, while ownership is. Better example might be statically typed languages. They were harder to use at first, but now with good type inference and features like generics, they are much more ergonomic than at first. The accessibility gap between static and dynamic languages has narrowed with time and maybe we can expect that user-friendliness of ownership will also improve like that.
- vlovich123 6mo ago
  I’ve marked your words, but I think you have to eat them. Studies by Microsoft and Google have already been done on this and Rust provides real tangible benefits. No one has ever claimed Rust eliminates all memory errors (if that’s the bar you’re setting), but it makes them vanishingly unlikely, even when you include the prescience of unsafe, thus “eliminating” memory errors (most, not all): > Memory safety issues, which accounted for 76% of Android vulnerabilities in 2019, and are currently 24% in 2024, well below the 70% industry norm, and continuing to drop. The old adage is important: do not left perfect be the enemy of good. https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html?m=1 https://security.googleblog.com/2024/09/eliminating-memory-s...
  - bcjdjsndon 6mo ago
    [flagged]
embedding-shape 6mo ago
> Rust is becoming less special in this area. Languages such as Dlang, Vlang, and Julia have added optional ownership and borrowing Isn't the crux that Rust does those things without a garbage collector, that's the novel part? Someone correct me if I'm wrong (likely), but I think all those languages have garbage collectors, which Rust doesn't.
- digikata 6mo ago
  Yes, it's a critical distinction that's important in many systems domains, but getting some form of ownership policy and method - even if implemented with a GC I think is a step forward in terms of building reliable code. The thing about it being optional in some languages is that it's an experiment, but one that as a feature it really pays off the more code in the ecosystem is compliant to ownership tracking. For rust, it's the vast majority of it (with opt out explicitly findable..) For languages offering it optionally, it's harder to assemble the full benefit.
- baranul 6mo ago
  > without a garbage collector, that's the novel part? That's not quite how it works in various languages. You appear to be thinking of the garbage collector as something inseparable from the language. Both Dlang and Vlang have optional garbage collectors, that can be turned off. In the case of Vlang, none of its libraries depend on the garbage collector. Vlang offers optional (flexible) memory management, somewhat similar to Nim (but they presently don't have optional ownership). In the case of Julia and Vlang, their optional ownership is new and experimental. Dlang's optional ownership has been around for some years now, showing that it could be done. Dlang and Vlang allow you to choose the type of memory management (along with some other languages) that you would like to use. Vlang does it by command line flags. You can turn off garbage collection and turn on ownership.
  - treyd 6mo ago
    > Both Dlang and Vlang have optional garbage collectors, that can be turned off. Until you need a library that was written with the assumption of using a garbage collector.
kibwen 6mo ago
It's not a question of support, it's a question of defaults. Rust code exercises a single-ownership discipline by default, and you must opt-in to dynamic multi-ownership (via refcounting or otherwise). In languages that have pervasive dynamic multi-ownership by default (via GC, etc.), enforced single-ownership is instead opt-in, which means that you cannot expect code in the wild to use it. In Rust, you can expect code in the wild to exhibit a single-ownership discipline; that's just the prevailing style for Rust code, as encouraged by the design of the language itself. In fact, we can see this "defaults matter" problem in Rust as well. Note that Rust by-default assumes that code is running in a context where a dynamic allocator is available, but allows one to opt-out of this ("no_std" mode). Code written for embedded devices or baremetal contexts uniformly opt into this mode, but because it's not the default, you can't just pull any old library off the shelf and expect it to work for you, so the ecosystem is much smaller and less mature. Defaults matter.
- baranul 6mo ago
  True, defaults matter. In many cases, however, using a language that defaults to a GC for memory safety is often preferable or easier. The argument is often about when ownership and borrowing is truly necessary. Rust has its uses, but arguably not all the time and with everything, because of its defaults.
  - kibwen 6mo ago
    I'm going to thoughtfully disagree here. The more I use Rust, the more I feel like we got it wrong all the way back in the mists of ALGOL, and that copy-by-default (which, in (non-immutable) managed languages, translates to multi-ownership-by-default) was a mistake in the same league as null. Being able to convincingly express resource consumption in a first-class way is just too broadly useful, IMO. Certainly we can imagine a "high-level Rust" that doesn't make you care so much about pointers and the stack/heap distinction, but I still think such a language would want to make single-ownership the default. To that end, rather than any of the aforementioned languages, I'll suggest Austral as looking fairly interesting, although it's still far from high-level: https://austral-lang.org/ https://austral-lang.org/
  - 6mo ago
pjmlp 6mo ago
This is the way forward, convenient automatic resource management, with improved type systems for low level coding. In various forms, affine types, linear types, dependent types, effects, formal proofs. The list is already rather long, D, Chapel, Swift, Linear Haskell, Ox, OCaml, Koka, Ada/SPARK, Mojo,...

by baranul 6mo ago

bcjdjsndon 6mo ago

[flagged]

b40d-48b2-979e 6mo ago
Rust already has.
kibwen 6mo ago
The point of Rust, without counting `unsafe`, is to eliminate memory errors at compile-time. But the point of Rust, when including `unsafe`, is not to entirely eliminate memory errors at compile-time, but to make it feasible to cordon off the unsafe parts into realistically-auditable sections with documented safety invariants. At this it has been dramatically successful, almost beyond anyone's wildest hopes. I have worked on embedded, bare-metal Rust codebases (i.e. the codebases you would most expect to have to do grotty memory faffing) with fewer than 5% of files containing `unsafe` blocks, whereas high-level unsafe code usually has no `unsafe` blocks whatsoever. It's an incredible force multiplier for writing correct low-level code.
- bcjdjsndon 6mo ago
  > without counting `unsafe`, Well, if you exclude all the bad code people have wrote, c is a safe language... See the point I'm making here? If coders couldn't be trusted multiple times in the past, and we had to invent language level features to correct them, but they still continued to make either the same, or a new, mistakes.... Why is rust any different? I guarantee you we will be complaining about unsafe rust in the future because rust doesnt really bring anything new to the table other than trivial cases that were easy to code in the first place. Rust brings you nothing a c coder couldn't already do in c.... They haven't solved the enduring problems of computer science, they have simply kicked the can down the road
  - reorder9695 6mo ago
    The difference I see there is any line in a C codebase could have these issues, whereas in Rust they're specifically marked as unsafe sections, with the language having a clear list of invariants it expects the programmer to uphold in an unsafe block. Additionally Rust has a culture of developers specifically justifying the unsafe block and why it's correct in comments. It's a massive reduction of the scope of the code that needs audited, that doesn't mean there can't be mistakes in it, just that it's easier to verify certain properties of the whole codebase.
    - bcjdjsndon 6mo ago
      > The difference I see there is any line in a C codebase could have these issues Not true. > Additionally Rust has a culture of developers specifically justifying the unsafe block and why it's correct in comments Yeah, if your on the message board. Wait til rust hits real world levels of usage and shit code begins to emerge.... It's easy to sit on that pedestal when your essentially a novelty language in comparison to amount of legacy code in production
  - kibwen 6mo ago
    > Well, if you exclude all the bad code people have wrote Nobody is doing this. Please read my comment again.
  - filleduchaos 6mo ago
    In general it helps if you read past the first six words of what someone says before responding.
  - imtringued 6mo ago
    Even if you think having better developers would prevent the problem, the average Rust developer is probably better at writing bug free unsafe code than the average C developer.
zigzag312 6mo ago
Handling of exceptions is not enforced at compile time, while ownership is. Better example might be statically typed languages. They were harder to use at first, but now with good type inference and features like generics, they are much more ergonomic than at first. The accessibility gap between static and dynamic languages has narrowed with time and maybe we can expect that user-friendliness of ownership will also improve like that.
vlovich123 6mo ago
I’ve marked your words, but I think you have to eat them. Studies by Microsoft and Google have already been done on this and Rust provides real tangible benefits. No one has ever claimed Rust eliminates all memory errors (if that’s the bar you’re setting), but it makes them vanishingly unlikely, even when you include the prescience of unsafe, thus “eliminating” memory errors (most, not all): > Memory safety issues, which accounted for 76% of Android vulnerabilities in 2019, and are currently 24% in 2024, well below the 70% industry norm, and continuing to drop. The old adage is important: do not left perfect be the enemy of good. https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html?m=1 https://security.googleblog.com/2024/09/eliminating-memory-s...
- bcjdjsndon 6mo ago
  [flagged]

embedding-shape 6mo ago

> Rust is becoming less special in this area. Languages such as Dlang, Vlang, and Julia have added optional ownership and borrowing Isn't the crux that Rust does those things without a garbage collector, that's the novel part? Someone correct me if I'm wrong (likely), but I think all those languages have garbage collectors, which Rust doesn't.

digikata 6mo ago
Yes, it's a critical distinction that's important in many systems domains, but getting some form of ownership policy and method - even if implemented with a GC I think is a step forward in terms of building reliable code. The thing about it being optional in some languages is that it's an experiment, but one that as a feature it really pays off the more code in the ecosystem is compliant to ownership tracking. For rust, it's the vast majority of it (with opt out explicitly findable..) For languages offering it optionally, it's harder to assemble the full benefit.
baranul 6mo ago
> without a garbage collector, that's the novel part? That's not quite how it works in various languages. You appear to be thinking of the garbage collector as something inseparable from the language. Both Dlang and Vlang have optional garbage collectors, that can be turned off. In the case of Vlang, none of its libraries depend on the garbage collector. Vlang offers optional (flexible) memory management, somewhat similar to Nim (but they presently don't have optional ownership). In the case of Julia and Vlang, their optional ownership is new and experimental. Dlang's optional ownership has been around for some years now, showing that it could be done. Dlang and Vlang allow you to choose the type of memory management (along with some other languages) that you would like to use. Vlang does it by command line flags. You can turn off garbage collection and turn on ownership.
- treyd 6mo ago
  > Both Dlang and Vlang have optional garbage collectors, that can be turned off. Until you need a library that was written with the assumption of using a garbage collector.

kibwen 6mo ago

It's not a question of support, it's a question of defaults. Rust code exercises a single-ownership discipline by default, and you must opt-in to dynamic multi-ownership (via refcounting or otherwise). In languages that have pervasive dynamic multi-ownership by default (via GC, etc.), enforced single-ownership is instead opt-in, which means that you cannot expect code in the wild to use it. In Rust, you can expect code in the wild to exhibit a single-ownership discipline; that's just the prevailing style for Rust code, as encouraged by the design of the language itself. In fact, we can see this "defaults matter" problem in Rust as well. Note that Rust by-default assumes that code is running in a context where a dynamic allocator is available, but allows one to opt-out of this ("no_std" mode). Code written for embedded devices or baremetal contexts uniformly opt into this mode, but because it's not the default, you can't just pull any old library off the shelf and expect it to work for you, so the ecosystem is much smaller and less mature. Defaults matter.

baranul 6mo ago
True, defaults matter. In many cases, however, using a language that defaults to a GC for memory safety is often preferable or easier. The argument is often about when ownership and borrowing is truly necessary. Rust has its uses, but arguably not all the time and with everything, because of its defaults.
- kibwen 6mo ago
  I'm going to thoughtfully disagree here. The more I use Rust, the more I feel like we got it wrong all the way back in the mists of ALGOL, and that copy-by-default (which, in (non-immutable) managed languages, translates to multi-ownership-by-default) was a mistake in the same league as null. Being able to convincingly express resource consumption in a first-class way is just too broadly useful, IMO. Certainly we can imagine a "high-level Rust" that doesn't make you care so much about pointers and the stack/heap distinction, but I still think such a language would want to make single-ownership the default. To that end, rather than any of the aforementioned languages, I'll suggest Austral as looking fairly interesting, although it's still far from high-level: https://austral-lang.org/ https://austral-lang.org/
- 6mo ago

pjmlp 6mo ago

This is the way forward, convenient automatic resource management, with improved type systems for low level coding. In various forms, affine types, linear types, dependent types, effects, formal proofs. The list is already rather long, D, Chapel, Swift, Linear Haskell, Ox, OCaml, Koka, Ada/SPARK, Mojo,...