sixthDot

I suspect one aspect is a sort of "generational gap". In the 2010's a lot of new languages were created by younger people who wanted to put their own language on the tracks: NiM, Zig, Odin, to name a few.

Similarly, a second aspect is that other new languages raised, but not in the "cool- kid" category, this time rather in the "big-company-backed" one: Go, Rust.

In both case : more concurrency, less seats.

To season the salad you can add a few errors in the leadership, too much time to create a real organization, the missing "killer-app" too ?, etc.

I see that D is mentioned in the "other languages" paragraph. When the LLVM-based compiler is used we got the exact same codegen but just like for zig, it's possible to annotate the input buffer `@noalias` (essentially an LLVM attribute), which enables vectorization, see https://godbolt.org/z/oPe4T5K3G.

lexical passes duration: 0 min(s), 0 sec(s), 79 msec(s)

semantic passes duration: 0 min(s), 0 sec(s), 272 msec(s)

irgen pass duration: 0 min(s), 2 sec(s), 431 msec(s)

linking duration: 0 min(s), 0 sec(s), 70 msec(s)

for 25kslocs.

Very well known https://en.wikipedia.org/wiki/Ninety%E2%80%93ninety_rule.

> What are some common activities to go from 90% to 100%?

To the list I'll add

- 100% coverage

- rewrite it in Rust (ha ha)

The big question is: why do people still put a "Quit" MenuItem in their File menu ?

D standard library uses much templates. So only what's used or what is not templatized get linked in the binary. The runtime somewhat tries to follows this too, aka the "pay-as-you-go" strategy as it is called in the dlang world.

For small applications this works even if certain templates can easily lead to have half of the standard library pulled in (e.g a few conversion, a few format, a few regex and boom, the size explodes).

A subset of the language called betterC allows to fully get rid of the "base", but requires to write much more code to get things done. Maybe this is why prakis managed to get the smaller binary ? The comment is not very clear about the methodology...

There's a similar issue on gitlab : https://gitlab.com/gitlab-org/gitlab/-/issues/255108.

It still does not support .init_array / .fini_array sections. Too bad I'd like to use it.

> The closest I have found is the network, which is slow to render (unless it is already cached), does not offer nearly as much details

$ gitk --all

not mobile however

This little caclulator might help : https://gitlab.com/kirill.saidov/fromago

> Then for other languages its media blackout, hate, and an avalanche of trolling [...] > Just weirds me out, as to how reactions and perception goes.

The prog lang world is a massive circle jerk, with plenty of toxicity, extreme fanboy-ism and haters.

As a compiler developper (yeah _I'm something of a_ ...) I'm shoked to see

- https://github.com/val-lang/val/issues/758

- https://github.com/val-lang/val/issues/711

That smells bad implementation. You should self-host ASAP guys, you'll find more basic bugs like that. Yet 500+ stars !

Volt

I have an old project that used Cairo directly in a Xlib window an allowed to make full UIs, with complexe layouts, alignments, compund widgets, etc. and without the GTK or QT massive bloat.

I would be interested if you could develop the problems you've seen

> I wish people would stop publishing me-too languages that implement, for the umpteenth time, the same concepts we have had for 40 years or more. I mean, if you just to learn from the experience of creating a language, that's fine, but you probably won't get much from publishing it

It's not really a language designed to be used. I've decided to post the link today to see a bit what people think.

> - Generic object literals (Why should generic type inference be limited to functions?)

Good idea.

Formely yes but self-hosted since 18 months.

BS

Lemmy's down ATM

Self-hosting a compiler is an important step when you create a language. With git, one might think that there's no reason you cant do it again, even 18 months after.