If Go And Rust Had A Baby

Recorded live on twitch, GET IN
Article
www.sophiajt.c...
By: Sophia J. Turner | / sophiajturner
My Stream
/ theprimeagen
Best Way To Support Me
Become a backend engineer. Its my favorite site
boot.dev/?prom...
This is also the best way to support me is to support yourself becoming a better backend engineer.
MY MAIN YT CHANNEL: Has well edited engineering videos
/ theprimeagen
Discord
/ discord
Have something for me to read or react to?: / theprimeagenreact
Kinesis Advantage 360: bit.ly/Prime-K...
Hey I am sponsored by Turso, an edge database. I think they are pretty neet. Give them a try for free and if you want you can get a decent amount off (the free tier is the best (better than planetscale or any other))
turso.tech/dee...

[@GreenJalapenjo]

The biggest revelation in this whole video is that Prime doesn't know what "for all intents and purposes" means

[@kez99]

This is the first time I've seen prime without a hoddie so idk...

[@ttcc5273]

for most indents and porpoises, it's perfectly reasonable

[@MNbenMN]

Make sure to align the tabs or spaces for all indented porpoises

[@StinkyCatFarts]

Yeah bet you can’t invert a binary tree

[@Kane0123]

You shouldn’t take your understanding of English for granite.

[@HalfMonty11]

Opt in safety means, you cannot trust any code you didn't write and probably can't trust code you did write and have to assume, simply because it's possible, that all code is unsafe until proven otherwise... which is possibly even worse than C because it could give you a false sense of security

[@dahahaka]

All code is safe, but you might get memory bloat, if you use too much memory you have to opt in and tell it where to clean up basically

[@AndrewBrownK]

Reminds me of javascript vs typescript vs purescript

[@allesarfint]

Yeah, I feel like opt out safety is a better approach, because it allows to be explicit about intentions rather reacting to undesired effects. The same way mutability works by allowing to mark what can mutate, it'll be better to mark what mutable references can be shared.

[@temper8281]

you just described rust

[@anderdrache8504]

I think this doesn't allow "unsafe" code as in undefined behaviour it just allows one thing rust disallows: shared mutable pointers which is depending on the language not a safety issue. Most high level languages allow this

[@foxwhite25]

The problem with opt in safety, heck all opt in feature, is that you are not the problem if you know the subject well, the problem is your coworkers, who write terrible code, and you have to maintain and debug that terrible code. Most people wouldn't do it if there wasn't a language forcing them to do it, or just don't know it is there, and you have to live with the consequences.

[@Leonhart_93]

There is also not touching in the first place the language that does that.

[@ShankeyMcstab]

no, you are the problem. You are not as skilled at writing safe code as you think.

[@HalfMonty11]

exactly. Just saw a video essay of someone explaining why they love C and how elegant it can be when done perfectly. I'm like cool story, how many people on this planet would you feel comfortable collaborating on something in C with? All the reasons the person listed for loving C goes out the window as soon as 1 other person can contribute to the code and doesn't see eye to eye perfectly. If your use case is fine with GC and the other limitations, Go makes a ton of sense because it's hard to do really wrong. It's an ideal language to collaborate with Juniors on. If you don't want GC, yeah, Rust is "tough", but how much confidence do you have in your coworkers check in once they passed the borrow checker and clippy? I'd say pretty damn confident. The best part of Rust imo is that things actually get solved and complete and they are done. There's heavily used crates that are archived because they are done, they are complete, no one needs to reinvent that thing again. I like my work to be done.

[@Leonhart_93]

@@ShankeyMcstab Pfff, Rust users just love to spread their impostor syndrome 😂

[@dahahaka]

It's safe either way, but you might get memory bloat without the opt in

[@MikkoRantalainen]

I think a lot of the Rust lifetime unreadability goes away if you start giving more descriptive lifetimes but 'a and 'b. For example, 'request, 'fileopen etc. Then your error messages will make more sense when it's obvious what the lifetime means for logic.

[@jongeduard]

Hmm, actually an interesting point. If you compare it to the tons of problems with single letter variable names and other horrible practices that you can see sometimes, it's actually surprising that lifetime annotations are done that way. Maybe they wanted to make it look more like other generic parameters, which are also single letter in most cases and for which the same question might be a good one as well.

[@thekwoka4707]

@@jongeduard I'd imagine because in a lot of cases the lifetime itself doesn't really have a semantic meaning, only a technical one.

[@TurtleKwitty]

Only ever seen people use a single lifetime name, typically 'a everywhere and let the compiler figure it out

[@MikkoRantalainen]

@@TurtleKwitty I agree that most Rust code uses just 'a but I fail to see why anybody considers it like the best possible implementation.

[@TurtleKwitty]

@@MikkoRantalainen My hot take as someone that really doesn't like rust; cause the lifetime annotations are all bullshit and should just be auto added by the compiler where needed so it's treated as exactly what it is useless noise in the code

[@coruscateor]

The reason why lifetimes “leak” is because you’re likely treating these annotated stack based objects like based heap based objects. The Rust lifetime checking system is not a substitute for garbage collection or reference counting. This is something that programmers who are used to the value-type-reference-type paradigm seem to struggle with the most when learning the language because when you think of lifetimes you tend to think in terms of the heap, which is something that has to be unlearned in the process of leaning the language.

[@elirane85]

The only reason I like Rust is because it's SAFE by default. Take that aways and why not just use C/C++?

[@programmerjowo]

👍

[@fotnite_]

Honestly, as soon as he said "opt-in safety" I'm like "oh so it's C++?"

[@rusi6219]

Ok if you want memory safety then don't even bother with a language like that use a garbage collected language and you get objectively better results anyway

[@HalfMonty11]

