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

91–100 of 153 posts

Re: The Koto Programming Language

#91

Post by SkiFire13 »

zozbot234 wrote: post #66
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) e…

> Rust will probably gain support for "pluggable" and optional garbage collectors as part of its upcoming local allocators API.

Source? AFAIK there's no confirmed upcoming allocators APIs, and even if there was they would just allow reusing the builtin `Box`/`Vec`/etc etc with custom allocators. This is not much different than what you could do with a custom type, so I find it hard to believe it would allow garbage collectors that are not possible right now.

Re: The Koto Programming Language

#93

Post by sparkie »

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 don’t understand why…

Because dynamic typing has its own advantages, which are worthy of experimentation even if you perceive absence of static typing as a weakness.

Gradual typing can offer us the benefits of both worlds.

> inferred typing is nearly as easy to use while being more robust.

Implementing type inference can be fairly trivial if your types are all disjoint. Hindley-Milner type inference is well studied and there's plenty of literature.

But as soon as you introduce subtyping, the traditional methods are not sufficient. It's only in the past decade that good solutions have been discovered, notably Dolan & Mycroft's MLsub[1], based on Dolan's Algebriac Subtyping thesis[2], and Parreaux & Chau's MLstruct[3], which uses a boolean algebra approach[4]. Type inference with subtyping is not a solved problem - these developments are big steps forward, but there are still open problems under research.

Subtyping doesn't imply object-oriented. Structural typing (ie "static duck typing") is a form of subtyping.

[1]:https://github.com/stedolan/mlsub

[2]:https://www.cs.tufts.edu/~nr/cs257/archive/stephen-dolan/the...

[3]:https://github.com/hkust-taco/mlstruct

[4]:https://dl.acm.org/doi/pdf/10.1145/3563304

Re: The Koto Programming Language

#94

Post by mostafah »

nine_k wrote: post #82
mostafah wrote: post #5

Very cool. I really like the idea of implementing higher level features as extensions on top of a smaller core. I wish real scripting languages like this were more common and in use. Lua comes to mind when thinking about a generic scripting language, but even that is not that widespread.

I think "implementing higher level features as extensions on top of a smaller core" is a hallmark of the Lisp family. Check out Fennel [0] or Janet [1] for two different approaches. On top of everything, Fennel is 100% Lua-compatible. [0]: https://fennel-lang.org/ [1]: https://janet-lang.org/

I agree. Emacs and its Emacs Lisp are one of the best examples of this design. Thank you for the links.

Re: The Koto Programming Language

#96

Post by VWWHFSfQ »

martin-t wrote: post #72
Sytten wrote: post #3

Earlier quoted context omitted.

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

It literally says "for Rust applications" on its front page. Your tone is insulting and has no place in technical discussions.

Describing rust programmers as "zealots" also has no place in a technical discussion.

Re: The Koto Programming Language

#98

Post by amedvednikov »

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.

https://vlang.io

GC, sum types, result/option types, interfaces, no OOP, fast compilation.

Re: The Koto Programming Language

#99

Post by irh »

pansa2 wrote: post #58
pansa2 wrote: post #38

Earlier quoted context omitted.

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

Yes that's right, they're checked at runtime (with the option to disable the checks if the performance cost is a concern) and failed checks simply throw exceptions.

The hints aren't used for other purposes at compile time yet, but they could enable some warnings.

Re: The Koto Programming Language

#100

Post by zozbot234 »

sparkie wrote: post #93
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 don’t understand why… Because dynamic typing has its own advantages, which are worthy of experimentation even if you perceive absence of static typing as a weakness. Gradual typing can offer us the benefits of both worlds. > inferred typing is nearly as easy to use while being more robust. Implementing type inference can be fairly trivial if your types are all disjoint. Hindley-Milner type inference is well studi…

> Gradual typing can offer us the benefits of both worlds.

Gradual typing has much the same overhead as other kinds of dynamic typing. It's broadly appropriate as part of the interface between separately-developed software components, and not very much otherwise.

Post reply on HN