Spoiler: Andreas is making a new language. It’s called Jakt.
7 Likes
Interesting. While SerenityOS has a very “home-grown everything” attitude, I think this is also another point in favor of the “there is no good contemporary general-purpose programming language” hypothesis.
I have had a suspicion for a while now that it is actually possible to build a programming language that is capable of everything from the lowest levels of kernel development with physical memory management all the way up to UI, even HTML UI development – as opposed to most of the current “crop” of new programming languages, which tend to be extremely specialized towards one or two usecases.
(In fact, I wonder how much Jakt will be useful for, anyway? Automatic reference counting on all classes, for instance, severely restricts how much you can do in the lowest-level parts of the kernel. A hybrid borrow checking / reference counting approach is more or less mandatory if you want to have memory safety in low-level kernel code.)
But of course these ideas would require an awful lot of time that I don’t have right now to experiment with. I know @Zenja has mentioned some thoughts very vaguely along these lines before, too.
2 Likes
Sounds like Rust. From Redox OS to Rust-compiled WebAssembly in the browser.
2 Likes
Rust is capable of this, but it is not especially ergonomic for UI development for the simple reason that it does not have classes and virtual inheritance (or a general equivalent thereof, like JS had in various ways, even before it introduced classes) which are kind of critical for ergonomic user interfaces programming.
Rust also tries to allow for maximum flexibility in terms of code structure around memory safety, which counterintuitively actually makes most code more complex in terms of “borrow checker appeasement” or the like. I think a different approach in which there is (slightly) less flexibility regarding how you can structure your code (e.g. the “actor model”) would simplify memory safety checking and also be easier to write.
1 Like
Nice, one more simple language that could be used to interface with Haiku C++ libs for GUI programing.
It looks less advanced than Nim for this use case, but more promising at the same time (in particular I find the inline C++ capability very interesting).
1 Like
The Red language is based off Rebol and intends to be a “full stack” language. It achieves this using Rebol’s concept of “domain specific languages” or “dialects”. According to Wikipedia, Red includes a dialect called Red/System which is equivalent to C.
I personally think Red would be an ideal foundation on which to build an operating system.
Isn’t Rebol a reason of death of Syllable OS?
1 Like
I mean Syllable team spent too much time and resources to Rebol so system itself progress stopped. Trying to invent new language and rewrite everything is dangerous idea because it need too much resources and will be likely abandoned.
6 Likes
- Use the Meta programming language for Syllable development, to further improve the quality and approachability of the system.
I would only be impressed with a BASIC like programming language with all the modern capabilities of languages like Swift or Rust (or name your favorite language here).
I am puzzled about where this Meta programming language sits with resect tof Red. I don’t even think the former is a fork of the latter, surely the obvious way of achieving differing goals when a similar project already exists.
Sounds like an ill portent for Serenity going with Jakt then 
Seriously, I hope not and also that Syllable gets a second wind with this Meta language. It would give a chance to see the relative merits of Meta and Jakt in their respective systems. There seems to be a trend for “hobbyist” OS written from scratch with modern languages (Redox using Rust also comes to mind).
My understanding is that it allows to have an “unsafe” mode, like Rust, for parts that need it.
The things that remain to be seen are:
- performance impact of the reference counting (but it shouldn’t be worse than shared_ptr)
- how much unsafe code will be needed in a typical app
- how they will handle threads (for now they… just don’t handle them yet)
3 Likes
It was the stated goal of Swift to become just such a general purpose language. They certainly haven’t achieved that but they didn’t set out to be particular specialized so I think it’s interesting to examine where they fell short.
The use case that they had to solve for was writing GUI applications. I think they did a great job in that regard. But it does not work well for quick and dirty scripting. They are working on some improvements there but I don’t think it will ever get good enough to be a replacement for Python/bash/etc scripts. It also does not scale downward to do systems programming. ARC has proved to be too expensive for reference types, and all the copying it has to do for value types is also too expensive. They are working on adding in an ownership system that is somewhat similar to the Rust borrow checker that will allow the developer to opt in when they want to avoid the ARC/copying overhead. It is possible that trying to bolt on such a massive change at this point will prove to be problematic. Considering what a good job they did at adding in async/await/concurrency last year I am somewhat hopeful though. They also made plans early on to do the ownership stuff so there’s a chance that they have designed things to ensure it will be possible to make it work. I guess well see.
They are also working on C++ integration which has made me wonder if it will be possible to build Haiku applications with it someday. My main motivation there is I’d like for it to be possible to use the native Haiku APIs but in a memory safe language. It would also be great to use the swift concurrency stuff to free application developers from having to think about threads.
If I understand correctly Jakt is going to use a Swift like ARC model for handling memory. The idea is that it will be used for building applications, not kernel development. And since Jakt transpiles to C++ it integrates well with C++ allowing you to fall back to it any time you need more performance. I think the combination there might actually work really well.
I am waiting for Swift to completely sort out C++ integration so that at last I can use it to try writing Haiku applications. First I need to sort myself out a dedicated Haiku laptop.
We’ll also have to bump the version though…
3 Likes
That is the exact place I am at. With both swift and the laptop.
Nowdays seems that almost everything is made in Python.
GH stats:
Oh, Python. OT, but this popped up in another forum and this is probably the perfect place forit:
3 Likes