Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The case against a C alternative

c3.handmade.network

Post reply on HN
Print view View original

371–380 of 388 posts

Re: The case against a C alternative

#371

Post by kaba0 »

logicchains wrote: post #199
woodruffw wrote: post #40

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

I would be interested in how big of a difference does it make — these branches will always go one way, so they are trivial to branch predict. Other than very slightly increasing the code size (which can have a big effect if the i cache is no longer sufficient), I fail to see it doing too badly as is.

Re: The case against a C alternative

#372

Post by weatherlite »

Nursie wrote: post #358
weatherlite wrote: post #332

Earlier quoted context omitted.

C noob here. Why isn't a hash table implementation merged into the c standard library? Is it because the stdlib has to be as thin as possible for some performance reason or something?

I did C for about 15 years.... Yeah C doesn't really go in for that sort of thing. The standard library tends to be much more about some minimal support for strings and interfaces to OS features like files, signals, memory allocation etc. It doesn't really provide much in the way of building blocks to be reused by application developers. The recommendation out there on the net seems to be to look at Glib, which is us…

How was doing C - is it a rewarding career? What did u move to? Sorry for randomly asking this I'm contemplating moving from Ruby/Go to C because doing web for so long gets old...I'm not feeling like I'm deepening my knowledge anymore.

Re: The case against a C alternative

#373

Post by jstimpfle »

kaba0 wrote: post #369
jstimpfle wrote: post #232

Earlier quoted context omitted.

_There are_ programs that are constantly running strlen(). C strings are the default builtin string representation that has an acceptable tradeoff for performance vs space and simplicity for where they are used: Mostly in string literals, which are expected to be small strings. Mostly for printf() and friends. Zero-terminated strings are space efficient and don't allow bike shedding like length-prefixed strings do. A…

Zero-terminated strings was a bad decision even back then, let alone now. They make vectorization very painful, and you just needlessly have to iterate over strings at every use-site.

Except nobody cares about vectorization of your printf("Hello, World\n") or other 12-character strings. Vectorization here would in fact be a waste of build time as well as object output size, and the runtime performance would be not measureably different, possibly even slower in some cases. It's a total waste.

When you're processing actual buffers full of text or binary data, and performance matters, of course you are not advised to use an in-band signaled sentinel like zero-terminator is. Use an explicit length for those cases.

Re: The case against a C alternative

#374

Post by kaba0 »

xorvoid wrote: post #314

The article misses a really big item. I’ve programmed in C for 20+ years and then recently switched to rust. When fellow C programmers ask me how Rust is going, I say “it’s modern” and “it’s consistent”. What I mean by that unlike C, Rust doesn’t have 50 years of baggage: string functions that handle null termination all differently, complicated implicit promotion rules, null-terminated strings that haven’t been a go…

What is C’s job, when would you use it for a green field project? Not trying to start a flame war, genuinely curious as I see less and less need for C, other than maintaining all those existing code bases.

Re: The case against a C alternative

#375

Post by Nursie »

weatherlite wrote: post #372
Nursie wrote: post #358

Earlier quoted context omitted.

I did C for about 15 years.... Yeah C doesn't really go in for that sort of thing. The standard library tends to be much more about some minimal support for strings and interfaces to OS features like files, signals, memory allocation etc. It doesn't really provide much in the way of building blocks to be reused by application developers. The recommendation out there on the net seems to be to look at Glib, which is us…

How was doing C - is it a rewarding career? What did u move to? Sorry for randomly asking this I'm contemplating moving from Ruby/Go to C because doing web for so long gets old...I'm not feeling like I'm deepening my knowledge anymore.

Honestly I'm happier where I am now, which is generally writing http APIs and cryptography related code in Java (with bits of Go and python thrown in).

Development in C is slow, fraught with unexpected pitfalls and you end up writing an awful lot of stuff from scratch. While this is satisfying in some ways, I find the modern paradigms of the languages I work in now to be more fulfilling - yes you throw a lot of existing components together, but you also get to deliver functionality much more frequently.

There are also a lot of very old-school C shops out there, that don't believe in modern things like CI/CD, git, even automated testing. I'm sure there are good ones too, but there are a lot of dinosaurs in that arena. One of the last ones I contracted for (for about three weeks until I quit) responded to my usual first-day question of "OK, how do we build this product?" with "Oh don't worry about that, we can sort that out later" and later never came.

That all said - I really enjoyed working on a couple of embedded devices. Seeing what you can achieve with 128kB of SRAM and 256kB of flash is challenging, and since I was a kid I've enjoyed making the computer do stuff. With embedded devices that have buzzers, leds, little displays etc, you get immediate feedback. And having to think more about things like memory allocation strategies does influence your thinking in (I think) a good way. You can definitely gain some deep knowledge!

Re: The case against a C alternative

#376

Post by bluGill »

jstimpfle wrote: post #320
bluGill wrote: post #293

Earlier quoted context omitted.

> 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. Your only comparison cases are cases where the code in question was re-written in C. This most likely means that everyone already knew it was slow and so the re-write also fixed the fundamental problems. If the code had…

> it is known that if you switch from gcc to g++ your code often will run faster if it compiles) I've never heard such a claim, can you back it up? And what does it say about the language? > and it is a lot more maintainable If you equate "maintainable" = readable, I've never once seen maintainable enterprise code. Everything is a convoluted mess that never gets anything done. Probably I haven't worked at the best sh…

