Live data from Hacker News

The case against a C alternative

c3.handmade.network

261–270 of 388 posts

Re: The case against a C alternative

#261

Earlier quoted context omitted.

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.

One cannot imagine C++ failing to emulate Rust's borrow checker by the end of the decade, even if compiler support is required. Has C++ ever failed to snarf a feature?

Safety features. The committee are, perhaps unconsciously, biased against safety on the presumption (seen in many comments here on HN) that safer has to mean lower performance.

But part of the impetus for Carbon is that WG21 (the C++ Standards Committee) rejected proposals that C++ should focus on better performance and safety. So maybe performance is no longer important either. What's left?

Where they've taken things which might appear on the surface to be modelled on a safer Rust feature, usually the committee insists they be made unsafe. For example suppose I call a Rust function which might return a char or might not, it returns Option and if I'm an idiot and I try to treat that as a char, it doesn't type check because it isn't one, I need to say what I'm going to do when it isn't or else that won't compile.

You can write that in modern C++... except it can automatically try to take the char (which isn't there) out of the empty optional structure and that's Undefined Behaviour. So whereas the Rust prevents programmers from making easy mistakes, the C++ turns those into unexploded bombs throughout your code.

Re: The case against a C alternative

#262

> First of all, pretty much all languages ever will make vacuous claims of "higher programmer productivity". The problem is that for a business this usually doesn't matter. Why? Because the actual programming is not the main time sink. In a business, what takes time is to actually figure out what the task really is. So something like a 10% or 20% "productivity boost" won't even register. A 100% increase in productivi…

Right? Productivity makes thinking easier. It’s part of a virtuous cycle.

Re: The case against a C alternative

#263

> any safety checks put into the competing language will have a runtime cost, which often is unacceptable. Suppose you have bounds checks on array accesses, but your program is 100% correct and the panic case is never hit. Doesn't the branch predictor essentially make the bounds check free? Or very low cost at least?

If what comes after the check is a write or any other destructive operation, then the check is not so easy to mask away. I don't have actual numbers, but my gut is a strong 'no'. That said, a lot of pedestrian code that isn't running particularly hot would probably be better off including runtime checks by default.

It is no different from QuakeC, GOAL, and a myriad of other programming languages that game studios never had as milestone to release to the wieder public, yet they were quite usefull to their owners.

Re: The case against a C alternative

#264
> any safety checks put into the competing language will have a runtime cost, which often is unacceptable

This is completely wrong. The best counterexample is probably ATS http://www.ats-lang.org which is compatible with C, yet also features dependent types (allowing us to prove arbitrary statements about our programs, and check them at compile time) and linear type (allowing us to precisely track resource usage; similar to Rust)

A good example is http://ats-lang.sourceforge.net/DOCUMENT/ATS2CAIRO/HTML/c36.... which uses the Cairo graphics library, and ends with the following:

> It may seem that using cairo functions in ATS is nearly identical to using them in C (modulo syntatical difference). However, what happens at the level of typechecking in ATS is far more sophisticated than in C. In particular, linear types are assigned to cairo objects (such as contexts, surfaces, patterns, font faces, etc.) in ATS to allow them to be tracked statically, that is, at compile-time, preventing potential mismanagement of such objects. For instance, if the following line:

      val () = cairo_surface_destroy (sf) // a type error if omitted
> is removed from the program in tutprog_hello.dats, then a type-error message is issued at compile-time to indicate that the resource sf is not properly freed. A message as such can be of great value in practice for correcting potential memory leaks that may otherwise readily go unnoticed. ATS is a programming language that distinguishes itself in its practical and effective support for precise resource management.

Re: The case against a C alternative

#265
post #221

Earlier quoted context omitted.

Thank you! Please keep pushing such certifications until they become regulations that, like GDPR, even we American developers cannot ignore. Then I can make a strong business case to move away from Electron in the product I'm currently working on. Edit to add: Related to your links to best-selling computers, I've been thinking about downgrading to a low-spec PC as my daily driver, and using a remote machine for the t…

> Please keep pushing such certifications until they become regulations that, like GDPR, even we American developers cannot ignore. People are apparently surprised at how easy it is to ignore the GDPR: https://web.archive.org/web/20200813235643/http://slawsonand... > Article 3(2), a new feature of the GDPR, creates extraterritorial jurisdiction over companies that have nothing but an internet presence in the EU and o…

The EU can fine US companies the same as it can fine most other extraterritorial companies, that is only if the other country allows it. The EU is not going to start an armed invasion over a GDPR violation.

Still big multinational companies will have international branches (Google, Amazon, Microsoft, ...) that can easily be fined in their host countries.

Re: The case against a C alternative

#266
post #84

Earlier quoted context omitted.

And I wrote a firmware in C for 4-quadrant torque control in about the same time. I do not have any formal proof on how buggy/or not it is but the thing runs properly for 10 years already. If that is not "production code" I do not know what is. I am not inexperienced programmer. Rather quite opposite. But this was after I did not touch C and any microcontrollers for like 10 years.

I feel like C is somewhat manageable on microcontrollers. Programs tend to be smaller (micro!), you can often do static allocation which mitigates a lot of the memory management issues, and you're also often dealing with simple types and bit manipulation which is where C shines. In larger programs on full-fat operating systems, programs tend to be much larger (esp. if you include libraries - dealing with libraries be…

This is how I’ve started to think about things too. If every program was authored by a single individual and was relatively small, C would already be the perfect programming language. All the advanced safety features of competitors really only become relevant once you introduce scale.

Re: The case against a C alternative

#267

> 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 not unusual to see C programs written in a "typical" C style become dramatically faster when rewritten in a more modern language.

On the other hand, empirically, it is not unusual to see straightforward C programs being dramatically faster than comparable C++ programs written in enterprise style, and to also build much faster.

> Last but not least, you would have to be a masochist to write heavily multi-threaded code in C

You have to be a masochist to write heavily multi-threaded code that uses a lot of ad-hoc synchronization with mutexes and atomics. As it turns out, for many many tasks, it's also a spectacular bad way to go about parallelization, because mutexes are the _opposite_ of parallelization.

As a rule of thumb, do coarse-grained concurrency. Install a few queues, come up with a job system, and it won't be hard to get parallization right in plain C at all. Writing in C is often a good idea because what's a bad idea to do on hardware coincedes pretty well with what is painful to write.

Re: The case against a C alternative

#268
post #197

Earlier quoted context omitted.

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

Babylonians used it. That's the origin of our time counting system of hours, minutes and seconds and our angle measuring system of degrees, minutes and seconds. Anyway, if we someday change our number system away from 10, I hope the change will be towards a smaller base, like 8 or 6, because when one is a child, it sucks to learn the times tables. Base 12 would increase the number of entries by 44%. Base 8 would decrease them by 46%, and base 6 would have only 6*6=36 very easy to remember entries.

Re: The case against a C alternative

#269
Rust is not only a C++ alternative, it's a C alternative too. You don't have to have methods in your structs or use generics, traits, closures, interators etc.

You won't be able to use the standard library, but it's doable.

Re: The case against a C alternative

#270
post #229

Honestly, I hate includes and preprocessor directives so much that any "better C" variant which replaces them with more modern solutions would probably be enough in my book - with the caveat being that I also like having an IDE very much and wouldn't want to revert to coding in something like emacs with plugins. BTW, C++20 has a good replacement for includes (modules), but IDE support is not there yet and thus it's n…

I wholeheartedly agree, the speed of processing includes annoys me most about C. The sad part is that the mainstream alternatives that I have on the radar are _even slower_ to build. And usage of the preprocessor in APIs is allowing for good things, at least for a compiled systems language like C: Macros allow to get rid of boilerplate on the syntax level and if-defs allow for compatibility. Both points' significance…

What bother me most is not even the speed of compilation (although it's a major pain too), but the fact that I need to create a header file for every .c file I want to have used from outside it's compilation unit, and add method declarations in it. In 2022 it's SO BACKWARDS it hurts.
Post reply on HN