This is a dream come true. Please do it, for the love of mankind.
Thanks sooo much! I would definitely do it!
Ask HN: A retrofitted C dialect?
51–60 of 81 posts
Re: Ask HN: A retrofitted C dialect?
#52Earlier quoted context omitted.
Exactly the kind of thoughts and insights I need from more of the users. Thank you for pointing out many concerns. > Headers. C++20 modules are left unstable and unused in major compilers there, but it’s a standard. And C is ironically perfect for FFI, as I said, almost every programming language speaks C: Rust WebAssembly API is extern C, JNI in Java, every scripting language, even Go itself talks to OS solely using…
> Async Rust is painful On the other hand, I've found normal threading in Rust quite simple (generally using a thread pool).
That's true!
Sorry that I didn't much clarify the "pain" though:
It's quite like the experience of using parser combinator in Rust, where you could happily define the grammar and the parsing action using its existing utitlies. But once you have to do some easy wrapping, e.g. to make a combinator called `parenthesized` to surround an expression with parentheses, the "pain" kicks in, you have to leave as many trait bounds as possible since wiring the typing annotations become tedious. That came up while I was using framework like `winnow`.
Async Rust kinda shares some similar characteristics, utility functionalities might bring in many "typing wirings" that could terrify some people (well but I love it though).
Re: Ask HN: A retrofitted C dialect?
#53Kind of along these lines but for C++: https://docs.carbon-lang.dev/
Thanks for the mention! I heard about Carbon years ago but I'm happy this time I could dig it further for insights now.
It's pretty fun to think about "Carbon to C++ is Kotlin to Java". One very important takeaway from all the discussions here is that, I cannot ship a language right to the target (small) community, as it's impossible to control how people decide to use this language. Which means, I have to focus much on how to improve the experience of application writing. Carbon would definitely be one of the inspiration.
Oh yeah, and I don't need to handle seemless integration with templates, I'm lucky.
Re: Ask HN: A retrofitted C dialect?
#54Here is a sound static analyzer that can identify all memory safety bugs in C/C++ code, among other kinds of bugs: https://www.absint.com/astree/index.htm You can use it to produce code that is semi-formally verified to be safe, with no need for extensions. It is used in the aviation and nuclear industries. Given that it is used only by industries where reliability is so important that money is no object, I never bot…
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.
Re: Ask HN: A retrofitted C dialect?
#55C is still evolving. Instead of creating a new C dialect, why not try improving C itself? You can prototype new features with Clang and submit a technical proposal to the C committee for review. Regarding "memory safety" specifically, many of the challenges folks face with RAM management are related to bounds checking so consider prototyping a slices concept [1]. [1] https://www.digitalmars.com/articles/C-biggest-mis…
The problem with this is that even seemingly basic, obviously desirable proposals can take years of labor and politicking to get through the committee. See JeanHeyd Meneide's valiant struggle to get an #embed preprocessor directive standardized [1] - it took five years, and I'm pretty sure the C++ equivalent (std::embed) is still in the oven. When faced with that, it's only natural that people lean hard towards diale…
C2Y, the next C revision, introduced "enable safe programming" into the C standard charter [1]. The C committee is eager for proposals like this.
Adding a new feature, like slices, as a Clang extension would be considerably faster than creating a new dialect or language, and it would be immediately usable by every C codebase building with Clang. Even if the feature is "slow" to be incorporated into the standard, it would still be accessible as a compiler extension in the interim.
[1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3223.pdf
Re: Ask HN: A retrofitted C dialect?
#56You may be interested in the new Clang -fbounds-safety extension https://clang.llvm.org/docs/BoundsSafety.html
Woah I enjoyed the read a lot.
I also learned that in LLVM IR, they have the implicit null checks [1] to replace the guard with just a signal handler, so it won't hurt the branch predictor too much.
So I believe there are many options upon "debug" and "release" profiles for the bound and null checking here. Very good design space.
[1]: https://llvm.org/docs/FaultMaps.html#the-implicitnullchecks-...
Re: Ask HN: A retrofitted C dialect?
#57Have a look at ATS, it is memory-safe and designed for kernel development. There's a kernel and arduino examples. Fluent C interop. No tactics metaprogramming but it'll give you a start.
Oh I heard about it and oops just hate myself for forgetting it.
And the first sentence [1] of its pointer type introduction, exactly says everything I said here...
> [...] greatest motivation behind ATS is to make it employed to construct safe and reliable programs running in OS kernel.
Also found this interesting Reddit thread [2]. Time to bring some old gems back with good ergonomics now, it won't be that hard. Hold my beer for a while.
[1]: https://ats-lang.sourceforge.net/DOCUMENT/INT2PROGINATS/HTML...
[2]: https://www.reddit.com/r/ProgrammingLanguages/comments/uacib...
Re: Ask HN: A retrofitted C dialect?
#58I believe what programmers actually want is clean dialect-free C with sidecar files. It seems people pretty universally dislike type annotations and overly verbose comments, like Ruby's YARD or Java's Javadoc. Also, if your new language doesn't compile with a standard C compiler, kernel usage is probably DOA. That means you want to keep the source code pure C and store additional data in an additional file. That addi…
I love this idea so much.
I got stuck at how to tackle "new language doesn't compile with a standard C compiler" for many times, but my solution is much worse than yours: Like LuaJIT, they left one unreadable "minilua" C file [1] to bootstrap some stuff, we could have a source-code version of the "new C" compiler, compile things twice. That sounds bad.
For languages with a very advanced type system that compiles to C, I could only think of Koka [2], which translates the "algebraic effect and handlers" code into pure C, achieving pure C generators, coroutines and async/await without the support of setjmp/setcontext. But the generated C code is unreadable, I would definitely think about how to handle the readability and debugging issue with sidecar files.
[1]: https://github.com/LuaJIT/LuaJIT/blob/v2.1/src/host/minilua....
Re: Ask HN: A retrofitted C dialect?
#59I'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…
I highly agree that they need to add slice and buffer types to the standard headers. Especially true because the recently added counted_by attribute.
Definitely feel the strict aliasing rule should be opt in.
And there are a lot of small UB that can be eliminated here and there.
I'll add adding types as first class objects. Make typeof actually useful
Re: Ask HN: A retrofitted C dialect?
#60In 2014 John Regehr and colleagues suggested what he called Friendly C[0], in an attempt to salvage C from UB. About bit more than a year later, he concluded that the project wasn't really feasible because people couldn't agree on the details of what Friendly C should be.[1] In the second post, there's an interesting comment towards the end: > Luckily there’s an easy away forward, which is to skip the step where we t…
I think the problem with "friendly C", "safe C++" proposals is they come from a place of "I want to continue using what I know in C/C++ but get some of the safety benefits. I'm willing to trade some of the safety benefits for familiarity". The problem is the friendly C/safe C++ that people picture from that is on a spectrum. On one end you have people that really just want to keep writing C++98 or C99 and see this as…
History has already proven this with Objective-C and C++, also with TypeScript, while those languages provide stronger safety guarantees over plain old C and JavaScript, there are always those that will keep using the old tricks on the new system.
Only removing copy-paste compatibility fixes that.