Tossing my hat in for Passerine [1]. Gorgeous ML inspired syntax. Written in Rust, and I suspect scripting Rust libraries is in the cards.
Dreaming here: Lua is a fantastic scripting language, but the Rust FFI isn’t as ergonomic as it could be. Enter Luster [2], which is basically LuaJIT rewritten in Rust.
Embedding a scripting language in a Rust application gives you tons of power (e.g. scripting Rust structs from Lua [3]), and setting this up isn’t terribly difficult.
> Tossing my hat in for Passerine [1]. Gorgeous ML inspired syntax.
I work on Passerine, cool to see the language mentioned in the wild, glad you like it!
> Written in Rust, and I suspect scripting Rust libraries is in the cards.
We have a rudimentary FFI to Rust already in place. We're also working on a proc macro lib for creating high-level bindings to Rust types/functions/crates (currently unreleased). Also working on an algebraic-effect-based system-injection engine, which will replace the FFI in the 0.10.0 or 0.11.0 release :)
Don't get too focused on "scripting". making one today and you learn quickly, that scripting/compiled is blurred. Eventually, both will borrow a little of the other to be more performant or useful.
---
I'm building on the side one (https://tablam.org) that is focused in the "crud" kind of apps and exist a lot of low-hanging fruit there. Simple stuff like making the paradigm relational/array from the start, support for decimals (and money and quantities?), in-built auto-vectorization (that comes almost for free when adding a bit of array languages) and a lot of other stuff I can't even explored yet.
Current scripting languages are not there yet in ergonomic or features to the kind of apps we actually do (ie: The popular ones, you bet niche experiments like mine are there on way or another).
---
And the challenge is even harder today!. In the article is mentioned better support for IDEs, that is more thought that I have expected!. This requiere a more sophisticate parsing pipeline and not much experience there around...
Also: Concurrency/parallelims. I don't think exist a truly nice ergonomic there. Sure, async/await is a little better, but none of the things I have experienced (with exception of SQL and magic) is something I could give to a "scripting user". You still need a complicated understanding of this, plus how express that in code.
Plus: Performance. Is possible to build very fast "scripting" languages! But is VERY hard to be fast across many workloads :(
And is terrible, because the kind of developers don't use them (C/c++ cough) will complain LOUDLY how terrible them are, and how you must not use them, when certain workload is not as optimal!
The author seems to basically be describing Dart 1, which wasn't actually all that successful. It was a dynamic language with optional typing and it excluded some of the hard to optimize parts of e.g. Ruby, JavaScript or Python. Whether it wasn't successful because of technical reasons or other reasons is perhaps hard to untangle, but the philosophy seemed very close to what this post argues for. Dart moved away from that though and went for static and sound typing instead with Dart 2 and seems to have carved out more of a niche that way.
It truly baffles me why Dart never picked up(ignoring flutter since it's in it's core). It is magnitudes better thought out than js, it is consistent and it comes with a ton of features baked into it by design(package management, statically typed, null safety, built-in linter and so on, all of which are available but as afterthoughts in js).
The main issue was that it was seen as Google pushing a language that people would have to support forever that wasn't really that much better than JavaScript.
That argument turned out to be more or less nonsense - if supporting language features forever is really an issue why have so many features been added to JavaScript?
But even so I think it was probably a good thing it didn't become a web standard because Dart has become way way better than it ever could have been had it been standardised.
Modern Dart is great. The problem now is that so is modern Typescript. Especially if you use it via Deno - in a lot of ways it is better than Dart.
I really like Dart and I wish it was more popular but I think it's too late for it to have any hope of beating Typescript.
Another language that comes to mind is Groovy.
Types are optional, but when used, they are checked at runtime, or compile time with `@TypeChecked` or `@CompileStatic`.
Groovy is absolutely phenomenal for scripting. Optionally typed, has the entire Java ecosystem of libraries available (with no extra download or build files neccessary), very good IDE support, mature, extremely rich common library, great performance.
I've built entire prototypes in Groovy at amazing speeds and then gradually replaced individual files with Java/Kotlin code and made sure the entire thing still worked. When I had grabbed everything of value I copied the resulting Java/Kotlin files to the real codebase and deleted the prototype. I could've left them in Groovy, too, as it is quite performant enough, alas customers preferred Java/Kotlin.
Exactly the same experience. "Elm on the server" was on my dream list before choosing Elm over Typescript, but Roc seems to be so much more. Very exciting!
Some of the OP's observations are why I wrote Empirical [1].
- I wanted static types that felt dynamic, which meant being able to infer types from a file as long as the file path can be determined at compile time.
- I wanted Dataframes to be a first-class container since the high-level of abstraction leads to great performance when doing analytics.
Therefore, I created a language with statically typed Dataframes. Empirical can infer a CSV's type at compile time, namely because it performs compile-time function evaluation automatically. The result is a language that runs easily in a REPL but can be used for long-running scripts without worrying about common programming errors.
I sometimes wonder to myself: what programming challenges would come up in something like the starship Enterprise (any of them) and what new language constructs (if any) would be required to address them?
In star trek they just tell the computer what they want to do in a very high level way like "computer, can you average the natural disaster data on Proxima 5's moon"? There is no file handles to open a .CSV file and find the right column and so forth.
I think there will need to be work with things that essentially are what we think of as speculative execution today. This is because I’m sure there will be need to interact with considerably more systems, threads, messages, instructions whatever in the scope of an interstellar starship.
And no doubt some advances will be necessary in terms of AI to handle the calculations. I don’t know what those calculations are, but I’m sure they’re difficult :)
I think about the voice interface to the various computers. Really complex interactions. Always on. Rapidly changing contexts. Historic conversations. Different languages.
I’m sure storage is an issue. Something to do with compression algorithms. And decompression. Probably encryption and security.
Challenges in redundancy might be hardware or materials problems.
Most of them are hard for me to even articulate plainly :)
The history of scripting languages is that they were really just a total joy for many C or C++ programmers that were tired of all the minutiae and ritual involved with those languages. Many picked one up, usually Perl or to a lesser extent at the time, Python, and enjoyed the heck out of either of them for web development, and scripting out file or text processing tasks.
That origin has really been lost, and people went on to give scripting languages a life of their own.
For me C++ is C#, and while I generally try to apply this language everywhere, my Perl equivalent would probably be Powershell. For some it might be C++ and Ruby, or Rust and Python.
I think there's enough work to be done in this field that there's going to be room for plenty of Python, Javascript, and other scripting language codebases.
New languages are all going to look pretty similar to what came before, because those raised on them are going to borrow elements that they're familiar with. Just like for me how the ideal programming language is or would look a lot like C#. As long as a language fits your technical needs on maintenance and performance grounds, and has the abstractions and keywords to properly express your ideas, it really doesn't matter what it looks like.
If .NET AOT experience had been a proper one, instead of just NGEN, and there wasn't so much politics between WinDev and DevDiv, I bet we would be enjoying it much more on Windows, but so is life, we get COM toys to wrap ourselves to call from .NET instead.
I guess they are just helping us to keep our C++ skills up to date. /s
Readit News
Dreaming here: Lua is a fantastic scripting language, but the Rust FFI isn’t as ergonomic as it could be. Enter Luster [2], which is basically LuaJIT rewritten in Rust.
Embedding a scripting language in a Rust application gives you tons of power (e.g. scripting Rust structs from Lua [3]), and setting this up isn’t terribly difficult.
[1]: https://github.com/vrtbl/passerine
[2]: https://github.com/kyren/luster
[3]: https://git.sr.ht/~ioiojo/kiwi
I work on Passerine, cool to see the language mentioned in the wild, glad you like it!
> Written in Rust, and I suspect scripting Rust libraries is in the cards.
We have a rudimentary FFI to Rust already in place. We're also working on a proc macro lib for creating high-level bindings to Rust types/functions/crates (currently unreleased). Also working on an algebraic-effect-based system-injection engine, which will replace the FFI in the 0.10.0 or 0.11.0 release :)
Deleted Comment
---
I'm building on the side one (https://tablam.org) that is focused in the "crud" kind of apps and exist a lot of low-hanging fruit there. Simple stuff like making the paradigm relational/array from the start, support for decimals (and money and quantities?), in-built auto-vectorization (that comes almost for free when adding a bit of array languages) and a lot of other stuff I can't even explored yet.
Current scripting languages are not there yet in ergonomic or features to the kind of apps we actually do (ie: The popular ones, you bet niche experiments like mine are there on way or another).
---
And the challenge is even harder today!. In the article is mentioned better support for IDEs, that is more thought that I have expected!. This requiere a more sophisticate parsing pipeline and not much experience there around...
Also: Concurrency/parallelims. I don't think exist a truly nice ergonomic there. Sure, async/await is a little better, but none of the things I have experienced (with exception of SQL and magic) is something I could give to a "scripting user". You still need a complicated understanding of this, plus how express that in code.
Plus: Performance. Is possible to build very fast "scripting" languages! But is VERY hard to be fast across many workloads :(
And is terrible, because the kind of developers don't use them (C/c++ cough) will complain LOUDLY how terrible them are, and how you must not use them, when certain workload is not as optimal!
“scripting” is an application domain, and a scripting language is one focussed on that domain (and, yes, its a domain with blurry boundaries.)
“interpreted/compiled” is a (blurred, sure) implementation distinction.
scripting languages tend to be interpreted, but talking about scripting vs. compiled is conflating two different axes of description.
Js has been for years but I thought both Python, PHP and Ruby were working in that direction. That sounds like all the major ones to me.
That argument turned out to be more or less nonsense - if supporting language features forever is really an issue why have so many features been added to JavaScript?
But even so I think it was probably a good thing it didn't become a web standard because Dart has become way way better than it ever could have been had it been standardised.
Modern Dart is great. The problem now is that so is modern Typescript. Especially if you use it via Deno - in a lot of ways it is better than Dart.
I really like Dart and I wish it was more popular but I think it's too late for it to have any hope of beating Typescript.
For scripting, a shout out to Dart CLI:
https://pub.dev/packages/dcli
I've built entire prototypes in Groovy at amazing speeds and then gradually replaced individual files with Java/Kotlin code and made sure the entire thing still worked. When I had grabbed everything of value I copied the resulting Java/Kotlin files to the real codebase and deleted the prototype. I could've left them in Groovy, too, as it is quite performant enough, alas customers preferred Java/Kotlin.
[1]: https://www.roc-lang.org/
- I wanted static types that felt dynamic, which meant being able to infer types from a file as long as the file path can be determined at compile time.
- I wanted Dataframes to be a first-class container since the high-level of abstraction leads to great performance when doing analytics.
Therefore, I created a language with statically typed Dataframes. Empirical can infer a CSV's type at compile time, namely because it performs compile-time function evaluation automatically. The result is a language that runs easily in a REPL but can be used for long-running scripts without worrying about common programming errors.
[1] https://www.empirical-soft.com
https://www.wolframalpha.com/
And no doubt some advances will be necessary in terms of AI to handle the calculations. I don’t know what those calculations are, but I’m sure they’re difficult :)
I think about the voice interface to the various computers. Really complex interactions. Always on. Rapidly changing contexts. Historic conversations. Different languages.
I’m sure storage is an issue. Something to do with compression algorithms. And decompression. Probably encryption and security.
Challenges in redundancy might be hardware or materials problems.
Most of them are hard for me to even articulate plainly :)
That origin has really been lost, and people went on to give scripting languages a life of their own.
For me C++ is C#, and while I generally try to apply this language everywhere, my Perl equivalent would probably be Powershell. For some it might be C++ and Ruby, or Rust and Python.
I think there's enough work to be done in this field that there's going to be room for plenty of Python, Javascript, and other scripting language codebases.
New languages are all going to look pretty similar to what came before, because those raised on them are going to borrow elements that they're familiar with. Just like for me how the ideal programming language is or would look a lot like C#. As long as a language fits your technical needs on maintenance and performance grounds, and has the abstractions and keywords to properly express your ideas, it really doesn't matter what it looks like.
I guess they are just helping us to keep our C++ skills up to date. /s