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

111–120 of 153 posts

Re: The Koto Programming Language

#111

Post by irh »

riidom wrote: post #109
irh wrote: post #95

Koto creator here, nice surprise to see this on HN so I'm a bit late to the discussion. Happy to answer any questions!

Would you say Koto (or some direct competitors, for that matter), is viable to learn when I otherwise don't intend to learn Rust at all? But let's say, want to keep the option open to participate in Rust-based projects which support Koto et al.?

Yes I would certainly hope so, you shouldn't need to know any Rust if you want to learn Koto. The guide assumes that the reader has some general experience with programming, but not from using any specific language.

https://koto.dev/docs/next/language/

Re: The Koto Programming Language

#112

Post by irh »

pansa2 wrote: post #50
mentalgear wrote: post #44

> Syntax: [...] minimizing visual distractions, while also managing to avoid inexpressive terseness. Nice! Now, if it only had type support.

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…

What I've had in mind with Koto is that when I need strictness and precision I'll generally be using Rust, and Koto is more intended for another aspect of programming where I want things to be much more fluid and easy-going.

My thinking is that the potential footgun here is outweighed by the win of paren-free calls for quick scripting / rapid iteration, but it certainly counts towards the language strangeness budget [1] so I figured it was worth pointing out in the guide.

[1] https://steveklabnik.com/writing/the-language-strangeness-bu...

Re: The Koto Programming Language

#113

Post by soulbadguy »

raphinou wrote: post #61
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.

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/

Fsharp is such a nice languange. Such a shame that I never seem to get the light it deserves. Between the alternative light syntax, type providers and first class "scripting" mode supported it really was a great middle point between fully scripting language and fast prototyping and full blow projects

Re: The Koto Programming Language

#114

Post by jakkos »

HKH2 wrote: post #24
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, bu…

I really like the idea of rust-script but last time I looked there didn't seem to be a good way to get rust-analyzer to work when writing a script. Maybe I'm a little too reliant on LSPs but I find writing Rust painful without it, has the situation improved at all since?

Re: The Koto Programming Language

#115

Post by no_wizard »

whytevuhuni wrote: post #75
no_wizard wrote: post #67

Earlier quoted context omitted.

I want Clojure on Rust, or a similar LISP. Such a great programming paradigm that sadly has few breakout successes

I'm having a hard time picturing that. What would it look like?

Like Clojure having access to the Java ecosystem it would need access to the Rust ecosystem I imagine.

I otherwise am unsure what you mean

Re: The Koto Programming Language

#118

Post by spacechild1 »

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

Isn't Rhai extremely slow? The website itself says that it's roughly 2x slower than Python3: https://rhai.rs/book/about/benchmarks.html. Apparently, Rhai doesn't even compile to bytecode and instead walks the AST! This doesn't sound like a language I would pick as for DSP...

On the other hand, you can always write your own Rhai interpreter if necessary. And if you restrict the language to a limited set of features, which you need to do anyway to keep it realtime-safe, you could even compile it to native code.

> and it can handle real-time audio blocks, which is really impressive:

Any scripting language can do this as long as you stick to operations that don't cause memory allocations, system calls or other non-realtime-safe operations.

For example, you can use Lua to write process functions for Pd objects: https://agraef.github.io/pd-lua/tutorial/pd-lua-intro.html#s...

The question is rather how much you can do in a given audio callback.

---

All that being said, Glicol is very cool!

Re: The Koto Programming Language

#120

Post by HKH2 »

jakkos wrote: post #114
HKH2 wrote: post #24

Earlier quoted context omitted.

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

I really like the idea of rust-script but last time I looked there didn't seem to be a good way to get rust-analyzer to work when writing a script. Maybe I'm a little too reliant on LSPs but I find writing Rust painful without it, has the situation improved at all since?

Nah, but that issue's to do with rust-analyzer looking for a Cargo file. Some people have apparently got around it by making a file.

You're right that it would be great with full LSP support, but for quick scripting, I mostly just want a linter.

Post reply on HN