7 ms·

I have a similar issue. I like the memory safety in Rust, but I don't like Rust: it limits my productivity for two reasons. 1. In order to reach memory safety i

I have a similar issue. I like the memory safety in Rust, but I don't like Rust: it limits my productivity for two reasons. 1. In order to reach memory safety it add abstractions that don't make programming simpler, but harder. 2. It is a language that started to enter the slippery slope of too many ad-hoc features. And given that I work alone, I try to write safe C code as much as I can (it is impossible to reach perfection, anyway), and avoid Rust as much as I can. What I will do more, however, is using more other safe languages when the C low-level control is not needed. Go is a good option, for my tastes. P.S. I see in realtime, reloading the post, the number of downvotes received (the score goes up and then ways down with the downvotes). Another problem is the Rust community. It has a very peculiar way to stay in this world.

rapsey 4y ago
What slippery slope exactly?
- simonh 4y ago
  I suppose once you have accepted ad-hoc features, you don't have a strong argument against adding more of them.
  - rapsey 4y ago
    Not becoming c++ is a strong argument
- antirez 4y ago
  One is a cultural matter: A design idea that no longer actively attempts to produce a language with few orthogonal features that work well together. The second is a side-effect: the more features you have in a language, the more complex new features will be to accomodate all the past cases.
rapsey 4y ago
Also nothing prevents you from using Rust without higher abstractions.
- antirez 4y ago
  If you are part of development community, you also get to read other people's code, use libraries, and so forth. When I open a C file it can be written without care certain times, but C is so self-evident that it's hard to don't understand the code after some superficial reading.
  - vore 4y ago
    I think C is misleadingly easy: it's easy to reason about, say, a single function body since there's only so many things you can even write in C. But when you start composing things together and juggling the lifetimes of various things, the complexity balloons and it becomes a lot harder to understand "spooky action at a distance"-type things. You might argue that with good structure and discipline it's still not difficult, but the assumptions are all implicit and you have to get into the mind of whoever wrote it in the first place to understand it. And I write a lot of C and still find it tricky when I have to go look at some random C codebase!
    - antirez 4y ago
      I agree, but what I said has very little to do with that. What you says means that poorly written code has unexpected bugs. But you understand what it does, easily.
      - vore 4y ago
        If the bugs are unexpected then it's hard to understand what it does :-)
      - krom 4y ago
        Isn't it more like, you understand the tiny portion of the source code easily, that fits on the screen/in your head?
vore 4y ago
I want to like Go but the language is designed such that writing it requires a lot of discipline to not do something silly by accident: https://www.uber.com/blog/data-race-patterns-in-go/ https://www.uber.com/blog/data-race-patterns-in-go/
- bsaul 4y ago
  i know the "pass sync.mutex by value" error was diagnosed by my linter, but are there any plan to fix all those issues in the go compiler itself ? Thoses are really bad footguns.
  - morelisp 4y ago
    Although `go vet` is nominally a linter it's probably more accurate in relation to other languages to think of it as `-Werror`. Everything it reports should be considered a serious issue, and it runs by default during `go test`. They haven't been moved to the compiler proper out of back-compat concerns (but lately even some of those are being overridden for very pathological things like int/string conversion).
