Are there any newer Sōzu related videos please? I would like to write some custom features for a reverse proxy, and Sōzu looks like a good place to start.
I like the talk a lot, and it's made me reconsider the design for my own lightweight game engine written in Rust. However, I'm wondering whether the whole generational indexes approach is the best way to go. Either you have very sparse entities with lots of different component arrangements (in which case you'll be allocating a lot of memory in your EntityMap component stores for entities not using these components), or your entites all have sort of the same set of components (in which case you might wonder if it's not better to just have a single Entity struct that contains all your components and store it in a large Vec<Entity>). Granted, the EntityMap pattern allows for very fast O(1) lookups of your components but it comes at the cost of wasted memory.
Really good talk and perspective! It reminds me btw a lot of the functional core, imperative shell approach (afaik Gary Bernhardt coined this concept). To be honest I'm not a big fan of OOP myself but it seems you use it in a very similar way I've been doing it: for "big" stateful services (aka actors). I also use it for "small things" that don't depend on anything else but contain a lot of state and functions on this state - so mostly container-like types. My main issue with OOP was always how bad it is at modelling domain problems and how OOP-abstraction increases actually tight coupling and decreases modularity. With data and functions it's simple: they are already "objects"/atoms/... so you model the data with these atoms, and you write the functions that transform this data and you put everything into modules to logically group it - everything is nicely separated and decoupled but logically grouped. Every function can work on a variety of data, so it's easier to model transformations between a variety of data - you don't have to think: where does function A belong? to object B,C or D? With objects on the other hand you create a "functional" relationship - data and functions are tightly coupled. In some cases that's perfectly valid, but more often it's not and you just created an abstraction over an abstraction for no reason. I often compare it to database relationships: in OOP you can only model 1:n relationships (1 class, which is also the state/data : n functions. I'm talking purely about the modeling side, so not how it is at runtime where you can have multiple objects for the same class). Most systems have a lot of n:m relationships though (n state/data : m functions, e.g. some_function(data a, data b, data c, ...)). So in OOP you need an extra layer of abstraction to "translate" to this n:m relationship. That's why I often see things like e.g. *Manager classes in OOP code. Nowadays whenever I encounter a "SomethingManager" class I consider it code-smell. The moment I have some inter-dependency of objects like: obj1.method(obj2) I usually refactor it so that they all depend only on pure data/functions not objects, like: obj1.method(just_some_simple_data). After all every dependency on an object makes it automatically depend on everything(!) else that object depends on: it's internal state, all the methods, class hierarchy, etc. You literally got the banana together with the gorilla and the jungle! Passing references to objects between objects is just crazy and I'm pretty sure that's not what Alan Kay had in mind. It's the lazy developers way of pulling in dependencies without specifying them explicitly, cheap in the beginning, but you pay double (and more) later. Some OOP-purists call me crazy but I have a very good track record of systems that are well designed this way - while they still discuss how to use design patterns to somehow manage their OOP mess ;)
I have some concerns about the Rust "weirdness budget" running out, where people look at this think "what the f" and walk away. I'd say a priority is to don't let this leak too much in application code.
What if the answer for "The internet is highly concurrent and highly security-conscious" is not a programming language but Webassembly runtime which is sandboxed ? Now if I write in C and compile to webassembly... can NSA say C is insecure ?
Amazing talk!! Very inspiring !! I chose Go over Rust 6 years ago cuz Rust didn't support async await natively at the time.Wish I had watched this video some time down the road. In 2024, i m starting with Rust.. Gotto to say its an amazing language for all people who consider coding as their passion.
"Rust in the Linux kernel"? Of course it turns out people did ask Linus about this and his response after looking at Rust was something like "It's not an entirely terrible idea". Which coming from Linus is high praise indeed. So now we do have Rust in the kernel. This talk is pretty amazing in that describes a lot of work done at MS that incorporated a lot of the ideas the Rust guys came up with and apparently was successful even if never adopted. So Rust is on the right track and this talk is a great sales pitch for it.
BTW: what is the extension of VSCode you are using that gives you the full explanation of the error cause in the text without the need to hover over the red curly underline? Atomic reference counting (ARC) - and Rust has an atomic variant of Rc called Arc (which means that only one thread at the same time may increment the count) in its arsenal which is very much needed in multi-threaded applications - does a nice job in Objective-C for memory management without garbage collection. Clone becomes cheap on an Arc as it just increments the reference count. I am glad that Rust offers it. But as you can only get immutable access to the data pointed to by an Arc, don't get over your head using it. If you want concurrent mutable access to data, you need a Mutex (or its more relaxed variant RwLock, which allows for multiple readers or one single writer at the same time), which is another smart pointer in Rust's arsenal. Packed into an Arc it can be cloned cheaply and distributed among threads, but only one thread at the same time will be able to read or alter the data protected by the Mutex (more readers are allowed with RwLock, but once a thread wants to write, it has to wait for all other readers or writers to release the lock). So don't be surprised if you see a lot of Arc<Mutex<Type>> declarations in multithreaded rust code. It's always a mouthful, but surprisingly efficient in the resulting machine code. But a mutual exclusive lock is never without costs. It depends on the nature of the task you want to compute using multiple threads and the way you organise the work - if locking happens often, the result may be (often much) slower than a single-threaded implementation.
Interesting. I was about to complain that the size of `Foo` isn't 5 but should be 8 because of padding. But then I actually tried it out and it turns out it is actually 4. I guess `char` has some niche values that are used. (Unicode code points only go up to 2^21 not 2^32, so there's a lot of values to choose from).
I found Stabby randomly on a Reddit post and I friggen love it. I opened this video because the topic is relevant to the work I am doing now, pleasantly surprised to see that this is an explainer on Stabby!
Thanks for this, I've been playing around with smart pointers and refcells and probably used them excessively, i can simplify some of what I've done with Box<>.
Mr Stropek you are one of the best exposer i“ve ever heard on the topic. This talk was invaluable for me! Thanks a lot. Rust, give this man more talks please. And ty you too.
