any examples of OS not written in C/C++?

[DiTBho]

OCaml

Do you think it is also worth to learn this language in 2021?
I am so tempted, although at the moment my priority is Rust.

I enjoyed the above post with a link to an real OS written in Rust!
I am the kind of person who better learns by examples 

[SiliconWizard]

OCaml

Do you think it is also worth to learn this language in 2021?

Learning something new is almost always worth it.
Now whether you will personally ever use OCaml for anything useful is another question.

[ve7xen]

Do you know anything at all about Rust or are you just blathering on ignorantly and arrogantly like a senile old man?

Are you blathering on ignorantly and arrogantly like a young idiot without the experience of seeing endless repeating cycles of the Next Big Thing that fades away? There's always that one wonderful little thing they do, that means the world is going to see the brilliance of the Next Big Thing and flock to it. Every once in a long while people actually do. Not often, though. Maybe Rust will hit the big time, but the odds are heavily against it unless one or more massive long term systems that are needed all over the place are written in it.

I did not argue it would be successful, just that 90% of the blathering I quoted does not apply to Rust and belies a complete lack of understanding of the actual situation. I also think the attitude that good programmers don't make mistakes and therefore don't need tools that make doing things correctly easier is elitist and stupid. Like anyone enjoys malloc/free, or is infallible at it .

Will it succeed? Yet to be seen. Does it have even one of the shortcomings that DC1MC rants about? No. Would the success of a modern language capable of systems programming be a good thing? Undeniably yes.

[ejeffrey]

One can't write an OS in garbage _collected languages

That isn't even remotely true.  Just like with all languages, when writing an OS you may need to implement some parts of the runtime yourself.  When writing an OS in C, you either have to avoid malloc entirely, implement it yourself, or use a library implementation that provides low level hooks to manipulate memory pools.  The same is true with garbage collection -- garbage collectors need some underlying functions to manage the size of their memory pools, but if you provide those you could absolutely use GC in an OS.

[DC1MC]

I would say, let's tune it down with name calling and person attacks, call names the tools (even the concepts), not the people. Insulting the discussion partners does not anyones point stronger and does not make one seem smarter, au contraire.
This being said, I will leave this topic forever and let you in the capable hands of the soon to be cRUSTaceeans overlords.

DC1MC

[coppice]

OCaml

Do you think it is also worth to learn this language in 2021?
I am so tempted, although at the moment my priority is Rust.

I enjoyed the above post with a link to an real OS written in Rust!
I am the kind of person who better learns by examples 

I think its a language you might want to learn, not so much to be able to use it but to see a rather different take on computer languages. There are a few languages its worth learning just to broaden your understanding of what a computer language can be like. Everyone should learn Snobol

[Cerebus]

I would say, let's tune it down with name calling and person attacks, call names the tools (even the concepts), not the people. Insulting the discussion partners does not anyones point stronger and does not make one seem smarter, au contraire.
This being said, I will leave this topic forever and let you in the capable hands of the soon to be cRUSTaceeans overlords.

DC1MC

You started off by insulting a whole class of people, so I don't think it very appropriate of you to lay claim to the moral high ground.

There were not many OSes written in C + assembly, only the ones who actually matter and passed the test of time, the rest went as academic masturbation, hyper-specialized NIH stuff and forgotten attempts of enthusiasts, forever remaining at version 0.0.1alpha0 in a forgotten '90s stile web page or repository.

 Rust will go like all the rest of over-engineered cretinic experiments, only to be eventually used in some kind of hypervisor or virtualization, where the heavy lifting will be done by C or assembly stuff, but it will be not visible to the mediocre programmer who will happily announce that "duuude, I've written a user mode driver in Python... Yeah dude, I written a scheduler in Rust, this OS stuff is so simple...".

 Some times low level and difficulty is just that, not reducible to application level stuff and trying to sugarcoat it with automated  garbage collectors and object paradigms, glorified interpreters of pseudocode and other crutches for mediocre programmers will always fail.

[Cerebus]

... There are a few languages its worth learning just to broaden your understanding of what a computer language can be like. Everyone should learn Snobol

But Lisp may be taking things too far. 

[coppice]

... There are a few languages its worth learning just to broaden your understanding of what a computer language can be like. Everyone should learn Snobol

But Lisp may be taking things too far. 

Well, I'd list LISP as one of the interesting things to learn, but I'd put it in brackets.

[SiliconWizard]

... There are a few languages its worth learning just to broaden your understanding of what a computer language can be like. Everyone should learn Snobol

But Lisp may be taking things too far. 

Well, I'd list LISP as one of the interesting things to learn, but I'd put it in brackets.

(why (would (you (say that))))

[magic]

It also seems to be getting traction in Linux - Rust code in Linux kernel looks more likely as language team lead promises support.

The Reg got it backwards - for this to happen, Rust would have to gain acceptance of Linux developers, not Linux gain acceptance of Rust developers

OCaml

Do you think it is also worth to learn this language in 2021?

Not necessarily, it will also be okay if you learn Standard ML instead.

[SiliconWizard]

It also seems to be getting traction in Linux - Rust code in Linux kernel looks more likely as language team lead promises support.

