13 ms·
Rue: Higher level than Rust, lower level than Go
Related: https://steveklabnik.com/writing/thirteen-years-of-rust-and-the-birth-of-rue/ https://steveklabnik.com/writing/thirteen-years-of-rust-and-...
- andsoitis 10mo ago> 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?
- steveklabnik 10mo agoI am playing around with this! I'm mostly interested in something in the space of linear types + mutable value semantics.
- echelon 10mo agoNice! 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.
- steveklabnik 10mo agoThis 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 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.
- echelon 10mo agoLove it! I think that's a nice target. Have fun! :)
- oulipo2 10mo agoSo linear type + mutable value would be quite close to Rust, right?
- steveklabnik 10mo agoRust has affine types, not linear. It also doesn't have mutable value semantics, it uses references, lifetimes, and borrowing.
- EnPissant 10mo agoI've never seen any significant difference in linear vs affine types. 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?
- steveklabnik 10mo agoAffine types are "may use" and linear types are "must use," yeah. That is, linear types are stronger. See https://faultlore.com/blah/linear-rust/ 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.
- jasonwatkinspdx 10mo agoYou might find one of my late brother's research interests relevant: https://www.cs.princeton.edu/~dpw/papers/space.pdf https://www.cs.princeton.edu/~dpw/papers/space.pdf
- steveklabnik 10mo agoThank you for the link! I'll check it out for sure. (And sorry to hear about your brother's passing.)
- jasonwatkinspdx 10mo agoYeah, that's just one of the essays he was on as a phd student, but he was really interested in the interaction of linear types and region inferencing as a general resource management framework. That grew into an interest in linear types as part of logical frameworks for modeling concurrency. But then like a lot of people he became disillusioned with academia, went to make some money on wall street, then focused on his family after that. Anyhow, I just thought it might be a good jumping off point for what you're exploring.
- torginus 10mo agoCould you please explain what this implies in layman's terms? I've read the definition of 'linear type' as a type that must be used exactly once, and by 'mutable value semantics', I assume, that unlike Rust, multiple mutable borrows are allowed? 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?
- steveklabnik 10mo agoI’m on my phone on a long road trip, so I can’t really give you a good lengthy explanation right now, to be honest. 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 :)
- onlyrealcuzzo 10mo agoAlso working on a language / runtime in this space. 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.
- steveklabnik 10mo agoNeat! Good luck, that sounds very cool. I have no idea what if anything I'm going to do about liveliness.
- Imustaskforhelp 10mo agocan you share the link, sounds fascinating language to follow its development as well and good luck on this project!
- sureglymop 10mo agoHave you explored the ideas explored for the Vale language: https://vale.dev/ https://vale.dev/ May be an interesting approach. That language seems very academic and slow moving at the moment though.
- steveklabnik 10mo agoI think Vale is interesting, but yeah, they have had some setbacks, in my understanding more to do with the personal lives of the author rather than the ideas. I need to spend more time with it.
- deleted 10mo ago[deleted]
- freakynit 10mo agoCheck out V-lang ... it has the details. It's a beautiful language... but, mostly unknown.
- maleldil 10mo agoOh, it's known. It just has an incredibly negative reputation on this site.
- aw1621107 10mo ago> Check out V-lang ... it has the details. 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 https://docs.vlang.io/memory-management.html [1]: https://github.com/vlang/v/blob/master/vlib/builtin/prealloc.c.v#L4-L14 https://github.com/vlang/v/blob/master/vlib/builtin/prealloc...
- pjmlp 10mo agoARC is GC, chapter 5. https://gchandbook.org/ https://gchandbook.org/
- andsoitis 10mo agoSure, ARC is a form of very specific, constrained garbage collection. Compile-time, reference-counting GC, not runtime tracing GC. So no background collector, no heap tracing, and no stop-the-world pauses. Very different from the JVM, .Net, or Go.
- pjmlp 10mo agoReference counting is a GC algorithm from CS point of view, it doesn't matter if it is compile time or runtime. Additionally there isn't a single ARC implementation that is 100% compile time, that when looking at the generated machine code has removed all occurrences from RC machinery.
- Warwolt 10mo agoBut common, collouqialy "Garbage Collection" as a language feature refers to a run time garbage collector. Saying that the language has GC just because it has opt-in reference counting is needlessly pedantic
- pjmlp 10mo agoKnowlege gets taught in specific institutions exactly because street knowledge is quite often incorrect, like in this case, spreading urban myths based in shaky foundations.
- gf000 10mo agoWhile I am usually the one that also goes in and correct people incorrectly calling RC not a GC, the important distinction here is that Rust (and C++) has the necessary language constructs to be able to implement ref counting entirely as a library.
- jameskilton 10mo agoProbably best to link to the repo itself, this is not meant to be used yet. https://github.com/rue-language/rue https://github.com/rue-language/rue
- killingtime74 10mo agoI 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.
- steveklabnik 10mo agoRue 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.
- written-beyond 10mo agoHow very so humble of you to not mention being one of the primary authors behind TRPL book. Steve you're a gem to the world of computing. Always considered you the J. Kenji of the Rust world. Seems like a great project let's see where it goes!
- steveklabnik 10mo agoThat is a very kind thing to say, I admire him quite a bit. Thank you!
- manaskarekar 10mo agoSince it's framed as 'in between' Rust and Go, is it trying to target an intersection of both languages' use-cases?
- steveklabnik 10mo agoI don't think you'd want to write an operating system in Rue. I may not include an "unsafe" concept, and will probably require a runtime. So that's some areas where Rust will make more sense. As for Go... I dunno. Go has a strong vision around concurrency, and I just don't have one yet. We'll see.
- norir 10mo agoI 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.
- stouset 10mo agoWould 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?
- aaronblohowiak 10mo agofunctional programming background / SICP ?
- Rusky 10mo agoTCO is less of an optimization (which are typically best-effort on the part of the compiler) and more of an actual semantic change that expands the set of valid programs. It's like a new control flow construct that lives alongside `while` loops.
- oersted 10mo agoFor people that like functional style and using recursion for everything, TCO is a must. Otherwise there’s no way around imperative loops if you want decent performance and not having to worry about the stack limit. Perhaps calling it an “optimization” is misleading. Certainly it makes code faster, but more importantly it’s syntax sugar to translate recursion into loops.
- int_19h 10mo agoYou don't need full fledged TCO for that; see Clojure's recur for an example. Zig recently added something similar but strongly typed with match/continue. These all map exactly to a closed set of mutually recursive functions with a single entry point, which is quite sufficient (and then some) to fully replace iterative loops while still desugaring to the same exact code.
- deleted 10mo ago[deleted]
- oulipo2 10mo agoInteresting, 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
- steveklabnik 10mo agoOne 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.
- vips7L 10mo agoCheckout Borgo: https://github.com/borgo-lang/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.
- behindsight 10mo ago> 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.
- vips7L 10mo agoAFAIK there’s still holes like reflection and you have some work, but if that’s changed that’s really good. I suspect it’ll be hard for C# to escape the stench of “enterprise” though. I’m looking forward to seeing how it shapes out over the next few years. Especially once they release union types.
- neonsunset 10mo agoFWIW JIT is rarely an issue, and enables strong optimizations not available in AOT (it has its own, but JIT is overall much better for throughput). RyuJIT can do the same speculative optimizations OpenJDK Hotspot does except the language has fewer abstractions which are cheaper and access to low-level programming which allows it to have much different performance profile. 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.
- coffeeaddict1 10mo agoHow does this differ from Hylo [0]? [0] https://hylo-lang.org https://hylo-lang.org
- steveklabnik 10mo agoI 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.
- fuzztester 10mo agoHow are Swift and Rust very similar? I can search, but want to hear your opinion. And congrats on starting a language project, even if Just for Fun (Linux). ;) https://frappe.io/blog/book-reviews/just-for-fun-a-book-on-linus-torvalds https://frappe.io/blog/book-reviews/just-for-fun-a-book-on-l...
- steveklabnik 10mo agoThanks :) Both are playing around in similar spaces, both shared team members for a while, both have a take an automatic memory management that isn’t a garbage collector, both were sponsored by a primary company for a while (Swift still is, I think). There’s a lot of differences too.
- frizlab 10mo agoHow does this compare to Swift?
- steveklabnik 10mo agoI 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.
- lifis 10mo agoAll the Rue code in the manual seems to also be valid Rust code, except for the @-prefixed intrinsics
- steveklabnik 10mo agoYes, 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.
- emerent 10mo agoHow 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?
- steveklabnik 10mo agoIt started off that way, but didn't (and won't) remain that way. 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.
- scuff3d 10mo agoOut of interest, what's the motivation? What are you hoping to do with Rue that Rust doesn't currently provide?
- steveklabnik 10mo agoPrimary motivation is to have a fun project. If nobody ever uses this, I'll still be happy. 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.
- 10mo ago
- chrysoprace 10mo agoIt may have been more useful to link to the blog post [0] which gives more of an introduction than the front page at this point. [0] https://rue-lang.dev/blog/hello-world/ https://rue-lang.dev/blog/hello-world/
- steveklabnik 10mo agoI posted that, and also https://steveklabnik.com/writing/thirteen-years-of-rust-and-the-birth-of-rue/ https://steveklabnik.com/writing/thirteen-years-of-rust-and-... Just to link them all together. This is the one that the algorithm picked up :)
- reactordev 10mo agoI write a lot of go. I tried to write a lot of rust but fell into lifetime traps. I really want to leave C++ but I just can’t without something that’s also object oriented. 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.
- steveklabnik 10mo agoI 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!
- amluto 10mo agoAs 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.
- xpe 10mo agoAh, yes, multiple inheritance in C++: where order matters but sanity does not
- chuckadams 10mo agoProtected and private inheritance are C++'s equivalent to traits, and they don't suffer from the usual issues of multiple inheritance. As for type classes, check out concepts. By no means am I trying to sell C++, I don't touch it myself, but it doesn't leave you completely adrift in those seas.
- waldrews 10mo agoWhat the world needs is a more expressive language than Go, that interops with Go's compilation model and libraries.
- rubenvanwyk 10mo agoSomething like Borgo https://borgo-lang.github.io/ https://borgo-lang.github.io/
- jandy 10mo agoSadly, seems to be abandoned. Last commit a year ago.
- pjmlp 10mo agoNah, we already have that in D, C#, and who knows maybe one day Java finally gets Valhala, or one can use Kotlin or Scala in the meantime.
- 4nonverbal-alit 10mo agoAny plans for adding algebraic data types (aka rust enums)?
- steveklabnik 10mo agoI 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.
- est31 10mo agoI have mostly been writing Rust in the last 10 years, but recently (1 year) I have been writing Go as well as Rust. 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.
- Kinrany 10mo agoFYI rust-analyzer can show expanded macros. It's not perfect because you only get syntax highlighting, but it works.
- ryanobjc 10mo agoThe "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).
- Panzerschrek 10mo agoHow does it achieve memory safety?
- steveklabnik 10mo agoRight now? By not even having heap allocation (though I'll be sending in the first PR for that soon.) Eventually: through not having references, thanks to mutable value semantics. Also linear types. But that's just ideas right now. It'll get there.
- Panzerschrek 10mo agoI am surprised that a language with nothing than a couple of promises gets so much attention. Why exactly?
- squirrellous 10mo agoIIRC the author has a good track record with programming languages.
- steveklabnik 10mo agoI've been a member of this community for a long time. 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.
- forgotpwd16 10mo agoOne of which the implementation is 100% vibe coded even.
- barnabee 10mo agoI think ~everyone wants a language that's kind of like Go with a Rusty type system (and maybe syntax), so any title like this gets attention. There's an obvious sweet spot in there.
- gethly 10mo agoThis is a bit silly but when i look at new languages coming up I always look at the syntax, which is usually horrible(Zig and Rust are good examples), and how much garbage there is. As someone that writes in Go, I can't stand semicolons and other crap that just pollutes the code and wastes time and space to write for absolutely no good reason whatsoever. And as this compares itself with Go, I just cannot but laugh when I see ";", "->" or ":" in the example. At least the semicolon seems optional. But still, it's an instant nope for me.
- imbnwa 10mo agoWhat would be better?
- christophilus 10mo agoI wish more languages would adopt Clojure’s approach to optional delimiters in collections. [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.
- int_19h 10mo agoIt's a Lisp thing, obviously, but also there's a benefit to explicit delimiters - it makes it possible to have an expression as an element without wrapping that in its own brackets, as S-exprs require.
- gethly 10mo agooh, yeah. that looks good. i always hated using ", " delimiter for lists and the amount of typos it always takes to make clean(well, not with Go fmt). 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.
- homarp 10mo agoIn the intro text, the Ramsus is who ? a typo about php creator or a more obscure language creator?
- steveklabnik 10mo agoIt's a typo, I'm referring to https://en.wikipedia.org/wiki/Rasmus_Lerdorf https://en.wikipedia.org/wiki/Rasmus_Lerdorf. I'll fix it, thank you :)
- pjmlp 10mo agoIf this language is supposed to be used for systems programming, doing a factorial isn't really a selling example of why Rue.
- steveklabnik 10mo agoFor sure. It's just such early days I don't have a lot of stuff that's useful yet. I'll get there.
- dingdingdang 10mo agoAny tentative ideas yet as to how you will manage the memory management? Sounds like a sort of magic 3rd way might be in the making/baking!
- steveklabnik 10mo agoSomething in the area of linear types and mutable value semantics.
- dingdingdang 10mo agoAnything out there for reference or would you be implementing from theory/ideas here? God speed to you in terms of the project overall, it's exciting to see the beginnings of a rust-like-lang without the headaches!
- steveklabnik 10mo agoNot implemented yet, I’m reading papers :) Thanks!
- Joker_vD 10mo agoOkay, right now it's basically Pascal as it was described in Revised Report, only even more restricted. Which is... fine, I guess, you can still write a whole OS with something like that (without using pointers/addresses) as Per-Brinch Hansen demonstrated but it's... an acquired taste. Are the actual references/pointers coming in the future?
- steveklabnik 10mo agoMaybe Pascal without the syntax, sure. It’s still very early on. I hope to not introduce references, because I’m going to give mutable value semantics a go. We’ll see though!
- dpflan 10mo agoJust pointing out here that "rue" is used to express "to regret", emphatically. Perhaps it is not the best name for a programming language.
- 9rx 10mo agoThe best code is the code not written, so perhaps it is the best name for a programming language?
- steveklabnik 10mo agoThat’s part of the reason for the name! “Rust” also has negative interpretations as well. A “rue” is also a kind of flower, and a “rust” is a kind of fungus.
- dpflan 10mo agoFair enough! I do like how others are framing this is as "write less code" -- if Rue makes one think more and more about the code that finally makes it to the production, that can be a real win.
- embedding-shape 10mo agoSounds fitting to me. Every line of code I wrote that ultimately didn't need code to begin with, is basically codified regrets checked into git.
- catlover76 10mo ago[dead]
- vivzkestrel 10mo agowhen we are we getting a language that looks like python and runs 50 times faster than c++ /s
- yoan9224 10mo agoThe positioning is interesting - claiming Rust's performance with Go's simplicity is basically every new systems language's promise since 2015. The key differentiator seems to be "zero-cost exceptions" which I assume means compile-time Result types without runtime unwinding overhead? That's compelling if true, since Rust's Result ergonomics can get verbose in deeply nested error chains. 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.
- whimsicalism 10mo agoYour style of commenting is pretty full of LLM tells fyi. Normally don’t comment on it but this is the second such comment of yours I have read in a few minutes. e: I would be curious of the thoughts of those downvoting as personally I don’t think mostly LLM written comments are a direction we want to move towards on HN.
- Hemospectrum 10mo agoRather than downvoting you, I will speak up to say I don't see what you're seeing. Spaces around hyphens, yeah, sure, but LLMs prefer em dashes, and even that is unreliable, because it's borrowed from habits that real humans have had for many years. For me, the more important indicator is the content. I see reports of personal experience, and thoughts that are not completely explained (because the reader is expected to draw the rest of the owl). I don't see smugly over-the-top piles of adjectives filling in for an inability to make critiques of any substance. I don't see wacky asides amounting to argumentum ad lapidem, accomplishing nothing beyond insulting readers who disagree with a baseless assertion. I think it's likely you have drawn a false positive.
- PunchyHamster 10mo agofn fib(n: i32) -> i32 so unnecesary, just extra writing. We're developers, we understand that function return types are after first () let mut i = 0; No, no, copy Go here, i := 0 is just fine
- culebron21 10mo agoI couldn't figure out the main points, besides the "between Rust & Go" slogan. I've worked both with Rust and Go, and I like Rust more, but there are several pain points: * 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.
- steveklabnik 10mo agoIt’s too early to have slick marketing and main points. Noted, thanks for the comment. I share some of these opinions more than others, but it’s always good to get input.
- resonious 10mo agoI've been having fun with Gleam. I'm not really sure where it falls on the spectrum though. It is garbage collected, so it's less abrasive than Rust in that sense. But it's pure functional which is maybe another kind of unfriendly.
- steveklabnik 10mo agoGleam is very cool! But yeah, higher level than I’m shooting for here.
- PrimalPower 10mo agoI don't need lower level than go. I just really like Rust' type system and error handling and I want it in a compiled language. Zero Cost abstractions and it's memory model is fascinating - but isn't particularly useful for the part of the tech stack I work on.
- trueno 10mo agoi see a lot of go hatred on HN but coming from c i actually kind of love go when i need just enough abstracted away from me to focus on doing a thing efficiently and still end up with a well-enough performing binary. i have always been obsessed with the possibility of building something that doesn't need me to install runtimes on the target i want to run it, it's just something that makes me happy. very rarely do i need to go lower than what go provides and when i do i just.. dip into c where i earned a lot of my stripes over the years. 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.
- xorvoid 10mo ago"Memory Safe No garbage collector, no manual memory management. A work in progress, though." I wish them the best, but until they have a better story here I'm not particularly interested. Much of the complexity in Rust vs simplicity in Go really does come down to this part of the design space. Rust has only succeeded in making a Memory Safe Language without garbage collection via significant complexity (that was a trade-off). No one really knows a sane way to do it otherwise, unless you also want to drop the general-purpose systems programming language requirement. I'll be Very Interested if they find a new unexplored point in the design space, but at the moment I remain skeptical. Folks like to mention Ada. In my understanding, Ada is not memory safe by contemporary definitions. So, this requires relaxing the definition. Zig goes in this direction: "let's make it as safe as possible without being an absolutist"
- rayiner 10mo agoIf you look at the Github, there's a design proposal (under docs/design) for that. 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.
- steveklabnik 10mo agoYeah, that stuff is very much a sketch of the area I want to play in. It’s not final syntax nor semantics just yet. Gotta implement it and play around with it first (I have some naming tweaks I definitely want to implement separate from those ADRs.) I don’t struggle with lifetimes either, but I do think there’s a lot of folks who just never want to think about it ever.
- tete 10mo agoLooks nice, but -> syntax always feels extremely off-putting. What does it get me?
- steveklabnik 10mo agoI’m just copying Rust here because I care more about semantics at the moment. I may get rid of it, see some previous musings around this here https://steveklabnik.com/writing/too-many-words-about-rusts-function-syntax/ https://steveklabnik.com/writing/too-many-words-about-rusts-...
- metaltyphoon 10mo agoWhat was the rationale to not use cargo? By the way, I really enjoy when you are a guest on the fallthrough podcast.
- steveklabnik 10mo agoThanks! So, one reason is "I just want to learn more about buck2." But, for the first iteration of Rue, I maintained both. However, for a language project, there's one reason Cargo isn't sufficient now, and one reason why it may not later: the first one is https://github.com/rue-language/rue/blob/trunk/crates/rue-compiler/BUCK#L6 https://github.com/rue-language/rue/blob/trunk/crates/rue-co... : I need to make sure that, no matter what configuration I build the compiler in, I build a staticlib for the runtime. With Cargo, I couldn't figure out how to do this. In test mode, it would still try to build it as a dylib. Later, well, the reason that rustc has to layer a build system on top of Cargo: bootstrapping. I'm not sure if Rue will ever be bootstrapped, but rustc uses x.py for this. Buck does it a lot nicer, IMHO https://github.com/dtolnay/buck2-rustc-bootstrap https://github.com/dtolnay/buck2-rustc-bootstrap