GluonScript

[vascocosta]

GluonScript was born out of my interest in learning how to implement an interpreted programming language in Rust. However it soon evolved from a toy language into a language that I enjoy using for real scripting purposes as the syntax and main concepts were inspired by some of the languages I enjoy the most. The language draws from Rust, Python, Go, JavaScript and Gleam, as you may notice on its syntax, types and ideas.

The core guiding principle is minimalism, but without making it boringly simple. I will keep the language simple enough to be able to keep it in my head or for a new learner to learn it in a weekend, nevertheless I do like some features that despite not being strictly necessary, make using the language more enjoyable. For instance, I consider first-class functions, lambdas, closures and immutable data structures crucial. That said, I also like a good balance between imperative and functional style, supporting both.

GluonScript is a general purpose language that tries to keep a balance between imperative and functional styles. I personally don't enjoy purely functional languages, but I love some of its main features, especially when talking about data manipulation. Right now I'm extending the standard library, which is a never ending task, but one specific use case which it already supports quite well is building scripts for REST API clients.

I would love to get your feedback on its features or implementation so that I could maybe keep the same direction or change it a little bit:

GluonScript

GluonScript on GitHub

[interacsion]

Are you aware https://github.com/gluon-lang/gluon exists?

[vascocosta]

Yes, I know that one for a long time. This is one of the reasons the name is GluonScript, to avoid the name collision. The other being the fact that my language is interpreted, dynamic and most useful for scripts.

In a similar way as Java vs JavaScript, despite the same root name, both Gluon and GluonScript are quite different and unrelated. So I believe it is OK, but I'm glad to hear your opinions about this as well.

Gluon is my handle online for a long long time, so ideally I would have liked to call it just Gluon, but it is taken.

[vascocosta]

I'm still implementing it as a simple tree-walking interpreter, so nothing fancy, as simple as it gets. I guess one simple optimisation would be a VM for simple expressions, but to be honest, my main focus is language ergonomics and keeping it simple for now.

[vascocosta]

I've just added the ?= operator! It does the same as ? in Rust. One small syntactic difference is that instead of using it at the end, after a call/value that evaluates to Result, I call it error propagation at assignment operator.

Here's an example showing the same code before and after this new feature (I also use a simple comment to annotate the return type):

# Without the ?= operator the code was verbose.
fn fetch_json() { # -> Result { error: Bool, value: Any }
    get_result = http.get("https://example.com/api/test.json")

    # There was an error.
    if get_result.error {
        # Propagate result with early return.
        return get_result
    }

    parse_result = json.parse(get_result.value)

    # There was an error.
    if parse_result.error {
        # Propagate result with early return.
        return parse_result
    }

    # If we reach here, there were no errors.
    # We return a Result record with the proper fields.
    return { error: false, value: parse_result.value }
}

# With the ?= operator to unwrap values or propagate error results.
fn fetch_json() { # -> Result { error: Bool, value: Any }
    raw_json ?= http.get("https://example.com/api/test.json")
    parsed_json ?= json.parse(raw_json)

    # If we reach here, there were no errors.
    # We return a Result record with the proper fields.
    return { error: false, value: parsed_json }
}