The Jakt Programming Language | Hacker News Reader

The Jakt Programming Language

github.com

108 pointsgw248 comments

I've done some hobby programming[1] in Jakt and while it had promise and took good ideas from other modern languages my understanding is that it's been abandoned at this point and isn't mature enough to build anything non-trivial.

Transpiling to C++ for maximum interop with the SerenityOS codebase was an interesting idea too, but what it meant was you had to interpret C++ compiler errors to to understand what was breaking a lot of the time

1: Here's my admittedly crappy markdown->HTML converter written in Jakt https://github.com/mikeakers/r3gen

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

Nice! Ok maybe Jakt can be used for more non-trivial stuff than I gave it credit for :)

Worth mentioning that the Jakt compiler is self hosting as well

I was pretty excited about this, but didn't the Serenity browser recently announce they're going with Swift? That kind of takes the wind out of this language's sails.

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.

They came to it through a pretty pragmatic process. They made a list of candidate languages (they haven't discussed what the list was beyond "all the obvious candidates were represented") and assigned existing parts of the codebase to a few engineers asking them to reimplement the feature in the candidate languages. The team found they enjoyed working with Swift the most, and Swift's good support for OOP fit the object model of a web browser very well.

This doesn't imply the decision is any less jaw-dropping.

Besides, polling enjoyment is not exactly what I would describe as a pragmatic approach.

I think they had two overarching criteria:

1 - memory safe (ish)

2 - OOP

Rust was off the table because of number 2. The list gets short after that.

Rust has all the OOP features minus class inheritance, but folks like to repeat otherwise.

All the COM programming patterns can be easily done in Rust.

Here, ray tracing in one weekend, quite closely translated from the original C++ OOP design into Rust.

https://github.com/pjmlp/RaytracingWeekend-Rust

It has to work with the existing C++ code and class hierarchy. And OOP-like API is not good enough. It was not my assessment though. It was theirs.

Sure but that is already another criteria set, similar to how Carbon is also being developed, and not a plain "doesn't do OOP", because Java OOP is not the only flavour in town, which many folks conflate OOP with.

Not only does it predate the language by a few decades, there is enough type systems variants to chose from.

I mean that excludes swift too, it can't use the C++ ABI any more than other languages can. Excepting super-specialty languages

I haven't worked with it myself but my understanding is that Swift's C++ interop has improved a lot recently and is continuing to be improved. Apple has a huge C++ codebase so they are incentivized to make Swift work well with it

https://www.swift.org/documentation/cxx-interop/

The C++ interop story for Swift isn't the most clear cut, though. You're forced to use Apple's fork of llvm (meaning no GNU or mainline clang support) and there are issues tracking the current blockers[0]. Along with other related issues under the "swift" tag[1]. I don't think this was necessarily a bad technical decision, but from a lock-in and practicality perspective it seems flawed.

[0]: https://github.com/LadybirdBrowser/ladybird/issues/933

[1]: https://github.com/LadybirdBrowser/ladybird/issues?q=is%3Ais...

polling enjoyment is superbly pragmatic! this is a volunteer project that depends critically on the developers continuing to enjoy working on it. once you get past the first cut of "is this a reasonably mature language with a lot of community support behind it that compiles to fast native executables", enjoyment is one of the best ways you can choose between the various candidates. you can pretty much assume that rust/c++/swift/go/kotlin/etc all have the cross-platform support and libraries you will need.

Sure, if you're trying to have a good time it works great! No hate here.

It seems like Andreas abandoned SerenityOS and Jakt with it, and moved on to Ladybird. The language died with this move. The project was always very clearly “for fun” so I don’t see any harm or foul here. I also got the sense that there was a falling out between Andreas and some members of the community, like JT and one of the major JavaScript engine contributors whose name I can’t recall right now. Or maybe it was just that the passion for this particular project dried up.

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.

> TikTok for programmers

And do you see that as a good or bad thing (genuine question, just curious)?

I thought Sophia officially closed down working on both Nushell and Jakt, but it appears I mis-remembered: it was Nushell and another language named June.

https://www.sophiajt.com/following-new-paths-ahead/

I'm shocked by that they took the class/struct differentiation from swift. I HATED it when I had to deal with it in the past when working with swift. What's wrong with letting the programmer take the reference whenever they want to? Why do I have to change the whole class when I find something that makes me think it's better to have it passed by value? Why do I have to deal with the complexity of 2 kinds of custom types, with all the existing delicacies of a modern type system? Why on the earth would someone think this is a good idea that is worth taking? Can someone educate me on this?

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

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

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"

> Jakt is a memory-safe systems programming language.

Sounds pleasant and safe to use. I wonder if they plan to use it on their Ladybird browser.

From their readme:

Automatic reference counting

Strong typing

Bounds checking

No raw pointers in safe mode

Null pointers are not possible in safe mode, but pointers can be wrapped in Optional, i.e Optional<T> or T? for short.

Integer overflow (both signed and unsigned) is a runtime error.

Numeric values are not automatically coerced to int. All casts must be explicit.

and more.

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 watched some videos of Andreas working on Jakt some years ago but right now it seems kind of dead looking at the commit history.

It’s pronounced “y-ah-kt”. I’d probably use it if it was pronounced “jacked”.

Seems pretty popular already, but I have missed this. What's the USP of Jakt over something like native c++, rust or zig? I don't really see the need, would love to hear from someone who knows

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.

She's Sophia now, FYI

Ah ok, sorry was unaware.

Jakt is the Swedish (and Norwegian) word for hunt.

Deerhunt = Hjortjakt

Boar hunt = vildsvinsjakt

And the most common and revered...

Moose hunt = älgjakt

Bugjakt

> The official project language is American English with ISO 8601 dates and metric units.

Very good taste for an American.

> Jakt is a memory-safe systems programming language

> It currently transpiles to C++

So C++ being safe was possible after all

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.

Every new programming language is just Rust but worse and it hurts me

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.

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 is called human language, if current AI expectations turn out true, eventually there won't be a need to use current languages as intermediary step.

Human language is a poor medium for concise and clear communication.

Might be, yet that is the future our AI overlords want to bring us into, and already present in ongoing agents attempts.

It started looking like "Rust but without lifetimes."

Then I noticed structured exception handling. Oh well.

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.

Reply on news.ycombinator.com