The Koto Programming Language

by virtualritz • 1 year ago

214 149 1 year ago

martin-t4• 1 year ago

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.

Sytten• 1 year ago

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...

01HNNWZ0MV43FF• 1 year ago

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

benwilber03• 1 year ago

Or like saying that C++ was somehow deficient just because NodeJS had to be created in order to script v8.

martin-t4• 1 year ago

It literally says "for Rust applications" on its front page.

Your tone is insulting and has no place in technical discussions.

Onavo• 1 year ago

We need LuaJIT in Rust.

benwilber03• 1 year ago

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/

Philpax2• 1 year ago

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.

martin-t4• 1 year ago

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, ...

jakkos2• 1 year ago

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.

perrygeo• 1 year ago

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.

martin-t4• 1 year ago

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.

HKH22• 1 year ago

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.

jakkos2• 1 year ago

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?

hypeatei• 1 year ago

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)

BiteCode_dev• 1 year ago

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.

mostafah2• 1 year ago

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.

nine_k6• 1 year ago

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/

mostafah2• 1 year ago

I agree. Emacs and its Emacs Lisp are one of the best examples of this design. Thank you for the links.

fstarship4• 1 year ago

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.

dustbunny2• 1 year ago

Check out Wren.

https://wren.io/

Written by Bob Nystrom, author of Crafting Interpretors.

fstarship4• 1 year ago

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.

pansa25• 1 year ago

Wren is dynamically-typed, though

sramsay• 1 year ago

Last release was four years ago.

oDot3• 1 year ago

You're describing Gleam

https://gleam.run

fstarship4• 1 year ago

Thanks looks great so far.

Also has pattern matching which I should also have mentioned in my top level post.

IshKebab3• 1 year ago

Can you easily embed it though? Looks like it depends on Erlang which means the answer is likely no.

letmeinhere• 1 year ago

For one thing, inferred types may feel easy to use when implemented (well) but they are not easy to implement.

rapind3• 1 year ago

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

no_wizard2• 1 year ago

I want Clojure on Rust, or a similar LISP.

Such a great programming paradigm that sadly has few breakout successes

cultofmetatron2• 1 year ago

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.

ossopite2• 1 year ago

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.

nerdponx• 1 year ago

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.

threatofrain• 1 year ago

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.

raphinou2• 1 year ago

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/

jeltz• 1 year ago

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.

xigoi• 1 year ago

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`.

rTX5CMRXIfFG• 1 year ago

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

sanderjd4• 1 year ago

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.

fstarship4• 1 year ago

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 ).

madeofpalk• 1 year ago

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.

chris_pie3• 1 year ago

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.

pjerem• 1 year ago

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.

ossopite2• 1 year ago

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?

haxiomic• 1 year ago

Haxe is the best fit for me, think of typescript with functional patterns and inferred typing. Written in ocaml and inspired by the language

camdenreslink• 1 year ago

You could probably write F# in the style that you describe (it is a descendant of OCaml).

pansa25• 1 year ago

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.

pansa25• 1 year ago

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`.

tuveson• 1 year ago

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.

IshKebab3• 1 year ago

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.

notnullorvoid• 1 year ago

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.

teleforce2• 1 year ago

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.

valenterry4• 1 year ago

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

zozbot2343• 1 year ago

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.

SkiFire13• 1 year ago

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.

simon_void• 1 year ago

check out Borgo https://github.com/borgo-lang/borgo It is Go with algebraic datatypes!

beagle3• 1 year ago

You are describing Nim.

mirekrusin• 1 year ago

MoonBit lang is probably closer. Beautiful language.

teleforce2• 1 year ago

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

nine_k6• 1 year ago

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)

sparkie2• 1 year ago

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

zozbot2343• 1 year ago

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.

amedvednikov• 1 year ago

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.

egl2020• 1 year ago

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.

brookritz• 1 year ago

Jabdah

sagacity• 1 year ago

Strange voice coming from the space!

tzury2• 1 year ago

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...

benwilber03• 1 year ago

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.

tzury2• 1 year ago

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.

chaosprint2• 1 year ago

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

nine_k6• 1 year ago

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.)

spacechild13• 1 year ago

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!

chaosprint2• 1 year ago

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

thayne• 1 year ago

Is koto any faster?

0x3444ac53• 1 year ago

I looked into Rhai but was disappointed that it doesn't have first class functions.

cp3io• 1 year ago

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.

esafak• 1 year ago

Would this compile fast enough to be used in shell scripts? #/usr/bin/env koto

irh13• 1 year ago

Yes! I'm using it for adding commands to Helix.

e.g. https://github.com/irh/dotfiles/blob/main/scripts/.scripts/t...

mentalgear• 1 year ago

Syntax: [...] minimizing visual distractions, while also managing to avoid inexpressive terseness.

Nice! Now, if it only had type support.

pansa25• 1 year ago

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."

nine_k6• 1 year ago

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.

Mawr2• 1 year ago

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.

irh13• 1 year ago

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...

pepa65• 1 year ago

Can "always (or never) use parentheses for function calls" be enforced..?

iTokio• 1 year ago

It has optional types

irh13• 1 year ago

Koto's dynamically typed, but optional type checks were introduced in 0.15: https://koto.dev/docs/0.15/language/#type-checks

seivan• 1 year ago

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.

amadoury• 1 year ago

Koto means big brother in Fulani (a West African language).

spacechild13• 1 year ago

It's named after https://en.wikipedia.org/wiki/Koto_(instrument)

replwoacause• 1 year ago

Elegant syntax!

fithisux• 1 year ago

Koto? Like the Italo-Disco band?

nine_k6• 1 year ago

Or like the Japanese musical instrument? https://en.wikipedia.org/wiki/Koto_(instrument)

irh13• 1 year ago

Yes it's named after the instrument, although I'm happy to hear about the Italo disco connection =)

account-5• 1 year ago

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.

irh13• 1 year ago

Koto creator here, nice surprise to see this on HN so I'm a bit late to the discussion. Happy to answer any questions!

riidom• 1 year ago

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.?

irh13• 1 year ago

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/

epage2• 1 year ago

What are your plans for language and in-language library compatibility?

irh13• 1 year ago

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

shahriarhus• 1 year ago

It's reminds me of Lua for C++, am I correct?

irh13• 1 year ago

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.

f18m• 1 year ago

Is this the equivalent of Lua for Rust?

irh13• 1 year ago

Yes that's essentially where it started, although it feels quite different to use now.

aerzen• 1 year ago

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.

irh13• 1 year ago

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...

The Koto Programming Language

Related Stories