The Reg got it backwards - for this to happen, Rust would have to gain acceptance of Linux developers, not Linux gain acceptance of Rust developers

Well, Linux talking about Rust seems to have be blown out of proportion. At no point I understand that Linus is going to consider replacing C with Rust for the Linux kernel, neither tomorrow nor maybe even in 10 years. All we can conclude, for what he said, I guess, is that at least he doesn't reject it violently as he has always done with C++.

[magic]

IMO moving everything to a different language is simply not gonna happen within the lifetimes of the project, but even accepting individual modules I think would be unlikely. But hey, you can always compile something yourself and modprobe it Some guys at some Polish university even put Haskell in there, whatever floats your boat.

[DiTBho]

The Reg got it backwards - for this to happen, Rust would have to gain acceptance of Linux developers, not Linux gain acceptance of Rust developers

LOL 

well .. true, but Linus is somehow using C as object programming language done with a language that does not have any native support for this; C++ does have, but Linus doesn't like it, Rust does have, and Linus is looking at it, but the Rust language is fastly evolving, and because of this certain compatibility issues can arise, despite efforts to ensure forwards-compatibility wherever possible.

Anyway, for me, fastly evolving means that even Rust is looking at Linux, in order to provide what is really needed.

[techman-001]

Have anyone seen and can report here a link to an OS not written in C/C++/ObjC?

You can find Forth OS written in almost every language there is including Rust, LISP, Assembly, BASH, Perl, Lua, Python, C, C++, etc. The Forth I use (below in my sig) is written in assembler.

Just a few examples:

Staapl is a macro assembler on steroids for PIC18F microcontrollers. It can be used for writing firmware optimized for size. It goes where C can’t go, and where assembler would be too complicated. It is based on Racket Scheme (code generator) and Forth (low-level language and machine model).
http://zwizwa.be/staapl

rust-forth-compiler 0.5.3
https://docs.rs/crate/rust-forth-compiler/0.5.3

Firth, A simple Forth-like language intended for DSL creation, implemented in Lua.
https://github.com/IonoclastBrigham/firth

pyforth, A minimal implementation of the FORTH language, written in Python.
https://github.com/whaleygeek/pyforth

[Nusa]

https://github.com/microsoft/MS-DOS

[radiogeek381]

Re: VMS and BLISS

My recollection was that VAX/VMS and PDP-11/RSX-11 were both written primarily in assembler.  The VAX filesystem (FILES-11), however, had BLISS components at least. 

I took the VAX/VMS internals courses in the 80's and wrote kernel modules for a few projects. (Digital alum  1983 - the acquisition of my division by Intel).  Prior to Digital I wrote an I/O driver for RSX.  I don't ever recall seeing any BLISS modules as part of the VAX VMS kernel prior to V5.0 -- perhaps BLISS was introduced after that. 

BLISS-11 was used to build the StarOS operating system for CMU's Cm*.

[SiliconWizard]

but the Rust language is fastly evolving, and because of this certain compatibility issues can arise, despite efforts to ensure forwards-compatibility wherever possible.

This is a *major* issue indeed.

[Nominal Animal]

At no point I understand that Linus is going to consider replacing C with Rust for the Linux kernel, neither tomorrow nor maybe even in 10 years. All we can conclude, for what he said, I guess, is that at least he doesn't reject it violently as he has always done with C++.

As I understand it, the rejection is logical: Unlike C's freestanding environment (which Linux relies on), C++'s still requires a runtime for <new> and <exception>, and that makes it a no-go, because the Linux kernel would have to be fundamentally redesigned to run on such a runtime.  Also, C++'s freestanding environment leaves too many things implementation defined, which means kernel developers would have to beg the compiler developers to provide sane implementation-defined behaviour, and except for the last few years, dealing with GCC developers has been quite a headache for the kernel developers.

It is important to note that most of the embedded C++ environments used with e.g. microcontrollers aren't really C++, but a subset of the freestanding C++ environment; in particular, exceptions are not supported.  So, while an enthusiastic C++ programmer will just say "then only use the subset you want!", the problem is that when you have a project that potentially will live for decades, you want something to rely on, instead of relying on implementation-defined behaviour and the assumed benevolence of the compiler developers.

In comparison, freestanding C environment is simple and well defined.

I believe this also shows why developing an OS kernel requires either a strictly defined compiler, or close cooperation with compiler developers.  I would be particularly interested in the interaction between Rust and Redox developers, especially since both are actively evolving.  In this PC era, I suppose any truly friction-causing issues are only discussed in private, without movement-starting paper trails...  I liked the honesty of LKML, where idiotic suggestions like kdbus got called out in public.

[coppice]

Re: VMS and BLISS

My recollection was that VAX/VMS and PDP-11/RSX-11 were both written primarily in assembler.  The VAX filesystem (FILES-11), however, had BLISS components at least. 

I took the VAX/VMS internals courses in the 80's and wrote kernel modules for a few projects. (Digital alum  1983 - the acquisition of my division by Intel).  Prior to Digital I wrote an I/O driver for RSX.  I don't ever recall seeing any BLISS modules as part of the VAX VMS kernel prior to V5.0 -- perhaps BLISS was introduced after that. 

