* macro abuse. E.g. bitshift storing like in C needs a bunch of #[...] derive_macros. Clap also uses them too much, because a CLI parameter is more complex than a struct field. IDK what's a sane approach to fixing this, maybe like in Jai, or Zig? No idea.

* Rust's async causes lots of pain and side effects, Golang's channels seem better way and don't make colored functions

* Rust lacks Python's generators, which make very elegant code (although, hard to debug). I think if it gets implemented, it will have effects like async, where you can't keep a lock over an await statement.

Zig's way is just do things in the middle and be verbose. Sadly, its ecosystem is still small.

I'd like to see something attacking these problems.

Noted, thanks for the comment. I share some of these opinions more than others, but it’s always good to get input.

But the real test is compile times and cognitive overhead. Rust's borrow checker is theoretically elegant but practically brutal when you're learning or debugging. If Rue can achieve memory safety without lifetime annotations everywhere, that's genuinely valuable. However, I'm skeptical - you can't eliminate tradeoffs, only move them around. If there's no borrow checker, what prevents use-after-free? If there's garbage collection, why claim "lower level than Go"?

The other critical factor is ecosystem maturity. Rust's pain is partially justified by its incredible crate ecosystem - tokio, serde, axum, etc. A new language needs either (1) seamless C FFI to bootstrap libraries, (2) a killer feature so valuable that people rewrite everything, or (3) 5+ years for the ecosystem to develop. Which path is Rue taking?

I'd love to see real-world benchmarks on: compile time for a 50k line project, memory usage of a long-running web server compared to Rust/Go, and cold start latency for CLI tools. Those metrics matter more than theoretical performance claims. The "fun to write" claim is subjective but important - if it's genuinely more ergonomic than Rust without sacrificing performance, that could attract the "Python developers wanting systems programming" demographic.

I do agree that those benchmarks are important. Once I have enough language features to make such a thing meaningful, I’ll be tracking them.

Where did I write that it’s fun to write?

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.

I don't think that's right. The level of abstraction is the number of implementations that are accepted for a particular interface (which includes not only the contract of the interface expressed in the type system, but also informally in the documentation). E.g. "round" is a higher abstraction than "red and round" because the set of round things is larger than the set of red and round things. It is often untyped languages that offer the highest level of abstraction, while a sophisticated type system narrows abstraction (it reduces the number of accepted implementations of an interface). That's not to say that higher abstraction is always better - although it does have practical consequences, explained in the next paragraph - but the word "abstraction" does mean something specific, certainly more specific than "describing things".

How the level of abstraction is felt is by considering how many changes to client code (the user of an interface) is required when making a change to the implementation. Languages that are "closer to the underlying machine" - especially as far as memory management goes - generally have lower abstraction than languages that are less explicit about memory management. A local change to how a subroutine manages memory typically requires more changes to the client - i.e. the language offers a lower abstraction - in a language that's "closer to the metal", whether the language has a rich type system like Rust or a simpler type system like C, than a language that is farther away.

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.

I almost never even think about the borrow checker. If you have a long-lived shared reference you just Arc it. If it's a circular ownership structure like a graph you use a SlotMap. It by no means is any harder for this codebase than for small ones.

The borrow checker does make some tasks more complex, without a doubt, because it makes it difficult to express something that might be natural in other languages (things including self referential data structures, for instance). But the extra complexity is generally well scoped to one small component that runs into a constraint, not to the project at large. You work around the constraint locally, and you end up with a public (to the component) API which is as well defined and as clean (and often better defined and cleaner because rust forces you to do so).

I will say, that for most of the Rust code that I've read, the vast majority of it has been easy enough to read and understand... more than most other languages/platforms. I've seen some truly horrendous C# and Java projects that don't come close to the simplicity of similar tasks in Rust.

Async is an irritation but not the end of the world ... You can write non asynchronous code I have done it ... Honestly I am coming around on async after years of not liking it... I wish we didn't have function colouring but yeah ... Here we are....