I think Prime is experiencing the Trough of Disillusionment when it comes to Rust. It's not the savior language to rule them all it seemed but it's also not completely missing the mark either like he seems to be alluding to more lately. Yes, it's difficult to learn "fully", but that difficulty buys you into a lot. It has a lot of high level ergonomics. You can pick up something like Dioxus and write gui and web apps in the same codebase pretty easily from a web dev background, or pick up any will written library with high level ergonomics and write great fast, safe high level rust. I wrote a damn custom bluetooth device sdk within a few months of learning Rust and I barely knew what I was doing. Yes, if you want to write on of those well crafted libraries... that's going to be harder, but it's at least in the same language. I think it's great that you can have the low level difficult problems being solved in the same language as having catered, neat and clean high level (js developer level) ergonomic programming, and both can confidently contribute to the same code solutions. Yes GO is sort've like this but it never gets deeper. If you dive into Go you'll break your neck immediately hitting the bottom and need to switch to another language to go deeper. Rust's unique super power is the high level ergonomics if you want to stay high level and the ability to go as deep as you want, all while playing by the same rules. Rust's difficulty is known, there is a way to do just about everything you could every want to do with code, you just have to learn it or the patterns. JS is "easy" but there's 8 trillion simple footguns along the way that we just pretend aren't there, it's difficulty is unknown. Known and understood difficultly is way more valuable to solve hard problems. I'm not fanboying for Rust btw, it's not the best thing, it has problems and doesn't fit everything, but it definitely does have it's place. I assume (and it may take some time), Prime will eventually revisit Rust with fresh eyes and see it a bit more positively than he currently does when he realizes, zig is too low for a lot of things and go is too 1 dimensional and Rust can actually straddle a very wide band of depth quite well

[@colto2312]

'JS is "easy" but there's 8 trillion simple footguns along the way that we just pretend aren't there, it's difficulty is unknown' best quote

[@TehKarmalizer]

That’s an interesting view. I haven’t used enough rust or go to have a solid opinion of my own, but Prime does seem to have a flavor of the year programming language, and rust had its moment.

[@j-p-d-e-v]

@@TehKarmalizer Agree, this year his favorite is Zig.

[@shimadabr]

I love and hate GO at the same time. It's philosophy to keep everything barebones and to force it's conventions on the developers are infuriating sometimes. Rust is much better to realize well architected systems, while Go makes you move fast and make it good enough, that's how I feel at least.

[@zactron1997]

Agreed. I think it speaks volumes about Rust as a language that the hardest thing to do in Rust is write a performant and accessible library (like Tokio, Serde, Axum, etc.), and yet the ecosystem is filled with them. I think Rust's real power is in the median programmer. You know, the person who just writes what the compiler tells them to do, trudges through the Jira tickets without much depth of thought. They will never write their own Tokio, and they'll never have to. And for the 1% of median programmers that eventually decide to go deeper, Rust will let them.

[@avi123]

should be called gust

[@elieobeid77]

dis-gust

[@anatheistsopinion9974]

Or rug

[@xenoversee]

How about guts?

[@micnic90]

in Romanian "gust" means "taste"

[@Valthonia]

gusto

[@dillon4248]

Prime is wrong here 11:07 that actually is the main reason shared mutable references are not allowed

[@CramBL]

Prime is so confidently incorrect all the time when talking about Rust. Lifetimes also aren't more leaky than async, he should know that since he has used Tokio, Serde, and probably inumerable other crates that use a ton of lifetimes internally all over the place but users typically never see them.

[@sucss3358]

yeah and then he talks about some other completely different thing

[@felixjohnson3874]

​@@CramBLI think it's because he (and most vaguely nerd-culture youtubers I've seen) don't ever *_expand_* their use/skill horizon, they just deepen it. He's said before that he used Rust primarily for CLI tools, and he primarily works on tooling, rather than final products.This is fine, *_until_* it becomes all you do. His Rust experience seems insanely narrow with very little real comprehension. This affects most youtubers even vaguely nerd-culturey. Vex recently released a video claiming ARM was open source because he didn't read the wikipedia pages he was citing and thought since ARM was RISC it was the sane as RISC-V. A year or so ago tons of phone youtubers fear mongered Samsung batts (again) because they didn"t realize keeping batteries at 0% for a long time was hilarilously unhealthy for them and stresses the battery to hell. Literally any video Linus has ever made. With a handful of exceptions almost every informational/nerd-culturey youtuber suffers from this issue, often from ignorance, other times flat out malice and/or the intentional choice to stay ignorant, many times both.

[@kasvith]

Prime is never right about lot of things, specially when he was bashing about Erlang/Elixir he demonstrated he doesnt know anything to even give a comment lol he was never right

[@keoghanwhimsically2268]

While some of Prime’s takes do expose the limits of his programming experiences, in this case, I think you’ve misunderstood but the stream comment and Prime’s answer. The comment was about a specific situation where a pointer is held to vec element while the vec itself is separately realloced. It was a gotcha question, as there are only very narrow, ultra-high-performance use cases where you’d even think about or want to share pointers to vec elements. The only general situtation that even comes close would be someone writing their own compiler or memory allocator. Presumably, they would have more of a clue than to do something so dumb as then reallocing the underlying vec. Prime, to be sure, did not get the gotcha nature of the question, and tried to answer the question of what languages should allow. And what exactly do you mean by “shared mutable references”? Do you mean pointers? Very few languages allow you to share actual references, and those like C that allow it severely restrict its usage in practice. But you can’t mean shared pointers as only some toy programs or perhaps data processing pipeline steps could be written without it.

[@untoldhorrordude]

Opt-in safety is how we got into the current unsafe mess in the first place though. If something is to be used by the masses, it needs to be on by default.

[@zactron1997]

Exactly. Seatbelts aren't opt-in precisely because while skill can mitigate a car crash, it can't prevent it.

[@thekwoka4707]

like typescript devs that at the start of a project turn off "no implicit any"

[@Leonhart_93]

@@thekwoka4707 Absolutely, I do that. There are some places in the code with specific arguments that would make things uglier if I had to abuse the "any" types. I found it better to keep it clean like that for implicit "auto" variables, and use "any" for the cases where there could genuinely be large variation like generics.

[@fb-gu2er]

I’m sorry, but with modern C++, GO and ZIG. Rust will never be what people thought

[@32zim32]

Easy, Safe, Fast. Pick only two. Lets call it ESF theorem ES: php, js, go EF: C, Zig SF: rust

[@asdfghyter]

S: Haskell

[@asdfghyter]

not sure if C is easy though

[@32zim32]

@@asdfghyter if you will compare it with rust or c++ it's easy )

[@GreatWalker]

And then there are different level of safety.

[@asdfghyter]

