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

21–30 of 153 posts

Re: The Koto Programming Language

#21

Post by ossopite »

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.

Re: The Koto Programming Language

#22

Post by rTX5CMRXIfFG »

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

Re: The Koto Programming Language

#23

Post by oDot »

fstarship wrote: post #18
oDot wrote: post #10

Earlier quoted context omitted.

You're describing Gleam https://gleam.run

Thanks looks great so far. Also has pattern matching which I should also have mentioned in my top level post.

I use it in production[0] and it's a delight so far. When Porffor[1] is ready you could compile to WASM through JS for self-contained binaries!

[0]: https://blog.nestful.app/p/why-i-rewrote-nestful-in-gleam

[1]: https://porffor.dev/

Re: The Koto Programming Language

#24

Post by HKH2 »

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…

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.

Re: The Koto Programming Language

#25

Post by nerdponx »

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.

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.

Re: The Koto Programming Language

#26

Post by sanderjd »

rTX5CMRXIfFG wrote: post #22
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'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

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.

Re: The Koto Programming Language

#27

Post by pansa2 »

dustbunny wrote: post #9
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…

Check out Wren. https://wren.io/ Written by Bob Nystrom, author of Crafting Interpretors.

Wren is dynamically-typed, though

Re: The Koto Programming Language

#28

Post by chris_pie »

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.

Re: The Koto Programming Language

#29

Post by hypeatei »

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…

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

Re: The Koto Programming Language

#30

Post by sramsay »

dustbunny wrote: post #9
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…

Check out Wren. https://wren.io/ Written by Bob Nystrom, author of Crafting Interpretors.

Last release was four years ago.
Post reply on HN