kouteiheika 4y ago
> I don't like Rust: it limits my productivity [...] I try to write safe C code It's definitely fair to argue that Rust is complex. But this doesn't compute. You don't like Rust because you're less productive with it so you write... C? Rust is so much more productive compared to C it's not even funny, even with its limitations and extra complexity that are necessary for memory safety. Things that take pages of code in C can be done in a single line of code in Rust. This starts at fairly fundamental data structures. Need a hash map? In Rust you have one available, out-of-box, with state-of-art performance. In C? Implement one yourself. And good luck getting even a fraction of the performance the Rust one has. Then there is dependency management and a huge ecosystem of libraries. Do you need to, say, encode an AVIF image? (Something I personally had to do.) Easy. `cargo add ravif`, and two lines of code later you're done. I can keep on going, but I'm sure you get the idea. I really honestly don't see how anyone can in good faith argue about productivity and say that C (out of all things!) is more productive than Rust. That Rust is more complex, sure. That you don't like it for aesthetic reasons? Fair enough. But not as productive as C? No way. Perhaps this is where the downvotes you're complaining about come from?
- antirez 4y ago
  The limits you are referring are not proper of C, but mostly of its standard library. Any long term C programmer has libraries, written by herself or by others, that will limit this problem a lot. An example, starting from your own example. I need a dictionary? I take my rax library, written for Redis. I need dynamic strings? I use SDS (and limit a lot the memory safety issues I could have). C is not well understood because it is seen as the language + its library. But the undefined behaviours and the terrible library are not C original sins, but the terrible work of the ANSI C committee. The Ansi C committee is responsible for a lot of bad things in software in recent years.
  - c-cube 4y ago
    But the problem is that C fundamentally limits reusability! I have great respect for you and redis, but your examples are telling: they deal only with strings. With Rust or C++ you can have an extremely efficient, well tested, robust generic map structure that will accept any key or value types. C simply cannot do that, because of the language's limitations, not just its stdlib.
spoiler 4y ago
I think your first point on limiting productivity is true only early on (or at least it was in my case) and when working alone. I pretty confident that this would go away if you write Rust for a few weeks. I remember when first learning C, I struggled with some things too, but then they just clicked. It's probably similar when learning any new language (especially if they add something novel)
szastamasta 4y ago
I also have mixed feelings about Rust. It gives me too many flashbacks from Scala. Complex types, a lot of generics, same elitist attitude. I just think it will end up the same way as Scala. Few years of hype and now we have plenty of unmaintainable codebases from wannabe functional zealots.
- antirez 4y ago
  I like other communities experimenting new ways. And the Rust lesson will not be forgotten even if Rust will be replaced by something else. However what I do not understand is, given the enormous code base written in C, the fact it will be used more in the future regardless of Rust and other alternatives, is why we don't fix C, at the same time. Create a standard project, within the ANSI C, to write a new, solid, modern standard library for C. Change the language behaviour so that the default compilation target is full of defined behaviours for all the common edge cases, and you can enable an "UB mode" only for speed and if you know what you are doing. And so forth.
  - szastamasta 4y ago
    This would be really cool. If there would be a more modern version of C, made by C standard committee. Without UB and with small, but robust stdlib. It would have to stay compatible on ABI level, but source level I think we can skip. For me Zig looks like something that could become a new C. They aim for great C binary and source compatibility (both ways - called and callable from C). It’s planned to be small and lean. And avoid preprocessor and UB as much as possible.
  - Santosh83 4y ago
    I suspect the problem is as always, political. The standards committee is dominated by compiler vendors, who at this point are desperate to cast C in the dustbin of history, or at least put it in deep freeze, and are eager to push their other favoured languages like C#, C++ and so on. Therefore the committee has decided to please all parties by pleasing none, i.e., keep C stagnated, with only minimal changes that everyone manages to agree on, essentially relegated to embedded work and legacy code maintenance. And as long as C remains under ISO's grip, this won't change, sadly. C needs a rejuvenation and ISO is the last place to make it happen.
ly3xqhl8g9 4y ago
Rust seems nice when you see someone like Jon Gjengset writing it [1], however when actually writing it yourself you discover that your errors have errors which only show some kind of alien fishing when you Google them. Perhaps ChatGPT could help here, it's quite useful/pleasant for trivial quizzes, however I asked it recently how to handle a file upload using actix-web and it hallucinated some really nice methods, too bad they aren't in the code base. Just a random recent example: call an async function for a side effect without caring what its result is, Rust yells at you that the result must be handled "`#[warn(unused_must_use)]` on by default", so you'd think I would just annotate with `#[allow(unused_must_use)]`, but no way, you must store the result in a _ variable: "let _ = my_async_fn().await;". It's a great language, it's just ugly, sorry, not sorry. [1] https://www.youtube.com/watch?v=rAl-9HwD858&list=PLqbS7AVVErFiWDOAVrPt7aYmnuuOLYvOa https://www.youtube.com/watch?v=rAl-9HwD858&list=PLqbS7AVVEr...
- c-cube 4y ago
  Nitpick: _ is not a variable, it's a wildcard pattern that means "ignore this value". It can occur in other places like tuple deconstruction and the likes.
  - ly3xqhl8g9 4y ago
    Nitpicking the nitpick: _ is a wildcard pattern when stated in a match as in [1], otherwise it's indeed a placeholder as a standalone, but also a special character when using it in the normal code flow to allow for unused variables as in `let _foo`. Asked even ChatGPT about it (they must add permalinks for the answers), they answered: "In Rust, the '_' symbol is a special value that can be used in a number of ways. Here are a few common uses: 1. As a placeholder for unused variables. 2. In pattern matching. 3. In iterators." [1] https://doc.rust-lang.org/book/ch18-03-pattern-syntax.html https://doc.rust-lang.org/book/ch18-03-pattern-syntax.html
    - c-cube 4y ago
      `let` takes a pattern, these are not just found in `match`. The `_` here is still a pattern.
