Scripting Languages of the Future

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • Scout APM - Less time debugging, more time building
  • SonarQube - Static code analysis for 29 languages.
  • OPS - Build and Run Open Source Unikernels
  • GitHub repo passerine

    A small extensible programming language designed for concise expression with little code.

    Tossing my hat in for Passerine [1]. Gorgeous ML inspired syntax. Built for scripting Rust applications.

    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

  • GitHub repo luster

    An experimental Lua VM implemented in pure Rust

    Tossing my hat in for Passerine [1]. Gorgeous ML inspired syntax. Built for scripting Rust applications.

    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

  • Scout APM

    Less time debugging, more time building. Scout APM allows you to find and fix performance issues with no hassle. Now with error monitoring and external services monitoring, Scout is a developer's best friend when it comes to application development.

  • GitHub repo shelljs

    :shell: Portable Unix shell commands for Node.js

    This talks a bunch about the "good run" of current scripting languages, including for example JavaScript.

    But JavaScript, as an actual scripting language, has been pretty primitive but finally starting to become a real candidate for actual scripting. There's imo crufty not very great options like shelljs[1]. But adding a tagged-template string for system(), for calling things, and a little bit of standard library has made JS a much more interesting & competent scripting language. Those efforts are being done in ZX[2].

    I like the idea of the topic, exploring it. But the author feels off in a number of places.

    > What TypeScript showed is that you could join together the idea of a flexible lightweight (and optional!) type system onto an existing programming language, and do so successfully. . . .The question then is - what if you created a programming language from the start to have this kind of support?

    Personally I just don't think languages matter very much. They're very similar, by & large. They have different tooling, packaging, somewhat different looks/feels for executing code, and their standard libraries are different. But TypeScript is popular & fast at least 90% because it is JS, because it works with JS things. Arguing that we should try to recreate TypeScript apart from JS sounds like a mind blowing waste of time. Also, Deno has good integrated TypeScript support.

    On the topic of easy parallelism, JavaScript promises are imo quite easy to stitch together & use & quite available.

    One of the main issues I see with easy-parallelism is that it's too easy: there's too many cases for uncontrolled parallelism. Throwing tarn.js or other worker-pools at problems seems all too common. But one is still left stitching together each pool/stage of work. I'd like to see SEDA[3] like architectures emerge, and perhaps get added to something like ZX standard library.

    [1] https://github.com/shelljs/shelljs

    [2] https://github.com/google/zx

    [3] https://en.wikipedia.org/wiki/Staged_event-driven_architectu...

  • GitHub repo zx

    A tool for writing better scripts

    This talks a bunch about the "good run" of current scripting languages, including for example JavaScript.

    But JavaScript, as an actual scripting language, has been pretty primitive but finally starting to become a real candidate for actual scripting. There's imo crufty not very great options like shelljs[1]. But adding a tagged-template string for system(), for calling things, and a little bit of standard library has made JS a much more interesting & competent scripting language. Those efforts are being done in ZX[2].

    I like the idea of the topic, exploring it. But the author feels off in a number of places.

    > What TypeScript showed is that you could join together the idea of a flexible lightweight (and optional!) type system onto an existing programming language, and do so successfully. . . .The question then is - what if you created a programming language from the start to have this kind of support?

    Personally I just don't think languages matter very much. They're very similar, by & large. They have different tooling, packaging, somewhat different looks/feels for executing code, and their standard libraries are different. But TypeScript is popular & fast at least 90% because it is JS, because it works with JS things. Arguing that we should try to recreate TypeScript apart from JS sounds like a mind blowing waste of time. Also, Deno has good integrated TypeScript support.

    On the topic of easy parallelism, JavaScript promises are imo quite easy to stitch together & use & quite available.

    One of the main issues I see with easy-parallelism is that it's too easy: there's too many cases for uncontrolled parallelism. Throwing tarn.js or other worker-pools at problems seems all too common. But one is still left stitching together each pool/stage of work. I'd like to see SEDA[3] like architectures emerge, and perhaps get added to something like ZX standard library.

    [1] https://github.com/shelljs/shelljs

    [2] https://github.com/google/zx

    [3] https://en.wikipedia.org/wiki/Staged_event-driven_architectu...

  • GitHub repo empirical-lang

    A language for time-series analysis

    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 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

  • GitHub repo TablaM

    The practical relational programing language for data-oriented applications

    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 gam 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.

  • GitHub repo langs-in-rust

    A list of programming languages implemented in Rust, for inspiration.

    For anyone interested in languages written in Rust, here’s a list: https://github.com/alilleybrinker/langs-in-rust

  • SonarQube

    Static code analysis for 29 languages.. Your projects are multi-language. So is SonarQube analysis. Find Bugs, Vulnerabilities, Security Hotspots, and Code Smells so you can release quality code every time. Get started analyzing your projects today for free.

  • GitHub repo xonsh

    :shell: Python-powered, cross-platform, Unix-gazing shell

  • GitHub repo proposal-record-tuple

    ECMAScript proposal for the Record and Tuple value types. | Stage 2: it will change!

    There's a proposal for immutable records and tuples: https://github.com/tc39/proposal-record-tuple

    Theoretically they would use structural sharing for their implementation which should reduce the overhead of creating a whole new array of objects like that

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts