Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Koto Programming Language

koto.dev

Post reply on HN
Print view View original

41–50 of 153 posts

Re: The Koto Programming Language

#41

Post by pjerem »

chris_pie wrote: post #28
fstarship wrote: post #7

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 programmin…

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.

Re: The Koto Programming Language

#43

Post by ossopite »

chris_pie wrote: post #28
fstarship wrote: post #7

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 programmin…

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

Re: The Koto Programming Language

#45

Post by lolinder »

karmakaze wrote: post #35
sanderjd wrote: post #26

Earlier quoted context omitted.

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.

Re: The Koto Programming Language

#46

Post by IshKebab »

oDot wrote: post #10
fstarship wrote: post #7

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 programmin…

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.

Re: The Koto Programming Language

#47

Post by benwilber0 »

Onavo wrote: post #4
martin-t wrote: post #2

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…

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/

Re: The Koto Programming Language

#48

Post by oDot »

IshKebab wrote: post #46
oDot wrote: post #10

Earlier quoted context omitted.

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

Re: The Koto Programming Language

#49

Post by benwilber0 »

tzury wrote: post #13

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.

Re: The Koto Programming Language

#50

Post by pansa2 »

mentalgear wrote: post #44

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

Post reply on HN