rwbt

> If you object to iostream on religious or stylistic grounds,

No I object to it on usability grounds. It took more than 30 years for the committee to admit it but C++ now has typesafe std::print/std::format finally, after admonishing programmers for using `printf` in C.

The soon to be standard C++26 Reflection library?

There's also Odin[0] too. I experimented them all and Odin is pretty nice. Nim is also good too but a lot more features.

But - I concluded that language matters a lot less compared to APIs. Yes, the language should have enough good features to let the programmers express themselves, but overall well designed APIs matter a lot more than language. For example -tossing most of the C stdlib and following a consistent coding style (similar to one described here -[1]), with using Arenas for memory allocation, I can be just as productive in C.

[0] - https://odin-lang.org [1] - https://nullprogram.com/blog/2023/10/08/

Template-Toolkit seems like the right tool for the job. Thanks for sharing.

I'm curious how your build process works with the codegen approach. Do you have the codegen run a pass everytime you build the project? Or is it a manual process?

I've always wanted to use Lua to generate boilerplate C code (like typesafe vectors) instead of relying on macros, so might actually start thinking in this direction going forward.

I've been using hledger[1] - similar tool but has more features like balance sheet, income statement generation with a plain text file for the last 3 years and it's been working out great. Before that I used iBank (rebranded as Banktivity) and don't miss it at all.

[1] - https://hledger.org

I love niche projects like this. Bonus points for the name.

Is that really that surprising? The thing about having software everywhere is that it tends to create ecosystems. The one or two companies that control those ecosystems tend to dictate everything which snuffs out a lot of these products.

How does one get virtual credit cards? I remember some banks like Discover offered them, but I don't see them anymore.

I find it to be the opposite. Re-gen braking is very close to engine braking in a manual transmission car (before the modern "rev hang" tuning to prevent people from stalling) - I love it.

I still drive a manual transmission car, but don't mind the one-pedal if I were to switch to an EV.

There's a lot of feature gap between C and C++. Many including me like to program in C but want just a _little_ more safeguards, syntax sugar and some established ideas (like defer) that improve the programming experience.

Now there are languages like Odin, Zig and C3 that are trying to fill that niche but having C evolve slowly to accommodate such users is also a great idea.

C99 added Designated Initializers which IMHO is probably the most innovative declarative syntax to initialize anything and it took C++ roughly 20 years to adopt such a thing (and then they had to nerf it).

That's clever!

I hope the C++ committee will fix their designated init feature implementation (atleast for POD structs) because this single feature makes the code 10x more readable.

> To be clear, I am talking about a tool that will generate the Odin bindings for the specified C header(s). A magical "import c code", is what I am arguing against.

Ok I understand now. I think even having such a tool i.e. to generate bindings from a C header file would be godsend.

> WebGPU is a mess regardless.

Interesting, it's not perfect but better than writing shaders in multiple languages and maintaining multiple render pipelines. Right?

> There is also the second issue that C is technically TWO languages: the C programming language and the C preprocessor. People mix the two together and things cannot be easily translated. A good basic example of this is people using `#define` for constants, and thus that name has no semantic meaning in the language itself. A translator has to try and make some semantic meaning from the intersection of these two languages, even if people don't make a distinction when making APIs.

I completely agree that this a giant PITA. But glad it's being considered to be part of toolchain. I would also suggest you reconsider the functionality of importing C headers directly. Yes, they won't be as nice as Odin bindings but they'll definitely give a nice stop gap. Just recently I had a project that uses WebGPU but couldn't generate Odin bindings automatically or find an existing one. So had to go with C++.

Another aspect is, many times I deal with proprietary APIs that have headers with all sorts of macros, bitfields and byte paddings. Having a direct C header import might also help with this case. Yes that API will still be ugly and less ergonomic but everything else would be nice. A bit like Futhark for Nim[0] or lcpp for LuaJIT[1] would really help to write more Odin.

Standard Library - I don't remember off the top of my head but I tried strconv procs a while ago to parse OBJ files and found that the floating point parsing to be slower than strtod. Maybe it's not the case anymore I'll give it a try again and open issues on Github for any feature requests.

Bitfields - In my line of work this is a must-have.

[0] - https://github.com/PMunch/futhark [1] - https://github.com/m-schmoock/lcpp

I also stopped writing destructors (because eventually that leads to writing move constructors); instead now just use a unique_ptr to wrap resources (covers most of the cases) or a simple scope_exit (ala "defer"). Turns out separating ownership and lifetime really helps to write much better C++ code for me.

These simple rules coupled with great modern C++ syntax sugar like lambdas, tuples and 'auto' along with the basic data structures in it's standard library makes it a breeze.

Why is it hugely unpopular if you don't mind me asking?

This is what I've been thinking lately i.e. C and Lua (throw in LuaJIT too if speed is needed).

But I've found out that using functional parts of modern C++ (bear with me) as a higher level language with C underpinnings also works very well. But you need tremendous discipline to do it successfully. For eg - using only C POD structs, no constructors, no exceptions, no inheritance, limited template usage etc. Some would say a very C style C++ with a lot of syntax sugar.

Huge fan of Odin, true C successor. Much better ergonomics and fun to program than say Zig. But needs the following in my view -

- A way to generate bindings automatically from C Headers or even better - not having to generate bindings separately and just import C headers directly.

- Better tooling and standard library improvements.

I think Odin & Nim are my two favorite "modern" languages but they fill different niches. I see Odin as mainly replacing C while Nim is more a C++ replacement (but with Python like rapid development). I'm always amazed at how productive Nim is but the language has many areas that I'm not familiar with (the AST Macros for example). But Odin mostly fits in my head.

Dawn & wgpu projects are great but having native WGSL support with-in Xcode would be pretty nice. They already have the whole spec implemented anyways, why not as a standalone framework?

A third implementation and also having a WebGPU.framework built-in and shipped with the OS (like all other first party frameworks) would simplify the build and debug process.

It'll be very nice if Apple also releases a standalone WebGPU.framework (or just expose the APIs in WebKit.framework) so we can finally have a true cross-platform OpenGL successor for native development.

I use Fossil every day for all my projects and it works great for me. Super easy to self host and has integrated Wiki, bug tracker, ticket system and a server. Very intuitive CLI too.

Highly recommended for indie/small teams.

Yes. I switched away from Cloudflare DNS and the reCaptcha issue went away.

Of all the "Better C" programming languages I've tried so far, Odin is my favorite. Somehow it feels very ergonomic and familiar to a C programmer. Zig has many cool things, but I'm always second guessing myself and trying to figure out the "right" way to do things. But writing Odin is really nice and feels fun.

I have high expectations from Odin going forward, but there are some pain points hopefully will get resolved in the future. - The toolchain is alright at best (I know this is being worked on right now). - Discord only communication with the community. They're all very nice but sometimes I wish a lot of these discussions should be indexed by a search engine.

I would love to make more trips on a bike rather than a car. Especially for trips less than 5 mile radius. But the city where I live (Los Angeles) has very few protected bike lanes. I'm glad things are gradually moving in the right direction, but boy do we have a long way to go.

Similarly, Apache Portable Runtime (APR) uses memory pools which is pretty effective.

I would suggest you to checkout Odin[0]. It's very similar to Zig but has much better ergonomics and probably the closest to a 'Better C' replacement in my experience. It does array bounds checking by default (which you can turn off if you choose to)

[0] - https://odin-lang.org

I think any reasonable C++ programmer should expect that adding two 16 bit uints of values 50000 will be greater than what a 16bit uint can hold and will overflow.

But can one e-File with Free File Fillable Forms? If I have to print out the return and mail it, then it's a no go for me.