deleted 4y ago
[deleted]
jedisct1 4y ago
I've been writing Rust code since 2013, and did what was probably the first large-scale production deployment of Rust code in 2014, at OpenDNS. Wrote quite a few crate and apps since, and started to heavily advocate for it. Here's why. In spite of having quite a bit of experience with many functional and imperative languages before, and picking up new languages used to be a seamless experience. But Rust turned out to be an extremely frustrating experience. I was feeling like I couldn't tell the compiler to do what I wanted it to do any more. I took it as a challenge, didn't want to give up. And when the first non-HelloWorld app actually got to compile and work (it was probably IPTrap 2, that implements a userland TCP stack), there was this feeling of accomplishment that I couldn't help myself sharing with the rest of the world. Fast forwarding a couple years... I don't enjoy Rust any more. I still maintain Rust code, but it's a pain, not something I'm having fun doing. First, memory safety in Rust is overrated. What it actually brings over GC'd languages is that two threads can't share the same pointer at the same time. Nothing else. If I'm not using threads, it doesn't matter. It's not any safer than PHP, Go or JS, but is far more complex. I won't provide memory leaks nor deadlocks either. To some extent, it actually encourages them (I'm often blindly adding Arc, Box, and Mutexes just to silence the borrow checker, not because they are actually needed). Next, readability is not great. Too many sigils, and the language got more and more complex and less and less readable over time. I'm frequently having a hard time reading my own code after a while. Even more with other people's code. It often feels like people try to maximize the number of language features being used, so that the source code looks impressive, rather than keep the code basic and simple. Finally, the ecosystem is very unstable. 3rd-party crates (even essential ones such as for error handling, due to limitations of the standard library) are constantly deprecated, abandoned, or having braking API changes. I gave up maintaining some projects, and keep using abandoned (even with security issues, such as old versions of hyper) with others, because the maintenance cost is too high. After using almost exclusively Rust, choosing Go for a new project (dnscrypt-proxy 2) was enlightening. There were probably runtime bugs that Rust could have detected at compile-time, but overall, productivity was way higher. Making a change is straightforward, I don't have to think about the implications on the borrow checker. The compiler is fast. Performance is fine, and I can spend more time optimizing the actual algorithms than fight the compiler. Go tells you at runtime, not at compile time, if locks have been forgotten. But otherwise, memory safety is comparable to Rust. The runtime gracefully catches out of bound accesses to slices, null pointer derefs, etc. I also still enjoy writing C code. It's good to have some freedom and control. But C also has rough edges. UBs, portability, minimal standard library. Zig fixes many issues that C had, and is the language I really enjoy the most now. It's fast, portable, easy to learn, easy to read, has proper error handling, strong typing, catches out of bound accesses to slices and does checked arithmetic, and, overall, is a joy to use. Not to mention its seamless integration with C. It doesn't have temporal memory safety, but, like Go, Zig's simplicity helps me reduce logic bugs, and focus more on algorithms than their implementation, overall resulting in better code.
bitwize 4y ago
If you don't like Rust, try a Lisp. You're probably looking for one that can compile fast code and has good, easy to use C FFI support. Gambit, Chicken, SBCL, CCL, and ECL are all good choices here, with Guile 3.0 also potentially a contender.
avgcorrection 4y ago
Complaining about downvotes is a waste of time. If Redis works then the proof is in the pudding, I guess. But as an average/below average programmer I’ll stick to something more modern when I need that level of control.
naasking 4y ago
> 1. In order to reach memory safety it add abstractions that don't make programming simpler, but harder. Another possible conclusion is that your program design is just not as simple as you thought it was, and Rust is pointing out why. This drives you to make it even simpler, which is arguably good.

rapsey 4y ago

What slippery slope exactly?

simonh 4y ago
I suppose once you have accepted ad-hoc features, you don't have a strong argument against adding more of them.
- rapsey 4y ago
  Not becoming c++ is a strong argument
antirez 4y ago
One is a cultural matter: A design idea that no longer actively attempts to produce a language with few orthogonal features that work well together. The second is a side-effect: the more features you have in a language, the more complex new features will be to accomodate all the past cases.

rapsey 4y ago

Also nothing prevents you from using Rust without higher abstractions.

antirez 4y ago
If you are part of development community, you also get to read other people's code, use libraries, and so forth. When I open a C file it can be written without care certain times, but C is so self-evident that it's hard to don't understand the code after some superficial reading.
- vore 4y ago
  I think C is misleadingly easy: it's easy to reason about, say, a single function body since there's only so many things you can even write in C. But when you start composing things together and juggling the lifetimes of various things, the complexity balloons and it becomes a lot harder to understand "spooky action at a distance"-type things. You might argue that with good structure and discipline it's still not difficult, but the assumptions are all implicit and you have to get into the mind of whoever wrote it in the first place to understand it. And I write a lot of C and still find it tricky when I have to go look at some random C codebase!
  - antirez 4y ago
    I agree, but what I said has very little to do with that. What you says means that poorly written code has unexpected bugs. But you understand what it does, easily.
    - vore 4y ago
      If the bugs are unexpected then it's hard to understand what it does :-)
    - krom 4y ago
      Isn't it more like, you understand the tiny portion of the source code easily, that fits on the screen/in your head?

vore 4y ago

I want to like Go but the language is designed such that writing it requires a lot of discipline to not do something silly by accident: https://www.uber.com/blog/data-race-patterns-in-go/ https://www.uber.com/blog/data-race-patterns-in-go/

bsaul 4y ago
i know the "pass sync.mutex by value" error was diagnosed by my linter, but are there any plan to fix all those issues in the go compiler itself ? Thoses are really bad footguns.
- morelisp 4y ago
  Although `go vet` is nominally a linter it's probably more accurate in relation to other languages to think of it as `-Werror`. Everything it reports should be considered a serious issue, and it runs by default during `go test`. They haven't been moved to the compiler proper out of back-compat concerns (but lately even some of those are being overridden for very pathological things like int/string conversion).

kouteiheika 4y ago

> I don't like Rust: it limits my productivity [...] I try to write safe C code It's definitely fair to argue that Rust is complex. But this doesn't compute. You don't like Rust because you're less productive with it so you write... C? Rust is so much more productive compared to C it's not even funny, even with its limitations and extra complexity that are necessary for memory safety. Things that take pages of code in C can be done in a single line of code in Rust. This starts at fairly fundamental data structures. Need a hash map? In Rust you have one available, out-of-box, with state-of-art performance. In C? Implement one yourself. And good luck getting even a fraction of the performance the Rust one has. Then there is dependency management and a huge ecosystem of libraries. Do you need to, say, encode an AVIF image? (Something I personally had to do.) Easy. `cargo add ravif`, and two lines of code later you're done. I can keep on going, but I'm sure you get the idea. I really honestly don't see how anyone can in good faith argue about productivity and say that C (out of all things!) is more productive than Rust. That Rust is more complex, sure. That you don't like it for aesthetic reasons? Fair enough. But not as productive as C? No way. Perhaps this is where the downvotes you're complaining about come from?

antirez 4y ago
The limits you are referring are not proper of C, but mostly of its standard library. Any long term C programmer has libraries, written by herself or by others, that will limit this problem a lot. An example, starting from your own example. I need a dictionary? I take my rax library, written for Redis. I need dynamic strings? I use SDS (and limit a lot the memory safety issues I could have). C is not well understood because it is seen as the language + its library. But the undefined behaviours and the terrible library are not C original sins, but the terrible work of the ANSI C committee. The Ansi C committee is responsible for a lot of bad things in software in recent years.
- c-cube 4y ago
  But the problem is that C fundamentally limits reusability! I have great respect for you and redis, but your examples are telling: they deal only with strings. With Rust or C++ you can have an extremely efficient, well tested, robust generic map structure that will accept any key or value types. C simply cannot do that, because of the language's limitations, not just its stdlib.

spoiler 4y ago

I think your first point on limiting productivity is true only early on (or at least it was in my case) and when working alone. I pretty confident that this would go away if you write Rust for a few weeks. I remember when first learning C, I struggled with some things too, but then they just clicked. It's probably similar when learning any new language (especially if they add something novel)

szastamasta 4y ago

I also have mixed feelings about Rust. It gives me too many flashbacks from Scala. Complex types, a lot of generics, same elitist attitude. I just think it will end up the same way as Scala. Few years of hype and now we have plenty of unmaintainable codebases from wannabe functional zealots.

antirez 4y ago
I like other communities experimenting new ways. And the Rust lesson will not be forgotten even if Rust will be replaced by something else. However what I do not understand is, given the enormous code base written in C, the fact it will be used more in the future regardless of Rust and other alternatives, is why we don't fix C, at the same time. Create a standard project, within the ANSI C, to write a new, solid, modern standard library for C. Change the language behaviour so that the default compilation target is full of defined behaviours for all the common edge cases, and you can enable an "UB mode" only for speed and if you know what you are doing. And so forth.
- szastamasta 4y ago
  This would be really cool. If there would be a more modern version of C, made by C standard committee. Without UB and with small, but robust stdlib. It would have to stay compatible on ABI level, but source level I think we can skip. For me Zig looks like something that could become a new C. They aim for great C binary and source compatibility (both ways - called and callable from C). It’s planned to be small and lean. And avoid preprocessor and UB as much as possible.
- Santosh83 4y ago
  I suspect the problem is as always, political. The standards committee is dominated by compiler vendors, who at this point are desperate to cast C in the dustbin of history, or at least put it in deep freeze, and are eager to push their other favoured languages like C#, C++ and so on. Therefore the committee has decided to please all parties by pleasing none, i.e., keep C stagnated, with only minimal changes that everyone manages to agree on, essentially relegated to embedded work and legacy code maintenance. And as long as C remains under ISO's grip, this won't change, sadly. C needs a rejuvenation and ISO is the last place to make it happen.

ly3xqhl8g9 4y ago

Rust seems nice when you see someone like Jon Gjengset writing it [1], however when actually writing it yourself you discover that your errors have errors which only show some kind of alien fishing when you Google them. Perhaps ChatGPT could help here, it's quite useful/pleasant for trivial quizzes, however I asked it recently how to handle a file upload using actix-web and it hallucinated some really nice methods, too bad they aren't in the code base. Just a random recent example: call an async function for a side effect without caring what its result is, Rust yells at you that the result must be handled "`#[warn(unused_must_use)]` on by default", so you'd think I would just annotate with `#[allow(unused_must_use)]`, but no way, you must store the result in a _ variable: "let _ = my_async_fn().await;". It's a great language, it's just ugly, sorry, not sorry. [1] https://www.youtube.com/watch?v=rAl-9HwD858&list=PLqbS7AVVErFiWDOAVrPt7aYmnuuOLYvOa https://www.youtube.com/watch?v=rAl-9HwD858&list=PLqbS7AVVEr...

c-cube 4y ago
Nitpick: _ is not a variable, it's a wildcard pattern that means "ignore this value". It can occur in other places like tuple deconstruction and the likes.
- ly3xqhl8g9 4y ago
  Nitpicking the nitpick: _ is a wildcard pattern when stated in a match as in [1], otherwise it's indeed a placeholder as a standalone, but also a special character when using it in the normal code flow to allow for unused variables as in `let _foo`. Asked even ChatGPT about it (they must add permalinks for the answers), they answered: "In Rust, the '_' symbol is a special value that can be used in a number of ways. Here are a few common uses: 1. As a placeholder for unused variables. 2. In pattern matching. 3. In iterators." [1] https://doc.rust-lang.org/book/ch18-03-pattern-syntax.html https://doc.rust-lang.org/book/ch18-03-pattern-syntax.html
  - c-cube 4y ago
    `let` takes a pattern, these are not just found in `match`. The `_` here is still a pattern.

deleted 4y ago

[deleted]

jedisct1 4y ago

I've been writing Rust code since 2013, and did what was probably the first large-scale production deployment of Rust code in 2014, at OpenDNS. Wrote quite a few crate and apps since, and started to heavily advocate for it. Here's why. In spite of having quite a bit of experience with many functional and imperative languages before, and picking up new languages used to be a seamless experience. But Rust turned out to be an extremely frustrating experience. I was feeling like I couldn't tell the compiler to do what I wanted it to do any more. I took it as a challenge, didn't want to give up. And when the first non-HelloWorld app actually got to compile and work (it was probably IPTrap 2, that implements a userland TCP stack), there was this feeling of accomplishment that I couldn't help myself sharing with the rest of the world. Fast forwarding a couple years... I don't enjoy Rust any more. I still maintain Rust code, but it's a pain, not something I'm having fun doing. First, memory safety in Rust is overrated. What it actually brings over GC'd languages is that two threads can't share the same pointer at the same time. Nothing else. If I'm not using threads, it doesn't matter. It's not any safer than PHP, Go or JS, but is far more complex. I won't provide memory leaks nor deadlocks either. To some extent, it actually encourages them (I'm often blindly adding Arc, Box, and Mutexes just to silence the borrow checker, not because they are actually needed). Next, readability is not great. Too many sigils, and the language got more and more complex and less and less readable over time. I'm frequently having a hard time reading my own code after a while. Even more with other people's code. It often feels like people try to maximize the number of language features being used, so that the source code looks impressive, rather than keep the code basic and simple. Finally, the ecosystem is very unstable. 3rd-party crates (even essential ones such as for error handling, due to limitations of the standard library) are constantly deprecated, abandoned, or having braking API changes. I gave up maintaining some projects, and keep using abandoned (even with security issues, such as old versions of hyper) with others, because the maintenance cost is too high. After using almost exclusively Rust, choosing Go for a new project (dnscrypt-proxy 2) was enlightening. There were probably runtime bugs that Rust could have detected at compile-time, but overall, productivity was way higher. Making a change is straightforward, I don't have to think about the implications on the borrow checker. The compiler is fast. Performance is fine, and I can spend more time optimizing the actual algorithms than fight the compiler. Go tells you at runtime, not at compile time, if locks have been forgotten. But otherwise, memory safety is comparable to Rust. The runtime gracefully catches out of bound accesses to slices, null pointer derefs, etc. I also still enjoy writing C code. It's good to have some freedom and control. But C also has rough edges. UBs, portability, minimal standard library. Zig fixes many issues that C had, and is the language I really enjoy the most now. It's fast, portable, easy to learn, easy to read, has proper error handling, strong typing, catches out of bound accesses to slices and does checked arithmetic, and, overall, is a joy to use. Not to mention its seamless integration with C. It doesn't have temporal memory safety, but, like Go, Zig's simplicity helps me reduce logic bugs, and focus more on algorithms than their implementation, overall resulting in better code.

bitwize 4y ago

If you don't like Rust, try a Lisp. You're probably looking for one that can compile fast code and has good, easy to use C FFI support. Gambit, Chicken, SBCL, CCL, and ECL are all good choices here, with Guile 3.0 also potentially a contender.

avgcorrection 4y ago

Complaining about downvotes is a waste of time. If Redis works then the proof is in the pudding, I guess. But as an average/below average programmer I’ll stick to something more modern when I need that level of control.

naasking 4y ago

> 1. In order to reach memory safety it add abstractions that don't make programming simpler, but harder. Another possible conclusion is that your program design is just not as simple as you thought it was, and Rust is pointing out why. This drives you to make it even simpler, which is arguably good.