I still regularly use typescript. One problem I run into from time to time is "spooky action at a distance". For example, its quite common to create some object and store references to it in multiple places. After all, the object won't be changed and its often more efficient this way. But later, a design change results in me casually mutating that object, forgetting that its being shared between multiple components. Oops! Now the other part of my code has become invalid in some way. Bugs like this are very annoying to track down.

Its more or less impossible to make this mistake in rust because of how mutability is enforced. The mutability rules are sometimes annoying in the small, but in the large they tend to make your code much easier to reason about.

C has multiple problems like this. I've worked in plenty of codebases which had obscure race conditions due to how we were using threading. Safe rust makes most of these bugs impossible to write in the first place. But the other thing I - and others - run into all the time in C is code that isn't clear about ownership and lifetimes. If your API gives me a reference to some object, how long is that pointer valid for? Even if I now own the object and I'm responsible for freeing it, its common in C for the object to contain pointers to some other data. So my pointer might be invalid if I hold onto it too long. How long is too long? Its almost never properly specified in the documentation. In C, hell is other people's code.

Rust usually avoids all of these problems. If I call a function which returns an object of type T, I can safely assume the object lasts forever. It cannot be mutated by any other code (since its mine). And I'm not going to break anything else if I mutate the object myself. These are really nice properties to have when programming at scale.

> If I call a function which returns an object of type T, I can safely assume the object lasts forever. It cannot be mutated by any other code (since its mine). And I'm not going to break anything else if I mutate the object myself. These are really nice properties to have when programming at scale.

I rarely see this mentioned in the way that you did, and I'll try to paraphrase it in my own way: Rust restricts what you can do as a programmer. One can say it is "less powerful" than C. In exchange for giving up some power, it gives you more information: who owns an object, what other callers can do with that object, the lifetime of that object in relation to other objects. And critically, in safe Rust, these are _guarantees_, which is the essence of real abstraction.

In large and/or complicated codebases, this kind of information is critical in languages without garbage garbage collection, but even when I program in languages with garbage collection, I find myself wanting this information. Who is seeing this object? What do they know about this object, and when? What can they do with it? How is this ownership flowing through the system?

Most languages have little/no language-level notion of these concepts. Most languages only enforce that types line up nominally (or implement some name-identified interface), or the visibility of identifiers (public/private, i.e. "information hiding" in OO parlance). I feel like Rust is one of the first languages on this path of providing real program dataflow information. I'm confident there will be future languages that will further explore providing the programmer with this kind of information, or at least making it possible to answer these kinds of questions easier.

Your paraphrasing reminds me a bit of structured vs. unstructured programming (i.e., unrestricted goto). Like to what you said, structured programming is "less powerful" than unrestricted goto, but in return, it's much easier to follow and reason about a program's control flow.

At the risk of simplifying things too much, I think some other things you said make for an interesting way to sum this up - Rust does for "ownership flow"/"dataflow" what structured programming did for control flow.

If anything, borrow checker makes writing functions harder but combining them easier.

Typescript also lacks enums. Why wasn't it considered annoying?

I mean, technically it does have an enum keyword that offers what most would consider to be enums, but that keyword behaves exactly the same as what Go offers, which you don't consider to be enums.

So it works for those types of employers and employees who need more performance than Node.js, but can't use C for practical reasons, or can't use Rust because specific libraries don't exist as readily supported by comparison.

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.

There are quantitative ways of describing it, at least on a relative level. "High abstraction" means that interfaces have more possible valid implementations (whether or not the constraints are formally described in the language, or informally in the documentation) than "low abstraction": https://news.ycombinator.com/item?id=46354267

Out of curiosity, how would you compare the goals of Rue with something like D[0] or one of the ML-based languages such as OCaml[1]?

EDIT:

This is a genuine language design question regarding an imperative/OOP or declarative/FP focus and is relevant to understanding the memory management philosophy expressed[2]:

  No garbage collector, no manual memory management. A work 
  in progress, though.

1 - https://ocaml.org/

2 - https://rue-lang.dev/

As for Go... I dunno. Go has a strong vision around concurrency, and I just don't have one yet. We'll see.

