That's really unfortunate.

> Not as bad as Apple nowadays though, quite far from Inside Inside Macintosh days.

Funny story, I know a guy who wanted to write a personal Swift project for an esoteric spreadsheet format and the quality of the documentation of SwiftUI made him ragequit. After that, he switched to kotlin native and gtk and he is much happier.

> Personally, I think that with the improvements on low level coding and AOT compilation from managed languages, we are reaching local optimum, where C and C++ are good enough for the low level glue, C23 and C++23 (eventually C++26 due to static reflection) might be the last ones that are actually relevant.

I agree on the managed language thing but, I mean, the fact that other languages are getting more capable with low level resources does not mean that improvements in C/C++ are a bad idea and will not be used. In fact, I think that features like the transcoding functions in in C2y (ironically those are relevant to the current HN post) are useful to those languages too! So even if C, C++ and fortran are just used for numerical kernels, emulators, hardware stuff, glue code and other "dirty" code advancements made to them are not going wasted.

[1]: https://devblogs.microsoft.com/cppblog/c11-atomics-in-visual...

[2]: https://devblogs.microsoft.com/cppblog/c11-threads-in-visual...

edit: Isn't it just:

  float (*arr)[m][n] = malloc(sizeof(*arr));

Comments URL: https://news.ycombinator.com/item?id=42115264

Points: 8

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=40337769

Points: 10

# Comments: 0

Not in gccgo

Wait, there is an LLVM based Go toolchain? I thought the Go crowd was known for their NIH obsession.

Comments URL: https://news.ycombinator.com/item?id=39726132

Points: 19

# Comments: 0

- For small 8 bit systems, SDCC is an excellent choice, supporting even C23 features! Also its lead maintainer is a committee member with really useful contributions to the standard.

- I have heard the RiscOS compiler is pretty cool and supports modern standards. That one uses the Norcroft frontend.

I agree with you in that we need a production level C compiler written in C. Though that is not a simple task and the C community nowadays prefers to engage on infighting over pedantic issues or rust rather than working together. A simple example of this is the lack of a modern library ecosystem, while everyone and their mother has their own custom build system. Even though C is sold as a performant language, there isn't a single parallelism library like OneTBB, Kokkos or HPX over at C++. Don't get me started on vendors not offering good standard support (Microsoft, macos-libc, OpenBSD libc)...

One correction though, cparser uses libfirm as a backend, not qbe. Also the author of chibicc has stopped writing that book AFAIK.

Bonus non-c based entries: - The zig community is working on arocc. Judging by the awesomeness of zig cc, these are really good news. - Nvidia offers their EDG based nvc with OpenACC support for free these days, which is cool.

Edit: formatting