Manage all types of time series data in a single, purpose-built database. Run at any scale in any environment in the cloud, on-premises, or at the edge. Learn more →
Oberon Alternatives
Similar projects and alternatives to Oberon
-
Smalltalk
Parser, code model, interpreter and navigable browser for the original Xerox Smalltalk-80 v2 sources and virtual image file (by rochus-keller)
-
oberon-riscv
Oberon RISC-V port, based on Samuel Falvo's RISC-V compiler and Peter de Wachter's Project Norebo. Part of an academic project to evaluate Project Oberon on RISC-V.
-
Onboard AI
Learn any GitHub repo in 59 seconds. Onboard AI learns any GitHub repo in minutes and lets you chat with it to locate functionality, understand different parts, and generate new code. Use it for free at www.getonboard.dev.
-
-
tectonic
A modernized, complete, self-contained TeX/LaTeX engine, powered by XeTeX and TeXLive.
-
-
-
atldotnet
Fully managed, portable and easy-to-use C# library to read and edit audio data and metadata (tags) from various audio formats, playlists and CUE sheets
-
InfluxDB
Collect and Analyze Billions of Data Points in Real Time. Manage all types of time series data in a single, purpose-built database. Run at any scale in any environment in the cloud, on-premises, or at the edge.
-
.NET Runtime
.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
-
LjTools
LuaJIT 2.0 bytecode parser, viewer, assembler and test VM. Lua 5.1 parser, IDE and debugger.
-
Som
Parser, code model, navigable browser and VM for the SOM Smalltalk dialect (by rochus-keller)
-
FrameworkBenchmarks
Source for the TechEmpower Framework Benchmarks project
-
are-we-fast-yet
Are We Fast Yet? Comparing Language Implementations with Objects, Closures, and Arrays
-
-
OberonSystem
Modified version of the original from http://www.projectoberon.com/ for use with the Oberon IDE
-
-
-
spec
WebAssembly specification, reference interpreter, and test suite. (by WebAssembly)
-
Avalonia
Develop Desktop, Embedded, Mobile and WebAssembly apps with C# and XAML. The most popular .NET Foundation community project.
-
Nim
Nim is a statically typed compiled systems programming language. It combines successful concepts from mature languages like Python, Ada and Modula. Its design focuses on efficiency, expressiveness, and elegance (in that order of priority).
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
NOTE:
The number of mentions on this list indicates mentions on common posts plus user suggested alternatives.
Hence, a higher number means a better Oberon alternative or higher similarity.
Oberon reviews and mentions
Posts with mentions or reviews of Oberon.
We have used some of these posts to build our list of alternatives
and similar projects. The last one was on 2023-11-12.
- FreeOberon cross-platform Oberon language IDD
-
Project Oberon (New Edition 2013)
> gain a deep understanding of it .. generate smaller subsets of the system
You can use the OberonViewer for this purpose with the original source code, or the Oberon IDE with a version of the Project Oberon System which runs with SDL on all platforms, see https://github.com/rochus-keller/oberon/#binary-versions and https://github.com/rochus-keller/OberonSystem/tree/FFI
-
KolibriOS on Single Floppy Disk
> Regardless, which one is more likely to be ported to a different architecture in the future?
Not sure I understand the question. I'm talking about CPU architectures. The current implementation is in x86 assembler. So if you want to run it on AMD64 or ARM, then you have to replace all assembler files, in the present case probable the full source code.
> what are the comparative performance benchmarks of the low-level language versus the high-level language?
I don't have any measurements. But consider that many operating systems are implemented in C (e.g. Linux) with only isolated parts in assembler, so it is easier to port to other architectures. Linux apparently is fast enough and available for nearly every CPU. Oberon in contrast to C is garbage collected, which also affects performance. I have measurements comparing the same benchmark suite implemented in C++ and in Oberon, where the former is about 22% faster (see https://github.com/rochus-keller/Oberon/blob/master/testcase...).
- Why Use Pascal?
-
C or LLVM for a fast backend?
I actually had a similar problem some years ago and finally moved away from LLVM because of complexity, continuous research effort and performance. My current Oberon+ implementation works like this: the CIL code generator together with Mono is used during development, integrated with the IDE, using the debugging features integrated in Mono; to deploy the application and to gain another factor 2 of performance C99 instead of CIL can be generated and compiled with any compatible toolchain. Here are some performance measurements: https://github.com/rochus-keller/Oberon/blob/master/testcases/Are-we-fast-yet/Are-we-fast-yet_results_linux.pdf. Compiling to CIL is very fast and the time Mono needs to compile and run is barely noticable.
- Do transpilers just use a lot of string manipulation and concatenation to output the target language?
-
Native AOT Overview
> annoying aspects was requiring the .NET runtime ... OpenJDK is a blessed implementation in a way that Mono never was
Which is unjustified, because Mono CLR is just a single executable less than 5 MB which you can download and run without a complicated installation process (see e.g. https://github.com/rochus-keller/Oberon/#binary-versions ). AOT compilation on the other hand is a huge and complex installation depending on a lot of stuff including LLVM, and the resulting executables are not really smaller than the CLR + mscorlib + app.
-
Does the JVM / CLR even make sense nowadays?
After evaluating a lot of different technologies I'm e.g. using the Mono CLR for my Oberon+ IDE because it is lean, fast and has also excellent platform independent debugging features, and also an integrated, mostly standardized and platform independent FFI (see https://github.com/rochus-keller/Oberon). It is more stable than LuaJIT and the same benchmark suit runs twice as fast on Mono than on LuaJIT (see https://github.com/rochus-keller/Oberon/blob/master/testcases/Are-we-fast-yet/Are-we-fast-yet_results_linux.pdf). Mono is also still fast enough compared to more recent CLR versions (see https://www.quora.com/Is-the-Mono-CLR-really-slower-than-CoreCLR/answer/Rochus-Keller). For the AOT use-case my compiler generates C for another factor two in speed when compiled e.g. with GCC -O2. You could even use the AOT feature of Mono for the same purpose.
-
How fast is JIT compiled Lua/JavaScript compared to static compiled C++ and Rust measured in runtime?
1: https://github.com/rochus-keller/Oberon/blob/master/testcases/Are-we-fast-yet/Are-we-fast-yet_results_linux.pdf
-
Useful lesser-used languages?
Oberon? see https://github.com/rochus-keller/Oberon/
-
A note from our sponsor - InfluxDB
www.influxdata.com | 28 Nov 2023
Stats
Basic Oberon repo stats
73
385
0.0
7 days ago
rochus-keller/Oberon is an open source project licensed under GNU General Public License v3.0 only which is an OSI approved license.
The primary programming language of Oberon is C++.
SaaSHub - Software Alternatives and Reviews
SaaSHub helps you find the best software and product alternatives
www.saashub.com