I wonder if it's useful to think of this as go is low type-system-complexity and rust is high type-system-complexity. Where type system complexity entails a tradeoff between the complexity of the language and how powerful the language is in allowing you to define abstractions.

As an independent axis from close to the underlying machine/far away from the underlying machine (whether virtual like wasm or real like a systemv x86_64 abi), which describes how closely the language lets you interact with the environment it runs in/how much it abstracts that environment away in order to provide abstractions.

Rust lives in high type system complexity and close to the underlying machine environment. Go is low type system complexity and (relative to rust) far from the underlying machine.

Rue author here, yeah I'm not the hugest fan of "low level vs high level" framing myself, because there are multiple valid ways of interpreting it. As you yourself demonstrate!

As some of the larger design decisions come into place, I'll find a better way of describing it. Mostly, I am not really trying to compete with C/C++/Rust on speed, but I'm not going to add a GC either. So I'm somewhere in there.

Yep. This was the biggest thing that turned me off Go. I ported the same little program (some text based operational transform code) to a bunch of languages - JS (+ typescript), C, rust, Go, python, etc. Then compared the experience. How were they to use? How long did the programs end up being? How fast did they run?

I did C and typescript first. At the time, my C implementation ran about 20x faster than typescript. But the typescript code was only 2/3rds as many lines and much easier to code up. (JS & TS have gotten much faster since then thanks to improvements in V8).

Rust was the best of all worlds - the code was small, simple and easy to code up like typescript. And it ran just as fast as C. Go was the worst - it was annoying to program (due to a lack of enums). It was horribly verbose. And it still ran slower than rust and C at runtime.

I understand why Go exists. But I can't think of any reason I'd ever use it.

Agree with Go being basically C with string support and garbage collection. Which makes it a good language. I think rust feels more like a c++ replacement. Especially syntactically. But each person will say something different. If people can create new languages and there's a need then they will. Not to say it's a good or bad thing but eventually it would be good to level up properly. Maybe AI does that.

C was designed as a high level language and stayed so for decades

I am playing around with this! I'm mostly interested in something in the space of linear types + mutable value semantics.

Check out V-lang ... it has the details. It's a beautiful language... but, mostly unknown.

> The typical Go story is to use a bunch of auto generation, so a small change quickly blows up as all of the auto generate code is checked into git. Like easily a 20x blowup.

Why do you think the typical Go story is to use a bunch of auto generation? This does not match my experience with the language at all. Most Go projects I've worked on, or looked at, have used little or no code generation.

I'm sure there are projects out there with a "bunch" of it, but I don't think they are "typical".

Yeah, this is a hard problem, and you're right that both have upsides and downsides. Metaprogramming isn't easy!

I know I don't want to have macros if I can avoid them, but I also don't forsee making code generation a-la-Go a first class thing. I'll figure it out.

FYI rust-analyzer can show expanded macros. It's not perfect because you only get syntax highlighting, but it works.

The "just generate go code automatically then check it in" is a massive miswart from the language, and makes perfect sense because that pathological pattern is central to how google3 works.

A ton of google3 is generated, like output from javascript compilers, protobuf serialization/deserialization code, python/C++ wrappers, etc.

So its an established Google standard, which has tons of help from their CI/CD systems.

For everyone else, keeping checked-in auto-generated code is a continuous toil and maintenance burden. The Google go developers don't see it that way of course, because they are biased due to their google3 experience. Ditto monorepos. Ditto centralized package authorities for even private modules (my least fave feature of Go).

I posted that, and also https://steveklabnik.com/writing/thirteen-years-of-rust-and-...

Just to link them all together. This is the one that the algorithm picked up :)

Yes, I started off with the idea that Rue's syntax would be a strict subset of Rust's.

I may eventually diverge from this, but I like Rust's syntax overall, and I don't want to bikeshed syntax right now, I want to work on semantics + compiler internals. The core syntax of Rust is good enough right now.

Something like Borgo https://borgo-lang.github.io/

What would be better?

I am very interested in Hylo! I think they're playing in similar spaces. I'd like to explore mutable value semantics for Rue.

One huge difference is that Hylo is using LLVM, whereas I'm implementing my own backends. Another is that Hylo seems to know what they want to do with concurrency, whereas I really do not at all right now.

I think Hylo takes a lot of inspiration from Swift, whereas I take more inspiration from Rust. Swift and Rust are already very similar. So maybe Hylo and Rue will end up like this: sister languages. Or maybe they'll end up differently. I'm not sure! I'm just playing around right now.

I landed non-generic enums this evening. I'm not 100% sure what abstraction paths I want to go down. But I see sum types as just as important as product types, for sure.

Would someone please explain to me why TCO—seemingly alone amongst the gajillions of optimization passes performed by modern compilers—is so singularly important to some people?

I only have basic constant folding yet in terms of optimizations, but I'm very aware of TCO. I haven't decided if I want to require an annotation to guarantee it like Rust is going to.

Plus we all know that fibs = 1 : 1 : zipWith (+) fibs (tail fibs) is the only serious Fibonacci implementation.

"Well you can judge the whole world on the sparkle that you think it lacks.

Yes, you can stare into the abyss, but it's staring right back"

In Rust you can have structs with any number of methods defined on them, which is functionally not that different from a class. You get interface like behavior with traitsz and you get encapsulation with private/public data and methods.

Does inheritance really matter that much?

I respect your preferences, but I am unlikely to add this sort of OOP. Ideally there'll be no subtyping at all in Rue. So you'll have to keep waiting, I'm afraid. Thanks for checking it out regardless!

As a long time C++ user, I’m curious why you like inheritance and virtual methods so much.

I maintain a medium sized, old-ish C++ code base. It uses classes and inheritance and virtual methods and even some multiple inheritance. I despise this stuff. Single Inheritance is great until you discover that you have a thing that doesn’t slot nicely into the hierarchy or when you realize that you want to decompose an interface (cough, base class) into a couple of non-hierarchically related things. Multiple inheritance is an absolute mess unless you strictly use base classes with pure virtual methods and no member variables. And forcing everything into an “is a” relationship instead of a “has a” relationship can be messy sometimes.

I often wish C++ had traits / or Haskell style type classes.

One thing working on this project has already done is give me more appreciation for a lot of Zig's design.

Zig really aims to be great at things I don't imagine Rue being useful for, though. But there's lots of good stuff there.

And lots of respect to Swift as well, it and Hylo are also major inspiration for me here.

Checkout Borgo: https://github.com/borgo-lang/borgo

I also find that D is good between language. You can do high level or low level whenever you need it.

You can also do some inbetween systems programming in C# if you don’t care about a VM or msft.

I don't plan on implementing ARC, I don't think. I do think Swift/Hylo mutable value semantics is a neat idea that I do want to play around with.