Scripting Languages of the Future

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

InfluxDB - Power Real-Time Data Analytics at Scale
Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
www.influxdata.com
featured
SaaSHub - Software Alternatives and Reviews
SaaSHub helps you find the best software and product alternatives
www.saashub.com
featured
  • 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

  • piccolo

    An experimental stackless Lua VM implemented in pure Rust (by kyren)

  • 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

  • InfluxDB

    Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

    InfluxDB logo
  • 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

  • SaaSHub

    SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives

    SaaSHub logo
  • 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

  • Jeffrey Snower was originally demoted over PowerShell

    2 projects | news.ycombinator.com | 8 May 2022
  • How would you change/remake your favourite programming language? (Inspired by a post on r/javascript)

    4 projects | /r/programming | 20 Apr 2022
  • A single person answered 76k questions about SQL on StackOverflow. Averaging 22.8 answers per day, every day, for the past 8.6 years.

    3 projects | /r/programming | 24 Sep 2021
  • Ask HN: What to use instead of Bash / Sh

    7 projects | news.ycombinator.com | 10 Apr 2021
  • Google/Zx v8.1

    1 project | news.ycombinator.com | 13 May 2024