-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
Graal
GraalVM compiles Java applications into native executables that start instantly, scale fast, and use fewer compute resources 🚀
-
-
Stackoverflow-Survey-2020
Discontinued Analyze a given Data and answer the questions using Python Pandas library. StackOverflow Developer Survey 2020 Analysis and answers
-
Stackoverflow-Survey-Analysis
Analyze a given Data and answer the questions using Python Pandas library. Stack Overflow Developer Survey Analysis and answers
-
slint
Slint is a declarative GUI toolkit to build native user interfaces for Rust, C++, or JavaScript apps.
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
Rust's lack of fast thread-local storage makes it a non-starter for me. It's really disappointing, especially when the language has incorporated so many other excellent performance improvements like Google's SwissTable and pattern-defeating quicksort.
https://github.com/rust-lang/rust/issues/29594
https://matklad.github.io/2020/10/03/fast-thread-locals-in-r...
Hmm, they didn't list SerenityOS[0] under the C++-based operating systems for some reason... maybe it's still too under the radar?
[0]: https://serenityos.org/
The article didn't list JNode, but it's also a pure Java OS.
I noticed in another thread that a few people seem to think you can't implement an entire operating system in a GCd language like Java or C#, but that isn't true. You can do it like this:
1. Use an ahead of time compiler to compile the base runtime/kernel image to static machine code. In managed language operating systems like JNode or Singularity there isn't a strong distinction between kernel and language runtime, so this is the same thing. This base needs to contain at least a GC and probably a JITC, as well as some basic support services. This can itself be written in the managed language.
2. Write a very short bootstrap loader in assembly like every OS has, which sets things up enough to jump into the entry point of that runtime.
3. Writing a compiler in a managed language is easy enough but what about a GC? To do this you teach the compiler that some methods are 'magic' and shouldn't be treated as normal method calls. Instead they become either compiler intrinsics that are translated to pure assembly e.g. to read/write raw memory locations, or they are compiled in special ways for example to remove GC safe points.
The current best example of this in action is the GC in SubstrateVM, which is the "VM" compiled into any program AOT compiled with the GraalVM native image tool:
https://github.com/oracle/graal/tree/master/substratevm/src/...
If you flick through it you'll see various annotations and types you wouldn't normally see in Java, like `Pointer` and `@Uninterruptible`. These are recognized by the compiler and affects how the machine code is generated. The language is the same, so all existing tools continue to work - it's not a dialect or subset of Java, it's the full thing, just with slightly modified rules for how the final generated code behaves.
SubstrateVM has one more trick up its sleeve to break the circularity: some objects can be initialized and persisted to an "image heap" at build time. In other words, the GC code can use Java classes to structure itself, despite being unable to allocate.
And that's all it needs.
There have been efforts to do things like this in the past for full operating systems. They have nice properties: for example you can sandbox drivers, and it's quite easy to keep ABIs stable. There are usually a few sticking points that prevent them taking off:
1. Historically, GCs have either been good at latency or throughput but not both simultaneously. Some of them also had trouble with large heaps. That's a problem because virtually all reasonable computing requires a mix of programs with wildly different sensitivity, most obviously, developers want latency to be prioritized for editing in their IDE but throughput to be prioritized for their build system. If you have one GCd heap for the entire computer then you have tow options:
1a. Pick one algorithm to manage it.
1b. Do what Singularity did and come up with a quasi-process notion in which each unit has its own GCd heap. Singularity had a nice concept called an 'exchange heap' which allowed objects to be passed between these quasi-processes very fast and cheaply, whilst ensuring that object graph could only be pointed to by one unit at once. This made IPC tremendously cheap, allowed one unit to be paused for GC whilst other units ran, and let them use IPC all over the place. However it did reduce the benefits of using managed languages somewhat as it reintroduced complex data ownership rules.
2. Raw efficiency/overheads of managed languages are higher. The successor at MS Research to Singularity was codenamed Midori and not much was ever published about it publicly, but from what was written (by Joe Beda) it seemed apparent that they went down a rabbithole of trying to make Midori have the same raw efficiency and overhead as C++ based Windows. They got a long way but ended up not having any interesting enough new features to justify the investment and the project was eventually canned.
3. All the same problems new operating systems always have: no apps, drivers etc.
I'm not sure it's "desperately" chasing; its trajectory looks positive. For example, in the 2019 Stack Overflow developer survey[1] only 3% of professional developers reported using Rust. A year later[2] it was 4.8% and a year after that[3] it was 6.4%. So based on that metric (of debatable value), professional developer use may have doubled in two years. For reference, in the SO surveys C++ and C use was about 20% and 16%, respectively and, if anything, slowly declining (as a percentage of respondents, of course).
1. https://insights.stackoverflow.com/survey/2019#technology-_-...
2. https://insights.stackoverflow.com/survey/2020#technology-pr...
3. https://insights.stackoverflow.com/survey/2021#technology-mo...
I'm not sure it's "desperately" chasing; its trajectory looks positive. For example, in the 2019 Stack Overflow developer survey[1] only 3% of professional developers reported using Rust. A year later[2] it was 4.8% and a year after that[3] it was 6.4%. So based on that metric (of debatable value), professional developer use may have doubled in two years. For reference, in the SO surveys C++ and C use was about 20% and 16%, respectively and, if anything, slowly declining (as a percentage of respondents, of course).
1. https://insights.stackoverflow.com/survey/2019#technology-_-...
2. https://insights.stackoverflow.com/survey/2020#technology-pr...
3. https://insights.stackoverflow.com/survey/2021#technology-mo...
Looks like C++ to me!
And my point is that when you mention OS-es like Mezzano (3k stars on Github, a dozen contributors [1]) and Redox (13k stars, 80 contributors [2]), but don't mention Serenity (18k stars, over 100 contributors [3] (Github limits this view to the top 100)) it seems funny.
[0] https://github.com/SerenityOS/serenity/tree/master/Kernel/Ar...
[1] https://github.com/froggey/Mezzano/graphs/contributors
[2] https://github.com/redox-os/redox/graphs/contributors
[3] https://github.com/SerenityOS/serenity/graphs/contributors
Looks like C++ to me!
And my point is that when you mention OS-es like Mezzano (3k stars on Github, a dozen contributors [1]) and Redox (13k stars, 80 contributors [2]), but don't mention Serenity (18k stars, over 100 contributors [3] (Github limits this view to the top 100)) it seems funny.
[0] https://github.com/SerenityOS/serenity/tree/master/Kernel/Ar...
[1] https://github.com/froggey/Mezzano/graphs/contributors
[2] https://github.com/redox-os/redox/graphs/contributors
[3] https://github.com/SerenityOS/serenity/graphs/contributors
Related posts
-
Fomos: Experimental OS, Built with Rust
-
SerenityOS author: "Rust is a neat language, but without inheritance and virtual dispatch, it's extremely cumbersome to build GUI applications"
-
Creator of SerenityOS announces new Jakt programming language effort
-
How far are we from writing Redox on Redox?
-
Porting QEMU to RedoxOS