If this ever becomes a production thing, then I can worry about FFI, and I'll probably just follow what managed languages do here.

I couldn't see how long-running memory is handled, is it handled similar to Rust?

I'm totally unsure about async.

Right now there's no heap memory at all. I'll get there :) Sorta similar to Rust/Swift/Hylo... we'll see!

That said, I'm an embedded dev, so the "level" idea is very tangible. And Rust is also very exciting for that reason and Rue might be as well. I should have a look, though it might not be on the way to be targeting bare metal soon. :)

You should use Rust for embedded, I doubt Rue will ever be good for it.

It is similar to PyTorch (which I also like), where you can add two tensors by hand, or have your whole network as a single nn.Module.

C was designed as a "high level language" relative to the assembly languages available at the time and effectively became a portable version of same in short order. This is quite different to other "high level languages" at the time, such as FORTRAN, COBOL, LISP, etc.

> No garbage collector, no manual memory management. A work in progress, though.

I couldn't find an explanation in the docs or elsewhere how Rue approaches this.

If not GC, is it via:

a) ARC

b) Ownership (ala Rust)

c) some other way?

https://gchandbook.org/

It transpiles to Zig, so you have native access to the entire C library.

It uses affine types (simple ownership -> transfers via GIVE/TAKES), MVCC & transactions to safely and scalably handle mutations (like databases, but it scales linearly after 32 cores, Arc and RwLock fall apart due to Cache Line Bouncing).

It limits concurrent complexity only to the spot in your code WHERE you want to mutate shared memory concurrently, not your entire codebase.

It's memory and liveness safe (Rust is only memory safe) without a garbage collector.

It's simpler than Go, too, IMO - and more predictable, no GC.

But it's nearly impossible to beat Go at its own game, and it's not zero overhead like Rust - so I'm pessimistic it's in a "sweet spot" that no one will be interested in.

Time will tell.

What's the practical implication of this - how does a Rue program differ from a Rust program? Does your method accept more valid programs than the borrow checker does?

Mutable value semantics means no references at all, from a certain perspective.

You can sort of think of linear types as RAII where you must explicitly drop. Sorta.

“More programs” isn’t really the right way to think about it. Different semantics, so different programs :)

(And sorry to hear about your brother's passing.)

Anyhow, I just thought it might be a good jumping off point for what you're exploring.

May be an interesting approach. That language seems very academic and slow moving at the moment though.

Do you see this as a prototype language, or as something that might evolve into something production grade? What space do you see it fitting into, if so?

You've been such a huge presence in the Rust space. What lessons do you think Rue will take, and where will it depart?

I see compile times as a feature - that's certainly nice to see.

It's a fun project for me right now. I want to just explore compiler writing. I'm not 100% sure where it will lead, and if anyone will care or not where it ends up. But it's primarily for me.

I've described it as "higher than Rust, lower than Go" because I don't want this to be a GC'd language, but I want to focus on ergonomics and compile times. A lot of Rust's design is about being competitive with C and C++, I think by giving up that ultra-performance oriented space, I can make a language that's significantly simpler, but still plenty fast and nice to use.

We'll see.

Have fun! :)

To me it just seems like Rust has Linear types, and the compiler just inserts some code to destroy your values for you if you don't do it yourself.

I guess the only difference is that linear types can _force_ you to manually consume a value (not necessarily via drop)? Is that what you are going for?

See https://faultlore.com/blah/linear-rust/ for a (now pretty old but still pretty relevant, I think) exploration into what linear types would mean for Rust.

Does it? From its docs [0]:

> There are 4 ways to manage memory in V.

> The default is a minimal and a well performing tracing GC.

> The second way is autofree, it can be enabled with -autofree. It takes care of most objects (~90-100%): the compiler inserts necessary free calls automatically during compilation. Remaining small percentage of objects is freed via GC. The developer doesn't need to change anything in their code. "It just works", like in Python, Go, or Java, except there's no heavy GC tracing everything or expensive RC for each object.

> For developers willing to have more low-level control, memory can be managed manually with -gc none.