BLISS-11 was used to build the StarOS operating system for CMU's Cm*.

As I understanding it there may not be much BLISS in the VMS kernel itself, but a large part of the code surrounding the kernel, that makes it a complete operating system, was originally in BLISS.

[coppice]

but the Rust language is fastly evolving, and because of this certain compatibility issues can arise, despite efforts to ensure forwards-compatibility wherever possible.

This is a *major* issue indeed.

This was one of the major things holding C++ back in the 90s. There was a period when almost every compiler update you received broke something in your code. If not for that, C++ compilers might well have displaced C compilers, with some of us writing like we were still using C, and some of us writing with the full features of C++.

[SiliconWizard]

but the Rust language is fastly evolving, and because of this certain compatibility issues can arise, despite efforts to ensure forwards-compatibility wherever possible.

This is a *major* issue indeed.

This was one of the major things holding C++ back in the 90s. There was a period when almost every compiler update you received broke something in your code. If not for that, C++ compilers might well have displaced C compilers, with some of us writing like we were still using C, and some of us writing with the full features of C++.

Apart from specific merits, or lack thereof, of a given language, this is the most problematic point indeed.

Regarding using "subsets" of a language, which is a relatively common approach with C++, I do think this is also a problem rather than a solution, especially when such subset is NOT clearly defined, which, as I have witnessed over the years, is the usual.

SPARK, OTOH, is an example of a well-defined subset (of ADA), and as such, it's usable. But with C++, I have rarely seen, if ever, a well-defined subset, in a clear report, that developers would stick to, so even the subset is often a moving target.

[westfw]

Quote

TOPS-10 - BLISS -

https://en.wikipedia.org/wiki/TOPS-10I'm pretty sure that TOPS-10 was written mostly in Macro-10, the PDP-10s assembly language.It's origins pre-date Bliss, and TOPS-20 (which is NEWER than TOPS10) was pretty much all Macro-10.
That's not to say that there was no Bliss involved anywhere.  But ... not a lot.
(Heh.  In the tops10 days, the lines between the "monitor" (OS) and utilities were pretty blurry.  The user command processor was part of the monitor, for instance, but I'm not exactly where the lines in "programming language" were.  In more recent times, there's a sharper line between "kernel" and "support code", but the overall term "OS" encompasses both (and generally "more" of the user-code)...)

The various "LISP machines" of the mid-1980s certainly had much of their "OS" written in LISP.

[tooki]

I think a large chunk of the first Mac OS versions was written in Pascal. Ditto for Lisa OS which Mac OS was partly based on.

Correct. The Lisa software and classic Mac OS (originally known simply as the Mac System Software) were originally written in Pascal. However, the Mac’s smaller ROM and RAM forced them to rewrite much of it in 68K assembler simply to make it fit. (In early Macs, there was about as much OS in ROM as on disk.)

From https://www.folklore.org/StoryView.py?project=Macintosh&story=Hungarian.txt

The Macintosh used the same Motorola 68000 microprocessor as its predecessor, the Lisa, and we wanted to leverage as much code written for Lisa as we could. But most of the Lisa code was written in the Pascal programming language. Since the Macintosh had much tighter memory constraints, we needed to write most of our system-oriented code in the most efficient way possible, using the native language of the processor, 68000 assembly language. Even so, we could still use Lisa code by hand translating the Pascal into assembly language.


We directly incorporated Quickdraw, Bill Atkinson's amazing bit-mapped graphics package, since it was already written mostly in assembly language. We also used the Lisa window and menu managers, which we recoded in assembly language from Bill's original Pascal, reducing the code size by a factor of two or so. Bill's lovely Pascal code was a model of clarity, so that was relatively easy to accomplish.

The Mac lacked the memory mapping hardware prevalent in larger systems, so we needed a way to relocate memory in software to minimize fragmentation as blocks got allocated and freed. The Lisa word processor team had developed a memory manager with relocatable blocks, accessing memory blocks indirectly through "handles", so the blocks could be moved as necessary to reduce fragmentation. We decided to use it for the Macintosh, again by recoding it from Pascal to assembly language.

Folklore.org is a website run by Andy Hertzfeld, one of the original Mac software devs, and has lots of references to said Pascal, e.g.:
https://www.folklore.org/StoryView.py?project=Macintosh&story=3rd_Party_Developers_and_Macintosh_Development.txt

[DiTBho]

In the meanwhile I wrote my driver in assembly for an ultrasonic ranger sensor used a personal soft-core for which, being its ISA a pure invention of mine, there is neither a C compiler nor a Pascal compiler, and I also had to write my own assembly compiler.

I just wrote a simple driver that samples the voltage from an SPI 12 bit ADC, controls the output trigger of the ultrasonic pulse transmitter and measure the pulse-width(1) of the echo impulses that return to the receiver, yet I am already so lost and so exhausted that I can't really understand how people have Managed these things before HL compilers 



(1) there is a free runner 32bit timer and bit compare circuit for this, it needs to be armed and controlled.