Rue: Higher level than Rust, lower level than Go

It didn't not even had compiler intrisics, a concept introduced by ESPOL in 1961, allowing to program Burroughs systems without using an external Assembler.

K&R C was high level enough that many of the CPU features people think about nowadays when using compiler extensions, as they are not present in the ISO C standard, had to be written as external Assembly code, the support for inline Assembly came later.

rust is cool. a lot of really cool software im finding these days is written in rust these days & i know im missing some kind of proverbial boat here. but rusts syntax breaks my brain and makes it eject completely. it's just enough to feel like it requires paradigm shifts for me, and while others are really good at hopping between many languages it's just a massive weakness of mine. i just cant quite figure out the ergonomics of rust so that it feels comfy, my brain seems to process everything through a c-lens and this is just a flaw of mine that makes me weak in software.

golang was started by some really notable brains who had lots of time in the game and a lot of well thought out philosophies of what could be done differently and why they should do it differently coming from c. there was almost a socio-economic reason for the creation of go - provide a lang that people could easily get going in and become marketable contributors that would help their career prospects. and i think it meets that mark, i was able to get my jr engineers having fun in golang in no time at all & that's panned out to be a huge capability we added to what our team can offer.

i like the objective of rue here. reviewing the specification it actually looks like something my brain doesn't have any qualms with. but i dont know what takes a language from a proposal by one guy and amplifies it into something thats widely used with a great ecosystem. other minds joining to contribute & flesh out standard libraries, foundations backing, lots of evangelism. lots of time. i won't write any of those possibilities off right now, hopefully if it does something right here there's a bright future for it. sometimes convincing people to try a new stack is like asking them to cede their windows operating system and try out linux or mac. we've watched a lot of languages come and go, we watch a lot of languages still try to punch thru their ceilings of general acceptance. unlike some i dont really have huge tribalistic convictions of winners in software, i like having options. i think it's pretty damn neat that folks are using their experiences with other languages to come up with strong-enough opinions of how a language should look and behave and then.. going out and building it.

just as you’re annoyed by low-effort LLM posts/comments, I’m annoyed by low-effort “this sounds like it was written by ChatGPT” comments (hence my response and at least a possible explanation of downvotes)

edit: I also scrolled through, you’re absolutely right! it does look like a low-effort bot

It looks like the idea at the present time is to have four modes: value types, affine types, linear types, and rc types. Instead, of borrowing, you have an inout parameter passing convention, like Swift. Struct fields cannot be inout, so you can't store borrowed references on the heap.

I'm very interested in seeing how this works in practice--especially given who is developing Rue. It seems like Rust spends a lot of work enabling the borrow checker to be quite general for C/C++-like usage. E.g. you can store a borrowed reference to a struct on the stack into the heap if you use lifetime annotations to make clear the heap object does not outlive the stack frame. On the other hand it seems like a lot of the pain points with Rust in practice are not the lifetime annotations, but borrowing different parts of the same object, or multiple borrows in functions further down the call stack, etc.

C has unions, but they're not tagged. You can roll your own tagged unions, of course, but that's moving beyond it being a feature of the language.

> How would you model this in Go?

I'm committing the same earlier sin by trying to model it from the solution instead of the problem, so the actual best approach might be totally different, but at least in staying somewhat true to your code:

    type OpComponent interface { op() }
    type Op = []OpComponent

    type Skip struct { Value int }
    func (s Skip) op() {}
    type Insert struct { Value string }
    func (i Insert) op() {}
    type Delete struct { Value int }
    func (d Delete) op() {}

    op := Op{
        Skip{Value: 5},
        Insert{Value: "hello"},
        Delete{Value: 3},
    }