> Arena allocation is available via a -prealloc flag. Note: currently this mode is only suitable to speed up short lived, single-threaded, batch-like programs (like compilers).

So you have 1) a GC, 2) a GC with escape analysis (WIP), 3) manual memory management, or 4) ...Not sure? Wasn't able to easily find examples of how to use it. There's what appears to be its implementation [1], but since I'm not particularly familiar with V I don't feel particularly comfortable drawing conclusions from a brief glance through it.

In any case, none of those stand out as "memory safety without GC" to me.

[0]: https://docs.vlang.io/memory-management.html

[1]: https://github.com/vlang/v/blob/master/vlib/builtin/prealloc...

Regarding the details, here is a pretty informative github discussion thread on same topic: https://github.com/vlang/v/discussions/17419

It is also accompanied with a demo video (pretty convincing in case you would like to watch).

V-lang is not shiny as other languages are, but, it does have a lot to learn from.

As sibling said, autofree is still stated to use a GC, which obviously disqualifies it from "memory safety without GC".

> Regarding the details, here is a pretty informative github discussion thread on same topic: https://github.com/vlang/v/discussions/17419

I did see that! Unfortunately it doesn't really move the needle on anything I said earlier. It describes manual memory management as an alternative to the GC when using autofree (which obviously isn't conducive to reliable memory safety barring additional guardrails not described in the post) and arenas are only mentioned, not discussed in any real detail.

> It is also accompanied with a demo video (pretty convincing in case you would like to watch).

Keep in mind the context of this conversation: whether V offers memory safety without GC or manual memory management. Strictly speaking, a demonstration that autofree works in one case is not sufficient to show V is memory safe without GC/manual memory management, as said capability is a property over all programs that can be written in a language. As a result, thoroughly describing how V supposedly achieves memory safety without a GC/manual memory management would be far more convincing than showing/claiming it works in specific cases.

As an example of what I'm trying to say, consider a similar video but with a leak/crash-free editor written in C. I doubt anyone would consider that video convincing proof that C is a memory-safe language; at most, it shows that memory-safe programs can be written in C, which is a very different claim.

Reading "Memory safe; No garbage collector, no manual memory management" on Rue homepage made me think of V for this very reason. Many think is trivial to do it and Rust has been in wrong for 15 years with its "overcomplicated" borrow checking. It isn't.

Are the actual references/pointers coming in the future?

I hope to not introduce references, because I’m going to give mutable value semantics a go. We’ll see though!

People also like hearing about new languages.

I agree that it's not really ready for this much attention just yet, but that's the way of the world. We'll see how it goes.

There's an obvious sweet spot in there.

[0] https://rue-lang.dev/blog/hello-world/

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

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.

I'd like fast compile times, and giving up some of Rust's lowest level and highest performance goals in exchange for it. As well as maybe ease of use.

I've thought a Rust like language but at Go's performance level would be interesting. Garbage collected, but compiled to a binary (no VM), but with Rust's mix of procedural and functional programming. Maybe some more capable type inference.

If you don't mind me asking, how did you get started with programming language design? I've been reading Crafting Interpreters, but there is clearly a lot of theory that is being left out there.

Crafting interpreters is fantastic!

Mostly just… using a lot of them. Trying as many as I could. Learning what perspectives they bring. Learning the names for their features, and how they fit together or come into tension.

The theory is great too, but starting off with just getting a wide overview of the practice is a great way to get situated and decide which rabbit holes you want to go down first.

Well I got that part covered at least. Seems like I'm constantly getting bored and playing around with a different language, probably more than I should lol

I'm using @ for intrinsics because that's how Zig does it and I like it for similar reasons to how Rust uses ! for macros.

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.

Rust on the other hand probably does much more such code generation (build.rs for stuff like bindgen, macros for stuff like serde, and monomorphized generics for basically everything). But all of this code is never checked into git (with the exception of some build.rs tools which can be configured to run as commands as well), or at least 99% of the time it's not.

