7 ms·

What's the most successful operating system created in one of those languages?

by xiaoma 10y ago

pjmlp 10y ago
Probably Oberon, which was used during several years at ETHZ across the IT department of the university, including the secretary personal. Was also the source for many of Plan 9 UI ideas. What is most successful operating system created in Go or Rust?
- nachtigall 10y ago
  For Rust, probably Redox (https://www.redox-os.org/ https://www.redox-os.org/). Then there's http://os.phil-opp.com/ http://os.phil-opp.com/ and https://intermezzos.github.io/book/ https://intermezzos.github.io/book/ For Go, I don't know any (but might be wrong, googling did not turn up anything).
  - pjmlp 10y ago
    I know them. 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.
    - barrkel 10y ago
      Software development has eternal amnesia. Deep understanding of the pros and cons of different ways of structuring things are being continuously re-learnt with each passing fad, and each rewrite of a legacy system by a bright new crop of young things who learned most of what they know with a decade or so of direct experience. 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.
      - pjmlp 10y ago
        100% on spot, the fashion driven software as Alan Kay puts it.
      - zzzcpan 10y ago
        But if you could learn some things from the history and use that to your advantage, why wouldn't you? Everyone would be doing so. And yet somehow it doesn't work like that, outdated things are in fact outdated and you can only take away very little from them. Things that were designed with trade offs for very expensive slow synchronous machines during the times when programmers were not bound to languages, because everyone had to develop everything from scratch, don't really make much sense today. Direct experience of the last decade is a lot more relevant with a lot more lessons to learn that were never even on the radar in the past.
        barrkel 10y ago
        There's a variety of reasons. It's often because our languages are too low-level and the architecture too opaque, such that you need to study a codebase for a long time to understand what works well and what doesn't work so well. The hill you need to climb to reach an epiphany is sufficiently steep that people much rather build their own hill, and learn their own lessons. 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.
        oblio 10y ago
        > But if you could learn some things from the history and use that to your advantage, why wouldn't you? Everyone would be doing so. 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".
    - xiaoma 10y ago
      >"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." 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++.
      - pjmlp 10y ago
        Faire enough, so prepare for an history lesson. :) 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/ http://www.digibarn.com/collections/systems/xerox-8010/ https://www.youtube.com/watch?v=Cn4vC80Pv6Q https://www.youtube.com/watch?v=Cn4vC80Pv6Q https://www.youtube.com/watch?v=ODZBL80JPqw 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_xeroxparcteCedarProgrammingEnvironmentAMidtermRepo_13518000 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 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 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&section=compilers&type=tutorial http://www.progtools.org/article.php?name=oberon&section=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 http://www-spin.cs.washington.edu/external/overview.html There were a few others, this is just a small sample.
- _ph_ 10y ago
  Interestingly, one of the Go core creators, Robert Griesemer did work at the ETHZ and seemed to have gotten a proper dosis of the Wirth languages which then strongly shaped Go.
  - pjmlp 10y ago
    Yes, which is why Go has Oberon-2 syntax for methods and also an unsafe package that is similar to SYSTEM. Go could be used for doing a, lets call it, Goberon. It just needs someone with enough motivation for doing it.
- samuell 10y ago
  Operating system written in Go: Clive (https://lsub.org/ls/clive.html https://lsub.org/ls/clive.html)

What's the most successful operating system created in one of those languages?

by xiaoma 10y ago

What's the most successful operating system created in one of those languages?

pjmlp 10y ago

Probably Oberon, which was used during several years at ETHZ across the IT department of the university, including the secretary personal. Was also the source for many of Plan 9 UI ideas. What is most successful operating system created in Go or Rust?

nachtigall 10y ago
For Rust, probably Redox (https://www.redox-os.org/ https://www.redox-os.org/). Then there's http://os.phil-opp.com/ http://os.phil-opp.com/ and https://intermezzos.github.io/book/ https://intermezzos.github.io/book/ For Go, I don't know any (but might be wrong, googling did not turn up anything).
- pjmlp 10y ago
  I know them. 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.
  - barrkel 10y ago
    Software development has eternal amnesia. Deep understanding of the pros and cons of different ways of structuring things are being continuously re-learnt with each passing fad, and each rewrite of a legacy system by a bright new crop of young things who learned most of what they know with a decade or so of direct experience. 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.
    - pjmlp 10y ago
      100% on spot, the fashion driven software as Alan Kay puts it.
    - zzzcpan 10y ago
      But if you could learn some things from the history and use that to your advantage, why wouldn't you? Everyone would be doing so. And yet somehow it doesn't work like that, outdated things are in fact outdated and you can only take away very little from them. Things that were designed with trade offs for very expensive slow synchronous machines during the times when programmers were not bound to languages, because everyone had to develop everything from scratch, don't really make much sense today. Direct experience of the last decade is a lot more relevant with a lot more lessons to learn that were never even on the radar in the past.
      - barrkel 10y ago
        There's a variety of reasons. It's often because our languages are too low-level and the architecture too opaque, such that you need to study a codebase for a long time to understand what works well and what doesn't work so well. The hill you need to climb to reach an epiphany is sufficiently steep that people much rather build their own hill, and learn their own lessons. 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.
      - oblio 10y ago
        > But if you could learn some things from the history and use that to your advantage, why wouldn't you? Everyone would be doing so. 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".
  - xiaoma 10y ago
    >"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." 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++.
    - pjmlp 10y ago
      Faire enough, so prepare for an history lesson. :) 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/ http://www.digibarn.com/collections/systems/xerox-8010/ https://www.youtube.com/watch?v=Cn4vC80Pv6Q https://www.youtube.com/watch?v=Cn4vC80Pv6Q https://www.youtube.com/watch?v=ODZBL80JPqw 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_xeroxparcteCedarProgrammingEnvironmentAMidtermRepo_13518000 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 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 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&section=compilers&type=tutorial http://www.progtools.org/article.php?name=oberon&section=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 http://www-spin.cs.washington.edu/external/overview.html There were a few others, this is just a small sample.
_ph_ 10y ago
Interestingly, one of the Go core creators, Robert Griesemer did work at the ETHZ and seemed to have gotten a proper dosis of the Wirth languages which then strongly shaped Go.
- pjmlp 10y ago
  Yes, which is why Go has Oberon-2 syntax for methods and also an unsafe package that is similar to SYSTEM. Go could be used for doing a, lets call it, Goberon. It just needs someone with enough motivation for doing it.
samuell 10y ago
Operating system written in Go: Clive (https://lsub.org/ls/clive.html https://lsub.org/ls/clive.html)