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

51–60 of 153 posts

Re: The Koto Programming Language

#51

Post by notnullorvoid »

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…

> For me the biggest gap in programming languages is a rust like language with a garbage collector, instead of a borrow checker.

I agree, though I often think Rust is probably good enough. You can use RC or grab a GC crate. It's not as ergonomic as just assuming all values are GCed, but I think it gives the flexibility and fast iteration of working in a GCed language.

Re: The Koto Programming Language

#52

Post by seivan »

The documentation and integration with Rust for this amazing, well done! Like other commenters, I also wish it had better static typing and looked more like Elixir with anonymous sum types and template literal types.

Re: The Koto Programming Language

#53

Post by valenterry »

sanderjd wrote: post #26
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

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

Re: The Koto Programming Language

#54

Post by valenterry »

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 are looking for Scala or F#, depending on your choice of ecosystem.

Both come with very powerful features, but you don't need to use them and you can use libraries accordingly. Especially Scala can be made to feel very similar to python

Re: The Koto Programming Language

#55

Post by rattray »

nerdponx wrote: post #25
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.

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?

Re: The Koto Programming Language

#56

Post by threatofrain »

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.

Implicit conversion is not obviously that convenient for scripting. The JS community has largely moved to anti-recommend implicit conversion, such as by basically striking `==` from their vocabulary.

Re: The Koto Programming Language

#58

Post by pansa2 »

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…

> not sure if these are checked at compile-time, run-time, or both

It looks like Koto only checks types at run-time. That means its type annotations are essentially shorthand for something like Python's `if not isinstance(...): raise TypeError`.

Re: The Koto Programming Language

#60

Post by benwilber0 »

Sytten wrote: post #3
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…

What are you rambling about, this is a sanboxed scripting language to allow your users to define customization at runtime. This has nothing to do with rust, it could be written in C or C++. You would not run random user provided C# in your application at runtime. It is like saying browser should be coded in C# because C++ can't be use instead of JavaScript...

Or like saying that C++ was somehow deficient just because NodeJS had to be created in order to script v8.
Post reply on HN