-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
Wren
The Wren Programming Language. Wren is a small, fast, class-based concurrent scripting language.
Check out Wren.
https://wren.io/
Written by Bob Nystrom, author of Crafting Interpretors.
-
-
curiefense
Curiefense is a unified, open source platform protecting cloud native applications. (by mathusiast)
Interesting.
At the time we did it with Lua.
We extended Nginx and Envoy-proxy with a Rust library (and a server), and added a Lua interface, so users can further tweak the config and the flow.
https://github.com/zuriby/curiefense/tree/main/curiefense/cu...
-
I use it in production[0] and it's a delight so far. When Porffor[1] is ready you could compile to WASM through JS for self-contained binaries!
[0]: https://blog.nestful.app/p/why-i-rewrote-nestful-in-gleam
[1]: https://porffor.dev/
-
mlua
High level Lua 5.5/5.4/5.3/5.2/5.1 (including LuaJIT) and Luau bindings to Rust with async/await support
This is already available as an optional Lua target in mlua [0]. I recently built a programmable server for Server-Sent Events scriptable with Lua [1]. I chose Lua 5.4, but it's trivial to switch it to LuaJIT, or really any other Lua derivative including Roblox Luau. It's just a matter of enabling the mlua feature you want.
[0] https://github.com/mlua-rs/mlua
-
>For me the biggest gap in programming languages is a rust like language with a garbage collector, instead of a borrow checker.
I cannot agree more that's the much needed sweet spot/Goldilock/etc. Personally I have been advocating this approach for some times. Apparently the language is already widely available and currently has stable and wide compiler support including the venerable GNU compiler suite (GDC). It also one of the fastest, if not the fastest programming in existence for both compilation and execution [1].
It has been beating Fortran in its number crunching territory, no small feat given the Fortran pedigree with many languages still depending on Fortran based infrastructure for their number crunching capabilities including Matlab, Julia, Rust, Go, C, C++, etc.
[1] D website:
https://dlang.org/
[2] Numeric age for D: Mir GLAS is faster than OpenBLAS and Eigen:
http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/...
-
I think "implementing higher level features as extensions on top of a smaller core" is a hallmark of the Lisp family. Check out Fennel [0] or Janet [1] for two different approaches. On top of everything, Fennel is 100% Lua-compatible.
[0]: https://fennel-lang.org/
[1]: https://janet-lang.org/
-
I think "implementing higher level features as extensions on top of a smaller core" is a hallmark of the Lisp family. Check out Fennel [0] or Janet [1] for two different approaches. On top of everything, Fennel is 100% Lua-compatible.
[0]: https://fennel-lang.org/
[1]: https://janet-lang.org/
-
> I don’t understand why…
Because dynamic typing has its own advantages, which are worthy of experimentation even if you perceive absence of static typing as a weakness.
> inferred typing is nearly as easy to use while being more robust.
Implementing type inference can be fairly trivial if your types are all disjoint. Hindley-Milner type inference is well studied and there's plenty of literature.
But as soon as you introduce subtyping, the traditional methods are not sufficient. It's only in the past decade that good solutions have been discovered - notably Dolan & Mycroft's MLsub[1], based on Dolan's Algebriac Subtyping thesis[2], and Parreaux & Chau's MLstruct[3], which uses a boolean algebra approach[4].
Subtyping doesn't imply object-oriented. Structural typing is a form of subtyping.
[1]:https://github.com/stedolan/mlsub
[2]:https://www.cs.tufts.edu/~nr/cs257/archive/stephen-dolan/the...
[3]:https://github.com/hkust-taco/mlstruct
[4]:https://dl.acm.org/doi/pdf/10.1145/3563304
-
mlstruct
Codebase for the paper "MLstruct: Principal Type Inference in a Boolean Algebra of Structural Types"
> I don’t understand why…
Because dynamic typing has its own advantages, which are worthy of experimentation even if you perceive absence of static typing as a weakness.
> inferred typing is nearly as easy to use while being more robust.
Implementing type inference can be fairly trivial if your types are all disjoint. Hindley-Milner type inference is well studied and there's plenty of literature.
But as soon as you introduce subtyping, the traditional methods are not sufficient. It's only in the past decade that good solutions have been discovered - notably Dolan & Mycroft's MLsub[1], based on Dolan's Algebriac Subtyping thesis[2], and Parreaux & Chau's MLstruct[3], which uses a boolean algebra approach[4].
Subtyping doesn't imply object-oriented. Structural typing is a form of subtyping.
[1]:https://github.com/stedolan/mlsub
[2]:https://www.cs.tufts.edu/~nr/cs257/archive/stephen-dolan/the...
[3]:https://github.com/hkust-taco/mlstruct
[4]:https://dl.acm.org/doi/pdf/10.1145/3563304
-
vos
Vinix is an effort to write a modern, fast, and useful operating system in the V programming language
> For me the biggest gap in programming languages is a rust like language with a garbage collector, instead of a borrow checker.
https://vlang.io
-
Yes! I'm using it for adding commands to Helix, e.g. https://github.com/irh/dotfiles/blob/main/scripts/.scripts/t...
-
Limited for now, Koto's main role as an embedded language has meant that I haven't had a need, but I would like to provide bindings for other languages at some point, and to enable dynamically loaded Rust libraries.
I'd start by trying UniFFI [1] which looks much simpler than the approach of manually writing a C API and using that as a foundation for higher-level language bindings.
This would also likely be the starting point for a package management system (if there ends up being demand for one). Rust doesn't have a stable ABI so to make sure that dynamically loaded Rust packages are compatible, either Koto would need to be in the business of Rust toolchain management so that packages can be recompiled when needed, or an API layer would be needed. There are some projects that provide ABI-compatibility shims but I don't like the idea of having two separate approaches to FFI, so I'd want to try to build on the foreign-FFI layer once it's in place.
I'm half hoping that by the time I'm interested in working on this Rust will have decided to pursue ABI stability. And there's also something in the back of my mind that's yelling 'Wasm!' at me but I would need someone wiser to convince me that it would be the right direction.
[1] https://github.com/mozilla/uniffi-rs
-
I implemented a similar project using Koto https://github.com/cornedriesprong/ohm. Not nearly as full-featured as Glicol, but I guess it can serve as comparison.
