Revo Programming language
81 points by Drakonis
81 points by Drakonis
tables represent everything used for
- module exports
- arrays
- maps
I was thinking of falling in love with Roc but this really catches my eye. Tables are goated and Lua made the right decision to only have tables, I will not defend this position if you probe me on it.
I do see using tables as both arrays and maps as an antipattern, ime there's basically zero situations where you can write code that accepts either an array or a map and have it do something sensible. Especially how Lua does it, where you Just Have To Know which is which 'cause they get treated differently under the hood and breaking the assumptions it makes will break your code. Like strings, arrays are a common enough special case that you don't really want them getting mixed up.
Using maps for modules/objects/vtables/etc is pretty awesome though.
Finally! I've been thinking for the last whee while that semi-typed languages are under explored. I primarily work in the Rust/C++ space but often end up writing a bunch of scripts in languages that don't feel "modern." There's significant benefits in the whipupatude of dynamic typing but then you're in exceptions and OOP land thanks to the era in which Ruby, Python etc. got going. It's exciting to see someone working on a new take here in the same way the new wave of statically typed compiled languages have been exciting
Very cool little language! I've been wanting a next-gen scripting language, maybe this will be it? I'll check it out more deeply sometime.
This looks really interesting. Kind of feels like a little bit of elixir, rust, and haskell.
Neat. I dug around the site to see how it can be embedded into another language: https://revo.lung.fyi/c/
The instructions require Zig to build the .a library. Forgive my ignorance about parts of Zig, but doesn't Zig have a way to convert Zig source code into C? If so, that would make it much easier to embed Revo into other programming languages with their own build systems.
I vaguely remember zig has a backend to generate C code, but it's not a clean translation ala coffeescript, more of an intermediary step in the compilation pipeline like rust-codegen-gcc
Between distributing a static .a library with headers, or distributing obfuscated by transpilation C sources to build by hand, I think I prefer a library. If something breaks during the compilation of the C files, you aren't going to dive into the sources to fix it, since the sources are machine-made; and I doubt compiling those to a different platform would also work, since it's the zig's comptime that has the target platform information, and that would be erased when translating to C
comptime that has the target platform information
That was the key technical detail I was missing: Zig generated C is unsuitable for cross-platform work. Machine-specific .a/ .so / .dylib / .lib has an analogous problem. My preference is to avoid both problems. Thanks!
Afaict Zig is also the best C build system around, so its probably not too big a barrier.
I am thinking of programming languages like OCaml which have a C FFI, builtin support for compiling C, and conventionally use source-based package managers. In those types of environments, the real problem is making the Zig executable and standard library available to builds (not easy with source-based package managers). Especially if you want to distribute a library, and can't guarantee that your library users have Zig preinstalled. However, it could be relatively straightforward to run Zig once to generate C source code (if possible) and check that C into source control alongside your other project source code.