@@SimonWoodburyForget it’s very easy to learn the basics of C, but it’s almost impossible to master. it’s like saying that brainf*ck is an easy language just because you can describe the entire language in a few paragraphs. and while the C standard itself is small, that is in large part because there is so much undefined behavior. you can for example sometimes accidentally depend on some UB and then everything breaks in very strange ways depending on literally anything in the environment of the code (debug/release version, compiler, platform, some random unrelated code, etc …) in general, i kind of think the EF category is kind of misleading. it’s only easy if you don’t care about safety or correctness at all. you can write safe code in any language, but it’s way more difficult to do it in languages like C. and manual memory management is more difficult than GC even if don’t care much about safety edit: Also, you can learn enough Rust to start being productive in a week if you are already comfortable with C. i think you’re exaggerating the difficulty. you don’t need to learn the entire language to get productive with Rust (especially things like async, but you can also write marginally slower code to not need to care about lifetimes) and for C learning the entire language is far from sufficient to get good.

[@benheidemann3836]

Opt in to safety = unsafe. We already know this from decades of experience. Explicit out is fine, which Rust allows in some cases. But maybe we should have more ways to do this? Also, as an aside, it seems always to be people coming from GC backgrounds who are arguing that Rust is hard. Is it possible that it’s just that GC programming is stupidly easy and that safe systems programming is just inherently non-trivial?

[@adriancruz2822]

I feel like it would be better to have more granular control over the level of safety. When you use an unsafe block you are opting out of ~100% of the safety guarantees rust offers you in that block, and it might be cool to have more kinds of blocks where you opt out of specific guarantees rather than all the guarantees.

[@Leonhart_93]

Actually, most Rust adopters are infamous for being web devs, to the point where its their first low level language. I see far less experienced C/C++ devs willing to switch.

[@rusi6219]

​@@Leonhart_93explains their ridiculous takes about C.

[@Leonhart_93]

@@rusi6219 I know, those takes make it sound like it's impossible to write in C programs that don't crash and you shouldn't even try. All while being blissfully ignorant that everything they use is derived from C 🤣

[@taragnor]

@@Leonhart_93 C diehard programmers tend to have a deluded view of their own infallibility ("Just don't make mistakes bro. I've never had to debug a memory error in my life because I don't make them."). Literally every flaw with the language is solved in their mind by just not making mistakes. If you're half as good as these guys think they are, you'd be a top 10 programmer in the world. As for C++, it's largely C++ is such a complicated language, there's a big sunk cost. There's always something new to learn about C++, the language is just insanely feature rich in a lot of aspects. And that's not even talking about the extra frameworks of C++ that you have to learn. In modern C++, assuming you write it correctly with smart pointers and similar constructs, does get some good safety features with RAII. It's not as good as Rust, but it's hardly basic C either. So I think there's a calculation to be made if it's worth trying to pick up a whole new systems programming language, when C++ could be flawed but good enough. If you're already several years deep in C++, it's probably not worth it. C++ isn't going anywhere for a while. Largely Rust tends to attract newer programmers who have probably started on languages like Javascript or Python, perhaps got a taste of a functional language or something with complex typing, like Typescript, and then saw Rust gave a lot of these features. When you program JS, you gain a profound respect for the compiler catching errors, because in JS, you get almost no help, so adding in more rigid typing is often seen as a very good thing after you've wasted 20 minutes debugging a JS problem only to realize it was caused by something utterly stupid like you leaving a letter off a variable name and the JS lack of a type system not immediately telling you, "X is an invalid property on this type".

[@JorgetePanete]

Important question: can I use June any other month of the year?

[@danigui8573]

If Go And Rust Had A Baby, his name will be: Grrr

[@F100cTomas]

Grost

[@xormak3935]

Neh, "Grrr" is just the sound you make when someone tells you to learn yet another newly developed type- and memory-safe language.

[@jeremymcadams7743]

Nah, Grrr is a little robot from Invader Zim who likes mashed potatoes ​@xormak3935

[@kira.herself]

grrrrrr

[@vladimircicmanec6103]

Rug

[@blarghblargh]

opting out of safety is better than opting into safety, and better than safety you cannot opt out of. I want it auditable. marking an entire block as unsafe I also think is a bit heavy handed. I like the idea of doing it surgically, because my assumption would be that you only need it in small targeted areas. I think there should be a little bit of friction at every separate point you can interface with.

[@blarghblargh]

I haven't really used unsafe enough in Rust or C# to have a less abstract hunch though. I've done plenty of C and C++ so I know what unsafety allows. I just don't know how easy it is to slip into a "everything is unsafe, yolo" mode in your mind, once you start having to maintain a lot of unsafe Rust/C# code. I know how easy it is to fall into a "mmm that sounds unsafe I'm scared" mindset tho. Lots of rust lovers who aren't as experienced with other languages are this way. My hunch is that surfacing more tools to make it surgical could help with that.

[@blarghblargh]

big arenas that drop at once sounds pretty great to me tho. as a game dev, having "per frame" "level load only" and "per game scope/room/level/whatever" buckets sounds quite useful. in C you get one big drop for free at program end, but it'd be real nice to have big free drops in more customizable places.

[@StatixCinder]

Qt has had the concept of deleteLater for like 25 years, but that is a library implementation as mentioned by someone else vs language impl

[@MikkoRantalainen]

