Comment by thasso | Hacker News Reader

Comment by thasso | Hacker News Reader

You can do lot's of the same things in C too, as the author mentions, without too much pain. See for example [1] and [2] on arena allocators (which can be used exactly as the temporary allocator mentioned in the post) and on accepting that the C standard library is fundamentally broken.

From what I can tell, the only significant difference between C and Odin mentioned in the post is that Odin zero-initializes everything whereas C doesn't. This is a fundamental limitation of C but you can alleviate the pain a bit by writing better primitives for yourself. I.e., you write your own allocators and other fundamental APIs and make them zero-initialize everything.

So one of the big issues with C is really just that the standard library is terrible (or, rather, terribly dated) and that there is no drop-in replacement (like in Odin or Rust where the standard library seems well-designed). I think if someone came along and wrote a new C library that incorporates these design trends for low-level languages, a lot of people would be pretty happy.

[1]: https://www.rfleury.com/p/untangling-lifetimes-the-arena-all...

[2]: https://nullprogram.com/blog/2023/10/08/

The author literally says that they used to do that in C. And I've done a lot of those things in C too, it just doesn't mean that C has good defaults nor good ergonomics for many of the tasks other languages have be designed to be good with.

I am not a C programmer, but I have been wondering this for a long time: People have been complaining about the standard library for literal decades now. Seemingly, most people/companies write their own abstractions on top of it to ease the pain and limit exposure to the horrors lurking below.

Why has nobody come along and created an alternative standard library yet? I know this would break lots of things, but it’s not like you couldn’t transition a big ecosystem over a few decades. In the same time, entire new languages have appeared, so why is it that the C world seems to stay in a world of pain willingly?

Again, mind you, I’m watching from the outside, really just curious.

Because to be _standard_, it would have to come with the compiler toolchain. And if it's scattered around on the internet, people will not use it.

I tried to create my own alternative about a decade ago which eventually influenced my other endeavours.

But another big reason is that people use C and its stdlib because that's what it is. Even if it is bad, its the "standard" and trivially available. Most code relies on it, even code that has its own standard library alternative.

> Why has nobody come along and created an alternative standard library yet?

Everybody has created their own standard library. Mine has been honed over a decade, why would I use somebody else's? And since it is designed for my use cases and taste, why would anyone use mine?

> Why has nobody come along and created an alternative standard library yet?

Because people are so terribly opinionated that the only common denominator is that the existing thing is bad. For every detail that somebody will argue a modern version should have, there will be somebody else arguing the exact opposite. Both will be highly opinionated and for each of them there is probably some scenario in which they are right.

So, the inability of the community to agree on what "good" even means, plus the extreme heterogenity of the use cases for C is probably the answer to your question.

> Why has nobody come along and created an alternative standard library yet?

Probably, IMO, because not enough people would agree on any particular secondary standard such that one would gain enough attention and traction¹ to be remotely considered standard. Everyone who already has they own alternatives (or just wrappers around the current stdlib) will most likely keep using them unless by happenstance the new secondary standard agrees (by definition, a standard needs to be at least somewhat opinionated) closely with their local work.

Also, maintaining a standard, and a public implementation of it, could be a faffy and thankless task. I certainly wouldn't volunteer for that!

[Though I am also an outsider on the matter, so my thoughts/opinions don't have any particular significance and in insider might come along and tell us that I'm barking up the wrong tree]

--------

[1] This sort of thing can happen, but is rare. jquery became an unofficial standard for DOM manipulation and related matters for quite a long time, to give one example - but the gulf between the standard standard (and its bad common implementations) at the time and what libraries like jquery offered was much larger than the benefits a secondary C stidlib standard might give.

I would not agree that the ergonomics are so much better in Odin that switching to another language is worth giving up the advantages of a much larger ecosystem. For a hobby project this may not matter at all, of course.

Odin has very good FFI with its `foreign import` system, so you can still use libraries written in C, Objective-C, or any other language. And Odin does support tools like asan, tsan, etc already too. So what are the thing that you are giving up if you were using Odin instead of C?—in practice.

Use of libraries via FFI also has a cost in terms of ergonomics. But then, what do you give up: For C, many tools exist that support C from very basic stuff such as syntax highlighting to formal verification etc. There are plenty of C programmers, C tutorials, C books etc. There is an industry supporting tooling with many different implementations even for obscure platforms. There is an ISO standard and processes for certification. It is also basically guaranteed that C exists and will be supported in the next 50 years no matter what. Once you start using a niche language you lose a lot of this.

(But I think Odin is great!)

For those use cases, I've always encouraged new languages to support transiting to a verifiable subset of C or another language with such tooling. Errors detected in the other language can be corrected in the source written in the new language. The abstraction gaps must be minimized, though.

> I think if someone came along and wrote a new C library that incorporates these design trends for low-level languages, a lot of people would be pretty happy.

I suppose glib comes the closest to this? At least the closest that actually sees fairly common usage.

I never used it myself though, as most of my C has been fairly small programs and I never wanted to bother people with the extra dependency.

Reply on news.ycombinator.com