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

Ask HN: A retrofitted C dialect?

news.ycombinator.com

Post reply on HN
Print view View original

61–70 of 81 posts

Re: Ask HN: A retrofitted C dialect?

#61

Post by pjmlp »

gwbas1c wrote: post #27

There are plenty of attempts at "safe C-like" languages that you can learn from: C++ has smart pointers. I personally haven't worked with them, but you can probably get very close to "safe C" by mostly working in C++ with smart pointers. Perhaps there is a way to annotate the code (with a .editorconfig) to warn/error when using a straight pointer, except within a #pragma? > Just talk to the platform, almost all the p…

> C# / .Net tried to do that. Unfortunately, the memory model needed to enable garbage collection makes it far too opinionated to work in cases where straight C shines. (IE, it's not practical to write a kernel in C# / .Net.

It was pratical enough for Singularity and Midori.

Those projects failed due to lack of leadership support, not technical issues.

Additionally, Android and ChromeOS are what Longhorn userspace could have looked like if leadership support was there, instead of rebooting the whole approach with C++ and COM, that persists to this day in Windows desktop land, with WinRT doubling down on that approach, and failing as well, again due to leadership.

Re: Ask HN: A retrofitted C dialect?

#62

Post by sim7c00 »

Its never a bad idea to have a better C. despite having alternatives that somewhat work, usually C is just the only logical choice in certain domains, because i think a certain freedom to express things memory wise, which ofc have a lot of pitfalls, but are needed.

i'd say if you want to make such a language, build embedded or core OS code with it. things that do MMIO, DMA interactions, low level IO in kernel code or firmware (more embedded).

if you can solve it in that domain, everyone will love you forever.

Re: Ask HN: A retrofitted C dialect?

#63

Post by Macha »

tayo42 wrote: post #49
mikexstudios wrote: post #20

Kind of along these lines but for C++: https://docs.carbon-lang.dev/

Isn't all C also valid C++? So this would apply?

No: https://en.wikipedia.org/wiki/Compatibility_of_C_and_C%2B%2B

There's the small stuff like "class" is a keyword in C++ so not a valid variable name.

There's the fact that C has continued to evolve so there are new C features that haven't made it into C++ yet (VLAs).

There's stuff that has been implemented differently in both in mostly compatible but sometimes observably different ways (e.g. the types of character and boolean literals)

Re: Ask HN: A retrofitted C dialect?

#64

Post by anqurvanillapy »

woodrowbarlow wrote: post #22
anqurvanillapy wrote: post #9

Earlier quoted context omitted.

> There are approaches e.g. Zig. Yes! Zig has done a great job on many C-related stuff, e.g. they've already made it possible to cross-compile C/C++ projects with Zig toolchain years ago. But I'm still quite stupidly obsessed with source-level compatibility with C, don't know if it's good, but things like "Zig uses `0xAA` on debugging undefined memory, not C's traditional `0xCC` byte" make me feel Zig is not "bare-bo…

> source-level compatibility with C not sure if this is exactly what you meant, but in Zig you can #include a C header and then "just" invoke the function. no special FFI syntax or typecasting (except rich enums and strings). it can produce compatible ASTs for C and Zig.

Notable approaches to compatibility with C might be: 1) LLVM, like Rust and Zig did (Zig stopped using it in 2023), since LLVM IR is good for being compatible and optimizing. 2) Other backends like libgccjit, I mentioned this because rustc has a libgccjit backend and its author who is a libgccjit maintainer loves the simplicity of it, one could also think of it as a programmable GCC. 3) Code generation directly to C, that's what Koka does.

So I was talking about the direct C codegen approach, but there's still much of some mess like one needs to choose a C standard and knows how to verify the generated code.

Re: Ask HN: A retrofitted C dialect?

#65

Post by jcarrano »

gwbas1c wrote: post #27

There are plenty of attempts at "safe C-like" languages that you can learn from: C++ has smart pointers. I personally haven't worked with them, but you can probably get very close to "safe C" by mostly working in C++ with smart pointers. Perhaps there is a way to annotate the code (with a .editorconfig) to warn/error when using a straight pointer, except within a #pragma? > Just talk to the platform, almost all the p…

Gobjects are a nightmare. A poor reimplementation of C++ on top of C. You have to know what "unref" function to call and that type to cast. For all the drawbacks of C++, it would have been less bad than Gobject.