I think one shouldn't create new systems language that is not safe by default. However, doing intentional exceptions should be easier than with Rust. Rust basically only has unsafe block but what we would really need is ability to declare that some specific data structure fullfills some restriction that allows it to be accessed cross-threads in some way that wouldn't be normally possible. That way the Rust compiler (or any other language we're talking about) could be in safe mode at all times but follow the explicit extra assumptions you've declared. Right now Rust only supports totally safe or "trust me bro, I know what I'm doing" modes.

[@thekwoka4707]

Like multiple types of unsafe blocks?

[@MikkoRantalainen]

@@thekwoka4707 I was thinking more along the lines "declare that variable X can be shared between threads without arc mutex" which would automatically only lift the requirements for needing to use arc mutex but that requirement would be lifted everywhere, not in a single unsafe block.

[@mikkelens]

@@MikkoRantalainen I think you mean a &mut X, not any variable. You can share references between threads using scoped threads, you just can't mutate their value. This is because Send and Sync are auto-derived traits. I recommend looking them up if you haven't. I kind of agree that it would be nice to have more specific "In this code block, I should be allowed to do _ 'unsafe' operation" instead of just any unsafe, but I think for 99% of cases the unsafe block is just enough as is and in any reasonable codebase that unsafe comes with a comment explaining why it is there. This is also why unsafe operation in unsafe fn was a mistake (I think it's being changed for the 2024 edition), since it implies the whole function can do anything it wants, whereas you should instead tightly wrap your unsafe blocks exactly where they are needed, unless the scope of that unsafe operation is coupled with another unsafe operation around it. Unsafe rust is also not C, you still have to obey the strict type system, unless you explicitly use specific unsafe functions.

[@MikkoRantalainen]

@@mikkelens Yes, I meant &mut X but was too sloppy in communication. Thanks for pointing it out.

[@CreativeWerxGFX]

It's all good Prime, we've all been there, 3am system full of caffine, fist pounding the keyboard after losing 3 hours of work only to be relieved to know you had a backup of all your rustygopron.

[@beest_]

If you ever programmed a by-value data-flow language, you'd see all these issues are irrelevant. All memories are deallocated once the function is done. The data will be available if another function is atill using it (passed by value). Obviously not suitable for systems programing language but all memory problems are not present

[@jeffreybritton3338]

Is there a data-flow language you can recommend?

[@beest_]

@@jeffreybritton3338 oh yeah, LabVIEW the gold standard. Used in commercial and academia for measurement and automations. . You can get started with a free community version

[@platin2148]

In short it’s using hidden allocators In this language to make “recycling” of memory possible. Guess there should be simply a incentive for people to use allocators and that would make stuff way more trivial. What was meant to be groups here are actually allocators. Embedded Programming with Rust is an Experiment, i found Odin on my side to be the thing i wanted it needs tooling though.

[@petersuvara]

So basically I have to do just as much work as C memory management. But it’s a complex mush mash of syntax that’s even more confusing than just managing the memory yourself. This is why C is still king.

[@Leonhart_93]

But hey it's safe. Sometimes. For some error types. Take it or leave it 😅

[@rusi6219]

It literally makes you do the garbage collecting but in a bad way. Trains you to do things in a certain way, I wouldn't be surprised if it was a ploy to just create malware and then offload the blame on those devs. Wouldn't even be mad; rustaceans would deserve it.

[@petersuvara]

@@Leonhart_93 yeah I think there’s far too much complexity and it’s not solving any problem really. If I want to do my own optimised memory management there’s C/C++ and for reference counted memory management I have Swift or if I want full safety I have rust.

[@Leonhart_93]

@@petersuvara And even in C you can always implement you own memory allocators and it's not that hard. There are even libraries for referenced counted allocation, something like shared pointers in C++. Point is, there are many more convenient and customizable solutions to such potential issues.

[@some1and297]

100% lifetime facts, literally why I use Vec instead of &[T] even in functions that having a set amount of values would be helpful.

[@foxwhite25]

You know lifetime elision exist right?

[@olchikind7816]

Why not Box?

[@throwaway3227]

Shared mutability is bad because it's not intuitive. If you have a thread with `if (state.is_valid) state.do_something()`, you expect state to still be valid when you run `state.do_something()`. This creates a whole category of bugs and security issues called Time of Check to Time of Use (TOCTOU). Having shared mutability be explicit (like how Rust does it with `Arc`) eliminates a lot of TOCTOU bugs (limited to its own data, not on external data such as the file system).

[@throwaway3227]

And I just got to the point where you addressed this. Still has the same issue on a single thread, though. ``` if (a.valid_state() && b.valid_state()) { a.do_work(); b.do_work(); } ``` With Rust, the code above can be assumed to be valid. With multiple mutable pointers, imagine that this is followed by `let a = NetworkHandler(&mut state); let b = FSHandler(&mut state);`, and suddenly you need to know implementation details of `do_work()` to know if this is safe. The TOCTOU foot gun is still there, just more subtle.

[@TJackson736]

The object based memory recycling seems like it should be possible in Zig. Just pass that allocator to the Zig object.

[@herrpez]

Another nigh-unsearchable name. Good job, well done!

[@klasus2344]

Shared mutable references are really bad, *especially* in single-threaded environments. Imagine a variable storing a mutable reference to a heap-allocated vector (e.g., &mut Vec), and another variable storing a reference to an element in that vector (e.g., &mut T). If the former variable modifies the vector, the vector might get reallocated. The latter reference is then invalidated and will segfault when dereferenced.

[@mikkelens]

Thank you for typing this! I didn't understand what they were talking about in the article when I read it on my own either, but this makes so much sense.

[@SamualN]

9:18 not necessarily. single threaded async can cause race conditions too

[@chriss3404]

2:04 YES THANK YOU PRIME. I've been talking to several developers in my friend circle, and they UNANIMOUSLY AGREE that this is the worst feature of Rust. It makes COMPLETE SENSE to SEPARATE how memory is structured from it's lifetime because a **correct lifetime is implied BY YOUR USE OF THE TYPE**. note: have not finished video, too excited to wait to comment.

[@samhughes1747]

@19:15 "We've solved memory management! The only stuff left to do is everything that's hard about memory management!"

[@hugobcdesrosiers5689]

Back in the days Objective-C in NeXTstep had auto-release pools (maybe still today on Swift/MacOS) providing a lifetime control feature on RC memory management. Compact regions in Haskell provides a similar feature on GC behaviour... and of course many more options for fine-tuning memory management without losing safe execution.

[@dv_xl]

9:30 shared multiple pointers on the same thread is fine from a safety prospective but imo it can lead to stinky code. Some of the old gnu coreutils code is really full of this stuff, you'll have n references to some shared pointer and have mutations happening as side effects to if conditions. It's really insane

[@fotnite_]

Yeah, Rust's safety features can be annoying if you're just doing a small project on your own, but as soon as you're working on maintaining code for an extended period of time and/or have to work with a lot of other people on the same project, these kinds of restrictions make a lot more sense. Doubly so for code that's been around for decades.

[@earx23]

Rust unique / shared pointer constraints can actually cause "race conditions" in a single thread. Consider memcpy() vs memmove() from C. Depending on implementation of memcpy(), if source and destination overlap, there may be undefined effects. This took me ages to figure out.. simple pointer aliasing. It was never mentioned anywhere in the Rust book... and I thought, but Rust threads are even forbidden to just share references, so what are these borrow checker rules then enforcing? The answer is prohibition of pointer aliasing.

[@fuzedcable5612]

It was actually easier to learn rust than c++ I still never learned C++ i just gave up

[@zactron1997]

An interesting experience I had was teaching Python developers from University how to program in Rust. They took to it almost immediately and had no issues. In fact, the strong types, a built in clone(), and the massive performance boost had them all elated. I think Rust is hard when you try to write C in Rust, but that's the same with every language. Try and write Lisp in JS. What I'd love to see isn't a Rust alternative that sacrifices safety, and instead something that makes writing the dumb version of Rust really easy. For example, most borrow checker errors can be avoided by just slapping a Gc wrapper around everything. If there was a language that did that, automatically applied the maximal set of derive(...) implementations, etc., I reckon you'd have a stellar language for prototyping.

[@Kwazzaaap]

You always think you've done it and then you run into a codebase with 14 more features you haven't used and 2837 macros nobody asked for

[@samhughes1747]

9:00 shared mutability effectively hidden data flow, just like try-except is a hidden control flow. It's not instant memory-corruption, or whatever, but it makes things harder to follow. ALSO, people like this seem to always seem to forget that unsafe is right there if they want to do a linked-list with cycles. That's kinda the point of having that. There's a "danger" button you can push when you need to do something that the borrow checker can't help you with, but you first have to be quite explicit that you do not, in fact, want any help there.

[@Pjiwm]

Was there at her talk at RustNL yesterday. Interop with Rust seems scary with the lack of an ABI.

[@d3stinYwOw]

It's already there, called Nim ;)

[@user-ck9tb4fv2x]

I think differently. This goes back to the idea of tools for a job. I've been messing with arduinos lately. It's the lowest I am going with programming as this is more robotics level tasks. But if we look at languages as tools then it becomes easier to choose the right tool for the job. We could compare these tools on how low or high level the language is, how type safe or not safe it is and more so. But after that we need to pick a few that meet some criteria and say this is our main belt, then after that pick some others you like to have some fun with. Programming isn't all serious stuff do some whacky stuff in another language, ide, engine etc. Explore and use your exploration to increase your main skill. Your main belt might be C instead of Rust, JS instead of Python, C++ instead of GO. etc. I want to end this with, this is just some thoughts for people wanting to do a lot in a lot of places. If you prefer to do one thing all day every day. Do it, but still explore enough to understand the big picture. I get mastering something but some times you don't need harnesses, steel toed boots, gloves, safety glasses, and a spotter to plug in a cord.

[@ericjbowman1708]

Zig's kid would beat it up! I've written my first zig program... level 2 bootloader. So far, it just says "Hello World! I am a bootloader" and whatever # is in the buffer, if the content of the buffer is a number. Level 3 bootloaders have filenames starting "#." Cool!

[@mischavandenburg]

Myself and many others from my community like watching your videos. Keep it up!

[@camotubi]

Race conditions are not exclusive to sharing data across thread. They happen when you have concurrent behavior, aka the order of things being executed is not defined.

[@jongeduard]

Exactly! In other words: single threaded concurrency is a thing. Parallelism is just one way to solve the concurrency. Asynchronous execution, deferred execution is another way. And in my understanding, race condition is used as a term in both contexts. The only real thing that only happens in parallel are wat is known as `data races`, where actual data corruption happens due to simultaneous memory access by different threads.

[@AndrewBrownK]

Exactly. Read-then-write has to be exclusive or atomic or it’s a race condition

[@nathanfranck5822]

Extending from 20:00 --- I think a LOT of people (me included) fell deep in love with Typescript, but felt bad for using a "fake" language, and found Rust because the type system is similar to Typescript while also being a "real" programming language. Now that I found Zig, I feel like I'm getting my Typescript-like type experience, my real compiled language (with top performance), and a general serious low level feel, which is what Typescript was lacking. I don't feel attached to Rust much nowadays, probably not enough sunken cost :)

[@HalfMonty11]

That's a pretty good summary that I think does fit a lot of people's experience, myself included, when it comes to getting into Rust. However, for whatever reason... Zig doesn't quite do it for me and I'm not sure why. What I like about Rust is that while yes, it can be hard, it can also be so easy, which is why a bunch of Typescript devs got into it in the first place. It depends on the kind of problem you are trying to solve, but well made crates in Rust can enable very high level plug and play Typescript-like logic. From what I've done with zig so for, the "bottom" is way easier than Rust, sure, but the top isn't really any easier than the bottom. This is good and probably good enough for most, but I really like that with Macros and such, you can make Rust easier. The hardest things in rust are really hard, the easiest thing are as easy as typescript. Zig is pretty flat, always just a little tough, not unlike C which makes sense.

[@Leonhart_93]

No joke, a lot of Rust users seem to have come directly from JS dev. Comparatively way less long time C/C++ users want to switch to it, it's a really hard sell.

[@nathanfranck5822]

@@HalfMonty11 Yeah, I really like in Rust how you can chain things together, effectively an extension of map/filter/reduce, and I miss that a lot in Zig, though I'm happy enough to write my own for loops and encapsulate them in little labeled code blocks and use then as expressions that way. I like that Zig isn't pretending to be convenient, just concrete and composeable.

[@mikkelens]

A lot of people who are not from the TS world also fall in love with the tools rust has e.g. cargo and rustup. I come from C# and god everything just fucking works in rust land its beautiful. Not sure what the Zig situation is, but I'm not sure I've heard of it even having a package manager.

[@FirstYokai]

The same thing with programming. We forget how hard programming really is

[@Leonhart_93]

And often it's purposefully made hard, inventing issues and then producing solutions to those issues, like it's some achievement...

[@rusi6219]

@@Leonhart_93 rust cve rs

[@rusi6219]

@@SimonWoodburyForget okay show us a problem that's so complicated that you need Rust to solve it and not any traditional language of your choice.

[@rusi6219]

@@SimonWoodburyForget python is objectively inferior to C in every way though

[@rusi6219]

@@SimonWoodburyForget plus python literally runs on C so that's a bad example anyway

[@mk72v2oq]

You can only have 1 mutable reference because it is very easy to shoot yourself otherwise. Imagine if such code would have been allowed: let mut vec = vec![1, 2, 3, 4]; let e = &mut vec[0]; vec.push(69); *e = 42; You get a mutable reference to the first element, then you push to the array, which causes reallocation. Suddenly, you end up writing into invalid reference to old freed memory, instead of actually changing the first element, because the array was moved to a new place. Classic use-after-free bug.

[@Leonhart_93]

Easy fix, don't do that without checking. Not sure why that's such a hard concept, I use about 6 high and low level languages right now and in ALL of them you have to check for null or in-existing references.

[@mk72v2oq]

@@Leonhart_93 yeah, yeah, skill issue, "just don't make mistakes". Not being able to write 100% correct code in assembly is a skill issue too btw.

[@Leonhart_93]

@@mk72v2oq What, do you think that if someone constantly forces you to only do things a specific way then you will write stellar code or something? The top 10-15 languages that stood the test of time all work in very similar ways, better get used to doing it.

[@isodoubIet]

@@Leonhart_93 iterator invalidation is not a trivial problem

[@Leonhart_93]

@@isodoubIet Not sure what you mean here, I do not know an issue by that name.

[@Tony-dp1rl]

I think we can pretty much say now after the past decade that Go and Rust have peaked in terms of usage scenarios, and Java/C#/JavaScript are essentially here to stay for career stability.

[@rusi6219]

The only development will be that Rust will completely fall off and Go will take over that segment because it's objectively better

[@hagaiak]

Rust is going to overtake all of those. As someone working in FAANG/MAGMA and who has friends in all big companies, Rust is slowly getting adopted and invested in. Eventually it will be considered bad practice to not use Rust unless you have a good reason to (such as legacy code or interoperability, or lack of library support).

[@ck-the-terrible]

damn these KZbin bots are fast lol

[@DecadantHandshake]

True!

[@monad_tcp]

15:12 yeah but that leads to fragmentation, and now you need heap compaction, and now you end up having to implement the hardest part of a garbage collector anyway, for what benefit ? oh they didn't do that, so you basically end up needing to profile and fix it manually, which is actually good.

[@rogerdinhelm4671]

Lifetimes attached to functions - is just a simple C stack allocation.

[@LukeFrisken]

I think many people want the type system of Rust on a Go-like runtime, with Rust quality tooling. Nothing like that currently exists, but I guess Gleam might be getting close, however it would be even nicer if it didn't depend on an external runtime but brought something along for the ride like Go or Ocaml. Roc seems interesting but again, it's purely functional language and will probably never have the broad appeal of something like Go or Rust for that reason alone. For most business code, you don't want to be thinking about lifetimes, and you don't want to be thinking about the footguns that come with a cooperative async model, or fit a square peg into a functional programming shaped triangle hole, I just want a simple, type safe ML style, functional leaning but not strictly functional, language with a runtime to take care of these things for me, so I can focus on the getting the software correct and reliable in a productive manner.

[@rafagd]

The problem with opt-in safety is that it can get really hard to see where you're opting out... That said, it would be nice if it was possible to make the lifetimes declarations not leak everywhere...

[@AndrewBrownK]

If you don’t want lifetimes to spread then just use an Rc or Arc. If the restrictions of a borrow are not exactly what you need, then don’t use it. Rust has all the primitives you need.

[@rafagd]

@@AndrewBrownK yeah, but I want to graduate from the rc+refcell, arc+mutex spam as well, I just don't want to have to rewrite the whole program because I'm doing it. lol

[@taragnor]

Yeah the main thing I'd love to see Rust implement is an implied lifetime that a struct can't outlive it's contents. And the compiler would just fit in the lifetimes in whatever you put them in to always ensure that guarantee. In other words: Struct A {data: &u32} would become valid rust and be equivalent to struct A as far as the compiler is concerned. That would solve so many problems.

[@Ben_EhHeyeh]

Watch your Forthin Words. It's a stack attack coming from Moore back...Number stack, data stack and return stack.

[@JoeTaber]

I wonder if you can enforce opt-in safety at a module level. That might sidestep the concerns about "other people's code" getting out of hand -- just don't import libraries that don't opt-in to safety.

[@drd2093]

about vectors. The vector struct itself is pointed to and never changes location. Reallocs happen to the things that structure points to

[@nERVEcenter117]

It would be called Nim. It's just Nim.

[@jenreiss3107]

lifetimes are independent of "reachability" on linked lists, so if all of the nodes in a linked list have the same lifetime, they will all be de-allocated at the same time, regardless of whether they are "reachable" from the head node. instead, the lifetime of child nodes of a linked list are "less" than the lifetime of the head node, as to guarantee memory safety and avoid a memory leak, the root node must live longer than it's child nodes

[@Hector-bj3ls]

Essentially its an arena per object and they have a weird `recycle` keyword that does some sort of mark and sweep style operation.

[@u9vata]

So close yet so far - especially the "we can treat all user-defined types as pointers" approach that kills all cache performance similar to GC languages. This makes me wanna properly finish my own systems programming language that has a better idea than this ;-)

