41–50 of 274 posts
> Memory Safe > 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?
I am playing around with this! I'm mostly interested in something in the space of linear types + mutable value semantics.
Earlier quoted context omitted.
Nice! I see you're one of (if not the primary) contributor! 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.
This is a project between me and Claude, so yeah :) 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 des…
Have fun! :)
Earlier quoted context omitted.
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.
How is it a subset then if it has the @-prefix? Wait, does Rust's grammar still have the @ and ~ sigils from the pre 1.0 times for pointers?
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.
Earlier quoted context omitted.
I am playing around with this! I'm mostly interested in something in the space of linear types + mutable value semantics.
You might find one of my late brother's research interests relevant: https://www.cs.princeton.edu/~dpw/papers/space.pdf
(And sorry to hear about your brother's passing.)
Earlier quoted context omitted.
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.…
Rust gets harder with codebase size, because of borrow checker. Not to mention most of the communication libraries decided to be async only, which adds another layer of complexity.
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 always thought of Go as low level and Rust as high level. Go has a lot of verbosity as a "better C" with GC. Rust has low level control but many functional inspired abstractions. Just try writing iteration or error handling in either one to see.
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 sys…
Earlier quoted context omitted.
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.
Wow didn't realise it was you who was the author. I learnt a lot about Rust from your writings.
Interesting, for me the "between Rust and Go" would be a nice fit for Swift or Zig. I've always quite liked the language design of Swift, it's bad that it didn't really take off that much
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 wince every time I see naive recursive fibonacci as a code example. It is a major turnoff because it hints at a lack of experience with tail call optimization, which I consider a must have for a serious language.
Interesting, for me the "between Rust and Go" would be a nice fit for Swift or Zig. I've always quite liked the language design of Swift, it's bad that it didn't really take off that much
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.
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.