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

131–140 of 153 posts

Re: The Koto Programming Language

#131

Post by tzury »

benwilber0 wrote: post #49
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.

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.

Re: The Koto Programming Language

#133

Post by poulpy123 »

cultofmetatron wrote: post #123
rapind wrote: post #121

Earlier quoted context omitted.

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

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

which culture and why it cased problems ? honest question, I barely heard of elm

Re: The Koto Programming Language

#134

Post by raphinou »

int_19h wrote: post #126
raphinou wrote: post #61

Earlier quoted context omitted.

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.

Re: The Koto Programming Language

#135

Post by pmarreck »

cultofmetatron wrote: post #73
rapind wrote: post #20

Earlier quoted context omitted.

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.

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

Re: The Koto Programming Language

#136

Post by Mawr »

valenterry wrote: post #124
sanderjd wrote: post #63

Earlier quoted context omitted.

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

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…

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.

Re: The Koto Programming Language

#137

Post by pepa65 »

pansa2 wrote: post #50
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 arg…

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

Re: The Koto Programming Language

#138

Post by spacechild1 »

chaosprint wrote: post #127
spacechild1 wrote: post #118

Earlier quoted context omitted.

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

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

Re: The Koto Programming Language

#140

Post by epage »

irh wrote: post #130
epage wrote: post #116

Earlier quoted context omitted.

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

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.

Post reply on HN