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

C isn't a programming language anymore (2022)

faultlore.com

Post reply on HN
Print view View original

211–217 of 217 posts

Re: C isn't a programming language anymore (2022)

#211

Post by mbonnet »

pjmlp wrote: post #78
nacozarina wrote: post #3

None of the alternatives have stability. What was exemplary & idiomatic rust pre-pandemic would be churlish & rejected now and the toolchain use would be different anyway. Carpenters, plumbers, masons & electricians work on houses 3-300 yrs old, navigate the range of legacy styles & tech they encounter, and predictably get good outcomes. Only C has, yet, given use that level of serviceability. C99, baby, why pay more…

Outside UNIX clones, and embedded space where it is mostly a religious point of view than available compiler toolchains, C has already been displaced. Even the most relevant C compilers are no longer written in C.

Rust is making huge headway in mission-critical embedded.

Re: C isn't a programming language anymore (2022)

#212

Post by thezipcreator »

phicoh wrote: post #115
pjmlp wrote: post #109

Earlier quoted context omitted.

First of all C did not had any generics, so same playing field. C has a runtime, even if tiny. That is what calls into main(), handles floating point arithmetic when none is available, functions that run before and after main(), nowadays also does threading. Heap memory handling in Pascal, Modula-2, Ada, is much safer than C, first of all no need to do math to calculate the right size, arenas are available on the sta…

C uses pointer casts all over the place to fake generics. If you don't have that (in Pascal or MODULA-2) then life becomes very unpleasant. There is a quite a bit of C code that makes creative use of the size of allocations. For example linked lists with a variable sized payload. Again one of the things that would prevent a C programmer from switching to Pascal. I don't expect the Zig user base to become larger than…

> C uses pointer casts all over the place to fake generics.

by "C" do you mean users of C? because most of the C code I write I don't use those sorts of techniques; instead I just use the preprocessor to make scuffed generics.[1] Unless you mean in libc itself, where I don't recall any use of pointer casts like that? If I'm missing something, please enlighten me.

[1] see my (probably terrible) dynamic array implementation, for example: https://git.sr.ht/~thezipcreator/xstd/tree/main/item/src/xst...

Re: C isn't a programming language anymore (2022)

#213

Post by thezipcreator »

thayne wrote: post #65
Ygg2 wrote: post #57

Earlier quoted context omitted.

> Yes, because C is, by virtue of its history Sure history is great and all, but in C it's hard to say reliably define this int is 64-bit wide, because of the wobbly type system. Plus, the whole historical baggage of not having 128-bit wide ints. Or sane strings (not null terminated).

> in C it's hard to say reliably define this int is 64-bit wide That isn't really a problem any more (since c99). You can define it as uint64_t. But we have a ton of existing APIs that are defined using the wobbly types, so we're kind of stuck with it. And even new APIs use the wobbly types because the author didn't use that for whatever reason. But that is far from the only issue. 128 bit ints is definitely a proble…

> 128 bit ints is definitely a problem though, you don't even get agreement between different compilers on the same os on the same hardware.

you technically have _BitInt(128) in C23, but I'm not sure that would even generate what you expect it to.

Re: C isn't a programming language anymore (2022)

#214

Post by 1718627440 »

pjmlp wrote: post #145
1718627440 wrote: post #105

Earlier quoted context omitted.

> but it should've been fixed long ago. Is 27 years for you not long ago enough? That's more than a generation away and closer to the invention of the language than today.

Worse than that, lets remember that WG14 rejected Dennis Ritchie proposal for fat pointers, and the C authors decided it was more fun to keep their own way with other programming languages than try to improve C from WG14. https://www.nokia.com/bell-labs/about/dennis-m-ritchie/varar...

I think we are talking past each other. I was saying that passing an array with a size to a function was standardized 27 years ago, asking if that isn't long enough. Sure, some may don't like how it was standardized, but it is possible.

Beside the sibling comment about this specific proposal, I also think that fat pointers don't belong in the C standard. There is nothing in the C standard that says that pointers on the abstract C machine don't come with the allocated size, in fact the behaviour is described as if they do. Pointers are essentially scoped by allocation. All that is missing is code for that in a C implementation, the language allows that just fine.

Re: C isn't a programming language anymore (2022)

#215

Post by 1718627440 »

SkiFire13 wrote: post #209
kevin_thibedeau wrote: post #154

Earlier quoted context omitted.

C specifies minimum sizes. That's all you need 99% of the time. I'm always annoyed by the people who assume int is 32-bits. You can't assume that in portable code. Use long or ensure the code works with 16-bit ints. That is how the type system was meant to be used. int was supposed to reflect the natural word size of the machine so you could work with the optimum integral type across mismatched platforms. 64-bit plat…

This doesn't really agree with this OP statement: > The programmer should rather prescribe intent and shouldn't constantly think about what size this should exactly have. You still have to constantly think about size! Except now you have to think about _minimum_ size, and possibly use a too big data type because the correctly sized one for your platform had a guaranteed minimum size that's too small for what you want…

It does agree with what I intended to say. The values a type needs to be able to represent are very much part of the intent of a variable. What the programmer doesn't need to specify, is with what bit pattern and what exact bits these values are going to be represented. There are use cases where you in fact do want to do that, but then that implies that you actually care about the wrapping semantics and are going to manipulate bit patterns.

Re: C isn't a programming language anymore (2022)

#216

Post by phicoh »

kreco wrote: post #162
phicoh wrote: post #148

Earlier quoted context omitted.

Maybe because the performance gain is just not there. Adding support for string with explicit length everywhere is a huge amount of work. And then the question is whether such a string is like a Rust slice or something else. And then the gain is close to zero because most filenames are short enough that there is almost no gain.

The mental overhead is pretty significant. You need to do weird string operations, you have certainly a class somewhere that needs to append a zero to then end of a buffer, and exclusively use the class for thw filename. You can't just toss a contiguous number of bytes you to convert it first. Every single piece of software that need to interact with the file system needs to deal with this. I'm not asking about a new…

In practice, with Rust the problem is somewhere else. There is a libc crate that wraps the Unix system calls, so no need to worry about that. What is a lot harder is that Unix filenames are not guaranteed to be UTF-8. So you can't convert to &str or String. At least, not without loss. So you have to keep this around as an OsString.

Re: C isn't a programming language anymore (2022)

#217

Post by kreco »

phicoh wrote: post #216
kreco wrote: post #162

Earlier quoted context omitted.

The mental overhead is pretty significant. You need to do weird string operations, you have certainly a class somewhere that needs to append a zero to then end of a buffer, and exclusively use the class for thw filename. You can't just toss a contiguous number of bytes you to convert it first. Every single piece of software that need to interact with the file system needs to deal with this. I'm not asking about a new…

In practice, with Rust the problem is somewhere else. There is a libc crate that wraps the Unix system calls, so no need to worry about that. What is a lot harder is that Unix filenames are not guaranteed to be UTF-8. So you can't convert to &str or String. At least, not without loss. So you have to keep this around as an OsString.

Yeah that's the kind of thing I'm talking about.

Even when you don't care about being cross-platform, you still need to rely on specific routines instead of having the most low level `ut8fopen(buffer, len, mode);`

My point is that I wish we would have a new "standard OS-related API", not even talking about introducing span type or anything, just creating something way more sane and care about moving forward from this point.

If I was about to create my own OS and decided to eliminate null-terminating string, and keep it as tiny and efficient as possible, I would face so many issues because I cannot reuse 99% of the code (related to file API) that already exists, I would need to think how to properly parse arguments from "main" without overhead etc.

Post reply on HN