https://www.codeproject.com/questions/445035/c-vs-cplusplus-... has a long discussion. The short answer is C++ has stricter aliasing rules, and so the compiler can apply more optimization. This of course assumes that your C code is also valid C++ code (C is no a pure subset of C++), and you don't have those aliases - those apply to a lot of C programs but not all.

> And what does it say about the language?

C++ has a stronger type system. This is already known. You avoid a few bugs in C++ because of this. The type system isn't nearly as strong as Haskell.

> I've never once seen maintainable enterprise code. Everything is a convoluted mess that never gets anything done

Two sides of the same coin. While the code is convoluted, it often is doing a lot of things in a generic way. More straightforward code is possible, but only by created a lot more code, and quantity is itself convolution.

> And why doesn't the language help mediocre programmers to write maintainable code?

It does. However you have to be careful here. C++ is often used for very large problems that are also complex. I would never use python for something that is over 100,000 lines of code as you can't change anything anymore for fear that some case isn't covered in the tests and so you won't see that syntax error until months later. I maintain 15 million lines of C++ (and this isn't the largest C++ codebase I know of).

Not, I'm not arguing that C++ is a great language. It has a lot of inconsistencies, and foot guns. However it is still the best language I know for very large, very complex programs. (Note that I do not know ADA or Rust, two that often come up in context of very large, very complex programs. I would not be surprised if they are better. That C++ is better known that others is itself an advantage to C++)

> I suspect that maintainability is almost exclusively a function of experience, not the programming language used.

Sort of. As I said before languages like Python are out of the running for very large programs because they are not compiled and so you can get runtime errors. There are also intentionally impossible to write languages that we can throw out even sooner. However there are for sure other languages that can play in the very large program space. So long as we limit ourself to languages that play in the very large program space, experience is the largest factor.

Re: The case against a C alternative

#377

Post by jstimpfle »

kaba0 wrote: post #368
jstimpfle wrote: post #326

Earlier quoted context omitted.

There's nothing complicated? You have to 1) #include 2) Write "std::unique_ptr foo" instead of just "My_Foo_Type *foo" in every definition. 3) Are required to define My_Foo_Type as a class with a separate deleter, or provide a deleter template argument at each declaration. 4a) write "foo.get()" in various places instead of just "foo". or 4b) lend around the unique_ptr in various places, breaking modularization and in…

> Data schemas and physical layout on the one hand, and memory and lifetime management on the other hand How are they separate? Like, that’s what Rust does pretty explicitly, with great results.

I'm not following, what is Rust doing exactly? Coupling schema / layout with lifetime management? If that's what you mean I would like to disagree about the "great results" because of a gut feeling, and possibly the disagreement could in theory be justified with build times, or viewpoints on maintainability or whatever. But unfortunately I have no basis for doing so. I don't understand Rust well. And have very little experience, expect failing at compiling some projects and their 500 dependencies a couple times...

Re: The case against a C alternative

#378

Post by weatherlite »

Nursie wrote: post #375
weatherlite wrote: post #372

Earlier quoted context omitted.

How was doing C - is it a rewarding career? What did u move to? Sorry for randomly asking this I'm contemplating moving from Ruby/Go to C because doing web for so long gets old...I'm not feeling like I'm deepening my knowledge anymore.

Honestly I'm happier where I am now, which is generally writing http APIs and cryptography related code in Java (with bits of Go and python thrown in). Development in C is slow, fraught with unexpected pitfalls and you end up writing an awful lot of stuff from scratch. While this is satisfying in some ways, I find the modern paradigms of the languages I work in now to be more fulfilling - yes you throw a lot of exist…

Do you think experience holds better the lower you go down the stack? Part of my frustration with web development - especially front end, is knowledge decays very fast there. I'm fine with learning new stuff but relearning the same thing all the time and losing my edge is a big annoyance. So part of my wanting to move lower down the stack is my belief that my knowledge and experience will hold up better there. So I'm considering either that or moving to backend work writing something like Java which I also perceive to be a very good investment. .

Re: The case against a C alternative

#379

Post by cartoonfoxes »

kaba0 wrote: post #374
xorvoid wrote: post #314

The article misses a really big item. I’ve programmed in C for 20+ years and then recently switched to rust. When fellow C programmers ask me how Rust is going, I say “it’s modern” and “it’s consistent”. What I mean by that unlike C, Rust doesn’t have 50 years of baggage: string functions that handle null termination all differently, complicated implicit promotion rules, null-terminated strings that haven’t been a go…

What is C’s job, when would you use it for a green field project? Not trying to start a flame war, genuinely curious as I see less and less need for C, other than maintaining all those existing code bases.

When working with the huge amounts of embedded silicon that is supported by C libraries and toolchains only.

Re: The case against a C alternative

#380

Post by water8 »

mumblemumble wrote: post #343
dagw wrote: post #228

Earlier quoted context omitted.

It's not unusual to see C programs written in a "typical" C style become dramatically faster when rewritten in a more modern language. This was equally true back when C vs Fortran was the big debate, and something not easily captured in benchmarks. C, as written by an expert in high performance C, was equally fast as Fortran written by an expert in high performance Fortran. C, as written by a domain expert with limit…

This actually reminds me a bit of an old competition between two Microsoft MVPs comparing C++ and C#, where they went back and forth optimizing their respective versions of a model program, and discussing the optimizations they made. The gist, as I recall it was: the initial, idiomatic, written-for-maintainability version of the C# program was significantly faster than the C++ equivalent. Up until the end, the C# ver…

C# is closer to Java than C++. It’s a garbage collector language and nowhere near the performance of C++
Post reply on HN