Пікірлер

• 
  @KushLemon4 күн бұрын

  Useless rambling talk with no proper context set up.

• 
  @erthiaczka20 күн бұрын

  HELL YEAH ALICE, YOU ROCK!!

• 
  @lanastasov23 күн бұрын

  Awesome app. Thank You Aram.

• 
  @restauradorcaseiro25 күн бұрын

  Have I seen it right? Brazil mention at the intro with a joke around a soap opera character? 😂😂

• 
  @user-gh4lv2ub2j25 күн бұрын

  Incompatible with libs when running in safe mode. Monstrous build times. Rust is, simply put, more political activism than computer science.

• 
  @nicolassturm8853Ай бұрын

  Thank you Aram for Zellij! I am glad that you are able to work on this project full time and with such passion.

• 
  @IleniaQuinteroАй бұрын

  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.

• 
  @vcoolАй бұрын

  The real content starts at 4:45. Everything before it is a waste of your time.

• 
  @chenkaihongАй бұрын

  i hate tmux the most, I think this is the answer, thank you aram

• 
  @FrankRehwinkel2 ай бұрын

  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.

• 
  @scosminv2 ай бұрын

  I'd rather have zig as a better C instead of Rust... C ABI Interop would be a breeze.

• 
  @NicolaiSyvertsenАй бұрын

  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.

• 
  @scosminvАй бұрын

  @@NicolaiSyvertsen the point was not adding rust in the first place. That ship has sailed :).

• 
  @nirmalyasengupta68832 ай бұрын

  Good information. Thanks. Whenever sessions are recorded for viewers on the 'Net, please ensure that that sound is **well-captured**.

• 
  @no-bias-2 ай бұрын

  Great talks! looking forward to tech talk like this especially on the chaos testing with Rust.

• 
  @umahanov13 ай бұрын

  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

• 
  @NoxyYTАй бұрын

  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.

• 
  @umahanov1Ай бұрын

  @@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

• 
  @pyyrr3 ай бұрын

  oh no. i think its better off if everyone just sticks to c personally

• 
  @patmelsen3 ай бұрын

  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?

• 
  @Babakinha3 ай бұрын

  Thats the best start for a talk I've ever seem X3

• 
  @greenspand4 ай бұрын

  Is this applied cathegory theory?

• 
  @pierreavital19174 ай бұрын

  Wait, category theory has applications!? 😁

• 
  @vcool4 ай бұрын

  It is dangerous to keep using C. Its use has to be replaced. On that note, even unsafe Rust is dangerous.

• 
  @lucianobestia4 ай бұрын

  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!

• 
  @jmarcelomb4 ай бұрын

  Loved the talk! Thank you so much!!

• 
  @WorstDeveloper4 ай бұрын

  I haven't watched the whole video yet, but what's the difference between this and frameworks like Loco, and Rocket? Why not join forces?

• 
  @duncan-dean4 ай бұрын

  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.

• 
  @Ic3q44 ай бұрын

  thank god you switched mics :D glorious indeed :P but imo getting adopted by microsoft is not like nothing ngl

• 
  @kitlith4 ай бұрын

  @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.

• 
  @pierreavital19174 ай бұрын

  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.

• 
  @furl_w4 ай бұрын

  Is it a type declaration? Or an incantation to awaken an eldritch horror? Either way I’m rolling an arcana check.

• 
  @pierreavital19174 ай бұрын

  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 :)

• 
  @triforce424 ай бұрын

  Fantastic presentation. It's inspirational :)

• 
  @mattbradbury17974 ай бұрын

  Talk into the mic and don't look back at the screen, or get a portable mic

• 
  @mskiptr3 ай бұрын

  I know this is kinda armchair engineering, but wouldn't it be much easier to use a purpose-made proof assistant like Agda or Idris?

• 
  @pierreavital19173 ай бұрын

  ​@@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 :)

• 
  @hemangandhi45964 ай бұрын

  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).

• 
  @pierreavital19174 ай бұрын

  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:)

• 
  @hemangandhi45964 ай бұрын

  @@pierreavital1917 thank you very much for the response. I should've realised that you'd just get syntactic data and need more. That makes sense.

• 
  @Onkoe4 ай бұрын

  this is wonderfully insane 🙏✨

• 
  @CGMossa4 ай бұрын

  3:02 Inner `print` should be `println`.

• 
  @HelloRust4 ай бұрын

  Keen eye. 😉

• 
  @will_i_craft55554 ай бұрын

  It's wild. I've seen so many cool projects in rust over the years and then joining the Zulip I realized like half of them were made by Raph.

• 
  @usercommon14 ай бұрын

  whaat

• 
  @flightmansam4 ай бұрын

  A musescore rewrite using this would be truely game changing.

• 
  @will_i_craft55554 ай бұрын

  Or an inkscape rewrite

• 
  @BurakBagdatli4 ай бұрын

  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.

• 
  @Caellyan4 ай бұрын

  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.

• 
  @lostname17814 ай бұрын

  This is madness! I love it.

• 
  @warvinn4 ай бұрын

  I could listen to Raph for hours, the topics are great, and I love the demonstrations

• 
  @jbca4 ай бұрын

  Raph never stops! Constantly pushing things forward. Such an asset to the communities.

• 
  @Turalcar4 ай бұрын

  Several months ago I implemented SK calculus in Rust traits and considered myself done with the subject

• 
  @thomasw.42984 ай бұрын

  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?

• 
  @ragectl4 ай бұрын

  Excellent talk

• 
  @moy20104 ай бұрын

  It's interesting to see the progress in the framework condensed in a single conference. Can't wait to test out the beta!

• 
  @AlexKen-zv8mm4 ай бұрын

  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 ?

• 
  @gzoechi4 ай бұрын

  Great insight

• 
  @zireael97975 ай бұрын

  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.

• 
  @rogueyeti7 ай бұрын

  Nice shirt!

• 
  @StyzeSoulmaker7 ай бұрын

  Very cool! I didn't know about tokio:select!, that seems very useful

• 
  @nirmalyasengupta68839 ай бұрын

  Very lucidly explained. Thank you! Where may I get some information about the _bus_ design that you have referred to?

• 
  @user-wj4mn6oe8i10 ай бұрын

  This was very insightful and clear

• 
  @aftalavera11 ай бұрын

  Having so many choices! Modern gaslighting!

• 
  @sergesolkatt Жыл бұрын

  ❤

• 
  @ariseyhun2085 Жыл бұрын

  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

• 
  @tenthlegionstudios1343 Жыл бұрын

  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!!