The momentum of C seems so vast that replacing it is like getting humans to switch to a base-12 number system
The case against a C alternative
191–200 of 388 posts
Re: The case against a C alternative
#192Earlier quoted context omitted.
Not to mention that both C++ and Rust can specialise algorithms and containers for specific types, whereas in C most developers resort to void* and function pointers. It's not unusual to see C programs written in a "typical" C style become dramatically faster when rewritten in a more modern language. For example, typical C programs also don't use hashtables even when this makes the most sense, causing weird performan…
Precisely. This is perhaps the strangest part of the original post: C++ has the same performance advantages as Rust! It has them not because it's more safe (although it is, in some regards), but because it allows programmers to express behaviors that the compiler can reason about statically.
Interesting. Can you list an example of C++ type system allowing optimization Rust system doesn't?
Re: The case against a C alternative
#193Finally an article I can agree with.
C is great mostly because it's easy to learn, and it has many other advantages.
I dislike all those new languages because they have too many features, and they're non trivial to learn.
I've looked at some rust codebases and I don't think there will be a lot of people who will want to maintain them. Rust is difficult, even though it's an awesome language.
A language that could compete with C would:
* Be fast to compile
* Have some quality of life things you can find in the C++ STL: map, string, etc
* Look a lot like C, meaning it would not try to innovate too much.
To summarize, it would be a lighter version of C++.
Re: The case against a C alternative
#194> Any C alternative will be expected to be on par with C in performance. The problem is that C have practically no checks, so any safety checks put into the competing language will have a runtime cost, which often is unacceptable. This leads to a strategy of only having checks in "safe" mode. Where the "fast" mode is just as "unsafe" as C. I don't think this is true, in the general case: Rust has shown that languages…
Not to mention that both C++ and Rust can specialise algorithms and containers for specific types, whereas in C most developers resort to void* and function pointers. It's not unusual to see C programs written in a "typical" C style become dramatically faster when rewritten in a more modern language. For example, typical C programs also don't use hashtables even when this makes the most sense, causing weird performan…
> it's just that C developers avoid them.
I'm not sure it's fair to say C developers avoid hash tables - I've worked on several projects with hash-table implementations in them.
The 'problem' if there is one, is that such things are rarely picked up from any sort of standard library, and are instead implemented in each project.
I'm also not really sure what the problem is with 'resorting' to void*, it's part of the language. It's not 'safe' in that the compiler won't catch your errors if you stuff any old thing in there, but that's C.
> you would have to be a masochist to write heavily multi-threaded code in C
pthreads makes it relatively straightforward. I've seen (and written) fairly sophisticated thread-pool implementations around them.
Re: The case against a C alternative
#195Earlier quoted context omitted.
Gonna beat a dead horse here, but >50% of PCs that are surveyed by Steam have 12 threads or more. That’s PCs that have steam installed at all. Intel’s bare minimum current-gen i3 processor has 12 threads. That’s the absolute cheapest desktop-level processor you can get. Your phone probably has 6 cores (though not 12 threads). So yes, if you’re writing code for desktop hardware, it’s safe to assume you have at least 8…
Gaming is very much not representative. There's roughly 120M active steam users, vs. ~1.4 billion windows installs. If I look around me, for instance in my whole family we're two with Steam installed but ever household has a desktop or a laptop (and generally a 7-8 years old cheap entry-level 350€ one, you'd be hard-pressed to find even a quad-core in there)
I don’t know dude, if you want to write software for the worst performers instead of commodity hardware that’s up to you
Just that single core systems are dying and probably won’t come back. Even Raspberry Pi’s are quad core now.
Re: The case against a C alternative
#196This article is just apologism for the status quo. Nothing new here. > Memory allocation, array and string handling are often tricky, but with the right libraries and a sound memory strategy, it can be minimized. Such a handwavy deflection. Parsing strings in C is a joke and also a minefield bursting with vulnerabilities. And if you use null terminated strings (which you are, let’s face it) it’s slow.
Ok, but there exists a sulotion for this. Using C++ with STL. Why we exactly need a new language?
Re: The case against a C alternative
#197The momentum of C seems so vast that replacing it is like getting humans to switch to a base-12 number system
That's a weird analogy considering humans used base-12 (and base-20 and base-60) number systems for most of history.
Re: The case against a C alternative
#198Earlier quoted context omitted.
> I'm sorry, but the C language toolchain is not great. The only part of the C language toolchain that is good is it's platform support. Every platform has a C compiler. Please take a few days to review John Regehr’s excellent blog. I’m certain that you’ll find dispelling your ignorance rewarding. > How do you grab dependencies for and build javascript? npm install, npm build. Npm is the poster child for supply chain…
> Please take a few days to review John Regehr’s excellent blog. Haven't heard of him but will certainly give a read. Thanks for the heads up. > Npm is the poster child for supply chain attacks. The only reason C doesn't (often) have similar supply chain attacks is because pulling in dependencies is so hard that you aren't likely to end up with a 10k dependency project. Hard to say that's really a plus. Other ecosyst…
> you aren't likely to end up with a 10k dependency project.
> Hard to say that's really a plus.
I'll definitely call that a plus. All dependencies introduce risk. Sure, we can't avoid all dependencies, but carefully evaluating them and keeping the list small is a big win for maintainability and security.
If a random library has a 0.1% chance of having malicious code (I'd say it's more like 1%, but let's be generous), a 10K-dependency program is guaranteed to be pulling in at least something malicious.
Re: The case against a C alternative
#199> Any C alternative will be expected to be on par with C in performance. The problem is that C have practically no checks, so any safety checks put into the competing language will have a runtime cost, which often is unacceptable. This leads to a strategy of only having checks in "safe" mode. Where the "fast" mode is just as "unsafe" as C. I don't think this is true, in the general case: Rust has shown that languages…
Rust does runtime bounds checks on array access, which the compiler can't elide in non-trivial cases (e.g. binary search), so if you want to write such algorithms as fast as in C, you need to use a lot of unsafe array indexing.
Re: The case against a C alternative
#200The momentum of C seems so vast that replacing it is like getting humans to switch to a base-12 number system
That's a weird analogy considering humans used base-12 (and base-20 and base-60) number systems for most of history.
Really? Wikipedia says it is historically uncommon
EDIT: What language uses base-60??