Jam Programming Language

It is different: .as_raw_fd doesn't close the file, it just doesn't prevent you from closing the file.

the thing that makes Rust’s ABI unstable doesn’t exist in Jam. There are no first-class references, no lifetimes, no niche-packed layouts to erase.

This is a misunderstanding of Rust's standard library FFI-stability. Shared references, mutable references, Box, and Options thereof all have a defined, stable ABI (making the whole Box::into_raw/from_raw dance of the example pointless). Lifetimes don't even exist at the binary level. If you opt into defining a stable ABI for an enum, niche optimizations get disabled.

The reason that most types choose not to define a stable ABI is that you often don't want to have a stable ABI, as that prevents you from changing the type's internals.

Jam isn’t public yet. The compiler exists and runs, but I’m holding the language back from a wider release while I work on the things that make it usable day to day: a stable surface, a package manager, an LSP, a formatter, the rest of the tooling you only notice when it isn’t there. Shipping a language without that is shipping a sharp edge, and I’d rather take the time.

I don't understand this choice - there's a big difference between "shipping" something incomplete and just making the source available. If you're going to do it eventually, what's the harm in doing it while the project is being built? The upsides are that people who really like what you're doing can try it and potentially even contribute (but "in the age of AI" I know it's not clear that such contributions will be net positive.) It also enables people to better understand what you're building and evaluate claims about why it's great. If we can't do that the project becomes a lot less interesting.

Also should point out that people exist who use none of these tools (yes, my current team can't even agree to adopt an automated formatter, but is otherwise great) so holding back while you build them doesn't make any difference.

None of this exposes a first-class reference. There is no reference type in Jam: no value the borrow could attach to, nothing to store in a variable or return from a function or hold in a struct field. Parameter borrows are call-frame ephemera. The callee gets read or read-write access through the parameter, the access expires when the call returns, and that’s it. Jam doesn’t need lifetime annotations to make any of it safe, because there are no lifetimes to attach.

People keep trying to invent "Rust, without those pesky lifetimes!" and keep failing. The other comment covers one failure mode (part of dropped value returned because you can't return references), but the other classic one is:

let mut arr = vec![1];
let x = &arr[0];
arr.push(2);
// What happens if you use `x`?

There are 3 answers:

1. Reject it, requiring some notion of borrows (usually shared XOR mutable, b/c only mutable sucks & only shared is unsafe)
2. Accept it, because references thru another variable don't exist & everything is a GC-ed or RC-ed pointer.
3. Accept it, and cause UB at runtime.

There are good reasons to choose any of these answers, but I get the sense that Jam wants to be (1) like Rust, but is actually (2) due to its value semantics (everything gets copied). This probably prevents you from both writing data structures that are both safe & efficient.

Love new languages, but hate everything just being a frontend for llvm, i get backends are hard, but lets have at least SOME other choices some times

A major part of what makes Zig what it is is the lack of RAII, and likewise Rust is borrow checking, and where these design choices landed doesn't feel like something anyone actually needs (RAII without references). That said, I think there is space for and appreciate experimenting in this niche, I just don’t think this approach is it.

I'll throw what I have been considering, because it's an area I am thinking about constantly lately. I am hopeful about some combination of a Zig comptime, Pony-ish reference capabilities, lifetimes are comptime values, and lifetimes branded to the allocator.. the hope being Zig's allocator strategy with the reference safety, and lifetimes that you basically never have to annotate

The counter comparison between Rust and Jam in the “Safe, and C-ABI compatible” section is quite unfair:

1. The Rust code boxes the counter and has Rust own the memory and so requires counter_new and counter_free. The Jam code doesn’t box the counter, so the caller could keep it on the stack or use malloc/free at its choice. Rust would have been perfectly happy with that too (though I will freely admit that, as things grow, Rust’s aliasing guarantees will be easier to violate this way).

2. The Rust code squeezes the add functionality into counter_add. The Jam code uses an add method so that the export fn is purely a stub.

Here’s something balancing them out:

#[repr(C)]
pub struct Counter { value: i64 }

impl Counter {
    fn add(&mut self, n: i64) -> i64 {
        self.value += n;
        self.value
    }
}

#[no_mangle]
pub unsafe extern "C" fn counter_add(c: *mut Counter, n: i64) -> i64 {
    (&mut *c).add(n)
}

​

const Counter = struct {
    value: i64,
    fn add(self: mut Counter, n: i64) i64 {
        self.value = self.value + n;
        return self.value;
    }
};

export fn counterAdd(c: mut Counter, n: i64) i64 {
    return c.add(n);
}

Sounds basically like Swift to me.