It's always nice to see others programming in Jakt. I've written a couple of network device drivers (rtl8139, virtio-net) and a TCP/IP stack in Jakt that is used in my TempleOS fediverse server project[1].

I also contributed some patches to Sophia's jaktnesmonster NES emulator a few years back, adding support for some popular mappers, as well as a TempleOS port, and more recently wired everything up[2][3] to use Serenity's native libraries (LibGUI, LibAudio, etc.)

1: https://github.com/slon-project/slon

2: https://files.catbox.moe/jq656f.webm

3: https://github.com/alec3660/jaktnesmonster

Yeah they've chosen Swift as their C++ successor language for Ladybird (the browser project forked from SerenityOS's browser)

Some work to do with making Swift work with ladybird's garbage collection but my understanding that this work is in progress.

Andreas talks about it here: https://www.youtube.com/watch?v=z1Eq0xlVs3g&t=759s

Hell of a decision.

I was never active in SerenityOS and only watched things from afar, but JT had a transition and I got the sense that the other contributor just got busy with life. That said, SerenityOS was a 'for us by us' mostly fun project that became too big and collapsed under its own weight without Andreas. Andreas is a great programmer and seems like genuinely nice person, but over time he was becoming more of a programmer influencer and since seems to have transitioned to PM/EM with full-time Ladybird. I miss his videos, they taught me I never want to write C++ and that splitting a giant work in tiny changes works and that programming videos are tiktok for programmers.

Which is to say, falling out with Andreas IMO is less than likely, dude just seems nice from the onset, but with changing tides in project it is highly likely that people just became uninterested over time.

The class/struct differentiation predates Swift by a few decades, it has come up in many other languages.

Contrary to Go folks, Swift designers have done their work why some approaches are better than others based on historical use of language features.

My feeling is that if Swift didn't have the requirement of very tight interop with Objective-C there would have only been one kind of object. Maybe just structs with the option of heap allocation/reference counting or something like that.

But that's not the world Swift was born into and so it has both classes that are optionally Obj-C compatible and structs

Not allowing take reference can avoid interior pointer. Interior pointers make memory safety harder and also make GC harder.

As mentioned in another reply, being able to take the address of any value implies supporting interior pointers (pointers into the middle of a value)

This is hard to implement in a memory-safe language. For example, the new WASM GC virtual machine does not support interior pointers.

I noticed this distinction recently, regarding the rewrite of TypeScript in Go:

https://lobste.rs/s/3q0ei5/10x_faster_typescript#c_xndrsg

- C#, Swift, Julia, Nim, Crystal, and very recently OCaml have separate value types and reference types. The choice is not orthogonal, which is what you don't like. (Java, Python, etc. do not have value types at all)

- Only Go and D have the memory model of C (values and references), with GC.

- Rust has also has the model of C, but with "static memory management"

Ladybird is no longer part of the SerenityOS project, and Jakt seems pretty dormant; my understanding is that Ladybird is moving to Swift as an eventual C++ replacement.

I think Andreas and JT wanted something that would tightly integrate/interop with the large existing C++ SerenityOS codebase. I think they also welcomed the opportunity to build a new language, consistent with the SerenityOS ethos of building every part of their OS themselves.

Bugjakt

C++ is merely behaving as a intermediate language/representation in this case. They are compiling to subset of it. Idiomatic C++ is not safe.

And after that it's compiled to assembly, so I suppose safe assembly was possible after all.

Sooner or later there will inevitably appear a new language, or an evolution of the current Rust, which will be significantly better than Rust and not just a minor tweak to the language we know today . Let’s say it is named Rust++ (any resemblance to existing languages is a pure coincidence). And the whole hype and rewrite starts over again… it is just a matter of time.

It started looking like "Rust but without lifetimes."

Then I noticed structured exception handling. Oh well.

also, all programming languages if/when given enough time adopt all features from all other languages

this is applicable to web-era languages circa the times of PHP thru Java.

I don’t know. There’s trade offs everywhere. Rust std file interface is ugly and meh. Intermediate buffers everywhere.

Async await and unwrap is ugly.

Lambdas and binding of locals is very ugly as well. Any fake lifetime errors I get are solved by a data type and impl which is just confusing, as if lambdas are a problem.