6 ms·

What that means, though, is that you have a choice between defining memory unsafely away completely with Rust or Swift, or trying to catch memory problems by a

What that means, though, is that you have a choice between defining memory unsafely away completely with Rust or Swift, or trying to catch memory problems by a writing a bunch of additional code in Zig.

TimSchumann 1y ago
I’d argue that ‘a bunch of additional code’ to solve for memory safety is exactly what you’re doing in the ‘defining memory safety away’ example with Rust or Swift. It’s just code you didn’t write and thus likely don’t understand as well. This can potentially lead to performance and/or control flow issues that get incredibly difficult to debug.
- agarren 1y ago
  That sounds a bit unfair. All that code that we neither wrote nor understood, I think in the case of Rust, it’s either the borrow checker or the compiler itself doing something it does best - i.e., “defining memory safety away”. If that’s the case, then labeling such tooling and language-enforced memory safety mechanisms as “a bunch of additional code…you didn’t write and…don’t understand” appears somewhat inaccurate, no?
  - rk06 1y ago
    It is quite fair as far as rust is concerned. For simple data structures, like doubly linked list,are hard problems for rust
    - josephg 1y ago
      So? That wasn't the claim. The GP poster said this: > This can potentially lead to performance and/or control flow issues that get incredibly difficult to debug. Writing a linked list in rust isn't difficult because of control flow issues, or because rust makes code harder to debug. (If you've spent any time in rust, you quickly learn that the opposite is true.) Linked lists are simply a bad match up for the constraints rust's borrow checker puts on your code. In the same way, writing an OS kernel or a high performance b-tree is a hard problem for javascript. So what? Every language has things its bad at. Design your program differently or use a different language.
- josephg 1y ago
  > This can potentially lead to performance and/or control flow issues that get incredibly difficult to debug. The borrow checker only runs at compile-time. It doesn't change the semantic meaning - or the resulting performance - of your code. The borrow checker makes rust a much more difficult and frustrating language to learn. The compiler will refuse to compile your code entirely if you violate its rules. But there's nothing magical going on in the compiler that changes your program. A rust binary is almost identical to the equivalent C binary.
ajross 1y ago
Weird that Swift is your totem for "managed/collected runtime" and not Java (or C#/.NET, or Go, or even Javascript). I mean, it fits the bill, but it's hardly the best didactic choice.
- saagarjha 1y ago
  I don't think they said anything about that?
  - ajross 1y ago
    The point was that basically no one knows Swift, and everyone knows Java. If you want to point out a memory safe language in the "managed garbage-collected runtime" family, you probably shouldn't pick Swift.
    - orobio 1y ago
      I wouldn’t put Swift in the same ‘managed garbage-collected runtime’ family as Java, C#/.NET, Go, and Javascript, so maybe they weren’t trying to do what you think. Swift is more like a native systems programming language that makes it easy to trade performance for ergonomics (and does so by default).
90s_dev 1y ago
What if -- stay with me now -- what if we solved it by just writing vastly less code, and having actually reusable code, instead of reinventing every type of wheel in every project? Maybe that's the real secret to sound code. Actual code reuse. I know it's a pipedream, but a man can dream, can't he?
- codr7 1y ago
  The way we've done code reuse up to this point rarely lives up to its promises. I don't know what the solution is, but these days I'm a lot more likely to simply copy code over to a new project rather than try to build general purpose libraries. I feel like that's part of the mess Rust/Swift are getting themselves tangled up in, everything depends on everything which turns evolution into more and more of an uphill struggle.
  - josephg 1y ago
    Why? In C I'd understand. But cargo and the swift package manager work great. By all means, rewrite little libraries instead of pulling in big ones. But if you're literally copy+pasting code between projects, it doesn't take much work to pull that code out into a shared library.
- 0x6c6f6c 1y ago
  Yeah that is the opposite take of recent posts that the Cargo/npm package dependence is way too heavy. Saying we should rely on reusable modules is great and all, but that reusable code is going to be maintained by who now? There's no sustainable pattern for this yet, most things are good graces of businesses or free time development, many become unmaintained over time- people who actually want to survive on developing and supporting reusable modules alone might actually be more rare than the unicorn devs.
  - 90s_dev 1y ago
    I meant in programming in general, not specific to Rust or Cargo.
- 1y ago

TimSchumann 1y ago

I’d argue that ‘a bunch of additional code’ to solve for memory safety is exactly what you’re doing in the ‘defining memory safety away’ example with Rust or Swift. It’s just code you didn’t write and thus likely don’t understand as well. This can potentially lead to performance and/or control flow issues that get incredibly difficult to debug.

agarren 1y ago
That sounds a bit unfair. All that code that we neither wrote nor understood, I think in the case of Rust, it’s either the borrow checker or the compiler itself doing something it does best - i.e., “defining memory safety away”. If that’s the case, then labeling such tooling and language-enforced memory safety mechanisms as “a bunch of additional code…you didn’t write and…don’t understand” appears somewhat inaccurate, no?
- rk06 1y ago
  It is quite fair as far as rust is concerned. For simple data structures, like doubly linked list,are hard problems for rust
  - josephg 1y ago
    So? That wasn't the claim. The GP poster said this: > This can potentially lead to performance and/or control flow issues that get incredibly difficult to debug. Writing a linked list in rust isn't difficult because of control flow issues, or because rust makes code harder to debug. (If you've spent any time in rust, you quickly learn that the opposite is true.) Linked lists are simply a bad match up for the constraints rust's borrow checker puts on your code. In the same way, writing an OS kernel or a high performance b-tree is a hard problem for javascript. So what? Every language has things its bad at. Design your program differently or use a different language.
josephg 1y ago
> This can potentially lead to performance and/or control flow issues that get incredibly difficult to debug. The borrow checker only runs at compile-time. It doesn't change the semantic meaning - or the resulting performance - of your code. The borrow checker makes rust a much more difficult and frustrating language to learn. The compiler will refuse to compile your code entirely if you violate its rules. But there's nothing magical going on in the compiler that changes your program. A rust binary is almost identical to the equivalent C binary.

ajross 1y ago

Weird that Swift is your totem for "managed/collected runtime" and not Java (or C#/.NET, or Go, or even Javascript). I mean, it fits the bill, but it's hardly the best didactic choice.

saagarjha 1y ago
I don't think they said anything about that?
- ajross 1y ago
  The point was that basically no one knows Swift, and everyone knows Java. If you want to point out a memory safe language in the "managed garbage-collected runtime" family, you probably shouldn't pick Swift.
  - orobio 1y ago
    I wouldn’t put Swift in the same ‘managed garbage-collected runtime’ family as Java, C#/.NET, Go, and Javascript, so maybe they weren’t trying to do what you think. Swift is more like a native systems programming language that makes it easy to trade performance for ergonomics (and does so by default).

90s_dev 1y ago

What if -- stay with me now -- what if we solved it by just writing vastly less code, and having actually reusable code, instead of reinventing every type of wheel in every project? Maybe that's the real secret to sound code. Actual code reuse. I know it's a pipedream, but a man can dream, can't he?

codr7 1y ago
The way we've done code reuse up to this point rarely lives up to its promises. I don't know what the solution is, but these days I'm a lot more likely to simply copy code over to a new project rather than try to build general purpose libraries. I feel like that's part of the mess Rust/Swift are getting themselves tangled up in, everything depends on everything which turns evolution into more and more of an uphill struggle.
- josephg 1y ago
  Why? In C I'd understand. But cargo and the swift package manager work great. By all means, rewrite little libraries instead of pulling in big ones. But if you're literally copy+pasting code between projects, it doesn't take much work to pull that code out into a shared library.
0x6c6f6c 1y ago
Yeah that is the opposite take of recent posts that the Cargo/npm package dependence is way too heavy. Saying we should rely on reusable modules is great and all, but that reusable code is going to be maintained by who now? There's no sustainable pattern for this yet, most things are good graces of businesses or free time development, many become unmaintained over time- people who actually want to survive on developing and supporting reusable modules alone might actually be more rare than the unicorn devs.
- 90s_dev 1y ago
  I meant in programming in general, not specific to Rust or Cargo.
1y ago