5 ms·

Rust instead is too far on the side of C++ I have tried to like the language, but sadly having to think about types and lifetimes robs precious energy which sh

Rust instead is too far on the side of C++ I have tried to like the language, but sadly having to think about types and lifetimes robs precious energy which should be devoted to thinking about business rules and what am I actually trying to achieve. In some niches Rust is perfect, but in every language thread on HN there's often someone that suggests to use Rust whatever the use case. C, in that respect, is more flexible and gets out of the way much more, of course while being unsafer, but it's easier to keep your mind on the goal and not figuring out the best memory safe approach for this piece of logic. Which is why I'm very excited for Zig. I don't want another C++. Give me safer C, thanks.

adrianN 6y ago
In C you also have to think about lifetimes and types, only that the compiler is helping you a lot less to get things right.
- 1_player 6y ago
  Of course, but you don't need a lot of work to make the C compiler happy. The result might not be 100% safe, secure and mathematically proven, but sometimes you need to deliver, fast, not create the safest 1k lines of code on Earth. To be honest I haven't used C in a long time, but I've been looking for a low level language that sparks as much joy as C does. Go, Rust ain't it, IMO.
- flukus 6y ago
  In C you have to think about lifetimes (and to a lesser extent types) at specific times, typically after the "make it work" step of writing code. Rust on the other hand forces you to think of these things from the start and this inhibits solving the actual problem first. Now there's an argument the front loading these decisions may be beneficial overall but I don't find that compelling either. After the "make it work" stage there's thinking about performance, comments, logging, etc and you usually need to think about lifetimes as they change at this point as well, so front loading it has only added work overall.
  - tene 6y ago
    This description doesn't match my experience of writing Rust at all. During the exploratory phase of my projects, I very rarely run into nontrivial lifetime issues, and when I do, I can just put whatever data into an Arc and then it just works. Most of my exploratory code is just objects that own their data. Later in a project, while doing a bunch of refactoring to handle performance, logging, etc. , I have a much easier time letting the compiler tell me when I've made mistakes with a value's lifetime rather than trying to keep the whole program in my head for the duration of the refactor. I don't spend a lot of time thinking about lifetime issues during either phase of my projects. Mostly I just write the same sort of thing that I'd have written in other languages, and the compiler tells me when I've made a mistake.
orthoxerox 6y ago
> I have tried to like the language, but sadly having to think about types and lifetimes robs precious energy which should be devoted to thinking about business rules and what am I actually trying to achieve. I've always wanted a "shut up about memory safety for a while, just don't free anything, I want to find out if my code produces the right answer" mode in rustc.
the_duke 6y ago
I totally agree that Rust isn't the right language for every domain. But especially in all those domains where memory safety is an issue , in my view it is currently the best option. Rust forces you to think about memory safet and ownership, which is hard to adjust to for many. But it does so for a good reason. In C you also have to think about lifetimes all the time, but the compiler let's you do whatever you want , and the issues instead have to get fixed when bugs pop up, or with static analysis tooling, etc. "I don't want to think about lifetimes" is exactly how we end up with vulnet and buggy software. After the initial learning curve, Rust is a very productive language, exactly thanks to the powerful type system. Like I said, I do wish for a simpler language that can provide similar guarantees, and I do think the design space is in reach, but Zig is (currently) not it.
- jorangreef 6y ago
  If we are talking of domains where memory safety is an issue, then surely the category of memory safety must include OOM-safety? i.e. Safe handling of out-of-memory conditions under overload?
  - saagarjha 6y ago
    Sure, but crashing cleanly in out-of-memory conditions is generally regard to be "safe" (if undesirable for reliability).
    - jorangreef 6y ago
      I personally like panics and assertions, but the "safety" of the approach would still have to depend on the characteristics of the system. I do not agree that panic-on-OOM should be considered "safe" at a global level hidden within a std lib, where there is no knowledge of the target domain. For example, if an attacker could arbitrarily inject overload to restart rate-limiting processes and then abuse this to trivially brute-force OTP logins. The definition of safety with respect to a resource in general always needs to include the safety of the system as it crosses the threshold i.e. in this case into out-of-memory, so if a system claims memory safety, the first thing I would want to ask is, what about OOMs?
square_usual 6y ago
This might just be me being naive, but if you have a business-rules heavy project, why not just use a garbage collected language? I can't think of many use cases where you need a systems programming non-GC language but also have to write tons of custom business logic.
- 1_player 6y ago
  Indeed I do, these days I spend most of my time on Elixir. But it's handy to have a lower level language that can compile statically for some complex sysadmin task. Go is fine, but a little too plain for my tastes.
- jorangreef 6y ago
  Because, for example, a business-rules heavy project would also benefit from type safety and from a compiler that checks that return values are not ignored, that variables are defined correctly and not shadowed, and that errors are all handled. I'm not sure if there are many GC'ed languages that would do all that? These kinds of safety guarantees tend to come from compiled languages not GC'ed languages. Beyond the correctness argument, also because the GC can really come back to bite you when you least expect, following the sudden "knee" of Little's Law. I've seen multi-minute pauses every few seconds even with V8's GC in production and it was not a pleasant experience. It cropped up, out of the blue, and in the end required a V8 core team member to advise and help comment out a few lines of C++ GC code that were overzealous.
  - creata 6y ago
    In your first paragraph, you seem to be confusing interpreted languages and GC'd languages. Even Java has all of the features you've listed above, afaict.
    - jorangreef 6y ago
      Yes, I was thinking of Java, which is why I said not "many" and "tend".
  - 6y ago