Re: Ask HN: A retrofitted C dialect?

#66

Post by anqurvanillapy »

viraptor wrote: post #39

Here's a thing... There's been many of them and they all die because they don't provide enough benefit over the status quo. Cyclone https://en.wikipedia.org/wiki/Cyclone_(programming_language) is probably the most known one. There's Safe C https://www.safe-c.org/ A bit further from just "dialect" there's OOC https://ooc-lang.github.io/ and Vala https://vala.dev/ But the only thing that really took off was effort to c…

> But the only thing that really took off was effort to change things at the very base level rather than patch issues.

Exactly, that's the most important takeaway I got from all the discussions here: I will be patching issues while people are flooding in for better general approaches.

I might shift much of my direction, but lucky that there are many "lessons" (like ooc) to learn.

Re: Ask HN: A retrofitted C dialect?

#67

Post by AlotOfReading »

edwcross wrote: post #54
AlotOfReading wrote: post #44

Earlier quoted context omitted.

Astree is a pain in the butt. Even if it were free, I'd recommend it to very few people. It's not usable without someone (often a team) being responsible for it full time. TrustInSoft is the higher quality option, polyspace is the more popular option, and IKOS is probably the best open source option. I've also had luck with tools from Galois Inc and the increasingly dated rv-match tool.

Funny you mentioned TrustInSoft but not its open-source origin (which is still under development and evolving in a different direction), Frama-C. I cannot compare it to IKOS, but their usefulness depends a lot on the type of code and verification needs.

I want to like Frama-C, but I've never managed to actually use it successfully on real projects and the repeated experiences have soured me on it. Getting a recent version installed was a serious chore last time I tried, and no one else is willing to deal with ACSL to get the full value.

Re: Ask HN: A retrofitted C dialect?

#68

Post by anqurvanillapy »

pkkm wrote: post #29

I'm a lot less experienced than you, but since you're collecting ideas, I'll give my opinion. For me personally, the biggest improvements that could be made to C aren't about advanced type system stuff. They're things that are technically simple but backwards compatibility makes them difficult in practice. In order of importance: 1) Get rid of null-terminated strings; introduce native slice and buffer types. A slice…

Love all the ideas here.

I found it might be possible to tackle "strict aliasing" and "pointer provenance" with a type system and I would head down to it early. The approach might sound like Rust's `MaybeUninit` but I didn't think much about it.

I've already implemented procedural metaprogramming in a JS dialect of mine [1], it's also trivial to use it to implement compile-time format strings. I would improve the whole experience in this new C-like language.

Again, very very practical ideas here. Great thanks!

[1]: https://github.com/rowscript/rowscript/blob/16cb7e1/core/src...

Re: Ask HN: A retrofitted C dialect?

#69

Post by tayo42 »

Macha wrote: post #63
tayo42 wrote: post #49

Earlier quoted context omitted.

Isn't all C also valid C++? So this would apply?

No: https://en.wikipedia.org/wiki/Compatibility_of_C_and_C%2B%2B There's the small stuff like "class" is a keyword in C++ so not a valid variable name. There's the fact that C has continued to evolve so there are new C features that haven't made it into C++ yet (VLAs). There's stuff that has been implemented differently in both in mostly compatible but sometimes observably different ways (e.g. the types of character…

Interesting I Wonder why I thought that then

Re: Ask HN: A retrofitted C dialect?

#70

Post by anqurvanillapy »

ebiederm wrote: post #40

If the goal is something that can be used to improve existing C code, I have a few thoughts. To get to memory safety with C: - Add support for array bounds checking. Ideally with the compiler doing the heavy lifting and providing to itself that most runtime bounds checks are unnecessary. - Implement trivial dependent types so the compiler can know about the array size field that is passed next to a pointer. AKA void…

> On the other hand I think we are in a local maxima with programming languages and type systems.

I think I gotcha. Oh no.

> But I haven't finished fleshing it out and proving the type system, so I really can't share it yet.

Any profile I could follow to wait for this to happen some day? I've made several pen-and-paper attempts on some problems you just mentioned, and further ones would be "strict aliasing", "pointer provenance" and many which appeared in all the dicussions here. It feels like you've already done many stuff, but I can't find your profile anywhere.

Post reply on HN