Rhai looks somehow more OO, and is somehow conceptually bigger, with function overloading, operator overloading, currying, etc. Koto looks more like FP an stream processing, with pervasive anonymous functions, very simple data structures, and an emphasis on iterators.
Rhai also offers some safety guarantees: no panics, no stack overflows, etc. Rhai seemingly requires slightly less ceremony when interfacing with Rust: direct use of many things, as opposed to implementing a trait to interact with Koto.
(Disclaimer: I spent 5 minutes skimming the docs of each.)
Isn't Rhai extremely slow? The website itself says that it's roughly 2x slower than Python3: https://rhai.rs/book/about/benchmarks.html. Apparently, Rhai doesn't even compile to bytecode and instead walks the AST! This doesn't sound like a language I would pick as for DSP...
On the other hand, you can always write your own Rhai interpreter if necessary. And if you restrict the language to a limited set of features, which you need to do anyway to keep it realtime-safe, you could even compile it to native code.
> and it can handle real-time audio blocks, which is really impressive:
Any scripting language can do this as long as you stick to operations that don't cause memory allocations, system calls or other non-realtime-safe operations.
That's a valid point. Being native to the host language (Rust) is generally a big advantage.
I just don't really understand why Rhai uses an AST walking interpreter, that's basically the least efficient way of implement a scripting language. Once you have an AST, a byte code compiler/interpreter is not really hard to implement, so I'm wondering why they knowingly leave so much performance on the table...
In my tests it's been ~1.5-2x faster than Rhai, but Koto's still some way behind Lua in benchmarks so I'm not trying to make a big claim here (although that said one of the reasons I started work on Koto was to avoid the runtime overhead of Lua <-> Rust conversions, e.g. Koto shares the same string representation as Rust, Koto lists are just wrapped `Vec`s, etc).
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.
Would you say Koto (or some direct competitors, for that matter), is viable to learn when I otherwise don't intend to learn Rust at all? But let's say, want to keep the option open to participate in Rust-based projects which support Koto et al.?
Yes I would certainly hope so, you shouldn't need to know any Rust if you want to learn Koto. The guide assumes that the reader has some general experience with programming, but not from using any specific language.
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.
Sorry, I meant the Koto language and built-in library compatibility story. Whats on the roadmap for a 1.0 and will you allow a 2.0? One of my annoyances with Tcl and Lua is their breaking changes would be pushed into my application and I'd have to decide what version of the language to target and have a plan for changing it.
I'm fine with the Rust API breaking compatibility.
I can't imagine wanting a 2.0 release, I'd rather take longer to get to 1.0 to reduce the risk of needing it, and anyway I'd much prefer to aim for something like Rust's editions, allowing the language to evolve without the whole community needing to migrate.
Before 1.0 I'd want to address at least:
- the FFI / package management topics mentioned above
Very cool. I really like the idea of implementing higher level features as extensions on top of a smaller core. I wish real scripting languages like this were more common and in use. Lua comes to mind when thinking about a generic scripting language, but even that is not that widespread.
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.
Recently I've started evaluating new languages in terms of "how difficult would it be to read working code in this language, written by an insane person".
After looking at this for 5 minutes it seems it is better than rhai according to my metric. But not necessarily better than lua.
I've used OpenResty extensively which is basically just nginx + luajit with a lot of additional APIs and features. The nginx-lua-module is available separately from the OpenResty distribution of nginx, so you can just install and run it as a dynamic nginx module.
Indeed, OpenResty comes with Lua and LuaJIT built-in.
Earlier version where we've implemented all in Lua, had no need for that. However, as we went fro Lua to Rust (and speed up by using only 15% CPU comparing to the Lua), we added that Lua interface support to the rust, and it worked like a charm.
If I was going to chose a scripting language for rust I'd pick nushell's syntax. Nushell is an amazing shell and it's syntax is one of the reasons why.
It says Coffeescript and Moonscript influenced Koto's syntax, which is a little worrying. IMO those languages are a little too flexible and sail too close to ambiguity - very small changes to code can sometimes radically change its meaning.
Edit: Sure enough, "whitespace is important in Koto, and because of optional parentheses, `f(1, 2)` is not the same as `f (1, 2)`. The former is parsed as a call to f with two arguments, whereas the latter is a call to f with a tuple as the single argument."
Oh it has optional parentheses? Into the trash it goes.
I'm guessing because "it's cleaner/simpler", but that's a shallow understanding of those words. Just because there are two characters fewer on the screen doesn't make the code simpler. Simple semantics are what you should aim for and inconsistencies like these throw a wrench into that.
For example, strings in JSON vs YAML. Isn't it "simpler" to not have to quote every string? So long as your string isn't "no" that may be true. So now instead of a simple mental model of "every string must be quoted" it's "strings don't need quotes except for these specific exceptions that cause issues: <list>". So much simpler... sigh.
What I've had in mind with Koto is that when I need strictness and precision I'll generally be using Rust, and Koto is more intended for another aspect of programming where I want things to be much more fluid and easy-going.
My thinking is that the potential footgun here is outweighed by the win of paren-free calls for quick scripting / rapid iteration, but it certainly counts towards the language strangeness budget [1] so I figured it was worth pointing out in the guide.
One of the problems of terse syntaxes is that one typo away from a syntactically valid program lies another syntactically valid program with entirely different semantics.
I prefer a syntax that has enough "gaps" between syntactic constructs, so that a single typo usually leads to an obvious syntax error. In this regard, Python or Java or TS are comfortable, Haskell or Lisp or C are okay, and Coffescript or Scala or C++ are terrible.
Yes, I was missing a 'companion language' for Rust similar to Lua for C and C++, I tried Lua bindings and other Rusty scripting languages but felt like starting a new project would be worthwhile.
It seems every scripting language does duck/dynamic typing (as far as I can tell this applies to Koto).
I don’t understand why…
inferred typing is nearly as easy to use while being more robust.
For me the biggest gap in programming languages is a rust like language with a garbage collector, instead of a borrow checker.
Rust has a lot of features that should be strongly considered for the next generation of programming languages such as
result/sum types
Inferred typing
Not object oriented or overly prescriptive with functional programming.
I think the closest language to filling that gap is occaml (I am not familiar with it).
I have coworker's that are more skilled in domain logic that can write basic self contained programs, but stuff like traits, OOP functional programming is a bridge too far.
I feel like a language that fills that gap could be useful, context is a manufacturing ERP system.
I think you really are describing ocaml, which is a great language, although its ecosystem isn't the best. It probably inspired most of the features you mentioned in rust. It also supports OOP (hence the O) but it's easy to avoid.
That said, I wouldn't compare it to scripting languages. The lack of implicit conversions / traits / ad-hoc polymorphism means it's not that convenient for scripting.
F# was never really "OCaml on .NET", though, not really. ML on .NET, sure, but it is (and always has been) missing OCaml's most interesting features, such as functors and OO with inferred row-types.
They have kinda positioned themselves that way and had (have?) syntactic compatibility with a subset of OCaml. And OCaml is probably the least obscure of the ML language family, so it's not exactly surprising.
Fsharp is such a nice languange. Such a shame that I never seem to get the light it deserves.
Between the alternative light syntax, type providers and first class "scripting" mode supported it really was a great middle point between fully scripting language and fast prototyping and full blow projects
Ruby does very little implicit type conversion and is great for scripting. I think implicit type conversion is not required or even a good thing for scripting languages.
Implicit conversion is not obviously that convenient for scripting. The JS community has largely moved to anti-recommend implicit conversion, such as by basically striking `==` from their vocabulary.
What makes OCaml inconvenient for scripting is how difficult it is to run code that uses some external libraries. You basically need to create a whole project structure with several config files, which creates a lot of friction compared to `import numpy as np`.
If I remember correctly, main reason for forking was that Nim BDFL was writing lazy commit messages and old codebase was hard to navigate around. Some small part of community forked the language and trying to rewrite the compiler. According to readme they're not trying to replace Nim, but to create new language with Nim as base. Not sure how usable it's right now or will it ever be.
I also want to point out that Araq quickly took the criticism and his commits look a lot better now.
Also, core Nim team is currently working on their own rewrite of Nim compiler, called Nimony, that should evolve into Nim 3.
> It seems every scripting language does duck/dynamic typing (as far as I can tell this applies to Koto).
It looks like Koto supports type hints - not sure if these are checked at compile-time, run-time, or both.
> I don’t understand why… inferred typing is nearly as easy to use while being more robust.
Is it (nearly as easy to use)? Every static type system seems to have special cases and exceptions which are avoided by dynamic typing. I'd love to find one that's actually simple.
Also, it's definitely not nearly as easy to implement - which is important for a language being designed and built by a small team and targeting a lightweight runtime.
> Also, it's definitely not nearly as easy to implement
I think this is the real reason why there are so many dynamic language implementations. If you want to implement a dynamic language, you just slap a type tag on your runtime objects and boom, your "type system" is done.
Dynamic languages get a lot of expressiveness "for free", whereas having a really expressive static type system requires a lot of work. It's not that hard to get a type system on the level of C, but if the language is interpreted, it's still going to be pretty slow.
I do think there can be benefits to having typing in a scripting language (and not a bolted-on type system like typescript or mypy). It's much easier to work with an FFI if the type system of the scripting language maps closely to the implementation language. It also does make it much easier to optimize the language down the line, if that becomes a priority. Making a fully dynamic language efficient is very, very difficult.
> not sure if these are checked at compile-time, run-time, or both
It looks like Koto only checks types at run-time. That means its type annotations are essentially shorthand for something like Python's `if not isinstance(...): raise TypeError`.
Yes that's right, they're checked at runtime (with the option to disable the checks if the performance cost is a concern) and failed checks simply throw exceptions.
The hints aren't used for other purposes at compile time yet, but they could enable some warnings.
Because dynamic typing has its own advantages, which are worthy of experimentation even if you perceive absence of static typing as a weakness.
Gradual typing can offer us the benefits of both worlds.
> 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]. Type inference with subtyping is not a solved problem - these developments are big steps forward, but there are still open problems under research.
Subtyping doesn't imply object-oriented. Structural typing (ie "static duck typing") is a form of subtyping.
> Gradual typing can offer us the benefits of both worlds.
Gradual typing has much the same overhead as other kinds of dynamic typing. It's broadly appropriate as part of the interface between separately-developed software components, and not very much otherwise.
Gradual typing is static typing augmented with a known static type `dynamic`, and some rules by which conversions to/from `dynamic` are statically checked, called consistency.
A program in a gradually typed language which does not use `dynamic` is fully statically checked and has no overheads. The overheads only appear when `dynamic` is used.
This is why it offers the best of both worlds. We get static typing everywhere where we're not using dynamic, and when we do use dynamic, we can basically use it however we want and have the benefits of dynamic typing, because from the static perspective, dynamic ~ dynamic, regardless of what the runtime type is.
The important innovation is that consistency (~) is not transitive - so it doesn't allow us to implicitly convert one type to another - only conversions to/from dynamic are implicit, and other conversions must be done explicitly.
Obviously, this provides an "escape hatch" from static typing where we do use it - we can get around some static type check by casting to/from dynamic explicitly, but this works out well in practice.
C# is an example of a gradually typed language since v4 which introduced `dynamic`.
Haskell is close , in that it has the type `Data.Dynamic`, but it doesn't support implicit conversions to/from it, which would be possible if it had a consistency rule. We have to do the conversions explicitly.
roc as a language looks really interesting but its by elm devs and I don't have much confidence in their ability to handle the transition to being a widely used language with all the cultural shifts that requires.
I hear ya, but Elm allowed me to eject out of the javascript churn for the past 7 years while still building some slick UIs that basically never fall over. I literally don’t know or care what the current hotness is in javascript, and that’s how I like it.
If roc ends up being even close to that productive for me, I really don’t care how widespread it is. I like these thoughtful unrushed languages that I can support for years without stress.
> but Elm allowed me to eject out of the javascript churn for the past 7 years while still building some slick UIs that basically never fall over.
Thats the real tragedy. Elm was a good language but the culture around it means it could never achieve critical adoption. It is great technology for building frontends but how easily will I be able to maintain that app as the web changes over the years?
I can only speak from experience, but it's been absolutely solid, incredibly easy to maintain (because there's been so little change), and I don't feel like I missed out on any groundbreaking front end tech at all. I literally have some elm code that's been in production doing it's thing for 7+ years without any maintenance, but more importantly it's not scary to open it up and make changes 7 years later either.
I doubt it's a silver bullet for everyone, but it's been phenomenal for me as a solo dev w/ my own product. I feel so much better about my elm code than I do about my React code. I have to do all the other things, like marketing, sales, training, support, back end, etc. It's nice to launch a UI and know it'll last (and also that it's easy to refactor and augment too!). Elm has turned my into a statically typed functional fanboy. It's been a gateway drug to Haskell, OCaml, and F#.
I see the same promise with Roc, although I bet Richard will update it more frequently than Evan w/ elm after 1.0.
It's created by Richard Feldman who was big in the Elm community, but I think most contributors to the Roc compiler have only used Elm a bit or have never used it.
FYI roc is in the early stages of a complete rewrite from Rust to Zig and... that may take a while. I'm messing with Nim in the meantime for some commandline tooling
Rust will probably gain support for "pluggable" and optional garbage collectors as part of its upcoming local allocators API. This will ultimately give devs the best of both choices - use tracing GC where it's actually needed (because you're working with totally general graph-like data and that's the only feasible memory management strategy) and manual memory management (supplemented by RAII and reference counting) elsewhere - for other parts of the program that don't have to manage general "spaghetti" graphs. Unfortunately the way GC's trace objects and collect garbage varies wildly among implementations, so there's no easy way to standardize a "generic" interface to pluggable garbage collection, that all custom crates might be expected to tap into by default. But other uses should be quite feasible.
> Rust will probably gain support for "pluggable" and optional garbage collectors as part of its upcoming local allocators API.
Source? AFAIK there's no confirmed upcoming allocators APIs, and even if there was they would just allow reusing the builtin `Box`/`Vec`/etc etc with custom allocators. This is not much different than what you could do with a custom type, so I find it hard to believe it would allow garbage collectors that are not possible right now.
I don't think you're disagreeing with parent. I also think these features are not groundbreaking and should be considered table stakes for any new/sane language.
I am aware of 3 “rust inspired scripting” languages that have dynamic types.
Rhai
Rune
Dyon
Mun is not dynamic, however it does not have string support afaik.
Kotlin and Swift may be better candidates than these scripting languages for my imagined usecase.
Come to think of it, maybe I don’t have a point other then there is so many scripting language’s inspired by rust that is dropping a major convenience feature, that I am surprised is negotiable (inferred typing ).
Rust itself has dynamic types via the Any trait and &dyn Any variables. They are not the default of course, but they're available should you really want them. IIRC C# works similarly, only its feature is called Dynamic instead, or something like that.
They're rather different: In Rust types only exist at compile time; dyn Any is a normal trait object, so you can only call the trait's methods. With C#'s dynamic, you can call arbitrary methods and access any fields with type checking of those accesses being delayed until runtime, which works because types exist at runtime too.
Rust's dyn Any corresponds better to C#'s Object; dynamic exists to interface with dynamic languages and is rarely used.
Yeah I think Kotlin is quite close to the OP's description. But it is perhaps more focused on object orientation than they would like, and also only runs on the JVM.
But if I were to create a self-contained (that is, non-JVM) "Rust-like but with GC", I think it would look a lot like Kotlin.
I haven't tried it but Kotlin/Native targets platforms like iOS, macOS, Linux, Windows, etc. There's also Kotlin/JS for JavaScript, and a WASM target with limitations.
Rather Scala but leaving out a few parts. Kotlin is very very OOP focussed and comes with a lot of baggage from Java.
Rust-like but with GC is already Scala. The reason is that Scala (unlike Kotlin) focusses on immutability, which makes it more similar to Rust. It's actually even easier to use (no borrow checker) but at the cost of performance.
After Rust, I would see F# as the next closest language, quite far before Kotlin.
Maybe like a third of Scala. But yeah, Scala has a lot of good parts, it's also just a huge surface area. I agree that you could pluck a subset out of Scala and make it this "Rust-like but with GC" language.
But it's nigh-impossible to actually make that "only use this subset" idea work in practice, because it just ends up being a bikeshed.
But you're right that the same can be said of the OO focus of Kotlin.
I think it absolutely works in practice. You have to pick the right libraries though. I would start with https://github.com/com-lihaoyi which basically follows that style.
> But you're right that the same can be said of the OO focus of Kotlin.
The difference is that Scala focuses on immutability, which makes the experience much closer to Rust than to Java. Whereas Kotlin does it exactly like Java does. Were Kotlin to focus on immutability like Scala does, than I would recommend Kotlin over Scala for what OP asked for.
A language is a shared way to communicate. If you start picking and choosing the parts of a language you like, you can no longer communicate effectively with the rest of its speakers, er, coders.
That's why C++ is so badly designed, you can do anything in it, so people do and no two C++ codebases are the same. Your codebase at work is written one way, the libraries it uses in another, your personal projects use something else entirely. It's a huge mess where nothing is compatible with each other and the mental load of switching between projects is untenable.
That's kind of true, but it's not black and white.
For example, look at Golang. The syntax is very plain and it's by design so that everything looks the same.
Then take a look at Lisp. On the surface the syntax looks all the same but in reality, everyone can write their their own macros and people usually do. Then, you can barely understand what's going on if you are new to the codebase - but on the other hand, the flexibility is enormous.
Scala is somewhere in between. When you hire someone for Golang, you don't really need to make anything clear in terms of code style (I believe). In Scala (or Lisp) you should definitely clarify the style that you use. It's actually normal (I've hired pretty big number of Scala developers over my career and I have also rejected job offers due to the style the company uses which doesn't match what I like).
C++ probably is alike, but I don't really any C++ experience.
Scala is a lot more like lisp in this way (or actually, the C++ comparison is the much better one) than it is like go.
There are lots of ways to write Scala, to its detriment.
This isn't meant as a knock on Scala! It's a great language and in particular I think it's been influential on other newer languages. It's just that it does have this "multiple dialects" issue.
>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 [2].
It also has a nice bulti-in REPL system due to its very fast compilation and execution [3].
For an excellent overview of D programming language please check this presentation at ACCU conference [4].
The point of many scripting languages is quick tinkering, mucking with stuff in a REPL, on top of a complex contraption of already-live objects. This works well with duck typing. It does not work with nice static type inference, because once you change something high upstream, it potentially invalidates everything downstream, your entire current session you've spent an hour building.
I totally agree. I think it's simply because most of these projects are pretty much one-man efforts and implementing static typing is a lot more effort than dynamic typing.
I'd say F# is closer to filling that gap than OCaml. It's a bit less insistent on being functional and has a more familiar syntax. I find it more practical in general.
I somehow discovered F# by accident and it’s really an hidden gem.
Its ahead of its time in basically every aspect, it’s 100% compatible transparently with the whole C# ecosystem, it’s mature yet still evolving.
The type system is something I never saw before : creating types is so ergonomic and fast that you can create custom type for basically any value of your program without boilerplate if you want.
It’s really a refreshing language that anyone should try.
What I really love with it is that it’s hard to write (when you are learning it) but incredibly clear to read.
I'm curious what you have in mind when it comes to ways in which OCaml is insistent on being functional while F# isn't. After all, OCaml has mutable data structures, mutable record fields, for loops and so on. Is it just that more libraries assume immutability and use functional abstractions?
To be fair, my knowledge of F# is a bit basic, but I meant stuff like classes (including abstract ones), interfaces, and the ingrained interop with C#.
You are looking for Scala or F#, depending on your choice of ecosystem.
Both come with very powerful features, but you don't need to use them and you can use libraries accordingly. Especially Scala can be made to feel very similar to python
> For me the biggest gap in programming languages is a rust like language with a garbage collector, instead of a borrow checker.
I agree, though I often think Rust is probably good enough. You can use RC or grab a GC crate. It's not as ergonomic as just assuming all values are GCed, but I think it gives the flexibility and fast iteration of working in a GCed language.
Favors minimal text entry. You keep the type information in your head and enter fewer tokens. Historically you also reduced the work and improved responsiveness for the interpreter, which might have been running on an 8- or 16-bit computer at 5 MHz.
The documentation and integration with Rust for this amazing, well done! Like other commenters, I also wish it had better static typing and looked more like Elixir with anonymous sum types and template literal types.
The amount of scripting languages _for Rust_ is a symptom of how Rust fails to satisfy the need to write code with less strict requirements.
It makes perfect sense to use Rust as the main language for your application but have areas which are either in the prototype stage, need to be written quicker or which simply don't need the performance. But Rust does not offer a way to enter such a less strict context and such proposals keep getting shot down by the community, even when they are made from core members of the Rust team.
Contrast that with C# which has a dynamic keyword, allows enabling a checked context (not just in code where you can't miss it but also from csproj), has reflection, etc.
I really want Rust to succeed but sometimes the attitude borders on zealotry.
While I would like a Rust-like language that has those things, complaining that Rust, a compiled native language with no runtime whose closest competitor is C++, does not is a little strange to me.
Yes, it is very multi-paradigm and can be used in many domains, but it's not trying to be C# and it can't be C#. I would love to see Rust# as a language, but Rust itself cannot be that language.
Should new languages artificially restrict themselves based on the restrictions of their main competitor even if it's possible to serve a wider range of usecases?
Dynamic can be implemented in a compile-to-native lang. Contexts with different rules as well. Reflection support would likely have overhead which would need a granular opt in mechanism but is very likely possible.
Similarly many features rust is missing like compile time reflection, field in traits, ...
> Should new languages artificially restrict themselves based on the restrictions of their main competitor even if it's possible to serve a wider range of usecases?
Nope - and indeed, we're seeing Rust used in a more diverse set of applications than C++ (e.g. there are several Rust web frontend frameworks, it's a popular WASM language in general, etc)
However, Rust is targeting the same kind of general constraints as C++ for development and deployment, which means it can't add anything that would depend on a runtime or impose an undue burden on users. (Of course, C++ cheats in this regard - RTTI and exceptions - but Rust matches that, and doesn't go beyond.)
> Dynamic can be implemented in a compile-to-native lang.
Requires runtime functionality, and it's not really clear what the resulting semantics would be, anyway: aside from the usual type-safety concerns, how do you deal with lifetimes and other compile-time constraints?
> Contexts with different rules as well.
What kind of different rules? The problem is that any deviation from the rules needs to be reconciled at some point, and that reconciliation has to be watertight: you can't weaken the guarantees somewhere that interacts with safe Rust code, because the weakness you've introduced can spread. This is already a pretty significant issue with unsafe Rust.
Similarly, moving to a higher level of abstraction has similar issues: how do you reconcile the interactions of GC'd objects with the rest of Rust, which expects deterministic destruction and somewhat-predictable object lifetimes?
> Reflection support would likely have overhead which would need a granular opt in mechanism but is very likely possible.
> Similarly many features rust is missing like compile time reflection, field in traits, ...
I'll give you compile-time reflection; that would have been quite nice to have, but the Rust Foundation alienated the primary person with a plan (https://thephd.dev/i-am-no-longer-speaking-at-rustconf-2023), so who knows when we'll see the next proposal? I agree that it's a shame, but there's usually ways to work around it (proc macros can be used to patch over a lot of Rust's relative deficiencies)
In general, the borrow checker is the primary impediment to copying features from other languages; it's just generally non-trivial to fit them into the Rust paradigm without significant R&D. That's why I think a higher-level Rust would have to be a separate language, not an extension of Rust proper: resolving the collision of semantics between abstraction levels is just too difficult in the general case.
> I personally haven't found Rust that difficult to prototype in
Rust is actually a pretty nice language for prototyping IMO. I agree with your take - Rust has many escape hatches you can use to develop quickly. Then when it comes time to clean up, it's obvious where the deficiencies are (look for all the clones and unwraps, etc)
> I see the main benefit of these scripting languages as being able to write/run code at runtime
Thank you. Some commenters seem to think a scripting language somehow reveals some deficiency in the core language. Reality: not all code is available at compile time. Many applications need some way to inject code without recompiling.
Niko Matsakis made a proposal on his blog for opt-in contexts with relaxed rules (such as implicit conversions) and it was hated, at least on reddit. I doubt he would delete it but i can't find it now.
Maybe I'm a zealot, but I use Rust-script with cmd_lib. Rust-script lets you define the libraries at the top of the file (instead of in a Cargo file) and cmd_lib gives you macros to call commands directly almost like in Bash. Then you can iterate over the output way faster than in Bash. It recompiles after any changes, and subsequent runs just call the compiled executable. The downside is that the cache does grow, but it's not that noticeable.
I really like the idea of rust-script but last time I looked there didn't seem to be a good way to get rust-analyzer to work when writing a script. Maybe I'm a little too reliant on LSPs but I find writing Rust painful without it, has the situation improved at all since?
What are you rambling about, this is a sanboxed scripting language to allow your users to define customization at runtime. This has nothing to do with rust, it could be written in C or C++. You would not run random user provided C# in your application at runtime.
It is like saying browser should be coded in C# because C++ can't be use instead of JavaScript...
Since it's written in Rust, that's the easiest place to use the embedding API. https://koto.dev/docs/0.15/api/ I imagine one _could_ use it from C, but it wouldn't be as ergonomic as Lua's C API. And Lua in turn isn't a perfect match for embedding in Rust
I think it's just a convenient and popular language to experiment with.
For production systems, people just use Python + Rust when needing a balance between dynamism and strictness. The tooling to mix them is very mature and the communities are overlapping.
With uv becoming the defacto packaging solution for python, I expect the border to blur even more in the future.
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.
Should compare with Rhai (https://rhai.rs/)
I found rhai's syntax very straightforward, and I could almost accomplish my needs just by looking at some basic examples.
I use Rhai in wasm, and it can handle real-time audio blocks, which is really impressive:
https://glicol.org/tour#meta2
Rhai looks somehow more OO, and is somehow conceptually bigger, with function overloading, operator overloading, currying, etc. Koto looks more like FP an stream processing, with pervasive anonymous functions, very simple data structures, and an emphasis on iterators.
Rhai also offers some safety guarantees: no panics, no stack overflows, etc. Rhai seemingly requires slightly less ceremony when interfacing with Rust: direct use of many things, as opposed to implementing a trait to interact with Koto.
(Disclaimer: I spent 5 minutes skimming the docs of each.)
Isn't Rhai extremely slow? The website itself says that it's roughly 2x slower than Python3: https://rhai.rs/book/about/benchmarks.html. Apparently, Rhai doesn't even compile to bytecode and instead walks the AST! This doesn't sound like a language I would pick as for DSP...
On the other hand, you can always write your own Rhai interpreter if necessary. And if you restrict the language to a limited set of features, which you need to do anyway to keep it realtime-safe, you could even compile it to native code.
> and it can handle real-time audio blocks, which is really impressive:
Any scripting language can do this as long as you stick to operations that don't cause memory allocations, system calls or other non-realtime-safe operations.
For example, you can use Lua to write process functions for Pd objects: https://agraef.github.io/pd-lua/tutorial/pd-lua-intro.html#s...
The question is rather how much you can do in a given audio callback.
---
All that being said, Glicol is very cool!
You are absolutely right. Thanks for the correction and info!
I gave Lua a shot, but getting the toolchain set up in wasm was a hassle:
https://bytedream.github.io/litbwraw/introduction.html
So at least I can say Rhai has some advantages on syntax and compatibility with wasm
That's a valid point. Being native to the host language (Rust) is generally a big advantage.
I just don't really understand why Rhai uses an AST walking interpreter, that's basically the least efficient way of implement a scripting language. Once you have an AST, a byte code compiler/interpreter is not really hard to implement, so I'm wondering why they knowingly leave so much performance on the table...
Is koto any faster?
In my tests it's been ~1.5-2x faster than Rhai, but Koto's still some way behind Lua in benchmarks so I'm not trying to make a big claim here (although that said one of the reasons I started work on Koto was to avoid the runtime overhead of Lua <-> Rust conversions, e.g. Koto shares the same string representation as Rust, Koto lists are just wrapped `Vec`s, etc).
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.
I looked into Rhai but was disappointed that it doesn't have first class functions.
Koto creator here, nice surprise to see this on HN so I'm a bit late to the discussion. Happy to answer any questions!
Would you say Koto (or some direct competitors, for that matter), is viable to learn when I otherwise don't intend to learn Rust at all? But let's say, want to keep the option open to participate in Rust-based projects which support Koto et al.?
Yes I would certainly hope so, you shouldn't need to know any Rust if you want to learn Koto. The guide assumes that the reader has some general experience with programming, but not from using any specific language.
https://koto.dev/docs/next/language/
What are your plans for language and in-language library compatibility?
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
Sorry, I meant the Koto language and built-in library compatibility story. Whats on the roadmap for a 1.0 and will you allow a 2.0? One of my annoyances with Tcl and Lua is their breaking changes would be pushed into my application and I'd have to decide what version of the language to target and have a plan for changing it.
I'm fine with the Rust API breaking compatibility.
I can't imagine wanting a 2.0 release, I'd rather take longer to get to 1.0 to reduce the risk of needing it, and anyway I'd much prefer to aim for something like Rust's editions, allowing the language to evolve without the whole community needing to migrate.
Before 1.0 I'd want to address at least:
- the FFI / package management topics mentioned above
- async support: https://github.com/koto-lang/koto/issues/277
- extend the parser to support an autoformatter: https://github.com/koto-lang/koto/issues/286
...and then have a larger number of people using it in projects without major issues coming up for a good while, e.g. a year+.
Very cool. I really like the idea of implementing higher level features as extensions on top of a smaller core. I wish real scripting languages like this were more common and in use. Lua comes to mind when thinking about a generic scripting language, but even that is not that widespread.
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 agree. Emacs and its Emacs Lisp are one of the best examples of this design. Thank you for the links.
As an avid Emacs user, can't but agree :)
Recently I've started evaluating new languages in terms of "how difficult would it be to read working code in this language, written by an insane person".
After looking at this for 5 minutes it seems it is better than rhai according to my metric. But not necessarily better than lua.
Haha well I'm sure if you put your mind to it you could create some madness in Koto!
If it helps here's a git blame helper script I made for Helix (as an example of practical code without any effort put in to making it readable for others): https://github.com/irh/dotfiles/blob/main/scripts/.scripts/g...
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've used OpenResty extensively which is basically just nginx + luajit with a lot of additional APIs and features. The nginx-lua-module is available separately from the OpenResty distribution of nginx, so you can just install and run it as a dynamic nginx module.
Indeed, OpenResty comes with Lua and LuaJIT built-in. Earlier version where we've implemented all in Lua, had no need for that. However, as we went fro Lua to Rust (and speed up by using only 15% CPU comparing to the Lua), we added that Lua interface support to the rust, and it worked like a charm.
If I was going to chose a scripting language for rust I'd pick nushell's syntax. Nushell is an amazing shell and it's syntax is one of the reasons why.
Would this compile fast enough to be used in shell scripts? #/usr/bin/env koto
Yes! I'm using it for adding commands to Helix.
e.g. https://github.com/irh/dotfiles/blob/main/scripts/.scripts/t...
Koto means big brother in Fulani (a West African language).
It's named after https://en.wikipedia.org/wiki/Koto_(instrument)
Elegant syntax!
> Syntax: [...] minimizing visual distractions, while also managing to avoid inexpressive terseness.
Nice! Now, if it only had type support.
It says Coffeescript and Moonscript influenced Koto's syntax, which is a little worrying. IMO those languages are a little too flexible and sail too close to ambiguity - very small changes to code can sometimes radically change its meaning.
Edit: Sure enough, "whitespace is important in Koto, and because of optional parentheses, `f(1, 2)` is not the same as `f (1, 2)`. The former is parsed as a call to f with two arguments, whereas the latter is a call to f with a tuple as the single argument."
Oh it has optional parentheses? Into the trash it goes.
I'm guessing because "it's cleaner/simpler", but that's a shallow understanding of those words. Just because there are two characters fewer on the screen doesn't make the code simpler. Simple semantics are what you should aim for and inconsistencies like these throw a wrench into that.
For example, strings in JSON vs YAML. Isn't it "simpler" to not have to quote every string? So long as your string isn't "no" that may be true. So now instead of a simple mental model of "every string must be quoted" it's "strings don't need quotes except for these specific exceptions that cause issues: <list>". So much simpler... sigh.
> Oh it has optional parentheses? Into the trash it goes.
<virtual high five>
What I've had in mind with Koto is that when I need strictness and precision I'll generally be using Rust, and Koto is more intended for another aspect of programming where I want things to be much more fluid and easy-going.
My thinking is that the potential footgun here is outweighed by the win of paren-free calls for quick scripting / rapid iteration, but it certainly counts towards the language strangeness budget [1] so I figured it was worth pointing out in the guide.
[1] https://steveklabnik.com/writing/the-language-strangeness-bu...
Oh, the usual Coffeescript footguns :(
One of the problems of terse syntaxes is that one typo away from a syntactically valid program lies another syntactically valid program with entirely different semantics.
I prefer a syntax that has enough "gaps" between syntactic constructs, so that a single typo usually leads to an obvious syntax error. In this regard, Python or Java or TS are comfortable, Haskell or Lisp or C are okay, and Coffescript or Scala or C++ are terrible.
Can "always (or never) use parentheses for function calls" be enforced..?
Koto's dynamically typed, but optional type checks were introduced in 0.15: https://koto.dev/docs/0.15/language/#type-checks
It has optional types
It's reminds me of Lua for C++, am I correct?
Yes, I was missing a 'companion language' for Rust similar to Lua for C and C++, I tried Lua bindings and other Rusty scripting languages but felt like starting a new project would be worthwhile.
Is this the equivalent of Lua for Rust?
Yes that's essentially where it started, although it feels quite different to use now.
Koto? Like the Italo-Disco band?
Or like the Japanese musical instrument? https://en.wikipedia.org/wiki/Koto_(instrument)
Yes it's named after the instrument, although I'm happy to hear about the Italo disco connection =)
It seems every scripting language does duck/dynamic typing (as far as I can tell this applies to Koto).
I don’t understand why… inferred typing is nearly as easy to use while being more robust.
For me the biggest gap in programming languages is a rust like language with a garbage collector, instead of a borrow checker.
Rust has a lot of features that should be strongly considered for the next generation of programming languages such as
result/sum types
Inferred typing
Not object oriented or overly prescriptive with functional programming.
I think the closest language to filling that gap is occaml (I am not familiar with it).
I have coworker's that are more skilled in domain logic that can write basic self contained programs, but stuff like traits, OOP functional programming is a bridge too far.
I feel like a language that fills that gap could be useful, context is a manufacturing ERP system.
I think you really are describing ocaml, which is a great language, although its ecosystem isn't the best. It probably inspired most of the features you mentioned in rust. It also supports OOP (hence the O) but it's easy to avoid.
That said, I wouldn't compare it to scripting languages. The lack of implicit conversions / traits / ad-hoc polymorphism means it's not that convenient for scripting.
Fsharp, which originally was ocaml on dotnet, can also be run as scripts. It is a really practical way to start a project. I blogged about it here: https://asfaload.com/blog/fsharp-fsx-starting-point/
F# was never really "OCaml on .NET", though, not really. ML on .NET, sure, but it is (and always has been) missing OCaml's most interesting features, such as functors and OO with inferred row-types.
It probably was too much of a shortcut, thanks for the correction.
They have kinda positioned themselves that way and had (have?) syntactic compatibility with a subset of OCaml. And OCaml is probably the least obscure of the ML language family, so it's not exactly surprising.
Fsharp is such a nice languange. Such a shame that I never seem to get the light it deserves. Between the alternative light syntax, type providers and first class "scripting" mode supported it really was a great middle point between fully scripting language and fast prototyping and full blow projects
Ruby does very little implicit type conversion and is great for scripting. I think implicit type conversion is not required or even a good thing for scripting languages.
Implicit conversion is not obviously that convenient for scripting. The JS community has largely moved to anti-recommend implicit conversion, such as by basically striking `==` from their vocabulary.
What makes OCaml inconvenient for scripting is how difficult it is to run code that uses some external libraries. You basically need to create a whole project structure with several config files, which creates a lot of friction compared to `import numpy as np`.
Nim was great along these lines when I tried it. But that was before the v2.0 which apparently was accompanied by drama and a fork.
What happened?
If I remember correctly, main reason for forking was that Nim BDFL was writing lazy commit messages and old codebase was hard to navigate around. Some small part of community forked the language and trying to rewrite the compiler. According to readme they're not trying to replace Nim, but to create new language with Nim as base. Not sure how usable it's right now or will it ever be.
I also want to point out that Araq quickly took the criticism and his commits look a lot better now.
Also, core Nim team is currently working on their own rewrite of Nim compiler, called Nimony, that should evolve into Nim 3.
Refs:
fork - https://github.com/nim-works/nimskull
commit 'drama' - https://news.ycombinator.com/item?id=32021299#32023998
nimony - https://github.com/nim-lang/nimony
> It seems every scripting language does duck/dynamic typing (as far as I can tell this applies to Koto).
It looks like Koto supports type hints - not sure if these are checked at compile-time, run-time, or both.
> I don’t understand why… inferred typing is nearly as easy to use while being more robust.
Is it (nearly as easy to use)? Every static type system seems to have special cases and exceptions which are avoided by dynamic typing. I'd love to find one that's actually simple.
Also, it's definitely not nearly as easy to implement - which is important for a language being designed and built by a small team and targeting a lightweight runtime.
> Also, it's definitely not nearly as easy to implement
I think this is the real reason why there are so many dynamic language implementations. If you want to implement a dynamic language, you just slap a type tag on your runtime objects and boom, your "type system" is done.
Dynamic languages get a lot of expressiveness "for free", whereas having a really expressive static type system requires a lot of work. It's not that hard to get a type system on the level of C, but if the language is interpreted, it's still going to be pretty slow.
I do think there can be benefits to having typing in a scripting language (and not a bolted-on type system like typescript or mypy). It's much easier to work with an FFI if the type system of the scripting language maps closely to the implementation language. It also does make it much easier to optimize the language down the line, if that becomes a priority. Making a fully dynamic language efficient is very, very difficult.
> not sure if these are checked at compile-time, run-time, or both
It looks like Koto only checks types at run-time. That means its type annotations are essentially shorthand for something like Python's `if not isinstance(...): raise TypeError`.
Yes that's right, they're checked at runtime (with the option to disable the checks if the performance cost is a concern) and failed checks simply throw exceptions.
The hints aren't used for other purposes at compile time yet, but they could enable some warnings.
> 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.
Gradual typing can offer us the benefits of both worlds.
> 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]. Type inference with subtyping is not a solved problem - these developments are big steps forward, but there are still open problems under research.
Subtyping doesn't imply object-oriented. Structural typing (ie "static duck 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
> Gradual typing can offer us the benefits of both worlds.
Gradual typing has much the same overhead as other kinds of dynamic typing. It's broadly appropriate as part of the interface between separately-developed software components, and not very much otherwise.
Gradual typing is static typing augmented with a known static type `dynamic`, and some rules by which conversions to/from `dynamic` are statically checked, called consistency.
A program in a gradually typed language which does not use `dynamic` is fully statically checked and has no overheads. The overheads only appear when `dynamic` is used.
This is why it offers the best of both worlds. We get static typing everywhere where we're not using dynamic, and when we do use dynamic, we can basically use it however we want and have the benefits of dynamic typing, because from the static perspective, dynamic ~ dynamic, regardless of what the runtime type is.
The important innovation is that consistency (~) is not transitive - so it doesn't allow us to implicitly convert one type to another - only conversions to/from dynamic are implicit, and other conversions must be done explicitly.
Obviously, this provides an "escape hatch" from static typing where we do use it - we can get around some static type check by casting to/from dynamic explicitly, but this works out well in practice.
C# is an example of a gradually typed language since v4 which introduced `dynamic`.
Haskell is close , in that it has the type `Data.Dynamic`, but it doesn't support implicit conversions to/from it, which would be possible if it had a consistency rule. We have to do the conversions explicitly.
https://jsiek.github.io/home/WhatIsGradualTyping.html
I'd keep an eye on Roc https://www.roc-lang.org/
Also, Elixir is working on gradual types, which is something I would keep an eye on. https://hexdocs.pm/elixir/main/gradual-set-theoretic-types.h...
https://www.youtube.com/watch?v=giYbq4HmfGA&t=1s
roc as a language looks really interesting but its by elm devs and I don't have much confidence in their ability to handle the transition to being a widely used language with all the cultural shifts that requires.
I hear ya, but Elm allowed me to eject out of the javascript churn for the past 7 years while still building some slick UIs that basically never fall over. I literally don’t know or care what the current hotness is in javascript, and that’s how I like it.
If roc ends up being even close to that productive for me, I really don’t care how widespread it is. I like these thoughtful unrushed languages that I can support for years without stress.
> but Elm allowed me to eject out of the javascript churn for the past 7 years while still building some slick UIs that basically never fall over.
Thats the real tragedy. Elm was a good language but the culture around it means it could never achieve critical adoption. It is great technology for building frontends but how easily will I be able to maintain that app as the web changes over the years?
I can only speak from experience, but it's been absolutely solid, incredibly easy to maintain (because there's been so little change), and I don't feel like I missed out on any groundbreaking front end tech at all. I literally have some elm code that's been in production doing it's thing for 7+ years without any maintenance, but more importantly it's not scary to open it up and make changes 7 years later either.
I doubt it's a silver bullet for everyone, but it's been phenomenal for me as a solo dev w/ my own product. I feel so much better about my elm code than I do about my React code. I have to do all the other things, like marketing, sales, training, support, back end, etc. It's nice to launch a UI and know it'll last (and also that it's easy to refactor and augment too!). Elm has turned my into a statically typed functional fanboy. It's been a gateway drug to Haskell, OCaml, and F#.
I see the same promise with Roc, although I bet Richard will update it more frequently than Evan w/ elm after 1.0.
which culture and why it cased problems ? honest question, I barely heard of elm
It's created by Richard Feldman who was big in the Elm community, but I think most contributors to the Roc compiler have only used Elm a bit or have never used it.
FYI roc is in the early stages of a complete rewrite from Rust to Zig and... that may take a while. I'm messing with Nim in the meantime for some commandline tooling
I want Clojure on Rust, or a similar LISP.
Such a great programming paradigm that sadly has few breakout successes
I'm having a hard time picturing that. What would it look like?
Like Clojure having access to the Java ecosystem it would need access to the Rust ecosystem I imagine.
I otherwise am unsure what you mean
Rust will probably gain support for "pluggable" and optional garbage collectors as part of its upcoming local allocators API. This will ultimately give devs the best of both choices - use tracing GC where it's actually needed (because you're working with totally general graph-like data and that's the only feasible memory management strategy) and manual memory management (supplemented by RAII and reference counting) elsewhere - for other parts of the program that don't have to manage general "spaghetti" graphs. Unfortunately the way GC's trace objects and collect garbage varies wildly among implementations, so there's no easy way to standardize a "generic" interface to pluggable garbage collection, that all custom crates might be expected to tap into by default. But other uses should be quite feasible.
> Rust will probably gain support for "pluggable" and optional garbage collectors as part of its upcoming local allocators API.
Source? AFAIK there's no confirmed upcoming allocators APIs, and even if there was they would just allow reusing the builtin `Box`/`Vec`/etc etc with custom allocators. This is not much different than what you could do with a custom type, so I find it hard to believe it would allow garbage collectors that are not possible right now.
I'm not sure what you're getting at here but none of the features you mentioned are groundbreaking anymore? At least in Swift:
result/sum types = enums whose cases have associated values
inferred typing = Swift "type inference"
Not object oriented or overly prescriptive with functional programming. = Uh, yes
Those features map to Kotlin too
I don't think you're disagreeing with parent. I also think these features are not groundbreaking and should be considered table stakes for any new/sane language.
I am aware of 3 “rust inspired scripting” languages that have dynamic types.
Rhai Rune Dyon
Mun is not dynamic, however it does not have string support afaik.
Kotlin and Swift may be better candidates than these scripting languages for my imagined usecase.
Come to think of it, maybe I don’t have a point other then there is so many scripting language’s inspired by rust that is dropping a major convenience feature, that I am surprised is negotiable (inferred typing ).
Rust itself has dynamic types via the Any trait and &dyn Any variables. They are not the default of course, but they're available should you really want them. IIRC C# works similarly, only its feature is called Dynamic instead, or something like that.
They're rather different: In Rust types only exist at compile time; dyn Any is a normal trait object, so you can only call the trait's methods. With C#'s dynamic, you can call arbitrary methods and access any fields with type checking of those accesses being delayed until runtime, which works because types exist at runtime too.
Rust's dyn Any corresponds better to C#'s Object; dynamic exists to interface with dynamic languages and is rarely used.
Yeah I think Kotlin is quite close to the OP's description. But it is perhaps more focused on object orientation than they would like, and also only runs on the JVM.
But if I were to create a self-contained (that is, non-JVM) "Rust-like but with GC", I think it would look a lot like Kotlin.
I haven't tried it but Kotlin/Native targets platforms like iOS, macOS, Linux, Windows, etc. There's also Kotlin/JS for JavaScript, and a WASM target with limitations.
It's been a few years since I tried Kotlin/Native but even then it was pretty good.
Neat. I didn't know that.
Rather Scala but leaving out a few parts. Kotlin is very very OOP focussed and comes with a lot of baggage from Java.
Rust-like but with GC is already Scala. The reason is that Scala (unlike Kotlin) focusses on immutability, which makes it more similar to Rust. It's actually even easier to use (no borrow checker) but at the cost of performance.
After Rust, I would see F# as the next closest language, quite far before Kotlin.
> Rust-like but with GC is already Scala.
Maybe like a third of Scala. But yeah, Scala has a lot of good parts, it's also just a huge surface area. I agree that you could pluck a subset out of Scala and make it this "Rust-like but with GC" language.
But it's nigh-impossible to actually make that "only use this subset" idea work in practice, because it just ends up being a bikeshed.
But you're right that the same can be said of the OO focus of Kotlin.
I think it absolutely works in practice. You have to pick the right libraries though. I would start with https://github.com/com-lihaoyi which basically follows that style.
> But you're right that the same can be said of the OO focus of Kotlin.
The difference is that Scala focuses on immutability, which makes the experience much closer to Rust than to Java. Whereas Kotlin does it exactly like Java does. Were Kotlin to focus on immutability like Scala does, than I would recommend Kotlin over Scala for what OP asked for.
A language is a shared way to communicate. If you start picking and choosing the parts of a language you like, you can no longer communicate effectively with the rest of its speakers, er, coders.
That's why C++ is so badly designed, you can do anything in it, so people do and no two C++ codebases are the same. Your codebase at work is written one way, the libraries it uses in another, your personal projects use something else entirely. It's a huge mess where nothing is compatible with each other and the mental load of switching between projects is untenable.
That's kind of true, but it's not black and white.
For example, look at Golang. The syntax is very plain and it's by design so that everything looks the same.
Then take a look at Lisp. On the surface the syntax looks all the same but in reality, everyone can write their their own macros and people usually do. Then, you can barely understand what's going on if you are new to the codebase - but on the other hand, the flexibility is enormous.
Scala is somewhere in between. When you hire someone for Golang, you don't really need to make anything clear in terms of code style (I believe). In Scala (or Lisp) you should definitely clarify the style that you use. It's actually normal (I've hired pretty big number of Scala developers over my career and I have also rejected job offers due to the style the company uses which doesn't match what I like).
C++ probably is alike, but I don't really any C++ experience.
Scala is a lot more like lisp in this way (or actually, the C++ comparison is the much better one) than it is like go.
There are lots of ways to write Scala, to its detriment.
This isn't meant as a knock on Scala! It's a great language and in particular I think it's been influential on other newer languages. It's just that it does have this "multiple dialects" issue.
Check out Wren.
https://wren.io/
Written by Bob Nystrom, author of Crafting Interpretors.
Thanks for your suggestion.
At first glance it appears to be object oriented, which is against preference but not a deal breaker.
However error case looks to be try catch which is a deal breaker.
> However error case looks to be try catch which is a deal breaker
Wren uses coroutines ("fibers") for error handling, which is unusual. But yes, ultimately it does seem to be equivalent to try-catch.
Last release was four years ago.
Last commit was 3 weeks ago...
Besides, it's "done" let it be done.
Wren is dynamically-typed, though
You're describing Gleam
https://gleam.run
Can you easily embed it though? Looks like it depends on Erlang which means the answer is likely no.
It also compiles to Javascript, which runs in a lot of places (to say the least). For WebAssembly, see my other comment about Porffor
Javascript isn't the nicest thing to embed either tbh. It looks like a nice language but it's clearly not in the same space as Lua or Rhai.
Thanks looks great so far.
Also has pattern matching which I should also have mentioned in my top level post.
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/
After learning Erlang, it was painful to go back to any language which didn’t offer pattern matching. Such a great language feature.
>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 [2].
It also has a nice bulti-in REPL system due to its very fast compilation and execution [3].
For an excellent overview of D programming language please check this presentation at ACCU conference [4].
[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/...
[3] Why I use the D programming language for scripting (2021):
https://news.ycombinator.com/item?id=36928485
[4] How DLang Improves my Modern C++ and Vice Versa - Mike Shah - ACCU 2024:
https://youtu.be/CnKsOak0DHU
The point of many scripting languages is quick tinkering, mucking with stuff in a REPL, on top of a complex contraption of already-live objects. This works well with duck typing. It does not work with nice static type inference, because once you change something high upstream, it potentially invalidates everything downstream, your entire current session you've spent an hour building.
"Everything should be built top-down, except for the first time" (See #15 in https://www.cs.yale.edu/homes/perlis-alan/quotes.html)
For one thing, inferred types may feel easy to use when implemented (well) but they are not easy to implement.
I totally agree. I think it's simply because most of these projects are pretty much one-man efforts and implementing static typing is a lot more effort than dynamic typing.
I'd say F# is closer to filling that gap than OCaml. It's a bit less insistent on being functional and has a more familiar syntax. I find it more practical in general.
I somehow discovered F# by accident and it’s really an hidden gem.
Its ahead of its time in basically every aspect, it’s 100% compatible transparently with the whole C# ecosystem, it’s mature yet still evolving.
The type system is something I never saw before : creating types is so ergonomic and fast that you can create custom type for basically any value of your program without boilerplate if you want.
It’s really a refreshing language that anyone should try.
What I really love with it is that it’s hard to write (when you are learning it) but incredibly clear to read.
Also the Units of Measure are a great feature. I think they're a zero-cost abstraction that Rust users love to mention.
I'm curious what you have in mind when it comes to ways in which OCaml is insistent on being functional while F# isn't. After all, OCaml has mutable data structures, mutable record fields, for loops and so on. Is it just that more libraries assume immutability and use functional abstractions?
To be fair, my knowledge of F# is a bit basic, but I meant stuff like classes (including abstract ones), interfaces, and the ingrained interop with C#.
Haxe is the best fit for me, think of typescript with functional patterns and inferred typing. Written in ocaml and inspired by the language
check out Borgo https://github.com/borgo-lang/borgo It is Go with algebraic datatypes!
You are looking for Scala or F#, depending on your choice of ecosystem.
Both come with very powerful features, but you don't need to use them and you can use libraries accordingly. Especially Scala can be made to feel very similar to python
> For me the biggest gap in programming languages is a rust like language with a garbage collector, instead of a borrow checker.
I agree, though I often think Rust is probably good enough. You can use RC or grab a GC crate. It's not as ergonomic as just assuming all values are GCed, but I think it gives the flexibility and fast iteration of working in a GCed language.
Rust is not as good as D in this domain in which D is designed for this, since it's GC by default, please see my other comments.
> I don't understand why.
Favors minimal text entry. You keep the type information in your head and enter fewer tokens. Historically you also reduced the work and improved responsiveness for the interpreter, which might have been running on an 8- or 16-bit computer at 5 MHz.
You are describing Nim.
You could probably write F# in the style that you describe (it is a descendant of OCaml).
> 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
GC, sum types, result/option types, interfaces, no OOP, fast compilation.
MoonBit lang is probably closer. Beautiful language.
The documentation and integration with Rust for this amazing, well done! Like other commenters, I also wish it had better static typing and looked more like Elixir with anonymous sum types and template literal types.
Jabdah
Strange voice coming from the space!
The amount of scripting languages _for Rust_ is a symptom of how Rust fails to satisfy the need to write code with less strict requirements.
It makes perfect sense to use Rust as the main language for your application but have areas which are either in the prototype stage, need to be written quicker or which simply don't need the performance. But Rust does not offer a way to enter such a less strict context and such proposals keep getting shot down by the community, even when they are made from core members of the Rust team.
Contrast that with C# which has a dynamic keyword, allows enabling a checked context (not just in code where you can't miss it but also from csproj), has reflection, etc.
I really want Rust to succeed but sometimes the attitude borders on zealotry.
While I would like a Rust-like language that has those things, complaining that Rust, a compiled native language with no runtime whose closest competitor is C++, does not is a little strange to me.
Yes, it is very multi-paradigm and can be used in many domains, but it's not trying to be C# and it can't be C#. I would love to see Rust# as a language, but Rust itself cannot be that language.
Should new languages artificially restrict themselves based on the restrictions of their main competitor even if it's possible to serve a wider range of usecases?
Dynamic can be implemented in a compile-to-native lang. Contexts with different rules as well. Reflection support would likely have overhead which would need a granular opt in mechanism but is very likely possible.
Similarly many features rust is missing like compile time reflection, field in traits, ...
> Should new languages artificially restrict themselves based on the restrictions of their main competitor even if it's possible to serve a wider range of usecases?
Nope - and indeed, we're seeing Rust used in a more diverse set of applications than C++ (e.g. there are several Rust web frontend frameworks, it's a popular WASM language in general, etc)
However, Rust is targeting the same kind of general constraints as C++ for development and deployment, which means it can't add anything that would depend on a runtime or impose an undue burden on users. (Of course, C++ cheats in this regard - RTTI and exceptions - but Rust matches that, and doesn't go beyond.)
> Dynamic can be implemented in a compile-to-native lang.
Requires runtime functionality, and it's not really clear what the resulting semantics would be, anyway: aside from the usual type-safety concerns, how do you deal with lifetimes and other compile-time constraints?
> Contexts with different rules as well.
What kind of different rules? The problem is that any deviation from the rules needs to be reconciled at some point, and that reconciliation has to be watertight: you can't weaken the guarantees somewhere that interacts with safe Rust code, because the weakness you've introduced can spread. This is already a pretty significant issue with unsafe Rust.
Similarly, moving to a higher level of abstraction has similar issues: how do you reconcile the interactions of GC'd objects with the rest of Rust, which expects deterministic destruction and somewhat-predictable object lifetimes?
> Reflection support would likely have overhead which would need a granular opt in mechanism but is very likely possible.
If you're already committing to a granular opt-in mechanism, you might as well use a library, which offers you more options: https://docs.rs/bevy_reflect/latest/bevy_reflect/
> Similarly many features rust is missing like compile time reflection, field in traits, ...
I'll give you compile-time reflection; that would have been quite nice to have, but the Rust Foundation alienated the primary person with a plan (https://thephd.dev/i-am-no-longer-speaking-at-rustconf-2023), so who knows when we'll see the next proposal? I agree that it's a shame, but there's usually ways to work around it (proc macros can be used to patch over a lot of Rust's relative deficiencies)
Field-in-traits has been discussed before, but is complicated due to the borrow checker: https://internals.rust-lang.org/t/fields-in-traits/6933/1
In general, the borrow checker is the primary impediment to copying features from other languages; it's just generally non-trivial to fit them into the Rust paradigm without significant R&D. That's why I think a higher-level Rust would have to be a separate language, not an extension of Rust proper: resolving the collision of semantics between abstraction levels is just too difficult in the general case.
Would you be able to share examples of these "shot down proposals"?
I personally haven't found Rust that difficult to prototype in, when I need to I just liberally use clone/Arc/RefCell.
I see the main benefit of these scripting languages as being able to write/run code at runtime, e.g. live coding music or mods for video games.
> I personally haven't found Rust that difficult to prototype in
Rust is actually a pretty nice language for prototyping IMO. I agree with your take - Rust has many escape hatches you can use to develop quickly. Then when it comes time to clean up, it's obvious where the deficiencies are (look for all the clones and unwraps, etc)
> I see the main benefit of these scripting languages as being able to write/run code at runtime
Thank you. Some commenters seem to think a scripting language somehow reveals some deficiency in the core language. Reality: not all code is available at compile time. Many applications need some way to inject code without recompiling.
Niko Matsakis made a proposal on his blog for opt-in contexts with relaxed rules (such as implicit conversions) and it was hated, at least on reddit. I doubt he would delete it but i can't find it now.
Maybe I'm a zealot, but I use Rust-script with cmd_lib. Rust-script lets you define the libraries at the top of the file (instead of in a Cargo file) and cmd_lib gives you macros to call commands directly almost like in Bash. Then you can iterate over the output way faster than in Bash. It recompiles after any changes, and subsequent runs just call the compiled executable. The downside is that the cache does grow, but it's not that noticeable.
I really like the idea of rust-script but last time I looked there didn't seem to be a good way to get rust-analyzer to work when writing a script. Maybe I'm a little too reliant on LSPs but I find writing Rust painful without it, has the situation improved at all since?
Nah, but that issue's to do with rust-analyzer looking for a Cargo file. Some people have apparently got around it by making a file.
You're right that it would be great with full LSP support, but for quick scripting, I mostly just want a linter.
What are you rambling about, this is a sanboxed scripting language to allow your users to define customization at runtime. This has nothing to do with rust, it could be written in C or C++. You would not run random user provided C# in your application at runtime.
It is like saying browser should be coded in C# because C++ can't be use instead of JavaScript...
Since it's written in Rust, that's the easiest place to use the embedding API. https://koto.dev/docs/0.15/api/ I imagine one _could_ use it from C, but it wouldn't be as ergonomic as Lua's C API. And Lua in turn isn't a perfect match for embedding in Rust
It literally says "for Rust applications" on its front page.
Your tone is insulting and has no place in technical discussions.
Describing rust programmers as "zealots" also has no place in a technical discussion.
Or like saying that C++ was somehow deficient just because NodeJS had to be created in order to script v8.
> Contrast that with C# which has a dynamic keyword
`dynamic` has a very narrow use-case and generally shouldn't be used at all (even when prototyping)
I believe it was introduced to make working with poorly designed external libraries easier (e.g. Windows/Office libs)
I think it's just a convenient and popular language to experiment with.
For production systems, people just use Python + Rust when needing a balance between dynamism and strictness. The tooling to mix them is very mature and the communities are overlapping.
With uv becoming the defacto packaging solution for python, I expect the border to blur even more in the future.
We need LuaJIT in Rust.
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
[1] https://tinysse.com/