Hacker News Reader

Comment by Koshkin | Hacker News Reader

Rust? Maybe. But then, why not Go or Swift or Lisp? Personally, if I were to be expelled from C/C++ paradise, I would try Oberon - the only language I know that can compete with C in its simplicity and, despite normally being perceived as garbage-collected, the ability to serve as a truly systems programming language.

View on HN

As far as vs Go or Swift or Lisp, Rust is much "closer to the hardware"(as discussed in other threads nothing is really close to the hardware anymore) than the other languages, go and most lisps use GC which causes problems in many systems language situations, and last I heard swift still has lackluster cross platform support.

I don't really know anything about Oberon so can't speak to that.

P.S. Personally, all my hobby projects are in lisp. I write applications though, not system stuff.

Oberon was used for writing a complete graphical workstation OS used during the mid-90 at the ETHZ in Switzerland.

It was a language and OS, following the same spirit of Xerox PARC OSes.

The A2 Bluebottle OS is latest incarnation of Oberon OS with GUI and very responsive. Languages like Oberon can do unsafe stuff for low-level work like OS's. You just use manual, memory management and UNSAFE keyword. Rest that can be GC'd, bounds-checked, etc is by default.

A few months ago, I considered Oberon as a viable alternative to C for my pet projects. Horace, after some time spent playing with it, I was scared by a fewserious limitations: (1) there is no support for UTF-8 strings, native strings are just sequences of ASCII characters, (2) lack of libraries and available bindings (e.g., SQLite, GSL, FFTW...), (3) scarcity of tools like package managers and Doxygen-like tools, (4) very few resources available on the web (Wirth's book is exceptional, but it does not cover use cases that are common in 2016.)

I suspect that Oberon wants you to roll out your own text library. It's actually how C probably wants you to roll out your own string library, too, because "C strings" are no better than Oberon's text facilities. The problem is that nobody knows how you want to work with your strings. There doesn't seem to be "the one correct way" to work with texts. Gauche Scheme, for example, has an interesting take on strings (http://practical-scheme.net/docs/ILC2003.html): backing arrays are shared and substrings are O(1), semantics for Scheme strings is observed - mutability is still possible but expensive, thus also gently discouraging the programmer from using it.

Oberon was great in the mid-90, but it is stuck in time.

I loved the complete OS experience, but nowadays Swift, .NET Native,Rust among others would be better options.

Honestly, my first thought upon seeing GP's post was "why not Ada?". Designed by the DoD for safe systems programming, it wouldn't really be a bad choice.

That would be my thought too, but at this point Rust covers compile time checks against a larger class of errors, and is gentler about doing it.

Reply on news.ycombinator.com