[@MikkoRantalainen]

GC is basically a trick where you pretend that your computer has infinite memory and you keep doing new allocations and GC hopefully can figure out stuff that is no longer referenced anywhere and can be released. If your system has really lot memory, a good GC never does anything because NOP implementation can already pretend having infinite memory. The problem is that GC systems typically have practical 5-10x overhead meaning if your application really required 500 MB RAM, it requires 2500-5000 MB when executed with GC. However, if your developer cost is 5-10x less with GC, it makes sense if you pay for all the hardware. And if the customers pay for the hardware, GC is pretty much always a win unless you're seriously RAM limited (e.g. gaming). GC can be tweaked to run with very small RAM usage overhead but then it will use lots of CPU to continuously go through the memory and look for stuff to free.

[@Leonhart_93]

Depends on the implementation. For example you can write a custom GC in C/C++ that is entirely deterministic, based on ref counting, similar to shared pointers. The reason why in some languages the GC doesn't collect the memory immediately is because it's always a performance hit and sometimes it might be preferable to wait until the user closes the application, or until it goes beyond a certain amount. And it does end up with less lag like that.

[@MikkoRantalainen]

@@Leonhart_93 That's true and with Rust, you can pretend that most of the memory is automatically garbage collected because it's internally either ref-counted or lifetime is decided during compile time. However, such solutions cannot handle with data structures that use reference loops. For those, you need to use some kind of manual book keeping such as weak pointers or manually breaking the loops.

