101–110 of 546 posts
Yeah but, C is essentially 32 years old by now. A more useful comparison would be to modern C++.
> "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…
My best guess is that people who are "stuck" working in C or C++ wish they could use Rust at their Jobs.
Or that others would make the leap and get over the learning curve.
> 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…
Earlier quoted context omitted.
Which form of Rust parallelism did you choose? I’ve read that the old one sucks. Certainly Rust is different beast than C. Code converted from C to Rust seems much more voluminous. Perhaps it’s easier to maintain if you know Rust well? I cannot believe at first that Rust is ever more performant than C, as C could be made parallel and seems more barebones. One of the languages that CUDA can be used with is C, so I sus…
The author did say that there is nothing that Rust does that C cannot. The difference is that in Rust, those things are easier, or many times, the default way, while in C, you would have to take care of way too many things to make sure things work.
But it’s not just taking care of those things that must be done; it seems to bloat the code.
I think it’s a great alternative to C for large apps like Firefox, and perhaps it’s a good alternative to Go for services.
For general purpose, I personally want something fast that’s easy, clear, and concise like Ruby.
Do I just accept that Rust is the most evolved version of C, or is my gut correct that it’s bloated? Is it a good choice for general purpose as-is?
Billions of cars with multi-billion ECUs, practically every device running an OS, and several NASA rovers disagree.
Earlier quoted context omitted.
> rely on process-based parallelism which is basically strictly worse. Why is that worse? I very seldomly use threads for concurrency, it creates monolithic binaries that are hard to maintain, configure, and understand. I much prefer a process based architecture with mmap'd shared memories for interprocess communications.
Doesn't this just move the hard part, the maintenance, configuration and understanding, to a different (and equally complex) abstraction layer? Personally, I'd prefer to have a single binary that I start with some arguments, then need to also have a launch script, probably in a different language, which needs to coordinate all the starting, stopping, shared state etc. But, most of my work has been at the workstation…
That's true indeed, but I find it more manageable that way.
To me, managing independent processes instead of threads is especially powerful when the lifecycle of the concurrent work can vary.
A typical example that happens quite often is when you have some kind of producer/consumer application. Say, you need to receive some data from a socket, and then process it.
If implemented with threads, it becomes quite messy very fast. You end up with a big blob binary that spawns whatever the hell it wants and need to engineer some complex configuration file to tell it how many workers you want, etc. You also need some notification to this process to tell him to increase or decrease its amount of workers, etc.
With independent process, it can be much more manageable. You can have a "collector" process that reads the socket and places messages in a shared memory, and if you want more/less workers, you just spawn worker processes to read from the shared memory.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/... shows C is generally better
"But the biggest potential is in ability to fearlessly parallelize majority of Rust code, even when the equivalent C code would be too risky to parallelize. In this aspect Rust is a much more mature language than C." Yes. Today, I integrated two parts of a 3D graphics program. One refreshes the screen and lets you move the viewpoint around. The other loads new objects into the scene. Until today, all the objects were…
Which form of Rust parallelism did you choose? I’ve read that the old one sucks. Certainly Rust is different beast than C. Code converted from C to Rust seems much more voluminous. Perhaps it’s easier to maintain if you know Rust well? I cannot believe at first that Rust is ever more performant than C, as C could be made parallel and seems more barebones. One of the languages that CUDA can be used with is C, so I sus…
This is a fairly odd claim.
If you have to deal with strings (ASCII and UTF-8) properly, C is stupidly verbose.
If you need a data structure more complex than an array of something, C is stupidly verbose.
If you want to deal with pattern matching/regexen, C is ridiculously verbose.
Do I agree that Rust is far more verbose for an embedded "blinky" (the embedded equivalent of "Hello, World!")? Yes.
But once I start doing things like processing messages in a communications stack (BLE, CANOpen, Ethernet, etc.), Rust starts looking better and better.