8 ms·

>(...) despite my experience and best intentions, I was in fact making mistakes with C. Subtle leaks, use-after-free,(...) Rust made it very clear that I was no

>(...) despite my experience and best intentions, I was in fact making mistakes with C. Subtle leaks, use-after-free,(...) Rust made it very clear that I was not the programmer I thought I was. This really resonated with me. I feel a lot more confident writing code in Rust than say in C or Java. However, in my opinion, it also comes with a downside: These days, whenever I use a 'more forgiving' programming language I find myself being much more paranoid of the code that I write. Even after double checking everything I still miss the memory guarantees that Rust brings, and end up spending a lot of time making sure things are behaving the way they should.

eventhorizonpl 4y ago
Do you pine for the nice days of C/C++, when men were men and spend hours on debugging segmentation faults?
- p0nce 4y ago
  This is quite rare in C++ since C++11.
- mbrodersen 4y ago
  I am a professional C++ programmer and I can’t even remember the last time I had a segfault. I also haven’t had a bug in production the last 5 years. But YMMV of course.
- farseer 4y ago
  Sticking to STL in C++ and avoiding pointers unless really necessary will significantly cut down on segmentation faults.
- ncmncm 4y ago
  It has been many years since I spent "hours debugging" a segfault. But I use C++, not C. (That said, I coded C from 2008 to 2012, and spent no hours on segfaults then, either.)
- papito 4y ago
  Well, because geniuses who were too smart for their own good turned every problem into an academic exercise, writing "elegant" code using the darkest corners of the vast language that is C++. And then we hate the language and not these characters. Scala has the same problem. Stop writing your own DSLs!
  - jcelerier 4y ago
    > Stop writing your own DSLs! 100% disagree. Writing custom DSLs is how you get the best programs.
- yakubin 4y ago
  The myth of segmentation faults being hard needs to die. A fault is like an exception in Java (or a panic in Rust for that matter), only generated by hardware. It's the best case scenario for your buggy code. It's when you don't get a segfault, but your buggy code keeps chugging along, that's a problem. If after using an out-of-bounds index into an array I get a segfault instead of a memory corruption, I thank god for his mercy. The alternative of the program just continuing execution is horrible.
  - kaba0 4y ago
    Depends, if it happens in prod, you are **
    - yakubin 4y ago
      If it doesn't happen in prod, you are even more **. Cue password leaks, privilege escalation etc.
      - kaba0 4y ago
        Fair enough.
  - klodolph 4y ago
    Segfault is only best-case scenario if it happens at the location with the bug. It is extremely common to start diagnosing a segfault and find that the location of the segfault, in code, is unrelated to the code which caused the segfault.
    - yakubin 4y ago
      Agreed.
      - Kon-Peki 4y ago
        My experience (15+ years of debugging legacy C code) is that if the segfault is repeatable - as in you can make it happen in the same place over and over again - the fact that the error is somewhere else only makes things marginally more difficult. Even the old-fashioned debuggers can monitor memory locations for changes, and if that doesn't work you can set breakpoints in various locations and manually check memory for corruption - it can really narrow down the possibilities. I always enjoyed the mystery. It's a puzzle with an as-yet unknown solution. How can you not love it?
quietbritishjim 4y ago
I still find this type of comment odd (although I do also recognise that it's very common). I write a lot of code in C++. And I'm definitely no fan of it, so I'm not here to defend it! And I write a lot of bugs in that code. But very few of them are segfaults. With smart pointers and some common sense, they're just not that big of a concern. Yes, they do happen, but it's far a minority of the bugs. Maybe everyone just has better tests than me? (shrug) I like the look of Rust, though I haven't yet got to use it professionally. I actually think it would be a perfectly good language without all the lifetime stuff, with lots of improvements over C++ (destructive move for a start). It would probably be good enough for most purposes, and the improved uptake would result in fewer bugs overall than the current situation. It's academic really since that's obviously not where we are. But, like I say, I don't think memory errors are that problematic in C++ in practice (unless you're writing security sensitive code where even an occasional one can cause big problems).
- bcrosby95 4y ago
  > I actually think it would be a perfectly good language without all the lifetime stuff, with lots of improvements over C++ (destructive move for a start). I'm not sure what you mean by this exactly. Do you mean Rust would be a perfectly good language without its safety guarantees? Because it can't have them without lifetimes. It could instead have GC like Go/Java/etc, but now it's a GC language. Lifetimes aren't a feature of the language. They are the implementation details for a couple features of the language. It's how it gets there. And I don't think Rust would have anywhere near the interest it has without those features.
- eventhorizonpl 4y ago
  It's not that big issue https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/ https://www.zdnet.com/article/microsoft-70-percent-of-all-se...
  - hellokittycity 4y ago
    This is why we need a professional organization to hold software developers accountable to the same standard as other fields of engineering.
