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

61–70 of 153 posts

Re: The Koto Programming Language

#61

Post by raphinou »

ossopite wrote: post #21
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 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/

Re: The Koto Programming Language

#62

Post by jeltz »

ossopite wrote: post #21
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 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.

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.

Re: The Koto Programming Language

#63

Post by sanderjd »

valenterry wrote: post #53
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.

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 be said of the OO focus of Kotlin.

Re: The Koto Programming Language

#64

Post by sanderjd »

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.

Neat. I didn't know that.

Re: The Koto Programming Language

#65

Post by IshKebab »

oDot wrote: post #48
IshKebab wrote: post #46

Earlier quoted context omitted.

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.

Re: The Koto Programming Language

#66

Post by zozbot234 »

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…

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.

Re: The Koto Programming Language

#67

Post by no_wizard »

rapind wrote: post #20
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 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

I want Clojure on Rust, or a similar LISP.

Such a great programming paradigm that sadly has few breakout successes

Re: The Koto Programming Language

#68

Post by zozbot234 »

fstarship wrote: post #32
rTX5CMRXIfFG wrote: post #22

Earlier quoted context omitted.

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

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.

Re: The Koto Programming Language

#69

Post by tuveson »

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

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

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

Re: The Koto Programming Language

#70

Post by martin-t »

Philpax wrote: post #6
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…

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

Post reply on HN