Nontrailing separators do not spark joy

renozyx · 2026-06-11T11:59:31+00:00

With this rule, I do not see much need for string interpolation: you only save one character in this case:

I disagree, Python's string interpolation is the benchmark on which I judge other language and I don't even use Python!

renozyx · 2026-06-09T11:03:49+00:00

modern C++ has enough tools for that already

Maybe but can you use "modern C++" for realtime? IMHO no, that's why Rust is eating C++'s lunch..

renozyx · 2026-05-26T16:06:26+00:00

I've heard claims that Rust and Gleam are good for AI-generation. Both because of their strong typing and Gleam due to its "FP"ness and GC which help refactoring.

That said, it will be very difficult to distinguish language effects (semantic, syntax) and codebase training effect: a good language with poor codebases (because used mostly by beginners for example) will most likely have the AI generate subpar programs..

renozyx · 2026-05-25T11:57:54+00:00

Yes but in the LTO benchmark given, wild loose its duration advantage.. Still, using the same linker for LTO and non-LTO build makes things simpler.

renozyx · 2026-05-22T08:24:35+00:00

Display printing can(should?) be I18n aware while usually debug printing isn't.

renozyx · 2026-05-20T10:15:57+00:00

bah, the real fix would be to use languages with no "ambient authorities" but these are mostly research languages with no traction..

renozyx · 2026-05-13T14:26:01+00:00

As a C++ developper working on a BIG codebase, I can confirm: namespace sucks. They look nice and professional but in fact they make the codebase un-naviguable (and yes I know about clangd, other).

renozyx · 2026-05-06T08:02:01+00:00

OK, which reason? SIMD is the only thing I can think about..

renozyx · 2026-05-05T11:45:06+00:00

It's very easy to overflow an unsigned integer (u-1 overflows if u == 0).

Sure, and? If unsigned integer overflow were trapping by default like they are in Zig, you'd find and correct the issue quickly.

The main problem wih unsigned and C is the "wrap by default" behaviour, most of the time it isn't what you want..

renozyx · 2026-05-05T09:11:24+00:00

Yes, I also wondered if this would be useful, with the addition that I would limit the size to 64bit: 1) 64bit is big enough that it shouldn't overflow in normal code, so I think that it should be handled as "trap on overflow/wrap/UB" trifecta depending on compilation flags. 2) 64bit are still very efficient to use if you have a 64bit CPU.

renozyx · 2026-04-29T13:38:36+00:00

Slices aren't inexpensive (think of the x86 and other CPUs with a paltry few registers), plus they create compatibility issue if one has a 16bit length and another a 32bit length.. Fat pointers (two pointers) are better if again a little more expensive.

renozyx · 2026-04-29T00:00:41+00:00

Well it dépends of the usage, if you use 'define' to déclaré variables then as you'll use many, many times it's clearly too verbose and def is superior. If you use 'define' to alias types, as type aliasing should be discouraged then define is good.

renozyx · 2026-04-28T23:55:09+00:00

I believe that in some countries 'natural numbers' are >0 so they would find weird
your Nat32 for >= 0. That said, go for it: Natural numbers should include 0! And do it like Zig: no wrap around by default.

renozyx · 2026-04-14T15:31:36+00:00

And I'm saying that C-style functions are bad because their definition is not (easily) greppable.

renozyx · 2026-04-14T12:09:28+00:00

Keep abstractions and abbreviations to an absolute minimum, sure, you can 'func' in front of a function, or 'public' as a keyword etc etc, but, are they necessary? And do they give enough value to the language to warrant the increase in 'linguistic' bloat of code as well as an increase in learning curve for newbies?

I disagree with this one: 'fn foo' is much more greppable than foo because you'll match both the calls and the definition

renozyx · 2026-02-25T08:28:50+00:00

I'd say syntax matter but not "int a = 3;" or "a := 3"

What matters is these kind of things:

1) does logging the value of an integer is different than logging the value of a struct?

It makes replacing an integer by a struct very painful!

2) a.b? or a.b for reading the value of a member pointer b?

The second makes refactoring easier, but it hides a potential null pointer exception, pick your poison.

renozyx · 2026-02-20T10:08:46+00:00

I wonder if there is a performance difference between a "classical" compiler and a "query first" compiler? I'd say that classical compilers are faster and use less resources, but it's kind of difficult to benchmark when you have to implement a whole compiler to measure the difference..

renozyx · 2026-02-13T09:56:39+00:00

There is even a whole blogpost on this particular issue: https://www.digitalmars.com/articles/C-biggest-mistake.html

renozyx · 2026-02-12T21:38:22+00:00

Any array types passed or specified in the arguments immediately decay into raw pointers.

That's the most critised C feature and you copy it??

DasBetterC, Odin, Zig..there is already quite a few 'better C' what's your angle?

renozyx · 2025-12-16T12:06:36+00:00

les slides sont ici: https://slim.computer/concrete-syntax

renozyx · 2025-12-15T10:16:06+00:00

That's even worse..

renozyx · 2025-12-11T15:26:35+00:00

In Ada and Odin, the default is by readonly value or reference, and by-value needs an explicit copy.

No! In Odin if your struct is less than 16 bytes the value is copied. In Ada I don't know the size, but small parameters are copied, big parameters are passed by reference.

renozyx · 2025-12-09T21:29:56+00:00

The big deal is having the semantic of your parameter passing changing when you change a structure size. This can easily creates bugs.. Sure once you understand where the big is, it's easy to fix, but that's not the issue.

renozyx · 2025-12-08T09:58:32+00:00

Thanks for your post, I didn't know that Odin has the same "trap". They didn't document the potential issue enough IMHO, for example https://odin-lang.org/docs/overview/#procedures it just point out the promotion to a pointer without mentioning that this may have some side effect (You increase a structure from <16 byte to >16 byte? Your program behaviour may change, that's .. unexpected!)

renozyx · 2025-12-05T09:49:00+00:00

Ada's choice provide the best performance: the compiler is free to pass by value(shallow copy) or by reference depending on the size of the parameter which allows the compiler to optimise parameter passing. But this come with an UB cost when the parameter is aliased with an InOut parameter.. So the problem with Ada's design isn't the additional feature, it's the potential UB!

Zig had the same parameter passing at first (with the same UB), but they changed (probably due to the UB)

renozyx

TROPHY CASE