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

121–130 of 153 posts

Re: The Koto Programming Language

#121

Post by rapind »

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.

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.

Re: The Koto Programming Language

#122

Post by archargelod »

rattray wrote: post #55
nerdponx wrote: post #25

Earlier quoted context omitted.

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

Re: The Koto Programming Language

#123

Post by cultofmetatron »

rapind wrote: post #121
cultofmetatron wrote: post #73

Earlier quoted context omitted.

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

Re: The Koto Programming Language

#124

Post by valenterry »

sanderjd wrote: post #63
valenterry wrote: post #53

Earlier quoted context omitted.

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…

> 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 focus on immutability like Scala does, than I would recommend Kotlin over Scala for what OP asked for.

Re: The Koto Programming Language

#125

Post by rapind »

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?

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.

Re: The Koto Programming Language

#126

Post by int_19h »

raphinou wrote: post #61
ossopite wrote: post #21

Earlier quoted context omitted.

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.

Re: The Koto Programming Language

#127

Post by chaosprint »

spacechild1 wrote: post #118
chaosprint wrote: post #14

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

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

Re: The Koto Programming Language

#128

Post by thayne »

spacechild1 wrote: post #118
chaosprint wrote: post #14

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

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

Is koto any faster?

Re: The Koto Programming Language

#129

Post by irh »

thayne wrote: post #128
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,…

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

Re: The Koto Programming Language

#130

Post by irh »

epage wrote: post #116
irh wrote: post #95

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

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

Post reply on HN