4 ms·

> 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.

> 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.
  - cyber1 4y ago
    But C can be improved by adding features that allow this and there is a lot of CS experience accumulated around metaprogramming to design this without lots of pitfalls, and no one says that this is easy, this is really hard, but possible. Unfortunately, the committee plays with old and ugly macros system and a little bit with lambda which for sure is better than nothing, but not enough to make C better.
flohofwoe 4y ago
I bet when you say "Rust is more productive than C", what you actually mean is "the Rust stdlib and its wider library ecosystem enabled by Cargo is more productive than what the C stdlib offers", and that is no doubt true. But when you look at just the language, the OPs statement is also no doubt true. The libraries that make C more productive are out there, they are just harder to find than in the Rust ecosystem. IME C programmers (including myself) separate a language and its stdlib much more strictly than (for instance) the Rust, C++ or Python crowd, mainly because the C stdlib is pretty much useless for anything that's not a simple command line tool (and because of such restrictions, C programmers also often use a whole language toolbox instead of attempting to write everything in C - Python and C go very well together for instance, right tool for the job etc...).
- kouteiheika 4y ago
  > I bet when you say "Rust is more productive than C", what you actually mean is "the Rust stdlib and its wider library ecosystem enabled by Cargo is more productive than what the C stdlib offers", and that is no doubt true. But when you look at just the language, the OPs statement is also no doubt true. No. I also mean that the language itself is more productive, even without the standard library and the tooling. (Although, indeed, to a lesser degree.) Sum types. Pattern matching. No need to bother with header files. A module system. Proper generics. AST-based hygienic better macros. Procedural macros. Stronger type system. RAII. A proper string type which knows its length. A proper array type which knows its length. Unicode support*. Async + await support. Support for closures. Ergonomic error handling (with the '?' operator). Proper abstraction for iterators. Do you want me to keep going? Because I can keep going. (: Again, this is more complex than what you have in C. And it is harder to learn. But that's not what we're talking about. We're talking about pure productivity here, so I'm assuming on one side you have someone who has mastered C, and on the other side you have someone who has mastered Rust. There's just no contest that the Rust person will get things done significantly faster than the C person, because the language itself is so much more powerful. (But of course it's a lot harder to master Rust, so the calculus might be different if you don't want to master your tools.) * - part of Rust's core so also available in `no_std` contexts, so I don't see it as part of the stdlib but part of the language.
gavinhoward 4y ago
Author here. > 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. I've implemented a hash map in my code. I loved the experience, and I know more about computers and hash maps now that I've done it. And my hash map was faster than the one in the C++ STL last I checked. I haven't benchmarked it against the Rust one, though.
- kouteiheika 4y ago
  > I've implemented a hash map in my code. I loved the experience, and I know more about computers and hash maps now that I've done it. Yep, everyone at least once should implement a hash map. Hash maps are so fundamental and so often used that it really pays off to understand what makes them tick. > And my hash map was faster than the one in the C++ STL last I checked. I haven't benchmarked it against the Rust one, though. The one in C++ is very famous for being really slow, so this is a low bar to clear. (: Not sure if someone directly compared Rust's hash map to C++'s, but Rust's hash map is based on Google's SwissTable, so you can probably assume it performs roughly the same. Here are some graphs: https://youtu.be/ncHmEUmJZf4?t=2093 https://youtu.be/ncHmEUmJZf4?t=2093
  - menaerus 4y ago
    > The one in C++ is very famous for being really slow, so this is a low bar to clear. (: There's nothing wrong with the C++ hash-map. It's a different trade-off which makes perfect sense for something that is part of the general-purpose toolbox. See my response above for more details if interested.
- menaerus 4y ago
  > And my hash map was faster than the one in the C++ STL last I checked. Last time I checked, benchmarking hash-maps, or FWIW any other data structure, in the vacuum did not make much sense to me. Microbenchmarks cannot mimic or predict end user workloads well enough, at least in the cases where it's worth it. That said, each implementation has its own trade-offs and in particular the one from C++ STL opted in for the pointer stability. For that reason alone, which I think is quite worthy, open-addressing conflict resolution is out of the question because it cannot give such guarantees. With that in mind, if you're ok that a pointer to your key-value pair can all of the sudden be _invalidated_ by the mere operation of inserting or erasing yet another element from your hash-map, then of course, you can trade robustness for a more cache-friendly conflict resolution algorithm. But then again, this says nothing about the potential performance improvement unless you're able to measure it.

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.
- cyber1 4y ago
  But C can be improved by adding features that allow this and there is a lot of CS experience accumulated around metaprogramming to design this without lots of pitfalls, and no one says that this is easy, this is really hard, but possible. Unfortunately, the committee plays with old and ugly macros system and a little bit with lambda which for sure is better than nothing, but not enough to make C better.

flohofwoe 4y ago

I bet when you say "Rust is more productive than C", what you actually mean is "the Rust stdlib and its wider library ecosystem enabled by Cargo is more productive than what the C stdlib offers", and that is no doubt true. But when you look at just the language, the OPs statement is also no doubt true. The libraries that make C more productive are out there, they are just harder to find than in the Rust ecosystem. IME C programmers (including myself) separate a language and its stdlib much more strictly than (for instance) the Rust, C++ or Python crowd, mainly because the C stdlib is pretty much useless for anything that's not a simple command line tool (and because of such restrictions, C programmers also often use a whole language toolbox instead of attempting to write everything in C - Python and C go very well together for instance, right tool for the job etc...).

kouteiheika 4y ago
> I bet when you say "Rust is more productive than C", what you actually mean is "the Rust stdlib and its wider library ecosystem enabled by Cargo is more productive than what the C stdlib offers", and that is no doubt true. But when you look at just the language, the OPs statement is also no doubt true. No. I also mean that the language itself is more productive, even without the standard library and the tooling. (Although, indeed, to a lesser degree.) Sum types. Pattern matching. No need to bother with header files. A module system. Proper generics. AST-based hygienic better macros. Procedural macros. Stronger type system. RAII. A proper string type which knows its length. A proper array type which knows its length. Unicode support*. Async + await support. Support for closures. Ergonomic error handling (with the '?' operator). Proper abstraction for iterators. Do you want me to keep going? Because I can keep going. (: Again, this is more complex than what you have in C. And it is harder to learn. But that's not what we're talking about. We're talking about pure productivity here, so I'm assuming on one side you have someone who has mastered C, and on the other side you have someone who has mastered Rust. There's just no contest that the Rust person will get things done significantly faster than the C person, because the language itself is so much more powerful. (But of course it's a lot harder to master Rust, so the calculus might be different if you don't want to master your tools.) * - part of Rust's core so also available in `no_std` contexts, so I don't see it as part of the stdlib but part of the language.

gavinhoward 4y ago

Author here. > 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. I've implemented a hash map in my code. I loved the experience, and I know more about computers and hash maps now that I've done it. And my hash map was faster than the one in the C++ STL last I checked. I haven't benchmarked it against the Rust one, though.

kouteiheika 4y ago
> I've implemented a hash map in my code. I loved the experience, and I know more about computers and hash maps now that I've done it. Yep, everyone at least once should implement a hash map. Hash maps are so fundamental and so often used that it really pays off to understand what makes them tick. > And my hash map was faster than the one in the C++ STL last I checked. I haven't benchmarked it against the Rust one, though. The one in C++ is very famous for being really slow, so this is a low bar to clear. (: Not sure if someone directly compared Rust's hash map to C++'s, but Rust's hash map is based on Google's SwissTable, so you can probably assume it performs roughly the same. Here are some graphs: https://youtu.be/ncHmEUmJZf4?t=2093 https://youtu.be/ncHmEUmJZf4?t=2093
- menaerus 4y ago
  > The one in C++ is very famous for being really slow, so this is a low bar to clear. (: There's nothing wrong with the C++ hash-map. It's a different trade-off which makes perfect sense for something that is part of the general-purpose toolbox. See my response above for more details if interested.
menaerus 4y ago
> And my hash map was faster than the one in the C++ STL last I checked. Last time I checked, benchmarking hash-maps, or FWIW any other data structure, in the vacuum did not make much sense to me. Microbenchmarks cannot mimic or predict end user workloads well enough, at least in the cases where it's worth it. That said, each implementation has its own trade-offs and in particular the one from C++ STL opted in for the pointer stability. For that reason alone, which I think is quite worthy, open-addressing conflict resolution is out of the question because it cannot give such guarantees. With that in mind, if you're ok that a pointer to your key-value pair can all of the sudden be _invalidated_ by the mere operation of inserting or erasing yet another element from your hash-map, then of course, you can trade robustness for a more cache-friendly conflict resolution algorithm. But then again, this says nothing about the potential performance improvement unless you're able to measure it.