This difference has impact on the developer story. In go land, you need to manually invoke the auto generator and it's easy to forget until CI reminds you. The auto generator is usually quite slow, and probably has much less caching smartness than the Rust people have figured out.

In Rust land, the auto generation can, worst case, run at every build, best case the many cache systems take care of it (cargo level, rustc level). But still, everyone who does a git pull has to re-run this, while with the auto generation one can theoretically only have the folks run it who actually made changes that changed the auto generated code, everyone else gets it via git pull.

So in Go, your IDE is ready to go immediately after git pull and doesn't have to compile a tree of hundreds of dependencies. Go IDEs and compilers are so fast, it's almost like cheating from Rust POV. Rust IDEs are not as fast at all even if everything is cached, and in the worst case you have to wait a long long time.

On the other hand, these auto generation tools in Go are only somewhat standardized, you don't have a central tool that takes care of things (or at least I'm not aware of it). In Rust land, cargo creates some level of standardization.

You can always look at the auto generated Go code and understand it, while Rust's auto generated code usually is not IDE inspectable and needs special tools for access (except for the build.rs generated stuff which is usually put inside the target directory).

I wonder how a language that is designed from scratch would approach auto generation.

https://pkg.go.dev/cmd/go#hdr-Generate_Go_files_by_processin...

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.

Difference is that other languages are built for things other than network services, so protobuf is much less likely to be a necessary dependency for their codebases.

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".

The only thing I can think of that Go uses a lot of generation for that other languages have other solutions for is mocks. But in many languages the solution is "write the mocks by hand", so that's hardly fair.

The golang/go repo itself has various checked-in generated repo

Not a dig at functional, it’s just my big codebases are logically defined as objects and systems that don’t lend itself to just being a struct or an interface.

Inheritance is why I’m stuck in C++ land.

I would love to have something like rust but that supports classes, virtual methods, etc. but I guess I’ll keep waiting.

Does inheritance really matter that much?

For example: Playable could be a trait that plays a sound when you interact with it. I would need to implement func interact for each object. Piano, jukebox, doorbell, etc. With inheritance, I write it once, add it to my class, and now all instances of that object have interact. Can I add instance variables to a trait?

This saves me time and keeps Claude out of my code. Otherwise I ask Claude to implement them all, modify them all, to try to keep them all logically the same.

I also don’t want to go type soup in order to abstract this into something workable.

I'm not trying to convince you to use Rust. If you prefer C++ have at it. I was just trying to point out that most patterns in C++ have a fairly close analogy in Rust, just with different tradeoffs.

To be honest, it’s been 3 years since I looked at rust and I might try again. I still prefer inheritance because some things just are-a thing. I also love ECS and components and see traits as that. I just wish I could store local state in those.

Fyrox, a game engine written in Rust, uses an ECS and several object oriented patterns in their design. Might be a good reference if your interested. The rust book also has a section on OOP patterns in Rust.

I think it's Fyrox anyway. I remember the creator of a Rust game engine talking about it in an interview on Developer Voices. It could have been Bevy I guess, but I don't think so.

I think I might be able to do it with a macro but I’m not a rust guy so I’m limited by my knowledge.

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.

[0] https://hylo-lang.org

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.

Eventually: through not having references, thanks to mutable value semantics. Also linear types.

But that's just ideas right now. It'll get there.

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.

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.

C# Native AOT gets rid of the JIT and gives you a pretty good perf+memory profile compared to the past.

It's mostly the stigma of .NET Framework legacy systems that put people off, but modern C# projects are a breeze.

I’m looking forward to seeing how it shapes out over the next few years. Especially once they release union types.

NativeAOT's primary goal is reducing memory footprint, binary size, making "run many methods once or rarely" much faster (CLI and GUI applications, serverless functions) and also shipping to targets where JIT is not allowed or undesirable. It can also be used to ship native dynamically or statically (the latter is tricky) linked libraries.

Perhaps calling it an “optimization” is misleading. Certainly it makes code faster, but more importantly it’s syntax sugar to translate recursion into loops.

If every iteration of a while-loop cost you a whole stack frame, then I'd be very rude about that language.

