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

141–150 of 153 posts

Re: The Koto Programming Language

#141

Post by dboreham »

Mawr wrote: post #107
pansa2 wrote: post #50

Earlier quoted context omitted.

It says Coffeescript and Moonscript influenced Koto's syntax, which is a little worrying. IMO those languages are a little too flexible and sail too close to ambiguity - very small changes to code can sometimes radically change its meaning. Edit: Sure enough, "whitespace is important in Koto, and because of optional parentheses, `f(1, 2)` is not the same as `f (1, 2)`. The former is parsed as a call to f with two arg…

Oh it has optional parentheses? Into the trash it goes. I'm guessing because "it's cleaner/simpler", but that's a shallow understanding of those words. Just because there are two characters fewer on the screen doesn't make the code simpler. Simple semantics are what you should aim for and inconsistencies like these throw a wrench into that. For example, strings in JSON vs YAML. Isn't it "simpler" to not have to quote…

> Oh it has optional parentheses? Into the trash it goes.

Re: The Koto Programming Language

#144

Post by valenterry »

Mawr wrote: post #136
valenterry wrote: post #124

Earlier quoted context omitted.

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…

A language is a shared way to communicate. If you start picking and choosing the parts of a language you like, you can no longer communicate effectively with the rest of its speakers, er, coders. That's why C++ is so badly designed, you can do anything in it, so people do and no two C++ codebases are the same. Your codebase at work is written one way, the libraries it uses in another, your personal projects use somet…

That's kind of true, but it's not black and white.

For example, look at Golang. The syntax is very plain and it's by design so that everything looks the same.

Then take a look at Lisp. On the surface the syntax looks all the same but in reality, everyone can write their their own macros and people usually do. Then, you can barely understand what's going on if you are new to the codebase - but on the other hand, the flexibility is enormous.

Scala is somewhere in between. When you hire someone for Golang, you don't really need to make anything clear in terms of code style (I believe). In Scala (or Lisp) you should definitely clarify the style that you use. It's actually normal (I've hired pretty big number of Scala developers over my career and I have also rejected job offers due to the style the company uses which doesn't match what I like).

C++ probably is alike, but I don't really any C++ experience.

Re: The Koto Programming Language

#145

Post by 0x3444ac53 »

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

I looked into Rhai but was disappointed that it doesn't have first class functions.

Re: The Koto Programming Language

#146

Post by sanderjd »

valenterry wrote: post #144
Mawr wrote: post #136

Earlier quoted context omitted.

A language is a shared way to communicate. If you start picking and choosing the parts of a language you like, you can no longer communicate effectively with the rest of its speakers, er, coders. That's why C++ is so badly designed, you can do anything in it, so people do and no two C++ codebases are the same. Your codebase at work is written one way, the libraries it uses in another, your personal projects use somet…

That's kind of true, but it's not black and white. For example, look at Golang. The syntax is very plain and it's by design so that everything looks the same. Then take a look at Lisp. On the surface the syntax looks all the same but in reality, everyone can write their their own macros and people usually do. Then, you can barely understand what's going on if you are new to the codebase - but on the other hand, the f…

Scala is a lot more like lisp in this way (or actually, the C++ comparison is the much better one) than it is like go.

There are lots of ways to write Scala, to its detriment.

This isn't meant as a knock on Scala! It's a great language and in particular I think it's been influential on other newer languages. It's just that it does have this "multiple dialects" issue.

Re: The Koto Programming Language

#147

Post by aerzen »

Recently I've started evaluating new languages in terms of "how difficult would it be to read working code in this language, written by an insane person".

After looking at this for 5 minutes it seems it is better than rhai according to my metric. But not necessarily better than lua.

Re: The Koto Programming Language

#148

Post by irh »

epage wrote: post #140
irh wrote: post #130

Earlier quoted context omitted.

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

Sorry, I meant the Koto language and built-in library compatibility story. Whats on the roadmap for a 1.0 and will you allow a 2.0? One of my annoyances with Tcl and Lua is their breaking changes would be pushed into my application and I'd have to decide what version of the language to target and have a plan for changing it. I'm fine with the Rust API breaking compatibility.

I can't imagine wanting a 2.0 release, I'd rather take longer to get to 1.0 to reduce the risk of needing it, and anyway I'd much prefer to aim for something like Rust's editions, allowing the language to evolve without the whole community needing to migrate.

Before 1.0 I'd want to address at least:

- the FFI / package management topics mentioned above

- async support: https://github.com/koto-lang/koto/issues/277

- extend the parser to support an autoformatter: https://github.com/koto-lang/koto/issues/286

...and then have a larger number of people using it in projects without major issues coming up for a good while, e.g. a year+.

Re: The Koto Programming Language

#150

Post by irh »

shahriarhus wrote: post #139

It's reminds me of Lua for C++, am I correct?

Yes, I was missing a 'companion language' for Rust similar to Lua for C and C++, I tried Lua bindings and other Rusty scripting languages but felt like starting a new project would be worthwhile.
Post reply on HN