[HN Gopher] Onyx, a new programming language powered by WebAssembly
___________________________________________________________________
Onyx, a new programming language powered by WebAssembly
Author : bkolobara
Score : 87 points
Date : 2023-12-01 17:22 UTC (5 hours ago)
(HTM) web link (wasmer.io)
(TXT) w3m dump (wasmer.io)
| kemitchell wrote:
| Clearly Wasmer wants to do WebAssembly. But for a whole new,
| general-purpose programming language, what's the case for that
| target, versus, say, LLVM intermediate representation?
| brendanfh wrote:
| Onyx is entirely independent from Wasmer. It is a separate
| project developed by me, over the past 3 years. It does however
| use Wasmer for running on Windows, MacOS, and optionally on
| Linux.
|
| I started making Onyx because I simply wanted to create my own
| programming language for the fun of it. I choose WebAssembly as
| the target for my compiler because it was relatively easy to
| write my own full-stack solution, instead of relying on
| something like LLVM. That language evolved over the years until
| I had something I felt was worth sharing. When the Wasmer team
| reached out to see if I wanted to do a collaboration blog post,
| I said yes.
|
| The main reason I didn't go with LLVM was simply because I
| wanted to write everything myself (for fun) and to have a
| super-fast compiler. LLVM is not the fastest backend, but it is
| understandable for all the optimizations that it does.
| IshKebab wrote:
| Looks neat. Some obvious basic questions that I imagine most
| people would wonder:
|
| 1. Is it value based (C++, Rust, Go, TCL) or reference based
| (basically everything else).
|
| 2. How is memory freed? GC?
|
| 3. If GC how do you deal with the fact that Wasm GC is still in
| progress?
|
| 4. What about concurrency? Is it single threaded?
|
| 5. How does error handling work?
|
| 6. Does it support modern type features - Option<>, sum types,
| etc.
|
| 7. It's imperative, does that mean things that should be
| expressions (e.g. if/else) are statements?
| norir wrote:
| 8. What does blazingly-fast build times mean quantitatively?
| How does it scale with project size?
| brendanfh wrote:
| The largest project I have in Onyx is currently around 30000
| lines (not all that large I know). That project on my Intel
| i7-1165G7 laptop compiles in about 80ms.
|
| There are currently no large Onyx projects that can really
| test how this number scales, but I would guess the growth is
| not linear. So for an off the cuff estimated, I would say a
| million line project could compile in about 4-5 seconds.
|
| Also worth noting that the entire compiler is currently
| single-threaded. So that number could get much better.
| titzer wrote:
| That's impressively fast. Well done!
| brendanfh wrote:
| Those are all great questions. I will add to the docs to
| explain more details later, but for now:
|
| 1. It is value based, like C. There is obviously passing by
| pointer, but you do that explcitly.
|
| 2/3. Memory is manually managed. To make this easier, like Zig
| and Odin, everything that allocates should take an allocator as
| a parameter. This allocator can be the general purpose heap
| allocator, or it can be an arena, ring buffer, or even tracked
| allocations that can be freed all at once. More details on that
| to follow in the documentation.
|
| 4. It does have multi-threading support, thanks to the atomics
| WASM proposal. The standard library currently has support for
| basic multi-threaded primitives like mutexes, semaphores, and
| condition variables. Note, there is currently not async/await
| or any kind of concurrent execution.
|
| 5/6. It does have modern type features like sum types. It has
| Optional(T) and Result(Ok, Err) out of the box. That is the
| preferred method of error handling.
|
| 7. It is mostly statement oriented, but there are features like
| Elixir's pipe operator (|>) and if/else (value if condition
| else otherwise) expressions.
| koube wrote:
| nit: seamless not seemless.
|
| Actually TIL seemless is actually a word but it's a synonym for
| unseemly.
| ivanjermakov wrote:
| I have irrational anger towards := assignment operator, probably
| because of Pascal course in high school.
|
| Interesting if anyone else have such stories regarding language
| syntax and features.
| topikk wrote:
| I also have this irrational anger, but as a result of PL/SQL.
| It's also an objectively hideous operator that is inconvenient
| to type.
| acheong08 wrote:
| Coming from Go, I got used to :=. I would've preferred if it
| defaulted to const though
| CooCooCaCha wrote:
| It bugs me too. Mainly because I don't see anything wrong with
| "=", plus it's shorter and more intuitive.
| brendanfh wrote:
| The example in the blog post could have been written a little
| bit better, but in Onyx ":=" is actually a combination of two
| operations: defining a new variable with ':', and assigning
| the value with '='. If the type can be inferred on the right
| hand-side of the assignment, you can leave out the type
| between the ':' and the '=' and it effectively becomes a
| single operator. An alternative way to write that could have
| been 'input: str = "111 110 121 120";'.
|
| To assign in Onyx, you only have to use '='.
| royjacobs wrote:
| How optimized is the generated code? One of the benefits of using
| LLVM is the amazing set of optimization passes, after all. Will
| Onyx have to reimplement a lot of these optimizations?
| brendanfh wrote:
| The compiler does not have many optimizations currently
| implemented. Currently, the compilers just uses constant
| folding and generally reducing unneeded operations if possible.
| There are plans to do function inlining and better tree-
| shaking, but those are a ways out.
|
| The "nice" thing about WebAssembly is that the job of
| generating optimized machine-instructions is up to the WASM
| embedder, which Wasmer is doing very well right now. Onyx does
| have a second runtime that is currently only implemented for
| x86_64 Linux, that does have some more optimizations, but it
| does not compile to native code; just to an interpreted byte-
| code.
| ipsum2 wrote:
| Not to be confused with Onnx, a popular language for machine
| learning models, that is also commonly used with WebAssembly.
| Even the logo looks similar.
|
| https://onnx.ai/
|
| https://cloudblogs.microsoft.com/opensource/2021/09/02/onnx-...
| FireInsight wrote:
| Not to be confused with Fedora Onyx, the budgie version of
| atomic Fedora.
|
| https://fedoraproject.org/onyx/
| ketralnis wrote:
| Not to be confused with Onix
| https://bulbapedia.bulbagarden.net/wiki/Onix_(Pokemon)
| tripdout wrote:
| Not to be confused with Onyx, the son of rappers Playboi
| Carti and Iggy Azalea.
| JoshStrobl wrote:
| Funny to see Onyx be mentioned in the wild! :D
| mike_hock wrote:
| Not to be confused with Onyx the clothing store.
| bnchrch wrote:
| I'm in no way against a new language! Love programming languages,
| particularly ones that push boundaries and challenge assumptions!
|
| (Great work on that front btw Onyx Team)
|
| But! When I see powered by WebAssembly. I can't see a good reason
| to choosing a unique language when any language in theory can
| target WASM/WASI.
|
| In other words Javascript/Python is looking at your lunch and is
| very hungry.
| orangea wrote:
| When I see "powered by WebAssembly", I take it as a sign that
| the language is going to be designed around WebAssembly's VM
| interface rather than the implicit standard of the C memory
| model and POSIX-like API which basically all popular
| programming languages are designed for. Even languages like
| Python have the concepts of stdin/stdout/stderr, a filesystem,
| threads, and a single globally accessible heap baked into their
| design. It would take a lot of work to amend Python's design to
| be able to easily use features that are somewhat unique to
| WebAssembly like the various things a .wasm file can import or
| export. As it stands, languages like Python can be run on WASM,
| but they use inelegant hacks in order to be able to replicate
| the execution environment features that their interpreters
| require such as malloc, and usually it is assumed that the
| target will be WASI. A language that is designed for WASM from
| the ground up would make it so that WASM can be used to its
| fullest potential as a lightweight execution environment that
| makes extremely minimal assumptions about what interfaces are
| going to be provided to the program.
| brendanfh wrote:
| That is exactly the way that I see it too.
|
| While Onyx does have core library support for doing standard
| POSIX things like stdin/stdout/stderr, file operations, and
| networking, Onyx can be used in an entirely different
| environment without any of these things. In fact, the
| standard libraries are (almost) entirely separate from the
| compiler (i.e. the compiler makes no assumptions about what
| the standard library is), so if the standard library does not
| suite your use case for one reason or another, you can write
| your own. It will be a bit of work, but there would be
| nothing in your way.
| gumballindie wrote:
| Add syntax to the list - it's horrible. The target audience is
| more used to the basic syntax of javascript.
| CyberDildonics wrote:
| I'm not sure a specific compilation target that is meant to be as
| simple and generic as possible makes a new language a good idea.
|
| New languages mean you start all over and wipe away decades of
| tools, knowledge, libraries, development environments, package
| managers, workflows and now people are in the wild west again. To
| justify that you have to have some enormous benefits.
| onyxlangfanboy wrote:
| Wow, this project is insane! Very well done to the creator, keep
| up the good work. Reading the comments all I gotta say: haters
| gnna hate
| kettlecorn wrote:
| Can Onyx's compiler be compiled to Wasm to itself run in the
| browser?
|
| It's niche, but I've thought it'd be cool if there were a mini
| Wasm-based game building tool in the browser, but that requires a
| Wasm language with a compiler that can run in the browser.
___________________________________________________________________
(page generated 2023-12-01 23:00 UTC)