71–80 of 363 posts
Earlier quoted context omitted.
C is the best choice if you want all of: small (both language and binaries), fast (both compiler and binaries), obvious (no/minimal complex magic), close to the metal, with excellent debugging support, portability and integrations. No other language has been battle tested for longer and more extensively than C. Your kernels, OSes, drivers, databases, web servers and compilers are written in C. If some of these featur…
Languages exist that compile to C which gives them many of the above advantages and more, so why choose C over them?
We already lose quite a bit of control with C (e.g. it reorders your code as it pleases) to gain portability across CPUs, otherwise we'd have to rewrite the code in several assembly languages.
If you consciously choose to give up even more control over the code that runs (because a compiler that targets C necessarily adds another layer of autogenerated code that you don't control) then it better be a wise tradeoff.
Earlier quoted context omitted.
When the world is a PDP-11.
And x86, Arm, PIC, Xtensa,... and everything else.
http://www.open-std.org/jtc1/sc22/wg14/www/wg14_document_log...
Earlier quoted context omitted.
I'm going for C, because I am experienced with C and despite it being more tedious, with having to do everything yourself, I stick with it because the compile times, and in fact the compile process, are so much faster and simpler. I really enjoy the direct feedback I can get. I considered C++ but that too had terrible compile times. Ideally a debug build should simply not take longer than 100ms for a codebase that is…
You could get productive in Rust in 3 months max, and then the productivity gains would quickly outweigh the initial investment
I can't tell if this is serious. Surely if you're still using C now it's for legacy reasons. And if using it for legacy reasons you are likely stuck using an old C standard. So who will use C23?
Sounds like you're not really in touch with the real word. C has many benefits and it is super practical. Yes, you can write unsafe code, but safety isn't always your #1 priority. There are also tools you can use to identify issues, which will mitigate risks.
The logic of it is something like: I write the code, I run a command written using similar code, scenes deleted, my program runs and my IDE tells me if there are problems in my code.
This is sometimes defined as the difference between developers and engineers, but I don't really buy the analogy because they're mostly highly competent and able to build solid and principled architecture into their software.
This is the only reason I can summise that educated programmers would say something like C is irrelevant.
I guess not everyone needs to have a depth of understanding of the platforms that underly their languages of choice, but - as demonstrated here - it certainly doesn't inform the future of languages when they are inherently tied to their ability to integrate with different hardware and OSs.
Removing K&R style function prototypes though is kind of big. I remember when one of the Objective-C upgrades started enforcing K&R. I don't think ObjC will be upgraded to C23 (ever, as it's a language being deprecated now I presume) so it will be stuck with K&R... while the rest will move on? Could someone also explain what this means for pure C in terms of compatibility? If there's void foo(); would the meaning of…
What's being removed in C23 is the ancient K&R syntax for function definitions: int max(a, b) int a, b; { return a>b?a:b; } My understanding is that C23 does not change the meaning of function declarations. So "void foo();" remains a declaration of a function accepting an unknown number of parameters.
Earlier quoted context omitted.
I get that the compile process is faster, but simpler? In my experience, the compile process usually consists of "cargo build" A advantage of Rust is that usually you spend way less time debugging, because the compiler prevents many mistakes from compiling in the first place.
I have an IDE with clang-lint and I find that it can spot pretty much every mistake. It can even detect some lifetime issues. Other than that my programming style is very much pass-by-value, trust the compiler to inline it, so the typical memory safety issues are simply not relevant to me.
Regarding compile times, Rust has a different approach. Instead of a fast cycle of run and see if it broke, it's more of following compiler nags until the program is correct and runs on the first try. Incremental (cached) compile times aren't too bad these days.
Earlier quoted context omitted.
> So who will use C23 I can't say if I'd immediately jump to C23 but I'll be thrilled to give it a try. Currently I'm rewriting an entire automotive OCPP charging point and it's associated CSMS in C because the original dev (who has no experience with Edge/IoT and just Cloud/SaaS) thought it was a great idea to implement this in golang. The binary size alone is already a problem where all I have is 30MB (needs to be…
Is it a good summary that the only reason for deciding for C instead of Rust/Nim/Zig is that not enough programmers know Rust/Nim/Zig?
Because they know the moment they come back "crying" saying "we can't find anyone with these skills" I'll consider it as their problem, because I for sure am not going to help sifting through LinkedIn profiles or get involved with their "talent acquisition strategy" (at least not in the capacity of an architect/engineer)
I'm not saying always use C but if you have a very narrow skill-set in your team then switching languages is a long-term strategic decision that goes well beyond the opinion of the SW-teams. It's about strategy, budget, risk. That's probably true for most new languages / tools that replace the status-quo and not just about C vs Rust&Co. If I bring in a new technology then I'd first use them in parts of the system that aren't core-business (e.g. my infra automation etc) and then gain experience slowly with them before considering allowing them into parts that make up my core-business. It's a long term project to adapt a new technology not something a few devs decide. (start-ups switching from MVP to real products might be an exception, as are bigger companies switching from PoC to a real implementation, etc.)
Earlier quoted context omitted.
Why does it matter if compile time is 100ms or 300ms? At even a second, that’s going to be so negligible in the context of code-compile-debug work. Especially if something like a flash download is involved.
0. it is a noticeable delay and impinges my momentum 1. A flash download is not involved 2. I hardly debug. I seem to be in a minority here, but my linter really does catch pretty much everything. I don't blindly write code, I always ponder my approach first. So basically, the compile times pull me out of the flow.
One trick I like is to have a 2nd terminal watching the file(s) I'm editing, triggering a make/run on each save; building and running is then a single keypress away:-
while [ 1 ]; do
inotifywait -e move_self foo.c
cc foo.c -o foo && ./foo # or 'make && ./foo'
done