Yes, it was very promising, but unfortunately abandoned. And yeah, the name was bad too. But it doesn't matter. Lua/Luau is still the only serious language in this field, which is a pity.
Google's Go has made finding info on the ancient Chinese board game generally referred to in English by its Japanese name Go difficult. This has has interestingly lead to increased use of its original name Weiqi or its Korean name Baduk.
The Japanese name is actually 囲碁 (igo). 碁 (go) is just an abbreviation; I don't see it often in Japanese text, but for some reason the Anglosphere decided to adopt it.
囲 is a simplification of 圍, and 碁 is a Japanese-specific letter that roughly maps to 棋. If you read 圍棋 in Chinese, you get weiqi.
In the 90s/2000s people also used to shorten cybersex to cyber. I guess if they wanted to have fun with it they could add a "Wanna Cyber?" in place of the usual "Try <x>".
I even had someone submit a resume that listed crypto as one of their skills. When I asked basic questions it quickly became clear they were talking about cryptocurrencies lol
And cryptosporidium (a type of bacteria which causes diarrhea) is also often abbreviated as "crypto". Not that there's much risk of confusion in CVs, but it does lead to some amusing lines like "preventing and controlling crypto", "symptoms of crypto", etc (e.g. at https://www.cdc.gov/cryptosporidium/prevention/preventing-an...).
Devs will never learn this because naming languages after common words is exactly the PL dev culture. It's not important to pldevs because they know the median number of users for a pl is 0, large companies know they can buy the search results, so names are chosen for reasons other than SEO.
People get around it by appending "-lang" or "-script" to the name and that solves the SEO.
My old web-framework was called "cyberweb". I wanted to insinuate
that it is modern and futuristic.
At some point in time, though, I was tired of prefacing "cyber"
to I simplified it to just 'web'. Makes also more sense, e. g.
in ruby:
require 'web'
But I like cyber as a theme still. Just as a name itself, it may
indeed not be optimal, so I do not totally disagree with you
either. The name is a bit of a problem though because people
will wonder what the difference is to javascript. In turn
people using javascript wonder why it contains the substring
java.
I think (outside hobbies) new programming language development is basically dead at this point. The major use cases have been filled, and there are more forces than ever towards using a battle-tested language with a massive ecosystem. Further, less and less code is being written or read by humans so the actual language ergonomics matter less than ever to those who would fund new language creation.
> new programming language development is basically dead at this point
I think it's the opposite. For the projects that warrant it (usually games), it has never been easier to create a custom embeddable scripting language. It was always somewhat common to have custom languages, specially if the game is open to mods and/or allows users to create custom maps, but now that's easier than ever to do.
For gamedev scripting, the gap has not been filled yet. Lua is good for embedding but the language itself is terrible for LLM usage (too much dynamic typing). C# is too heavy for scripting usage (long compile times, clunky to embed into a C++ engine), and other alternatives (AngelScript, daScript, ...) are just too niche.
Niche as in... I haven't heard anyone using it except for the studio that made it (Gaijin Entertainment). Might be a good language (at least from what the docs suggest), but needs some marketing to increase adoption...
Odin... technically not a scripting language, and haven't used it that much. But if compile times are good enough and hot reloading works, might worth a try. Though I think manual memory management can be antithetical when churning out gameplay code quickly (or when you're working with game designers with minimal background in programming)
The major use cases have not been filled, only the major corporate use cases. That doesn't mean there aren't still major gaps to be filled now, or that the current use cases won't evolve in the future.
So it may be true that "programming language" development is done, but there are many more applications for formal languages than just writing apps and websites and such.
Moreover, it may be true that less code as a proportion of all code is being written or read by humans. But more humans today are reading and writing code than ever before. So the ability to express unambiguous ideas to agents using formal langauges is more important than ever, even if people are only reading/writing a small proportion of all code.
Similarly, it's not true that because agents will be reading / writing code that language ergonomics do not matter. Agents have resource restrictions like token budgets, and they are also trained using human knowledge and conventions. Ergonomics apply to agents just as they do humans; languages which are verbose require more tokens to write, languages that can be verified are more useful in agentic loops, languages with live compiler introspection and interpreters can give fast results to agents etc.
So I hold exactly the opposite view: it's not clear to me why languages built 30 years ago in a world where the Internet barely existed would be accidentally ideal for AI agents in 2026 to the pint we can say the whole field is solved for good (and no, I don't think the amount of training data on those languages seals the fate because that status is ephemeral and also it's not clear training on one language corpus isn't transferrable to other languages).
My gripe with new languages like this is that strings are always UTF-8 and that makes it needlessly difficult to parse HTTP headers correctly. This has led to vulnerabilities in the past.
I disagree. UTF-8 is the right default. Pure ASCII strings are rarely needed in modern software. Unless you know that you need ASCII, your strings should support unicode.
Perhaps so, and that's a good development imho. However, the most notorious of all, HTTP, has not afaik. Different encodings have been suggested including UTF-8. I'm not entirely sure why those proposals weren't implemented, but the dot-com bubble at the time might've had something to do with it.
The first networked computers predate unicode by several decades. Back then, the word length could be 8 but not neccesarily. All sorts of different encodings existed and a given common standard wasn't yet agreed upon
It's not like internet standards don't know there are other languages, it's just that they documented how things were done at the time. Some legacy has remained ever since.
Sure, but most code doesn't interact with raw packets. Legacy, ascii-only internet standards probably make up much less than 1% of new lines of code written today. Programming languages should support this use case. But not at the expense of the other 99% of software.
Unicode-aware strings are the right choice for 99% of code. The last 1% should be a special case.
Yes, plenty of times. But I’m usually using raw byte arrays via protobuf or something similar. ASCII only text protocols are rare. Most devs don’t reimplement them from scratch.
I’d wager most code is application code, where UTF8 strings are a great choice.
I agree. At this point scripting languages should have native support for string subtypes with custom charsets (ascii/utf16) or just regexp-defined or even ENUM()'erated values.
IIRC historically on Windows, a string was UTF16, on unix it was ASCII; nowadays everywhere it's UTF8 without a way to specifically limit what goes into a string.
For example UTF8 opens the door to homoglyph attacks and various other things (RTL, spaces), and a program should be able to force a string to be ASCII-only so that these classes of problems are ruled out.
Homoglyph attacks and RTL work just as well in UTF-16. UTF-8 and UTF-16 are different character encodings for the same character set (Unicode).
That being said, Windows permits unpaired surrogates in its "UTF-16" strings, even though that is not actually valid UTF-16. Similarly, many Linux APIs accept arbitrary bytes, not just valid UTF-8.
Of course. I was trying to say that it would be nice to limit certain variables to an ASCII charset, or ASCII+umlaut+accents without any of the 10k other UTF8 shenanigans.
Interesting concept I guess. But the website reads like poorly AI generated code. No information as to what the grey and orange bars mean, overlapping text and such.
It links to the bench.cy, but nothing explains how the others were measured. It seems that they're including some start-up time in some that dominates, but not explaining whether it's realistic to be needing to spend that.
Looks cleaner than lua. Unfortunately I think new programming languages
kind of need to demonstrate first that they are really viable. So many
new languages struggled to retain momentum, such as Io by Steve Dekorte;
and some more examples (it is just one semi-random example of many more).
2022-2023 on the bottom of the main page, last release from 2023 & most recent commit from 8 months ago... seems almost dead to me
Yes, it was very promising, but unfortunately abandoned. And yeah, the name was bad too. But it doesn't matter. Lua/Luau is still the only serious language in this field, which is a pity.
Looks like it's safer to stick to Lua and use LuaJIT.
This is by far the most stupid name for a new language imaginable. Shortening it to "cyber" on the landing page too..
When will devs learn that being able to search for a term on the open internet without having it polluted by normal language is kind of important
Google's Go has made finding info on the ancient Chinese board game generally referred to in English by its Japanese name Go difficult. This has has interestingly lead to increased use of its original name Weiqi or its Korean name Baduk.
The Japanese name is actually 囲碁 (igo). 碁 (go) is just an abbreviation; I don't see it often in Japanese text, but for some reason the Anglosphere decided to adopt it.
囲 is a simplification of 圍, and 碁 is a Japanese-specific letter that roughly maps to 棋. If you read 圍棋 in Chinese, you get weiqi.
Google's search surely degraded a lot, but if I search for "go board game" - I get 0 results for the programming language.
In the 90s/2000s people also used to shorten cybersex to cyber. I guess if they wanted to have fun with it they could add a "Wanna Cyber?" in place of the usual "Try <x>".
It drove me nuts in the cryptocurrency boom that people shortened cryptocurrency to "crypto". As in, "I'm into crypto" or "I work in crypto".
Cryptography is much older than bitcoin.
I even had someone submit a resume that listed crypto as one of their skills. When I asked basic questions it quickly became clear they were talking about cryptocurrencies lol
And cryptosporidium (a type of bacteria which causes diarrhea) is also often abbreviated as "crypto". Not that there's much risk of confusion in CVs, but it does lead to some amusing lines like "preventing and controlling crypto", "symptoms of crypto", etc (e.g. at https://www.cdc.gov/cryptosporidium/prevention/preventing-an...).
These days "cyber" undecorated usually implies "-security", muddying those waters further.
"I put on my robe and wizard hat"
oh behave
Devs will never learn this because naming languages after common words is exactly the PL dev culture. It's not important to pldevs because they know the median number of users for a pl is 0, large companies know they can buy the search results, so names are chosen for reasons other than SEO.
People get around it by appending "-lang" or "-script" to the name and that solves the SEO.
What is PL?
I'm guessing it's programming language, but I don't think I've seen it abbreviated that way before.
It's very common in the language design circles, but yeah, programming language.
It's pretty common from where I sit, tbh.
programming language
My old web-framework was called "cyberweb". I wanted to insinuate that it is modern and futuristic.
At some point in time, though, I was tired of prefacing "cyber" to I simplified it to just 'web'. Makes also more sense, e. g. in ruby:
But I like cyber as a theme still. Just as a name itself, it may indeed not be optimal, so I do not totally disagree with you either. The name is a bit of a problem though because people will wonder what the difference is to javascript. In turn people using javascript wonder why it contains the substring java.[dead]
I think (outside hobbies) new programming language development is basically dead at this point. The major use cases have been filled, and there are more forces than ever towards using a battle-tested language with a massive ecosystem. Further, less and less code is being written or read by humans so the actual language ergonomics matter less than ever to those who would fund new language creation.
> new programming language development is basically dead at this point
I think it's the opposite. For the projects that warrant it (usually games), it has never been easier to create a custom embeddable scripting language. It was always somewhat common to have custom languages, specially if the game is open to mods and/or allows users to create custom maps, but now that's easier than ever to do.
For gamedev scripting, the gap has not been filled yet. Lua is good for embedding but the language itself is terrible for LLM usage (too much dynamic typing). C# is too heavy for scripting usage (long compile times, clunky to embed into a C++ engine), and other alternatives (AngelScript, daScript, ...) are just too niche.
Why is daScript too niche?? Gamedev scripting itself is a niche, what can't you do in daScript or what would you not want to do in daScript?
daScript looks very complete
Niche as in... I haven't heard anyone using it except for the studio that made it (Gaijin Entertainment). Might be a good language (at least from what the docs suggest), but needs some marketing to increase adoption...
What about Python? LLMs seem to like it well enough.
Slow and not so operable with C/C++
Slow I'll grant you, but I assumed for scripting use cases that didn't matter so much.
It doesn't matter that much. Probably 10x slower than C++/Rust is fine. 100x is a bit much though.
This is not my area, but what about Rust or Odin?
Rust is slow to compile, and not that productive when writing gameplay code (see https://loglog.games/blog/leaving-rust-gamedev/)
Odin... technically not a scripting language, and haven't used it that much. But if compile times are good enough and hot reloading works, might worth a try. Though I think manual memory management can be antithetical when churning out gameplay code quickly (or when you're working with game designers with minimal background in programming)
This gives me "why build dropbox" energy.
We never know when a revelation or unmet customer niche arrives around the corner. Never bet against it.
...to have C0ndi on the board to allow the gov't complete access and data retention for ever and ever under a mountain
The major use cases have not been filled, only the major corporate use cases. That doesn't mean there aren't still major gaps to be filled now, or that the current use cases won't evolve in the future.
This talk argues there are many purposes for formal languages other than programming: https://medium.com/bits-and-behavior/my-splash-2016-keynote-...
So it may be true that "programming language" development is done, but there are many more applications for formal languages than just writing apps and websites and such.
Moreover, it may be true that less code as a proportion of all code is being written or read by humans. But more humans today are reading and writing code than ever before. So the ability to express unambiguous ideas to agents using formal langauges is more important than ever, even if people are only reading/writing a small proportion of all code.
Similarly, it's not true that because agents will be reading / writing code that language ergonomics do not matter. Agents have resource restrictions like token budgets, and they are also trained using human knowledge and conventions. Ergonomics apply to agents just as they do humans; languages which are verbose require more tokens to write, languages that can be verified are more useful in agentic loops, languages with live compiler introspection and interpreters can give fast results to agents etc.
So I hold exactly the opposite view: it's not clear to me why languages built 30 years ago in a world where the Internet barely existed would be accidentally ideal for AI agents in 2026 to the pint we can say the whole field is solved for good (and no, I don't think the amount of training data on those languages seals the fate because that status is ephemeral and also it's not clear training on one language corpus isn't transferrable to other languages).
[dead]
It would be nice if the examples included an integration with an existing game engine. Game scripting is a very common use case for those languages.
My gripe with new languages like this is that strings are always UTF-8 and that makes it needlessly difficult to parse HTTP headers correctly. This has led to vulnerabilities in the past.
I disagree. UTF-8 is the right default. Pure ASCII strings are rarely needed in modern software. Unless you know that you need ASCII, your strings should support unicode.
Internet Messages have been ASCII since Internet Messages.
Most internet protocols these days have shifted to UTF-8.
Perhaps so, and that's a good development imho. However, the most notorious of all, HTTP, has not afaik. Different encodings have been suggested including UTF-8. I'm not entirely sure why those proposals weren't implemented, but the dot-com bubble at the time might've had something to do with it.
True, but humans have been speaking non English languages since humans.
The first networked computers predate unicode by several decades. Back then, the word length could be 8 but not neccesarily. All sorts of different encodings existed and a given common standard wasn't yet agreed upon
It's not like internet standards don't know there are other languages, it's just that they documented how things were done at the time. Some legacy has remained ever since.
Sure, but most code doesn't interact with raw packets. Legacy, ascii-only internet standards probably make up much less than 1% of new lines of code written today. Programming languages should support this use case. But not at the expense of the other 99% of software.
Unicode-aware strings are the right choice for 99% of code. The last 1% should be a special case.
Raw packets? Legacy? Have you've ever talked to anything over a socket?
You don't need a raw socket to get into trouble. You also don't need a "legacy" protocol.
Yes, plenty of times. But I’m usually using raw byte arrays via protobuf or something similar. ASCII only text protocols are rare. Most devs don’t reimplement them from scratch.
I’d wager most code is application code, where UTF8 strings are a great choice.
I agree. At this point scripting languages should have native support for string subtypes with custom charsets (ascii/utf16) or just regexp-defined or even ENUM()'erated values.
IIRC historically on Windows, a string was UTF16, on unix it was ASCII; nowadays everywhere it's UTF8 without a way to specifically limit what goes into a string.
For example UTF8 opens the door to homoglyph attacks and various other things (RTL, spaces), and a program should be able to force a string to be ASCII-only so that these classes of problems are ruled out.
The NT kernel predates UTF8 by at least 3 years. It originally used UCS2, which covers the basic multilingual plane of the first unicode standard.
Homoglyph attacks and RTL work just as well in UTF-16. UTF-8 and UTF-16 are different character encodings for the same character set (Unicode).
That being said, Windows permits unpaired surrogates in its "UTF-16" strings, even though that is not actually valid UTF-16. Similarly, many Linux APIs accept arbitrary bytes, not just valid UTF-8.
Of course. I was trying to say that it would be nice to limit certain variables to an ASCII charset, or ASCII+umlaut+accents without any of the 10k other UTF8 shenanigans.
Interesting concept I guess. But the website reads like poorly AI generated code. No information as to what the grey and orange bars mean, overlapping text and such.
"Showing script time (orange), load time (gray), and peak memory usage."
The benchmarking seems a little bit suspect.
It links to the bench.cy, but nothing explains how the others were measured. It seems that they're including some start-up time in some that dominates, but not explaining whether it's realistic to be needing to spend that.
Seems to be in the same category as Lua. Can a PL nerd explain what's different about it?
Lua has users. Network effects are important. (I have a PhD in programming languages.)
This. Despite my personal dislike of Python I would never discourage anyone from using it. It has an extraordinary ecosystem.
There's a lot to the language. Python and Rust vibes. Written in Zig. Seems to have lost steam. I wonder what happened
Last release 2 years ago.
Looks cleaner than lua. Unfortunately I think new programming languages kind of need to demonstrate first that they are really viable. So many new languages struggled to retain momentum, such as Io by Steve Dekorte; and some more examples (it is just one semi-random example of many more).
Great you came up with a compiler and some syntax.
What libraries exist.
What's package management system.
How does it interop with existing code?
Is there a JSON parser, an XML parser? Crypto algorithms? Database drivers?
People who invent languages from scratch inherit the technical debt of recreating the entire software ecosystem.
It looks like they are just pulling from the internet at the top of source files:
`use rl 'https://mycdn.com/raylib'`
Good luck with securing that. At least JavaScript has the sense to put it all in a single config file.