Scripting Languages of the Future

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

Our great sponsors
  • SonarLint - Clean code begins in your IDE with SonarLint
  • InfluxDB - Access the most powerful time series database as a service
  • SaaSHub - Software Alternatives and Reviews
  • 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

  • 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

  • SonarLint

    Clean code begins in your IDE with SonarLint. Up your coding game and discover issues early. SonarLint is a free plugin that helps you find & fix bugs and security issues from the moment you start writing code. Install from your favorite IDE marketplace today.

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

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

  • 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

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

  • 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

  • InfluxDB

    Access the most powerful time series database as a service. Ingest, store, & analyze all types of time series data in a fully-managed, purpose-built database. Keep data forever with low-cost storage and superior data compression.

  • xonsh

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

  • 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