vegai_ 4y ago
This kinda counter-resonates with me. I'm not a superb programmer by any means, but C's memory management rarely caused me bad problems. I find it much easier to deal with than the complexity of languages like C++ and Rust.
- juped 4y ago
  Calling malloc isn't even manual memory management to me, it's just calling malloc. Writing malloc (not that hard in general! but tricky to get exactly the allocator performance or security properties you want for your use case) is manual memory management.
  - afdbcreid 4y ago
    > In computer science, manual memory management refers to the usage of manual instructions by the programmer to identify and deallocate unused objects, or garbage. https://en.wikipedia.org/wiki/Manual_memory_management https://en.wikipedia.org/wiki/Manual_memory_management So, you can call it however you like, but calling `malloc()`/`free()` manually (emphasis on the `free()`, since allocation is explicit in most languages in form of `new` or something) is manual memory management, and this is how most programmers use this term.
    - juped 4y ago
      Why did you think this added to the conversation?
premek 4y ago
I understand the comparison with C (the memory management) but I wonder how do you compare Rust to Java? What is it that makes you feel more confident in Rust compared to Java?
- haspok 4y ago
  I think you shouldn't compare Rust to Java (the language), you should compare it to Java (the ecosystem). The JVM is rock solid and very performant, and you have languages like Java++ (called Kotlin) and Haskell# (called Scala), or even Common Scheme (called Clojure). The same is true for the ecosystem, eg. build tools (Maven/Gradle are the default ones, but there are many more), frameworks (Spring + all the reactive stuff), the largest number of libraries on the planet after C, and so on. The target niche is not exactly the same though, you wouldn't want to systems program on the JVM, and it would probably not make much sense to choose Rust over Spring Boot for web programming. YMMV of course.
- orangetuba 4y ago
  No null pointers, and no data races when you're working with threads.
- chungus 4y ago
  You're right that with regards to memory management, using Java over Rust doesn't make me any more nervous. The things I really miss are at the type level. Small things like the compiler forcing you to be explicit about mutability. Large things like Rust enums and pattern matching which make it easy to model complex workflows without worrying about missing any cases. Let me also make clear that I like the direction Java is moving (even if is taking decades) For example, something I look forward to in Java is pattern matching on switch expressions, which just got added as a preview feature in the latest LTS.
- speed_spread 4y ago
  Java _used_ to give me that "it just works" feeling when I started using it... in 1999. The rich type system makes the biggest difference. In Rust, you can solve a problem by first modelling it through structs and enums and then define operations pertaining to elements of the model. rustc (the compiler) has such a grasp on the implications of a given model that it will most often guide you toward a near-optimal (and safe) solution that ends up working flawlessly the first time you get it running.

eventhorizonpl 4y ago

Do you pine for the nice days of C/C++, when men were men and spend hours on debugging segmentation faults?

p0nce 4y ago
This is quite rare in C++ since C++11.
mbrodersen 4y ago
I am a professional C++ programmer and I can’t even remember the last time I had a segfault. I also haven’t had a bug in production the last 5 years. But YMMV of course.
farseer 4y ago
Sticking to STL in C++ and avoiding pointers unless really necessary will significantly cut down on segmentation faults.
ncmncm 4y ago
It has been many years since I spent "hours debugging" a segfault. But I use C++, not C. (That said, I coded C from 2008 to 2012, and spent no hours on segfaults then, either.)
papito 4y ago
Well, because geniuses who were too smart for their own good turned every problem into an academic exercise, writing "elegant" code using the darkest corners of the vast language that is C++. And then we hate the language and not these characters. Scala has the same problem. Stop writing your own DSLs!
- jcelerier 4y ago
  > Stop writing your own DSLs! 100% disagree. Writing custom DSLs is how you get the best programs.
yakubin 4y ago
The myth of segmentation faults being hard needs to die. A fault is like an exception in Java (or a panic in Rust for that matter), only generated by hardware. It's the best case scenario for your buggy code. It's when you don't get a segfault, but your buggy code keeps chugging along, that's a problem. If after using an out-of-bounds index into an array I get a segfault instead of a memory corruption, I thank god for his mercy. The alternative of the program just continuing execution is horrible.
- kaba0 4y ago
  Depends, if it happens in prod, you are **
  - yakubin 4y ago
    If it doesn't happen in prod, you are even more **. Cue password leaks, privilege escalation etc.
    - kaba0 4y ago
      Fair enough.
- klodolph 4y ago
  Segfault is only best-case scenario if it happens at the location with the bug. It is extremely common to start diagnosing a segfault and find that the location of the segfault, in code, is unrelated to the code which caused the segfault.
  - yakubin 4y ago
    Agreed.
    - Kon-Peki 4y ago
      My experience (15+ years of debugging legacy C code) is that if the segfault is repeatable - as in you can make it happen in the same place over and over again - the fact that the error is somewhere else only makes things marginally more difficult. Even the old-fashioned debuggers can monitor memory locations for changes, and if that doesn't work you can set breakpoints in various locations and manually check memory for corruption - it can really narrow down the possibilities. I always enjoyed the mystery. It's a puzzle with an as-yet unknown solution. How can you not love it?

quietbritishjim 4y ago

I still find this type of comment odd (although I do also recognise that it's very common). I write a lot of code in C++. And I'm definitely no fan of it, so I'm not here to defend it! And I write a lot of bugs in that code. But very few of them are segfaults. With smart pointers and some common sense, they're just not that big of a concern. Yes, they do happen, but it's far a minority of the bugs. Maybe everyone just has better tests than me? (shrug) I like the look of Rust, though I haven't yet got to use it professionally. I actually think it would be a perfectly good language without all the lifetime stuff, with lots of improvements over C++ (destructive move for a start). It would probably be good enough for most purposes, and the improved uptake would result in fewer bugs overall than the current situation. It's academic really since that's obviously not where we are. But, like I say, I don't think memory errors are that problematic in C++ in practice (unless you're writing security sensitive code where even an occasional one can cause big problems).

bcrosby95 4y ago
> I actually think it would be a perfectly good language without all the lifetime stuff, with lots of improvements over C++ (destructive move for a start). I'm not sure what you mean by this exactly. Do you mean Rust would be a perfectly good language without its safety guarantees? Because it can't have them without lifetimes. It could instead have GC like Go/Java/etc, but now it's a GC language. Lifetimes aren't a feature of the language. They are the implementation details for a couple features of the language. It's how it gets there. And I don't think Rust would have anywhere near the interest it has without those features.
eventhorizonpl 4y ago
It's not that big issue https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/ https://www.zdnet.com/article/microsoft-70-percent-of-all-se...
- hellokittycity 4y ago
  This is why we need a professional organization to hold software developers accountable to the same standard as other fields of engineering.

vegai_ 4y ago

This kinda counter-resonates with me. I'm not a superb programmer by any means, but C's memory management rarely caused me bad problems. I find it much easier to deal with than the complexity of languages like C++ and Rust.

juped 4y ago
Calling malloc isn't even manual memory management to me, it's just calling malloc. Writing malloc (not that hard in general! but tricky to get exactly the allocator performance or security properties you want for your use case) is manual memory management.
- afdbcreid 4y ago
  > In computer science, manual memory management refers to the usage of manual instructions by the programmer to identify and deallocate unused objects, or garbage. https://en.wikipedia.org/wiki/Manual_memory_management https://en.wikipedia.org/wiki/Manual_memory_management So, you can call it however you like, but calling `malloc()`/`free()` manually (emphasis on the `free()`, since allocation is explicit in most languages in form of `new` or something) is manual memory management, and this is how most programmers use this term.
  - juped 4y ago
    Why did you think this added to the conversation?

premek 4y ago

I understand the comparison with C (the memory management) but I wonder how do you compare Rust to Java? What is it that makes you feel more confident in Rust compared to Java?

haspok 4y ago
I think you shouldn't compare Rust to Java (the language), you should compare it to Java (the ecosystem). The JVM is rock solid and very performant, and you have languages like Java++ (called Kotlin) and Haskell# (called Scala), or even Common Scheme (called Clojure). The same is true for the ecosystem, eg. build tools (Maven/Gradle are the default ones, but there are many more), frameworks (Spring + all the reactive stuff), the largest number of libraries on the planet after C, and so on. The target niche is not exactly the same though, you wouldn't want to systems program on the JVM, and it would probably not make much sense to choose Rust over Spring Boot for web programming. YMMV of course.
orangetuba 4y ago
No null pointers, and no data races when you're working with threads.
chungus 4y ago
You're right that with regards to memory management, using Java over Rust doesn't make me any more nervous. The things I really miss are at the type level. Small things like the compiler forcing you to be explicit about mutability. Large things like Rust enums and pattern matching which make it easy to model complex workflows without worrying about missing any cases. Let me also make clear that I like the direction Java is moving (even if is taking decades) For example, something I look forward to in Java is pattern matching on switch expressions, which just got added as a preview feature in the latest LTS.
speed_spread 4y ago
Java _used_ to give me that "it just works" feeling when I started using it... in 1999. The rich type system makes the biggest difference. In Rust, you can solve a problem by first modelling it through structs and enums and then define operations pertaining to elements of the model. rustc (the compiler) has such a grasp on the implications of a given model that it will most often guide you toward a near-optimal (and safe) solution that ends up working flawlessly the first time you get it running.