[@BaldurNorddahl]

@@Leonhart_93 turns out that a lot of data is created and used for a very short time. Keeping track and freeing the memory requires CPU and memory access. A copying GC will only spend time on the data that is still live (by copying it to a new location) and everything else is freed for free. This can be more efficient that malloc or reference counting. A modern approach is to have generations, such that a copying GC is used for the youngest generation with most probability of having a large number of unused allocations. So another reason to wait a while to run the GC is that you want some objects to become free and therefore not requiring copying.

[@Dogo.R]

5-10x is absolutely insane. GC inherenrly has a max of 2x, since you could just swap between 2 areas each time. And the main development behind different garbage collectors is to get under 2x aswell as reduce pause times. You clearly havent looked very hard into garbage collectors in you are misunderstanding their memory usage to such an insane degree. Look into zgc or C4 for great garbage collector implmentations.

[@dexterman6361]

Isn't this just almost C++ but with extra steps? I mean, sure you do some similar extra steps with C++ too, such as installing a library such as jemalloc or something that does pools, and then just replacing the global memory allocator with this one, and you effectively have the same result as June ... if I am not mistaken Interesting nonetheless since it's baked into the language. The "full encapsulation" also reminds me strongly of unique_ptr

[@Leonhart_93]

That's the ironic thing about doing things "better" than a long-lasting standard. When you will add everything the previous one was capable of, then you will find you basically duplicated the thing entirely.

