kcores-llm-arena VS glicol

Gemini 2.5 pro is far ahead of even Claude

Chart:

https://raw.githubusercontent.com/KCORES/kcores-llm-arena/re...

Description of the challenges:

https://github.com/KCORES/kcores-llm-arena

I recently successfully run Glicol (https://github.com/chaosprint/glicol) on Pico 2 and I am building a prototype board for myself. AIC3204 is my first choice for now so you can save PAM8003DR amplifier

I have starred this language for a while. I considered similar form when I designed the Glicol syntax, but I still wanted it to be more readable in live performance.

If you are looking for a language that can be used on Linux, you might want to try Glicol:

https://glicol.org/

You can use it directly through wasm on the web page, and there is also a cli version:

https://github.com/glicol/glicol-cli

reading about Eno's ideas on organization and variety makes me want to share some perspectives directly from my experience with music performance practice, specifically in live coding.

For a long time, the common practice in live coding, which you might see on platforms like Flok.cc (https://flok.cc) supporting various interesting languages, has been like this: Everyone gets their own 'space' or editor. From there, they send messages to a central audio server to control their own sound synthesis.

This is heavily influenced by architectures like SuperCollider's client-server model, where the server is seen as a neutral entity.

Crucially, this relies a lot on social rules, not system guarantees. You could technically control someone else's track, or even mute everything. People generally restrain themselves.

A downside is that one person's error can sometimes crash the entire server for everyone.

Later, while developing my own live coding language, Glicol (https://glicol.org), I started exploring a different approach, beginning with a very naive version:

I am creator and maintainer of several Rust projects:

https://github.com/chaosprint/glicol

https://github.com/chaosprint/asak

For LLM, even the latest Gemini 2.5 Pro and Claude 3.7 Thinking, it is difficult to give a code that can be compiled at once.

I think the main challenges are:

1. Their training material is relatively lagging. Most Rust projects are not 1.0, and the API is constantly changing, which is also the source of most compilation errors.

2. Trying to do too much at one time increases the probability of errors.

3. The agent does not follow people's work habits very well, go to docs.rs to read the latest documents and look at examples. After making mistakes, search for network resources such as GitHub.

Maybe this is where cursor rules and mcp can work hard. But at present, it is far behind.

have you considered using webtransport?

When I was developing Glicol (https://glicol.org/) sync, the main challenge is network jitter. Had to remove it eventually.

Furthermore, have you factored in the synchronization as perceived by the listener?

Also, it seems system-level differences, particularly in audio output latency across various OS and hardware setups, would need to be considered.

What I mean is, the variation in inherent audio output latency between different systems (e.g., Mac vs. Windows, different hardware) could easily exceed 10ms in itself.

I completely understand, and it's not the first time I've heard of people switching from Bevy to Unity. btw Bevy 0.16 just came out in case you missed the discussion:

https://news.ycombinator.com/item?id=43787012

In my personal opinion, a paradox of truly open-source projects (meaning community projects, not pseudo-open-source from commercial companies) is that development seems to constantly branch out, lacking a unified roadmap. While this leads to more and more cool things appearing, there always needs to be a balance with sustainable development.

Commercial projects, at least, always have a clear goal: to sell. For this goal, they can hold off on doing really cool things. Or they think about differentiated competition. Perhaps if the purpose is commercial, an editor would be the primary goal (let me know if this is alreay on the roadmap).

---

I don't think the language itself is the problem. The situation where you have to use mature solutions for efficiency is more common in games and apps.

For example, I've seen many people who have had to give up Bevy, Dioxus, and Tauri.

But I believe for servers, audio, CLI tools, and even agent systems, Rust is absolutely my first choice.

I've recently been rewriting Glicol (https://glicol.org) after 2 years. I start from embedded devices, switching to crates like Chumsky, and I feel the ecosystem has improved a lot compared to before.

So I still have 100% confidence in Rust.

After trying to start a business for a year, I basically gave up negotiating with VCs.

My current goal is to spend half of my time on the development and maintenance of open source projects, such as Glicol (https://glicol.org/).

The other half of my time is to do some profitable business.

I just found that the VC model is not suitable for my current situation.

There are similar trends in music and sound art, which can be experienced with Glicol (https://glicol.org/) as well as many other languages here:

https://github.com/toplap/awesome-livecoding

Really interesting to read about this! That's wonderful validation for a vital digital culture and its heritage.

As the creator of Glicol (https://glicol.org/), based in Oslo and working in the digital arts space, I'm always fascinated by how different countries foster creative technology. Sweden's approach in recognizing the demoscene this way is particularly encouraging.

It makes me reflect on the pathways to support here in Norway. While academic environments can be very supportive (as my previous supervisors have been), navigating the broader public arts funding structures for newer digital art forms sometimes feels more challenging, especially perhaps for those working outside of long-established networks.

Seeing Sweden's success in formally recognizing this kind of digital heritage is genuinely inspiring and offers food for thought.