This channel is dedicated to the videos of the RustLab conference. RustLab is the first Italian international conference on the Rust programming language, organized by Develer. Develer is not just an Italian company projecting and releasing hardware and software solutions for the industrial environment, but is also an ensemble of people sharing their great passion for new technologies and how they can be applied to your everyday life.
Hello, I was looking at your video channel. We may be helping a company that uses secure images to increase supply chain security and help cloud native development. Would you be willing to help try their software, make a video, and help show devs how to use their tools? This is not an offer, but just to start a conversation about your willingness to take on sponsorship. Please provide me with your email if you are interested. You'd have a chance to look at their technology and decide if it's the type of software that you'd be interested in covering in your channel.
This is a very good talk about how to use Rust even better once one is comfortable with the borrow checker and Traits and Associated Types. I think it also helps to grasp what is being said if one has first cloned the Xilem repo and run the two examples in it and looked at the very small Rust source file for each one and wondered how it accomplishes what it does.
Rust is more mature, and interop with C can be improved. Lets at least get one non-C language that has reached 1.0 into the kernel before we think about adding more.
Rust is not for this kind of tasks. Way better and easier to use go for it. Each language have it own purpose. There is no need to solve every task using same tool
Zero cost abstraction makes rust perfect language for this kind of thing, given you find good abstraction. Building backend from scratch would easily be better experience with go, but given good crate you can have equality good or better DX.
@@NoxyYT The problem is that you need lots of good crates. And right now they're not present for this kind of development. Maybe in the future. Anyway I'm a bit skeptical about it. But lets see what happens
Been looking forward to watching this talk. I think property testing is an incredibly useful tool to have in your belt, and the ability to combine it with futures execution ordering is really useful. This means you can basically get some features that you would get from formal verifications systems (promela, TLA+) for *free* in Rust! At least for promela, it works simply by trying out all possible permutations of orderings and ensuring your assertions hold. Combining property testing with execution ordering achieves the same. How awesome is that?
Zelij is great! Thank you! I use it on my webserver. I open 5 tabs for different apps. Then I detach. Next time I connect over SSH I just attach my Zelij environment. And everything is under my fingertips again. Great!
The benefit of a brand new project is the openness for experimentation. Existing projects can always adopt what they find useful from Pavex. In my opinion of course.
@pierreavital1917 do you have any interest in publishing the type-fu from the first portion of the talk (or the typenum2 module in stabby) as it's own crate with optional compatibility with typenum? or are you avoiding stabilizing that kind of interface for potential future optimizations in stabby? something that I want to look into: would bundling `FullAdderCarry<B, C>: Boolean` and `FullAdderSum<B, C>: Boolean` into a `FullAdder<B, C>: FullAdderRes` where FullAdderRes is defined with associated types Sum and Carry ever be useful? Maybe not for this specific case. I'm trying to think of a way where the compiler would be able to reuse some computation that is shared between multiple outputs of a single "function", that it might not if the outputs were split as currently implemented.
Hi there, No plans to release it independently, not so much because I don't want to stabilise it, but more because stabby needs the special ternaries to be part of the trait for the proof chain not to break. I don't actually plan on breaking its API (it'd be quite annoying to me as well), or at least not without a major, so feel free to use it wherever applicable. Compatibility with `typenum` isn't a high priority either, because I'm not certain either would get benefits from that. Grouping up the outputs of the adder would actually hinder performance: the compiler would need to additionally prove that the group can be split, all to split the type again. There would need to be one such proof for every combination.
Hi, speaker here, just letting you know that I'll be checking in on the comments here to answer questions. Feel free to tag me to make me see your questions faster :)
@@mskiptr When your end goal is the proof, most definitely. But what this talk really is about is how to use the type system to perform computations at compile time. Specifically, my use case for all of this was to keep track of type layouts to be able to pick niches deterministically for sum types, so that we could get ABI-stable compact sum types, which I explain more about in my RustConf 2023 talk :)
I wish somebody asked: "why not use a proc macro?" I think a proc macro would be more maintainable, but I didn't understand stabby's feature set enough to know if there was a reason not to use proc macros (something like one of the inner proof terms actually being something a stabby user could use in `impl`s or something).
I'm checking the videos every now and then, so I can answer questions that weren't asked live :) Macros are awesome, but can only (barring some very evil tricks) produce a pure result of their syntactic input. I use them in Zenoh to move some input validity checks to compile time, in fact. However, they can't really compute anything that's not part of their input (the size of a type, for example), because all they see is a tokenized version of their input. They can't tell whether `Arc` is the one defined in `std::symc` or some arbitrary crate. What they can do however (and that's how stabby uses them) is write the very cursed type-fu on behalf of the user, while the type-system handles keeping track of the values associated to each type. Making these two work together gives you power akin to true magic, but kiss your sanity goodbye:)
I wonder if SVG editors are things that are being considered as a customer of this effort. It would be great to see the progress done here in editors that can also target print as the final product.
Making an SVG editor is a huge feat and requires a lot of effort an people working on it. Given that Inkscape already exists there's very little motivation for anyone to create a new tool from scratch, especially such a complex one. Note that the only feature complete editor for SVGs is still a text editor because the spec allows way too much features, some of which are almost never used. Making an SVG editor is as complicated as creating a game engine _and_ a scene/level editor - all for a single format (which is crazy). Not sure how vello stands with feature completeness, but I think there's not a single 2d graphics library that can _correctly_ render all SVGs.
Don't tokio's file/net handles require to be run exclusively on the tokio runtime? If you have a Tokio::net TcpStream and run it on a home brew executor, wont it not work? I think it throws an error when it can't detect the tokio runtime. Is this where the mocks come in?
Do you think this could make microservices or large monolithic applications like spring boot dose. Or do yo thin this would replace spring boot or .NET in future and rewrite applications in Pavex ?
Great talk! we need more rust content from Alice. I was looking into Microsoft Orleans (mainly for the Actor aspect) and was looking for equivalent things in rust. Looks like it's tons more fun to just roll it yourself with tokio.
Actually enjoyed this talk immensely. You spoke extremely clearly and I took notes. I've used the tuple trait in a project before, and I'll definitely be using it more, it's super powerful at avoiding the Vec Box dyn's
In the javascript framework world we are seeing a move towards signals. Like in solidjs, leptos, or a library for signals only like reactively (there is a great blog post on this one explaining the full tree for propagting state to do the least amount of work). Obviously a vdom or tree like UI can be much faster in something like rust that is much more efficient and easier to parallelize than something like javascript. In react the version of rebuild is render (which isn't actually rendering) and runs via the framework. I have always been curious about the signal architecture inside a UI library outside of the DOM. Very interesting talk. I still greatly enjoy functional programming and programming languages like haskell, so I still like the idea of a more functional UI library and am interested to see where this goes. Especially combined with more of a data oriented design as seen in bevy ECS and other ECS's. Thanks! Also I greatly appreciate your work on wgpu!!