This works, btw:

  #include <stdio.h>

  long calc_sum(int n, long acc) {
    return n == 0
      ? acc
      : calc_sum(n-1, acc+n);
  }

  int main(void) {
    int iters = 2000000;
    printf("Sum 1...%d = %ld\n", iters, calc_sum(iters, 0));
    return 0;
  }

Well, sure, but real programmers know how to do while loops without invoking a function call.

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

  func (lst *List[T]) Push(v T) {
    if lst.tail == nil {
        lst.head = &element[T]{val: v}
        lst.tail = lst.head
    } else {
        lst.tail.next = &element[T]{val: v}
        lst.tail = lst.tail.next
    }

And this one doesn't even have the infamous error-checking.

Even though I have a Perl tattoo, it'll never get like that, though.

(Semicolon rules, for now at least, will be the same as Rust)

Take this:

  fn fib(n: i32) -> i32 {}

The -> i32 can also be just i32 because, again, the -> serves no purpose in function/method definition syntax.

So you end up with simple and clean fn fib(n i32) i32 {}

And semicolons are an ancient relic that has been passed on to new languages for 80 fucking years without any good reason. We have modern lexers/tokenizers and compilers that can handle if you don't put a stupid ; at the end of every single effing line.

Just go and count how many of these useless characters are in your codebase and imagine how many keystrokes, compilation errors and wasted time it cost you, whilst providing zero value in return.

  fn fib(n i32) i32 {}

Personally, I would like a language that pushes the programmer to write the types as part of a doc comment.

Also think about returning lambda's. Should it look like this?

  fn foo(n i32) (i32 i32) {}

  > And semicolons are an ancient relic that has been passed on to new languages for 80 fucking years without any good reason. 

It should be

  fn foo(n i32, m i32) (i32, i32) {}

  fn foo(n i32) (a i32, b i32) {}

  for (;;;) {}

  if foo := a + b; foo > c {}

  > fn foo(n i32, m i32) (i32, i32) {}

  Foo<T<string, T2>> -> (bool -> IDictionary<string, T3> -> i32 -> T3) where T2 : T3

  fn foo(n i32, m T2) (????) {}

Even if you your context-depended parser can recognize it, does the user? I agree that a language designer should minimize the amount of muscle damage, but he shouldn't forget that readability is perhaps even more critical.

____

1. Note, even if the parser can recognize this, for humans the '>' is confusing unless syntax highlighting takes care of it. One time it delimits a generic type argument, the other time it is part of '->'. This is also an argument for rendering these things as ligatures.

> The -> i32 can also be just i32 because, again, the -> serves no purpose in function/method definition syntax.

Well, there is, but it's more of a personal trait than a universal truth. Some human programmers (e.g. me) tend to read and parse (and even write, to some extent) source code more accurately when there is a sprinkle of punctuation thrown in into a long chain of nothing but identifiers and subtly nested parentheses. Some, e.g. you, don't need such assistance and find it annoying and frivolous.

Unfortunately, since we don't store the source code of our programs as binary AST blobs that could be rendered in a personalized matter, but as plain text instead, we have to accept the language designer's choices. Perhaps it actually has better consequences than the alternative; perhaps not.

[2 45 78]

It’s just a nicer thing to view and type in my experience.

Regarding syntax soup, I think Odin is probably syntactically the cleanest of the lower level languages I’ve played with.

Odin seems interesting but for me it has two deal-breakers: first one use the use of ^ for pointer de/reference. Not that it does not make sense, it's just that it is not an easy key to get to on my keyboard layout and i will not be changing that. The & and * are well known characters for this purpose and, at least for me, easily accessible on the keyboard. Second issue is the need to download many gigabytes of visual studio nonsense just so i am able to compile a program. Coming from Go, this is just a non-starter. Thirdly, and this is more about the type of work i do than the language, there are/were no db drivers, no http/s stack and other things i would need for my daily work. Other than that, Odin is interesting. Though I am not sure how I would fare without OOP after so many years with inheritance OOP and encapsulated OOP.