[@MrJamesstarr]

From an institutional level, you want always and never. Look up the cost to Microsoft of memory leaks. If you are project manager, can eliminate a cost that is on C levels radar or higher medicore engenineers to develop drivers that just need to be good enough, and not have these critical bugs.

[@rusi6219]

Except that they need to be fast and even C often isn't enough to achieve that hence why those programs are full of inline assembler. Rust can and will never catch up.

[@KoltPenny]

Why would you want a terrible community + telemetry?

[@throwaway3227]

C++ has opt in safety with `std::shared_ptr` and `std::unique_ptr`.

[@Colonel1954Dz]

We're recreating C++? Opt-in safety as in smart pointers? I do see the value of Rust for sure. Developers should have some freedom though (which comes with responsibility)

[@rafelgrau]

The baby would want to be a lawyer and nothing about programming

[@Caellyan]

2:17 - Lifetimes are a kind of type, it's just that they're not conventional "types" developers are used to and data types can't interact with lifetimes besides "including" them. It makes sense to specify them as part of type signature as it's the most compact option. In type theory you'd have to write a separate line to specify it right after you init data - which is less convenient. They don't leak, stop saying that.

[@ezhilsivarajsr5759]

Go + Rust = Gost🥵🥵

[@theondono]

Clearly Go + Rust = Groot

[@thatmg]

BRAZIL MENTIONED

[@chrisrowlandson9564]

20:39 This caught me so off guard 😂😂😂

[@Harve6988]

So much effort to stop shared mutable state across multiple threads. Who is sharing mutable data across threads nowadays? At least for businessey apps - just use a library that provides concurrent data structures. Or use something like Java that has them built in....

[@mskiptr]

Also, you would love Haskell and Idris so much. They are all about the type system really

[@someguy9440]

Go doesn't need a baby. It's sterile. There are no children. heh. also - Turso was a nice shout. Wonder how this will play with wasmer edge. Thanks for that 👍

[@tonytins]

Used Rust for quite a while, but it slowly started to burn me out every time I had to do something complex with the borrow checker. Not to mention compile time is slow, and project sizes are stupidly big.

[@rusi6219]

Thank you. I've recently had a rust fanatic insist that Rust files are the same size as C files. Absolutely deranged.

[@taragnor]

​@@rusi6219 Really depends on what you're doing, some things are shorter to do in Rust, others are larger. Using iterator based functionality makes complex filter, map, etc. operations way easier to write than clunky C int based for loops. Of course, if you have to write a bunch of complex lifetime signatures and trait definitions, Rust can really blow up in size. Of course, C doesn't even have many abstraction tools, so comparing Rust to C++ is probably a more fair comparison. Also Rust doesn't require header files which does present an advantage in terms of space.

[@rusi6219]

@@taragnor yes comparing rust to c++ is much fairer but that's not what rustaceans do because they know nothing

[@RenderingUser]

The blondeagen

[@nicholashendrata]

Petition for Prime to react to Concurrency vs. Parallelism

[@asdfghyter]

9:04 if nothing else, it’s horrible in the case of single-threaded concurrency. if you have long-living shared mutable state, you’re likely to have something that is effectively concurrency unless you’re very careful to only yield to the other concurrent actions when a transaction is complete and all the state is in a valid state that is expected by the other code. in summary, shared mutability is an issue because now you need to think about if there is any interaction between the different users of the data instead of being able to consider them separately, since you know that nothing else can touch your data shared mutability is a necessary evil that should be kept to a minimum possible for your system

[@arsenbabaev1022]

allocating and defer freeing isnt SAFE, so lets do the same thing but by placing manual recycles, bloating memory usage with more additional tracking and hidden work being executed, sign me up

[@dahahaka]

Why isn't defer freeing safe?

[@chinoto1]

15:30 So that's why there's a slight echo. I wasn't sure if I was just imagining something odd in the audio.

[@denisvolin7489]

Can we just have a language like C and C++ had a baby, taking only good things out of both: pretty much low level, operator overloading, constructors and destructors, but only structs, enums and unions, no classes, inheritance, virtual staff. Can it be around that type safe as C and thus ABI consistent. Can strict type safety be a compiler option? Open source is a cool way to learn by reading other's code, but can we NOT making it mandatory, stripping developers of the income source for selling new version?

[@rusi6219]

It might be worth the effort to try and see if a compiler like this could be written.

[@Leonhart_93]

In many ways you can just write that type of code right now and ignore all the other un-needed features.

[@sasasmylee]

Guys, what do you think about Swift?

[@Leonhart_93]

Never used it but that syntax is very agreeable, which is always a good start. I will need to do some stuff on macOS soon.

[@macserv]

@@Leonhart_93 You don't necessarily *need* to use macOS... the Swift Toolchain is supported by Apple for Linux and Windows. You can build tools multiple systems using the Swift Standard Lib, and other Swift Packages from Apple. Web services are easy too, using Vapor.

[@macserv]

I think It's the language everybody actually wants, but they don't know it yet. While Prime and other engineering KZbinrs long for a better balance of safety, ergonomics, and interoperability, Swift already offers it, with the added bonuses of transparent, community-driven evolution, and full-scale corporate investment. Unfortunately, the common perception is that Swift is just for building GUI apps for Apple platforms, but nothing could be further from the truth. Hopefully that changes at WWDC this year with Swift 6. Meanwhile I'll be in my office, using it to work miracles across the command-line, desktop, mobile, and web domains.

[@fotnite_]

​@@macserv I've looked into it, but I don't really see why people outside Apple's ecosystem would use it over Go, because it seems like it kinda targets the same use cases. Go uses a GC, while Swift puts Arcs everywhere, but from what I've seen there isn't a significant difference in performance between the two.

