It seems to have kept a lot of good things from python, but fixes many quirks:
- slicing with index or with index+length ? Well, both apparently!
- len() is a method
- ranges and slices have the same syntax
- you can use | to avoid the indentation hell that comes with '''
- true, false and none don't have an upper case first letter
- the lambda design allow for multi lines, despite the language being heavily biased toward statements. And it's using "=>".
- circular imports do not cause errors
- explicit export, although i'd prefer it to be opt in
- lua style ffi
- mapping on dict key/values is the simple case
- CYON is quite interesting
- and of course concurrency and perf from the start
But some of them will cause big troubles:
"errors are values and do not propogate up the call stack by default. Users are not forced to handle errors unless the error value is passed to a typed destination."
Yeah, silent errors in bash scripting taught me I really don't want that.
"The shorthand method for calling functions omits parentheses and commas"
The reason I still can't parse Ruby after 15 years.
Why are programming language designers so bad at naming languages. Pick something that doesn't already have a gazillion search results, people! Go, Swift, Rust, Cyber, all bad. Though I'm still hoping for a UI library for Go where the elements are called gadgets, just so we at Google can look them up under go/go/gadget/Button.
Those other languages were created/sponsored by huge corporations. Search for "Cyber Script" on Google, none of the top results include cyberscript.dev
Okay. When I search for “Cyber Script” on kagi.com, cyberscript.dev is the third result.
Google search is user hostile. Or to drag out that overused cliche, on Google search, the advertisers are the customers, while the attention of people searching the web is the product.
Adding 'language' or 'programming' to the search query should solve it. Anyway Google seem to retain context when searching certain topics.
But yeah there's definitely room for improvement and creativity here.
Building a new language in a new language (zig) is quite the choice. Usually you choose your host language to leverage some aspect of its ecosystem — whether that be a VM like JVM, or a standard library, or something else.
The other reason would be that writing a language takes time, measured in years and decades. Usually you would pick a well-supported language so that you can be assured it won’t disappear before you’ve finished yours.
I’m only just looking through the project now, but would be interested in finding the author’s rationale for writing this in Zig. Seems like with Zig you wouldn’t get any of this, so I’m wondering why go this direction.
Looking at the commit history of the Zig repo, the first commit was in 2016, so that can’t be right; Go hit 1.0 in 2012. Unless maybe it was just being talked about in 2012.
Either way, that’s still pretty new as far as languages go these days, and the bus factor still seems to be 1 or at best 3. There has to be some compelling reason that Zig was the choice here and I’m curious.
I grew up in the 70s with the term cybernetics from Norber Wiener, and I liked it before Gibson's Neuromancer in the 80s, so I guess I was inoculated before the pandemic use of the word. Cyber-Physical Systems (CPS) is a term being bandied about a bit now (reading Logical Foundations of Cyber-Physical Systems, and it is pretty cool [1]; Andrew Sorensen's Extempore as a CPS environment [2]). I also attended the first HOPE in 1994 in NYC and although the press abused the term cyber, it's still cool to me! But the Papa John's stuff was funny.
I grew up in the 70s with the term cybernetics from Norber Wiener, and I liked it before Gibson's Neuromancer in the 80s, so I guess I was innoculated before the pandemic use of the word. Cyber-Physical Systems (CPS) is a term being bandied about a bit now (reading Logical Foundations of Cyber-Physical Systems, and it is pretty cool[1]; Andrew Sorensen's Extempore as an environment for Cyber-Physical Systems). I also attended the first HOPE in 1994 in NYC and although the press abused the term cyber, it's still cool to me!
Benchmarks for fib are great and all, but unless you are making fibonacci simulator 2023 it's not really a good selling point.
What I really want to know when looking at a scripting language is: how easy is it really to embed? Does it have a good debugger? Does it make too many assumptions about how your program works? Can it scale for a larger project? Does it have any interesting features like apis for reflection?
You mean allowing circular references seems Javascripty or you mean outright incorrect equality checks seems Javascripty? I don't think Javascript suffers from the latter, as long as you understand the implicit casting Javascript deos.
This looks awesome. What are the plans for host security? For example, LUA is secure in the sense that you can explicitly disallow it to use APIs that can modify the operating system. This makes it a good candidate for multiplayer games.
Lots of features that look really great to see at first blush. As a bruised and battered Python programmer, the only thing missing from my list would be static compilation target/deployment strategy. Having a first class option to distribute code is important to me.
No performance comparisons to julia? Julia is pretty much the language I would currently look into for a scripting language outside python, so it might be a pretty relevant comparison target.
> Suggest five more names, but pick names that do not end in "script"
Kinda cheating to reply to this with s/Script/Lang/ from the previous answer, since those were not 5 more names. I blame it using the same seed for its random number generator : - D
This looks great. The first use case that occurs to me is to accelerate pieces of our horribly slow Ansible scripts - but I'm probably the only one on our team who's interested in making the investment in learning a new language, and dealing with the bespoke code. How do I generate the required enthusiasm?
Personally I think that would be a pretty hard sell. Writing custom code, presumably for things used in production, in a new language that isn't even at version 1?
If you're committed to, and enjoy the combination of, Python & YAML & Jinja2 - but don't enjoy the architecture, performance, and sharp edges of Ansible, you may want to review Saltstack as a config management tool. It's not a drop-in replacement, of course, but it's much closer to where you are now than the traditional two alternatives.
However, as others have observed to you, it's not a good idea to replace your current functional Ansible menagerie with a new unstable language + no framework.
We're using ansible-pull. Aside from occasional access to NFS mounts, there's a minimum of network traffic. E.g., the git retrieval is usually: I've got version x. That's current? Thanks, we're done. The time is spent executing Ansible modules on the local system. 200+ tasks ok, 200+ tasks skipped, maybe 10 changed. That takes between 5 and 20 minutes. I have an unsubstantiated suspicion that the large dictionary representing the package inventory is a contributor - systems with fewer packages seem to work faster.
From my experience, it is not always just the network. Ansible can be slow in operations such as copying files between directories on the remote target. I suffered from this a couple of years ago and the solution I implemented was to delegate the copy operation to a bash script and leave Ansible to just take care of uploading that script and run it passing the configured parameters.
Anyways, if the network is a problem I strongly recommend to have a look to "Ansible pull".
Find a good use case that justifies using an unstable language. This is typically internal developer tooling or testing systems.
Personally I would love a language with better type+test system than python for shuffling json around and math stuff.
Python's dict functionality feels like a big fat hack (recusive merging, splitting json, detection of subdict etc) and likewise the xml stuff (there is no guide what xml tooling to use and what is broken in what python version and a third party package is better than libstd).
First, establish that the language is the issue. Measure. It's difficult for me to imagine a situation with Ansible scripts where the performance bottleneck is the raw performance of the python runtime.
Looks really nice! one thing I instantly noticed though is the import order, would be nice if they could consider switching the path and module name around, like `from "x" import y`, not sure why modern languages would still do it like this.
I’m wondering if all values are boxed, like in Python, which is increasing RAM usage and creating a lot indirections, instead of being able to create arrays and structs where the members are located in the same block of contiguous memory.
Values seem to be nan-boxed, which means numbers are simply doubles and therefore will still be located in the same block of contiguous memory. When the higher 8 bits are FF the remaining 48 normally are an indirection pointer. So right, for anything other than numbers your cache misses increase, but storing dynamically sized objects like strings or tuples or maps continuously in array is a hard problem anyway not to mention storage in maps or in tables.
Since this is seemingly a byte code or threaded code based VM, your code execution probably also contributes to cache exhaustion.
- slicing with index or with index+length ? Well, both apparently!
- len() is a method
- ranges and slices have the same syntax
- you can use | to avoid the indentation hell that comes with '''
- true, false and none don't have an upper case first letter
- the lambda design allow for multi lines, despite the language being heavily biased toward statements. And it's using "=>".
- circular imports do not cause errors
- explicit export, although i'd prefer it to be opt in
- lua style ffi
- mapping on dict key/values is the simple case
- CYON is quite interesting
- and of course concurrency and perf from the start
But some of them will cause big troubles:
"errors are values and do not propogate up the call stack by default. Users are not forced to handle errors unless the error value is passed to a typed destination."
Yeah, silent errors in bash scripting taught me I really don't want that.
"The shorthand method for calling functions omits parentheses and commas"
The reason I still can't parse Ruby after 15 years.