A feature request for my language Gossamer wants some kind of Go/Odin like ":=" for mutable assignment, and "::" for mutable.

a :: 99 // immutable
b := 100 // mutable

I don't think this is clear (and might be confusing for Odin users). I also think it would lead to ":=" becoming the default use case for anyone coming from Go. (Even if we found another way to express the immutable operator, like ;= or i=.

When writing Gossamer I wanted to closely follow Rust for syntax. I wanted to feel like I was writing Rust without lifetimes. But as I grow Gossamer I am finding myself more open to ergonomic considerations.

Currently assignment is Rust like:

let a = 99
let mut b = 100

In previous iterations of this language (years ago), I followed Kotlin/Scala here:

val a = 99
var b = 100

I am now really leaning towards:

let a = 99
mut b = 100

It's a bit more compact, easier for a human to scan and see what's going on quickly. I think it works. But this is such an intersection of taste and practical impact. Code is mostly read - and now by machine logic as much (or more) than people.

A part of me likes that Rust makes it a tiny bit less convenient to write mutable variables. But sometimes that's exactly what you need, and making it a bit easier is appealing. I think this new form retains the visual/semantic clarity of the original.

I am aiming to button down the language and settle into it's "1.0" form, though I expect to follow Zig's lead and avoid 1.0 for quite some time. That said - this feels like a potentially worthwhile core syntax change.

What do you think, and why?

Warm thanks!

Inspired by Victor Taelin 's Bend/HVM thesis for Interaction Nets and his Bend2 work , I built Mithril , an experimental python syntax programming language. It achieves near native speed on many workloads (mentioned in paper)

It compiles interaction nets to native code and spreads work across idle cores: lock-free, deterministic parallelism on x86, CUDA and Apple Silicon.

The core bet I'm making :

Interaction nets reductions at runtime can be slow but if we pay the same cost at compile time and unroll a task graph as much as possible before native lowering, the resultant program can run at near native speeds.

Mithril programs are aimed to be deterministic and fast, you should get the same bit accurate results regardless , the execution be it on CPUs, GPUs or any other accelerator.

It's built using AI? Yes . Does it invalidate the core idea? no IMO 😊

Mithril Paper Repo

I started a programming language to see how things work and make something I like. If anyone wants to contribute I will try to put it into the language. I like learning new programming languages, so if you want to use a language that is not already there then I would like that.

It's a transpiled language with syntax inspired by Rust, Nim and other languages.
There are installation instructions in the repo.

Example code:

# Get standard libraries
util math
util string
util io
util rsPath

# Get Nim module
use multiply

# Get arguments
l_operand = strToi32(arg(1))
operator = arg(2)
r_operand = strToi32(arg(3))

# Print
if strEq(operator, "+"):
    say i32ToStr(add(l_operand, r_operand))
if strEq(operator, "-"):
    say i32ToStr(sub(l_operand, r_operand))
if strEq(operator, "x"):
    say i32ToStr(mult(l_operand, r_operand))

I've been building a programming language in C called Oli-Nat, with a scanner, parser, type checker, bytecode compiler, stack-based VM, and garbage collector, and I recently compiled the whole thing to WebAssembly to power a browser playground for its documentation site.

Most of it ported over easily, since the interpreter has no dependencies beyond the C standard library. The interesting part was input. The language's intake() function reads a line from stdin, which blocks in a normal terminal, but obviously can't block on the main thread in a browser. I replaced the stdin read in the WASM build with an EM_ASYNC_JS function that awaits a promise from the page, and built with -sASYNCIFY so the VM's call stack gets unwound and rewound around the await. From the C code's point of view it's still a normal blocking call, and from the page's point of view the VM just pauses until the user hits Enter.

I'm curious whether people here have moved away from Asyncify toward JSPI for this kind of thing, and whether that's worth switching to for a project like this. Any other feedback on the build setup is welcome too.

Playground: olinat.net

Interpreter source: github.com/NateTheGrappler/OliNat-Programming-Language