[@admercs]

C++ still works great. Rust is nice, but more of a headache.

[@mrrolandlawrence]

this makes me miss arm macro assembler. it was so simple.

[@monad_tcp]

2:43 maybe Type tagging is a better alternative for that, I mean "dependently typed".

[@LtdJorge]

I think you have some automatic noise reduction enabled for the audio, or something like that. It doesn’t sound good, and seems like it’s cutting out some frequencies at different times, that’s why I suspect it’s noise reduction.

[@giovanni640]

Back to manual memory management, huh?

[@isodoubIet]

In rust, you have: - red/blue functions for async/non-async - an effective continuum of possible lifetime annotations - a large number of possible error returns (Option, Result with arbitrary Es) Any change you make to anything touching these is viral and you'll have to do a large refactoring. Compare with its direct competitor C++, where you have (effectively) red/blue functions for async and that's it. Rust discourages iterative development.

[@FlanPoirot]

C has no coloring at all. everything is a function that you pass data to, everything is just a number. Git rekt, "modern devs" 😎

[@isodoubIet]

@@FlanPoirot C++ doesn't have "coloring" as a built-in language feature either; when you launch an async task you receive a std::future that you have to call .get() on to receive the result, so the 'coloring' is really a library feature. C's lack of anything comparable is a weakness, not a strength.

[@infinitelink]

​@@isodoubIetif you know C's history and what came before, with the choices based on what came before (K&R detail them in the earliest books, which remain valid and the most accessible of any I've found), you understand that C was kept so simple quite on purpose to ensure it's infinitely portable and easy to create a valid compiler for any new architecture in months or less. C was spartan to the point of its creators emphasizing that it's not its standard library and the stdlib is not C. C was meant to implement only the objects intrinsic to physical computers and only the operations they themselves implement (logic & arithmetic). Everything else can be composed from those and accessed from a library. It's literally C's intended strength and also why possible to create ultra-compact programs or replace any part of C that you like....and why compilers & interpreters for other languages (including those that came before C!) get (re)written in C. Saying C's "lack of xyz isn't a strength" is just missing the point entirely.

[@isodoubIet]

@@infinitelink "you understand that C was kept so simple quite on purpose to ensure it's infinitely portable and easy to create a valid compiler for any new architecture in months or less." Yeah and what a colossal fail that was I'll skip the rest since it's clearly not relevant to what we're talking about.

[@nullid1492]

@@isodoubIet ​ C is not a failure. 50 years after its creation, 20% of developers use C (according to jetbrains survey). Almost all mainstream programming languages have a C ABI. Embedded systems and operating systems largely all have a significant amount of code in C.

[@JeremyAndersonBoise]

🔥Lead tone on the final solo ☄️

[@asdfghyter]

4:46 excuse me, but “treat all user data as pointers” sounds like a terrible idea if you want high performance and low memory overhead!

[@cloudsquall88]

I trust Sophia wholeheartedly, she is amazingly skilled and transparent in her thought process (I 've watched a few nushell development streams, and articles). When I hear from her own mouth that some of these problems can be solved, I honestly believe that they can. I am very very hopeful that her and her partner's work will be viable, just as we have watched nushell grow so much.

[@ciCCapROSTi]

I just don't understand why people want to reinvent C++ all the time.

[@Leonhart_93]

And when they manage to do everything that C++ does, then they will see that they have duplicated it 😅

[@isodoubIet]

Literally all I want is C++ with less baggage. Cppfront gets me like 90% of the way there.

[@Leonhart_93]

@@isodoubIet Why is the feature bloat of C++ an actual issue? C++ has a lot of features you don't actually need, but in that case just don't use them. Hell, it's perfectly possible to write it exactly like C with some perks here and there. Just use what you want to use from its kit.

[@rusi6219]

@@isodoubIet just write C you don't really need objects for anything. And modern C is pretty nice, no bloat and pretty much every feature that's been added over the years is amazing.

[@isodoubIet]

@@rusi6219 Half the baggage I don't like in C++ is from C, why would I want more of that?

[@pranavbadrinathan6693]

Shared mutability on the same thread (or "spooky action at a distance") is bad in my opinion. It makes debugging a whole lot harder. That being said, this is mainly a skill issue imo (yes, I have skill issues lol), and can be fixed by the programmer not doing anything stupid, so maybe it is fine and I am just being a bitch. On a related note, I think having shared mutability on the same thread will make UI libraries a whole lot easier. Afaik, the lack of shared mutable pointers is what makes traditional UI paradigms so difficult on rust. Though I don't actually have experience making UI libraries, so take this with a grain of salt.

[@shredder4841]

Just write C++ its fine

[@pauldraper1736]

Go + Rust = Ghost

[@thekwoka4707]

Opt in safety just means nobody will use it....

[@Leonhart_93]

And that would mean that nobody actually wants it. Perhaps it's the reason why the Rust job market is still so small despite the incredible push.

[@ryanwilliams5499]

Ocaml...the answer is Ocaml, you are welcome.

[@DeveloperOfGames]

ew

[@Ohmriginal722]

I want a Rust that's as simple and slow moving as C, but I also think there's way too many languages already

[@rusi6219]

You're describing Go.

[@Ohmriginal722]

@@rusi6219 no because I want a borrow checker, not a garbage collector

[@rusi6219]

@@Ohmriginal722 borrow checker is a lazy way to pretend you're doing the job yourself

[@computerfan1079]

I was there when it was announced at RustNL, very cool to see it here!

[@saiphaneeshk.h.5482]

Under 10min? I'm blazingly fast.

[@itzhakeretzkdosha6875]

Sounds nice. Is this a real language yet?

[@Dogo.R]

From seeing talks that explain different garbage collectors and show visuals for them (like this talk: kzbin.info/www/bejne/oWXZnJdmls2KoLM) This litterally just looks like garbage collection but you understand the tree via keeping a copy of it, rather than understanding the tree by moving like an ant across it like garbage collectors do. Both utilize the fact programs are a tree of references and deallocate when a part of the tree is cut off. The reason I say keep a copy of it is thats the only way they could garbage collect off a specific node. You have to know what points to what accross the whole program in order to know what is or isnt a part of the branches of a node you want to free. So you have to either walk across the whole tree or keep a representation of the tree as a database, like a b-tree or similiar.

[@maxlee3838]

This is an actor system dressed up in different clothing. Instead of sending data, you pass references to your actor.