littlestymaar 6y ago
> but sadly having to think about types and lifetimes robs precious energy which should be devoted to thinking about business rules and what am I actually trying to achieve. That's a really strange argument, because as soon as you're not in a GCed language, you need to think about the lifetime of your objects. The big difference with Rust is that you can't make mistakes when doing so, because the compiler will catch it. You don't have the mental burden that if you make a mistake everything will blow up and you can focus on your business rules instead.

adrianN 6y ago

In C you also have to think about lifetimes and types, only that the compiler is helping you a lot less to get things right.

1_player 6y ago
Of course, but you don't need a lot of work to make the C compiler happy. The result might not be 100% safe, secure and mathematically proven, but sometimes you need to deliver, fast, not create the safest 1k lines of code on Earth. To be honest I haven't used C in a long time, but I've been looking for a low level language that sparks as much joy as C does. Go, Rust ain't it, IMO.
flukus 6y ago
In C you have to think about lifetimes (and to a lesser extent types) at specific times, typically after the "make it work" step of writing code. Rust on the other hand forces you to think of these things from the start and this inhibits solving the actual problem first. Now there's an argument the front loading these decisions may be beneficial overall but I don't find that compelling either. After the "make it work" stage there's thinking about performance, comments, logging, etc and you usually need to think about lifetimes as they change at this point as well, so front loading it has only added work overall.
- tene 6y ago
  This description doesn't match my experience of writing Rust at all. During the exploratory phase of my projects, I very rarely run into nontrivial lifetime issues, and when I do, I can just put whatever data into an Arc and then it just works. Most of my exploratory code is just objects that own their data. Later in a project, while doing a bunch of refactoring to handle performance, logging, etc. , I have a much easier time letting the compiler tell me when I've made mistakes with a value's lifetime rather than trying to keep the whole program in my head for the duration of the refactor. I don't spend a lot of time thinking about lifetime issues during either phase of my projects. Mostly I just write the same sort of thing that I'd have written in other languages, and the compiler tells me when I've made a mistake.

orthoxerox 6y ago

> I have tried to like the language, but sadly having to think about types and lifetimes robs precious energy which should be devoted to thinking about business rules and what am I actually trying to achieve. I've always wanted a "shut up about memory safety for a while, just don't free anything, I want to find out if my code produces the right answer" mode in rustc.

the_duke 6y ago

I totally agree that Rust isn't the right language for every domain. But especially in all those domains where memory safety is an issue , in my view it is currently the best option. Rust forces you to think about memory safet and ownership, which is hard to adjust to for many. But it does so for a good reason. In C you also have to think about lifetimes all the time, but the compiler let's you do whatever you want , and the issues instead have to get fixed when bugs pop up, or with static analysis tooling, etc. "I don't want to think about lifetimes" is exactly how we end up with vulnet and buggy software. After the initial learning curve, Rust is a very productive language, exactly thanks to the powerful type system. Like I said, I do wish for a simpler language that can provide similar guarantees, and I do think the design space is in reach, but Zig is (currently) not it.

jorangreef 6y ago
If we are talking of domains where memory safety is an issue, then surely the category of memory safety must include OOM-safety? i.e. Safe handling of out-of-memory conditions under overload?
- saagarjha 6y ago
  Sure, but crashing cleanly in out-of-memory conditions is generally regard to be "safe" (if undesirable for reliability).
  - jorangreef 6y ago
    I personally like panics and assertions, but the "safety" of the approach would still have to depend on the characteristics of the system. I do not agree that panic-on-OOM should be considered "safe" at a global level hidden within a std lib, where there is no knowledge of the target domain. For example, if an attacker could arbitrarily inject overload to restart rate-limiting processes and then abuse this to trivially brute-force OTP logins. The definition of safety with respect to a resource in general always needs to include the safety of the system as it crosses the threshold i.e. in this case into out-of-memory, so if a system claims memory safety, the first thing I would want to ask is, what about OOMs?

square_usual 6y ago

This might just be me being naive, but if you have a business-rules heavy project, why not just use a garbage collected language? I can't think of many use cases where you need a systems programming non-GC language but also have to write tons of custom business logic.

1_player 6y ago
Indeed I do, these days I spend most of my time on Elixir. But it's handy to have a lower level language that can compile statically for some complex sysadmin task. Go is fine, but a little too plain for my tastes.
jorangreef 6y ago
Because, for example, a business-rules heavy project would also benefit from type safety and from a compiler that checks that return values are not ignored, that variables are defined correctly and not shadowed, and that errors are all handled. I'm not sure if there are many GC'ed languages that would do all that? These kinds of safety guarantees tend to come from compiled languages not GC'ed languages. Beyond the correctness argument, also because the GC can really come back to bite you when you least expect, following the sudden "knee" of Little's Law. I've seen multi-minute pauses every few seconds even with V8's GC in production and it was not a pleasant experience. It cropped up, out of the blue, and in the end required a V8 core team member to advise and help comment out a few lines of C++ GC code that were overzealous.
- creata 6y ago
  In your first paragraph, you seem to be confusing interpreted languages and GC'd languages. Even Java has all of the features you've listed above, afaict.
  - jorangreef 6y ago
    Yes, I was thinking of Java, which is why I said not "many" and "tend".
- 6y ago

littlestymaar 6y ago

> but sadly having to think about types and lifetimes robs precious energy which should be devoted to thinking about business rules and what am I actually trying to achieve. That's a really strange argument, because as soon as you're not in a GCed language, you need to think about the lifetime of your objects. The big difference with Rust is that you can't make mistakes when doing so, because the compiler will catch it. You don't have the mental burden that if you make a mistake everything will blow up and you can focus on your business rules instead.