anqurvanillapy

I love your gradual approach pretty much. It sounds like gradual typing but not just the typing part.

I used to make many tools with libclang Python bindings to automate some chores of refactoring. I don't remember if one could expand the macros using it, and I was told that lexer and preprocessor are messed together in Clang. So it should be quite hard to extend the existing framework.

I would definitely go into this direction, but for now it just looks like some final boss, let me finish some early quests.

> Build embedded or core OS code with it. things that do MMIO, DMA interactions, low level IO in kernel code or firmware (more embedded).

I have a friend currently writing a GC in C and I was making it a project to test around my ideas (where problems with generic containers, compile-time eval and static reflection kicked in so early). But these you mentioned sound more important to me, I have more friends working on RISC-V projects, I should find some inspirations from their projects. Thanks for the mention!

> Offer real and significant benefits.

Yeah! The criterion is just there like you said.

> Do you have an opinion on the dotnet version of generics?

I'm not familiar with dotnet languages, but I have much experience implementing generics, especially how to avoid getting the poor C++ templates. Also, I believe traits (not that of C++) and typeclasses (Rust/Haskell) are definitely needed, and it's already proven too, to pair with the generics feature.

> Ceph.

My former job was to write a distributed object storage in Go and it was heavily inspired by Ceph. But subset of the design could make much benefits for a smaller company, since the initial idea to write a new one was from the pain of doing rebalancing in Ceph... oh you want to know the solution? Manual partitioning and migration by our SRE/Ops team lol. It's unexpectedly effective.

> 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.

> 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.

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.

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.

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).

Thanks sooo much! I would definitely do it!

> Imagine writing large games in your language.

You don’t. Read the features I listed. One ends up with a C alternative frontend (Cfront, if you love bad jokes) including type system like Zig without any standard library. No hash tables, no vectors. You tended to write large games with this.

Like I said the main 3 groups of users, if you’re concerned about application writing, ask it. Rest of the comments talked about possible directions of langdev.

> Modules.

You write C++ and don’t know what a standard is. Motivating examples, real world problems (full and incremental compilation, better compilation cache instead of precompiled headers), decades spent on discussions. Economy would come for projects with modern C++ features.

> Threading.

If you know Rust and Go, talk about them more. Go creates tasks and uses futexes, with bare-bone syscall ABI. Higher level primitives are easy to use. Tools and runtime are friendly to debugging.

I wrote Go components with channels running faster than atomics with waits, in a distributed filesystem metadata server.

On CPU intensiveness, I would talk about things like automatic vectorization, smarter boxing/unboxing, smarter memory layout (aka levity, e.g. AoS vs SoA). Not threading niche.

> Strlen implementation and plan of low level programming.

Because I keep talking about designing a general purpose language. One can also use LLVM IR to implement such algorithms.

The design space here is to write these if necessary. Go source code is full of assembly.

> Pointer provenance.

Search for Andras Kovacs implementation of 2ltt in ICFP 2024 (actually he finished it in 2022), and his dtt-rtcg, you would realize how trivial these features could be implemented “for a new language”. I design new languages.

> libc.

Like I said, your happy new APIs invoke malloc.