For Rust, probably Redox (https://www.redox-os.org/). Then there's http://os.phil-opp.com/ and https://intermezzos.github.io/book/
For Go, I don't know any (but might be wrong, googling did not turn up anything).
For Go, I don't know any (but might be wrong, googling did not turn up anything).
My point is that commercial failures of specific OSes have more to do with politics and economic games than capabilities of programming languages.
As the OP was kind of insinuating just because many are too young to remember the OSes written in those languages, they should be ignored.
Yet, so far none of the OSes being written in Rust or possibly Go, have achieved the same amount of users those old forgotten systems had.
We can only improve our future by learning the lessons from the past.
Different concerns have different emphases in each fad, but the systems built have structural isomorphisms with what came before - they could hardly avoid it, being built to solve the same problems - and the older experience is lost, because people focus on the surface, rather than the larger shape. Older experience is dismissed because it was in an outdated language, despite it containing lessons that will continue to be applicable.
Everyone is myopic. It's like politics; the appearance of things is what matters. It's like fashion; it's the intersection of the ideas associated with the surface structure of your output that define its perception. No wonder older developers tend to leave this industry.
The trade-offs come around and around, the lessons are not as inapplicable as you think. We used to struggle to run programs on small machines; those struggles came back again with mobile, and come back again in a slightly different guise in clusters (where the program is too big to fit on any one machine).
They recur on different scales, too. Just the other day I was looking at dependency injection. Dependency injection solves the problem of coordinating dynamic program composition; the reason the program needs to be composed is because it was decomposed for testing. But this is just another iteration of the same pattern come around again. It's been done before in a large variety of ways; sometimes through ambient configuration (global variables), sometimes with patched jump tables (dynamic linking), sometimes statically (module instantiation). The emphasis is different - testing - but the solution is not structurally novel in the least.
Hah! Reasons for not learning from history:
* history is hidden behind NDAs, bad licences and patents
* history is hard to access due to its environment (printed on out-of-print books, stored on tapes, HDD and other forms of storage in someone's basement)
* history is written in a programming language nobody knows anymore
* history is written in an incompatible programming language, one for which there are no stable bindings to your favorite language (or for which there aren't any bindings, period)... just think how many times the String class or data type has been written and rewritten just in something like C, let alone the copies in Java, PHP, Ruby, Javascript, Go, Rust, etc., etc.
There's a ton of (somewhat) valid reasons history is forgotten and most of them aren't "history was bad, let's just forget it".
For example, I have collected the majority of Xerox and DEC research papers that I could get hold of.
Do you make that statement with the experience to back it up? Or do you make it because "if it were useful someone would have done it"? What if everyone is thinking the same thing as you are?
Beyond what other people have said, we are also a relatively young industry. There aren't that many people with 30, 40 years experience in the field. When I got my CS degree, 13 years ago now, there was no such thing as a "software engineering" degree, and CS was mostly focused on CS rather than the sort of thing you're talking about.
I also wonder how much collective knowledge we throw away with pushing developers into management. Or the outsourcing in the late 90's and early 00's. Or ageism. We are purposefully driving people with knowledge out of the industry.
That is country specific.
I took my degree around 20 ago and is it called "Degree in Software Engineering", certified by our Engineering Society.
http://www.fct.unl.pt/ensino/curso/mestrado-integrado-em-eng...
Created in 1977.
No, I wasn't. It was an honest question.
The only OSes I've used or had any experience with are Dos/Windows, MacOS, iOS, various Unix/Linuxes and the reaally old Commodores/Macs that just ran Basic. I was hoping maybe something I'd heard of wasn't based on C/C++.
Mesa/Cedar was created at Xerox PARC, as an extension of the Xerox Star 8010 system, which was programmed in Mesa, the language that inspired Niklaus Wirth to create Modula-2.
http://www.digibarn.com/collections/systems/xerox-8010/
https://www.youtube.com/watch?v=Cn4vC80Pv6Q
https://www.youtube.com/watch?v=ODZBL80JPqw Mesa evolved to Mesa/Cedar, which allowed for automatic memory management via reference counting and a tracing collector for the cycles.
https://archive.org/details/bitsavers_xeroxparcteCedarProgra...
The environment had a REPL and debugger inspired by the Smalltalk and Lisp systems at Xerox.
Think of Swift Playgrounds, kind of.
This system inspired Niklaus Wirth to create Oberon, which you can read about in his book, about how the OS was built.
http://www.ethoberon.ethz.ch/books.html
In 2013, Niklaus Wirth revised the language and updated the book for a FPGA based computer.
http://people.inf.ethz.ch/wirth/ProjectOberon/index.html
There were several generations of the Oberon OS, the last one before it stop being relevant, the Bluebottle OS coded in Active Oberon variant.
http://www.progtools.org/article.php?name=oberon§ion=com...
It had a strange mix of UI, using a mix of text and mouse input. Basically all applications were dynamic modules and the procedures/functions with a special signature could be used from the UI.
So you could select text or objects from applications, and invoke such operations on the selection.
The Oberon System 3 and Oberon V4 with their Gadgets framework were the best experience, before AOS was designed.
Most relevant OS in Modula-3 was SPIN OS,
http://www-spin.cs.washington.edu/external/overview.html
There were a few others, this is just a small sample.