Oberon Alternatives

Oberon reviews and mentions

• Vishap Oberon Compiler
  5 projects | news.ycombinator.com | 8 Apr 2025

  > Since Oberon is as much a compiler as it's a complete system,

  The system and the language are two different things (even if they unfortunately share the same name); the language itself doesn't depend on the system. Instead there is a standard library defined in the Oakwood guidelines; the guidelines even define a (primitive) drawing window (XYPlane). The Oberon+ compiler (see https://github.com/rochus-keller/oberon/) includes a foreign function interface and a binding to e.g. the NAppGUI library which is a powerfull cross-platform user interface framework, but also an SDL binding, which is e.g. used by https://github.com/rochus-keller/OberonSystem3/.

• Ask HN: What less-popular systems programming language are you using?
  38 projects | news.ycombinator.com | 1 Mar 2025

  My major system programming languages are C and C++, but I did some projects in Oberon (which turned out to be not particularly suited for systems programming), and then created a modified, better suited version of it called Oberon+ (https://github.com/rochus-keller/Oberon), which I e.g. used to create platform-independend versions of different Oberon System generations.

  But Oberon+ is still too high-level for many system programming tasks. So I'm designing a new system programming language called Micron (for Micro Oberon, see https://github.com/micron-language/specification) which has the full power of C without its disadvantages. You can even use it for the OS bootstrapping when there is no stack and no heap, but also for higher-level application development, due to its selectable language levels.

• A Resource for Oberon-07
  1 project | news.ycombinator.com | 25 Feb 2025
• Good research of Java (JIT) vs. C++ (AOT) performance with interesting results
  3 projects | news.ycombinator.com | 10 Dec 2024

  It's not about a "final conclusion", just about a summary of the measurement results at hand. Instead of letting the user to trawl through a lot of documents and figures and make geomean and factors calculations him/herself, the author who publishes measurement results should do this. Here is an example how this could look: https://github.com/rochus-keller/Oberon/blob/master/testcase.... It is immediately recognizable how much less time on average the C++ implementation used compared to the reference (LuaJIT in this case).

• Deegen: A JIT-Capable VM Generator for Dynamic Languages
  2 projects | news.ycombinator.com | 19 Nov 2024

  You can e.g. use Node.js as a reference and compare with these results: https://github.com/rochus-keller/Oberon/blob/master/testcase.... LuaJIT with JIT on is usually factor two slower than Node.js and factor five slower than C/C++ in my measurements.

• Pallene: A statically compiled companion language for Lua
  8 projects | news.ycombinator.com | 28 Jul 2024

  Pallene unfortunately is only a subset of Lua, i.e. you cannot simply take a Lua program and compile it with Pallene. The use case of this language is not obvious to me, since if I have to re-implement the performance-critical parts of the Lua program anyway, I can just as good implement it in C using the Lua C API. Thus the claim of the Pallene authors is a bit misleading.

  Concerning LuaJIT performance, I have done a lot of measurements over the years (see e.g. https://github.com/rochus-keller/Oberon/blob/master/testcase...) and would rather say that its performance is about factor four worse on average than an equivalent C++ -O2 compiled program. For some exceptional use cases it might perform as good as C, but not in general (one reason is the missing tracing JIT support for closures).

• Boehm Garbage Collector
  9 projects | news.ycombinator.com | 21 Jan 2024

  > Sure there's a small overhead to smart pointers

  Not so small, and it has the potential to significantly speed down an application when not used wisely. Here are e.g. some measurements where the programmer used C++11 and did everything with smart pointers: https://github.com/smarr/are-we-fast-yet/issues/80#issuecomm.... There was a speed down between factor 2 and 10 compared with the C++98 implementation. Also remember that smart pointers create memory leaks when used with circular references, and there is an additional memory allocation involved with each smart pointer.

  > Garbage collection has an overhead too of course

  The Boehm GC is surprisingly efficient. See e.g. these measurements: https://github.com/rochus-keller/Oberon/blob/master/testcase.... The same benchmark suite as above is compared with different versions of Mono (using the generational GC) and the C code (using Boehm GC) generated with my Oberon compiler. The latter only is 20% slower than the native C++98 version, and still twice as fast as Mono 5.

• Niklaus Wirth, or the Importance of Being Simple
  3 projects | news.ycombinator.com | 18 Jan 2024

  Great, thanks!

  There are books online for free, e.g.

  https://people.inf.ethz.ch/wirth/ProgInOberonWR.pdf

  and https://ssw.jku.at/Research/Books/Oberon2.pdf

  Oberon+ is a superset of Oberon 90 and Oberon-2. Here is more information: https://oberon-lang.github.io/, and here is the current language specification: https://github.com/oberon-lang/specification/blob/master/The.... I already had valuable feedback here on HN concerning the channel extensions. Further research brought me to the conclusion, that Oberon+ should support both, channels and also monitors, because even in Go, the sync package primitives are used twice as much as channels. Mutexes and condition variables can be emulated with channels (I tried my luck here: https://www.quora.com/How-can-we-emulate-mutexes-and-conditi...), but for efficiency reasons I think monitors should be directly supported in the language as well, even if it might collide with the goal of simplicity.

  Feel free to comment here or e.g. in https://github.com/rochus-keller/Oberon/discussions/45.

• Tex-Oberon: Make Project Oberon Pretty Again
  3 projects | news.ycombinator.com | 6 Jan 2024

  > Does anyone know why Wirth never modernized his style?

  Readability. It's easier to read the source code with uppercase keywords. (I think Wirth once said that code is written once but read many times). See this source code - https://raw.githubusercontent.com/rochus-keller/OberonSystem... - to get an idea of this (the uppercase keywords allow you to easily scan the blocks of code). Ofcourse, one can claim that the same can be achieved better today with colour-coded keywords.

  If I remember right, the Oberon+ IDE - https://github.com/rochus-keller/Oberon - gives you an option to disable this and use lowercase keywords.

• FreeOberon cross-platform Oberon language IDD
  3 projects | news.ycombinator.com | 12 Nov 2023
• A note from our sponsor - SaaSHub
  www.saashub.com | 25 Apr 2025

  SaaSHub helps you find the best software and product alternatives Learn more →