261–270 of 546 posts
Earlier quoted context omitted.
I read it. Didn’t find any outdated information in it.
Please check reply by dig1, it does contains some mis-information. It even incorrectly refer to the Heartbleed problem.
> "Clever" memory use is frowned upon in Rust. In C, anything goes. No, it does not. If Rust programmers don't have discipline in C, other people have. And don't drag out some random CVE numbers again. These are about a fraction of existing C projects, many of them were started 1980-2000. It is an entirely different story if a project is started with sanitizers, Valgrind and best practices. I'm not against Rust, exce…
Most surveys place the use of static analysis tools at about 11%, and they all go back to early 80's. Some people are hard learners.
Earlier quoted context omitted.
Lately on another Rust thread somebody pointed out that C programs use a lot of indirection like pointers and vtable dispatches which actually detracts from the supposed mega-speed of the low-level C. I found that to be mind-blowing and felt stupid for not remembering that earlier.
I don't think vtables are often used in C.
Its just amusing, in this thread everyone with critical thinking and skeptical is down voted, even if one expresses himself moderately. It shows how much of zealots, Rust fanboys have become.
And most pertinently, this critique was written by someone who genuinely loves programming in Rust. Shows you that Rust users aren't blinded to the faults of the language. You shouldn't think that Rust users are fanboys just because you see push back to low effort, low knowledge critiques.
I prefer to have great ideas in rust ported over to C instead of rewriting everything with Rust. this approach will benefit all the existing softwares written in C which I think is much larger than Rust in terms of both impact and code size. am I a minority having this opinion?
I don't know if you are a minority, but Rust is available right now and C-but-with-Rust's-great-ideas isn't. As far as I know no one is working on C-but-with-Rust's-great-ideas, so I don't think it's a good strategy to wait around for it instead of using the tools that exist and are already used with great impact.
Earlier quoted context omitted.
The world is full of highly parallel programs getting useful work done. Most graphics, AI and compression libraries (picking 3 easy examples I've worked on) parallelize well, and can usually make use of all the cores you can throw at them. Jonathan Blow makes good games, but chooses not to make particularly CPU intensive ones. That's fine, but that's also his choice.
He's also currently building one of the fastest compilers around. It's unreasonable to consider that he never encountered use cases where parallelism makes sense.
I completely agree with the points made here, it matches my experience as a C coder who went all-in on Rust. >"Clever" memory use is frowned upon in Rust. In C, anything goes. For example, in C I'd be tempted to reuse a buffer allocated for one purpose for another purpose later (a technique known as HEARTBLEED). Ha! >It's convenient to have fixed-size buffers for variable-size data (e.g. PATH_MAX) to avoid (re)alloca…
I’ve been using smartstrings, which is both excellent and maintained. https://github.com/bodil/smartstring
The good thing about having a decent type system is that I expect that transitioning to smartstrings should be painless! Thank you for that.
> computed goto I did a deep dive into this topic lately when exploring whether to add a language feature to zig for this purpose. I found that, although finnicky, LLVM is able to generate the desired machine code if you give it a simple enough while loop continue expression[1]. So I think it's reasonable to not have a computed goto language feature. More details here, with lots of fun godbolt links: https://github.c…
Really cool investigation. I wonder if this applies to rust as well. As you said though, this is finicky, and if you need this optimization for performance then you don’t want to rely on compiler heuristics.
However, in this specific instance at least, this isn't as optimal as it could be. What this is basically doing is creating a jump table to find out which branch it should go down. But, because all the functions have the same signature, and each branch does the same thing, what it could have done instead is create a jump table for the function to call. At that point, all it would need to do is use the Inst's discriminant to index into the jump table.
I'm not sure what it would look like in Zig, but it's not that hard to get that from Rust[1]. The drawback of doing it this way is that it now comes with the maintenance overhead of ensuring the order and length of the jump table exactly matches the enum, otherwise you get the wrong function being called, or an out-of-bounds panic. You also need to explicitly handle the End variant anyway because the called function can't return for its parent.
I don't know Zig, but from what I understand it has some pretty nice code generation, so maybe that could help with keeping the array and enum in step here?
Earlier quoted context omitted.
How could an OS adapt its processes functionality to help Rust here?
Capabilities would probably be helpful :V
I prefer to have great ideas in rust ported over to C instead of rewriting everything with Rust. this approach will benefit all the existing softwares written in C which I think is much larger than Rust in terms of both impact and code size. am I a minority having this opinion?
I think it would be basically impossible to perform this task without making the language fundamentally not C. Zig is an interesting take in that direction (learn from the last 30 years but still try to be "C") that I think gets a lot closer to the ideal than most other alternatives. C++, OTOH, you could probably port most of Rust's concepts into (with some extra language changes for various reasons I don't want to g…