Recorded live on twitch, GET IN / theprimeagen Original: joshuamo876.bearblog.dev/can-... MY MAIN YT CHANNEL: Has well edited engineering videos / theprimeagen Discord / discord
For those who don't know... "steelmanning" is when you address the strongest interpretation of your opponent's argument; that is, the interpretation that is most favorable for your opponent's position. Steelmanning does not mean you're defending their position. Steelmanning is the opposite of a straw-man argument, wherein you attack a position your opponent doesn't actually support. In politics, straw-man arguments are the norm, and steelmanning is rare.
@@phudlow No it won't, because people as always most of the time want to win the argument even when they know they aren't right. "Should" will never properly apply to human behavior.
Pointing out that Yew is slow actually helped me wrap my head around these things. React and Yew are slow not NECESSARILY because of their respective languages, but has a lot more to do with their architecture. Virtual DOMS do be expensive
Not entirely true. Dioxus is fast yet uses (a very well optimized) VDOM with (even stricter than react) hooks. But several of the optimizations it makes require a static compiler that does more work than transforming JSX to nested createelement calls, its VDOM nodes are a shallow tree of static templates that are basically just the state tree instead of the DOM tree.
Yes, Leptos and Dioxus also uses Sledgehammer that provides a ton of optimizations around string decoding, etc. which are some of the slowest parts of JSWASM communication.
I would appreciate to see your tech choices (backend, frontend, databases, devops, etc) for different situations like: what to pick for a MVP, or a small personal project, or a CPU intensive worker, or an IO intensive API, etc
10:00 These are called "Magical handler functions" and are also used by Axum and Bevy. The technique is done by taking advantage of Rust traits by implementing a trait for Fn with an arbitrary number of arguments, through generics (generated by macros, usually). They are nice but also comes with some caveats: Error handling (what happens if an extractor fails? e.g. de/serialization), performance with regards to re-computing extractors (as they are independent and cannot share "work already done" between each other) and that the order of how you define extractors in your function arguments can have different performance characteristics (yes, really).
Guys help I watched some rust programming language videos and now youtube thinks Im a Rust gamer and only recommends me rust gameplay (sorry rust foundation)
That thing with the type of the srgs changing what you get is also how Be y, the game engine let's you access different things in the world. Like you can add a "system" that's a function that accepts an arg of type `Query` and now that arg is an iterator over the Players that are Mages. And you can have an infinite number of them for all kinds of different things. It's amazing to work withm
Just a heads up that Dioxus does not use signals (it follows VDOM + hooks approach) but is still fast. But its VDOM implementation is much, much better than React/Vue/Preacts approach and the VDOM nodes are flattened templates allocated in a bump allocated arena instead of mapping 1:1 to the DOM.
I like this article too. Seems a little strange yet to me this mix of Rust with "HTML", remember a lot of old freaking PHP sites. The fact of not using try/catch is awesome, help a lot in logic because many of times we use try/catch of part of our business logic and this is terrible!! Thanks Prime, cheers my brother!
I don't think it'll be happening, purely because of one reason. No one is hiring for this specifically, unless you're the 0.1% highly specialized example of a company
yeah, there is definitely a slow shift happening, it was just a few jobs, now its a bit easier to find them. my guess is within 1 year we will start seeing more regular rust jobs.
rust's excellence is its own pitfall. its a near pefect language but comea at a very high price of learning and frustration and most people will not stick with it, especially when you already have a full time job and family and just wanna get your work done and be done with it. this is why go was a lot more successful in about the same time frame that rust had. it offered a much simpler language with GC to help make code even simpler while giving pretty good performance. sure the gc leaves some performance on the table and you might get some unexpected errors here or there... but in the time someone is learning rust, someone else write a whole bakcend api with go and works pretty good. we cant compare go to rust in this case, we should compare go to javascript and in every case it's a success
Hi, personally I have not yet explored web and WASM development with Rust (I am not primarily specialized in the web in general), but about what you said at 19:10 I have something to notice: Rust is not just different from JS in this perspective, but also from C and C++ in that exact same kind of way: Not noticing your bugs, giving you a false impression of simplicity. And this is actually kind of surprising, since JS versus C and C++ are generally speaking 2 very different kinds of technology, which both bug and crash in different ways (JS type coercions resulting in unexpected outputs, C and C++ bugs with memory and pointers resulting in UB and crashes, segfaults). So fun fact is that from both the side of JS as well as C and C++ you hear people often come up with that fallacy that development in Rust takes more time, while the opposite is true.
I should do my personal portfolio page in rust. Would be a good excuse to finally learn it, plus it'd be extra funny because I've somehow become a React frontend dev (fml).
Compile times, no hmr, no code splitting, big bundles, utf-16 conversions, ... For zero to no performance benefit. Idk man. I think it's cool what they r doing, but the big break s not gonna be for anytime soon imo.
Thats what rust shines at. Programming a Rust application means the chance it works properly and without bugs has increased and therefore the time for a solid product shipping has declined. Even though it takes more time to write a Rust application where the compiler yells against you all the time.
I like most takes in the video, I don't agree with the take on TS + Zod though. In rust you will also need a DTO validation library for more than just checking that the type is what you expect. Think of things like min / max / length / regex / comparing two fields etc. This is why Zod and libraries like it for other languages (including rust) are useful, they provide a declarative way to validate data coming into your system that you don't control. If it was just for validating the runtime types it would still be useful but extremely meh.
fair enough field length validation and other non specific type checking is very nice facet of zod but i still stick by deserialization is validation is one of my favorite aspects of rust.
Hey Prime. First of all: Wow, thank you for reacting! I didn't even realise this had gotten so much attention until someone in a discord I'm in actually linked me to this video (and a clip of your initial reaction on-stream). I definitely agree the initial picture was probably not ideal and putting the performance benchmarks first probably ruined the first impressions of the article (as well as maximum clickbait title), but I'm glad that I could get some of your thoughts from reacting to this!
I code in JS because the I need libraries for Azure and the ecosystem is insanely good. I also swap between OSs on the regular and node/JS handles that very well. I nice bonus is anything algo heavy is 2-4x slower than C, which I can live with.
Dioxus is more of a "React in Rust" than Yew i think (that is kind of the purpose of dioxus) but dioxus VDom has a better architecture than Yews, i belief. Returning `impl WhatEver` is also not a trait object its an existential type, you can only return one type out of the function. Trait objects are the ones with "dyn" which are implemented using vtables and dynamic dispatch.
I have had the inverse problem for the longest time: I was nevere importing any library, always coding every function by myself while at uni Until my professors told me "Don't re-invent the wheel" for the 10th time But it made me an overall better programming and I never realised it, I always thought I was just inefficient and ignorant of all these magic libraries that do stuff for you
I am not going to use rust on the frontend anytime soon ( solid js is awesome btw ) but thinking of switching from a mess of backend services in deno and Golang into rust. But in terms of development time and performance go is good enough. Do you think I should do it. The software is serving a small audience and performance is not my concern at the moment.
I doubt the value proposition of a switch simply for the sake of using rust on the backend would be worth it, but if it's for learning's sake then it might be worth indulging
Go for backend is great. My team is currently in a migration to Go for our backend services. I find it very enjoyable to write. Personally I think it's much more fun to write than Java or C#.
@@stugeh people praise Rust for it's great documentation. Honestly, if this is the best that Rust can offer, I'm worried about the people that think Rust will beat any language LMAO
@@okie9025 i think the docs for the language itself are incredible but the eco system hasnt reached the point of maturity yet where there are well established frameworks around with a book's worth of introductory documentation like there is if you're trying to pick up vue or something.
also that you need the Visual Studio Build Tools for the rust compiler if you want to code on windows. Which is a must for me... Interestingly Go does not have this issue.
@@stugeh Agreed, the Rust docs are great. Given how good the support for documentation is in the first party toolchain, there's a really good chance we'll see fantastic docs across the ecosystem as it matures.
Rust is amazing for TUI and other systems level dev, but Elixir is by far my favorite for BE and other comms dev - there’s a good reason Whatsapp chose the Erlang/OTP platform
@@RedStone576 Yes exactly, and they still use Elixir but leverage Rust to build very specific "plugins" (so to speak) into the Erlang/OTP platform. You get the best of both worlds.
I know you are a rust guy, but I have been learning C++ for the past 2 months, and I'm really surprised by how quickly I'm picking it up. I already made a rest api that could serve content, authenticate, and authorize with a database all in almost one month only. It all depends on how much you know the stack+language.
@@ThePrimeTimeagen I think DX usually boils down to compile times and the errors you get from crashes and the compiler, and how easy it is to refactor the code you've written. Familiarity helps equally across all languages, so it factors itself out I think.
It's more complicated than that. It's more a case of how big your project is. JS is extremely fast to create small projects. When the project gets larger though, JS runs into a lot of problems. It's the reason typescript was invented because JS at mid to large scale is a nightmare. And while the initial write speed of JS/TS is always going to beat Rust, keep in mind that after you write it, you'll probably be debugging it. And Rust code, while taking much longer to write and produce a working executable, is also far more bug free.
@@taragnor I agree 100% but it does make it really hard to know what to use and when. Most companies are simply not willing to build at 10% speed just to have less bugs. Its sad but true.
@@boot-strapper Yeah, eventually Rust does "catch up" in terms of design speed, but the initial speed to put out a semi-functional program is much slower with Rust. Rust gains its advantage the more complicated things become, because that's more errors the borrow checker and compiler can spot for you. The problem is that projects typically start small, so they often favor languages early on that are good for small projects. You won't see reap the benefits of Rust until years or probably decades into your program's life.
@@taragnor yep. And in a world where companies want quick profits, and managers need projects completed fast so they can get promoted it makes it very hard to actually use rust. It makes me sad.
Elixir is production ready today different from GO that u need a lot to have the same quality and BEAM have fantastic ecosystem battle system for year in the server area, not a system language trying to do server apps.
The order of importance is: 1. A working app (no bugs) 2. Developer experience 3. User satisfaction 4. Performance Rust violates this by sacrificing developer experience for user satisfaction and performance, which are the 2 least important factors.
@@okie9025 "sacrificing developer experience" i doubt it hurts developer experience any more than a language like c++ if anything, it might have a better experience compared to that, especially in the long run
I just dont get why SQL support would be of any relevance for a clientside application. I think stuff like component libraries, GQL clients etc. wohld have been of a lot higher interest. Am I forgetting something?
Totally confused by what you mean when you say validation "doesn't exist in Rust." It's not like serde isn't parsing and validating at the same time. Whether you're using JSON.parse and then throwing the result into Zod, or rolling your own solution to do both with slightly greater efficiency, you're doing the same thing. If you're using Zod for anything other than ingesting external input, you're almost definitely doing something wrong.
I prefer seed-rs, closest one to elm-lang, using it on production, it is basically stale framework and that's amazing, much like elm-lang, it is already complete.
@@basilfeitknecht6430 I'm using it for an admin dashboard which has a LOT of state and configs for an ecommerce system for B2B, I probably woudn't use it for B2C because that requires a lot more polishing on the asthetics, for for B2B where you don't need animations for example, and standards UIs is enough it is perfect especially paired with a backend in rust, the structs are shared, and since it is using rust + elm architecture it is bug free and very easy to reason about especialy regarding state changes.
unfortunately JS is a plague that will be haunting us for decades ahead. Rust might gain more traction in 2023, but I highly doubt it's going to be the norm this year. The number of JS work globally right now is the reason this is going to be a slow transition, mainly because Rust is a breakthrough for the developers, not the consumer.
There isn't going to be a transition in the first place. People have been trying to replace JS for decades, but the JS community and toolchain is simply too advanced to be replaced.
I was stupid enough to not realise that the speed of writing software is directly proporsional with you familiarity with the programming language... All this talk about "Fast Developer Experience" => "Faster Programming" was bull**** all along! It's Rather "More Familiarity With Language" => "Faster Programming" Thank you for enlightening me.
I use go webassembly for some really performant read/write processes for compute done client side. If I didn't have an easy performant serialization method for talking to the web services it would have sucked and been basically impossible. So ya I have 4 web workers using wasm and I throw the map tiles into those workers on the client and it works great (10x better for bandwidth/compute), and it wouldn't have been possible without wasm. However I would never do any DOM shit with wasm lol. I think it's a performance when you need it thing, like figma I think did the UI in wasm / webgl.
From a purely practical perspective, I don't really understand how rust is so much better than typescript from an error handling point of view. Some yes definitely, but disallow allow nulls for example and you'll see all the potential errors. Yes it's true javascript does have a little loosey goosey personality with truthies and falsies, but that can easily be overcome with a habit of doing triple equals. It's hard for me to think of how you could possibly get an error that way with strict typescript, unless you're relying on third party apis that might contain errors. But the same can be said in some way about hitting APIs with rust. How do you know the data you're getting back fits the type unless you validate it? You can do the same in TS essentially. Theoretically nothing can go wrong. I think what happens is people maybe don't have the strictest typescript settings on generally, that's why they run into errors. I definitely think there is a place for rust, but I don't see it in a web framework. It's true what you say about js/ts/node being a nightmare, I totally agree. But nowadays, for example, Vite+SolidTS is a fantastic combo. You kind of skimmed over the fact that it's still faster than Leptos, and has a much smaller size, and Vite fantastically breezes over the node/js/ts nightmare. I do think rust is really cool, but more for programming OS drivers. I don't see it succeeding in the web world taking over javascript except for heavy computational tasks. I also think a lot of the benefits of WASM (it seems to me not many people talk about this) comes from unblocking the main thread, which can be accomplished with a web worker. Unless you're doing *heavy* computation, I don't really think WASM/rust adds much benefit. This is my opinion right now and I reserve my right to change my mind later.
"This is my opinion right now and I reserve my right to change my mind later." Your ignorance is funny. First, error handling is different from optional values. So, null's got nothing to do with this. Second, how do you know some weird function you call in typescript throws an error? You don't. Now think clearly about what that entails. In Rust, errors are a part of the type system, and you have to handle it explicitly. When you call some weird function, you know what errors it could throw, and you have to explicitly handle them. This means, even if the error involves runtime data, as in you can't know if it will error at compile time, you still know if it COULD error, and you HAVE TO handle it. This allows you to build fault-tolerant systems, that you can be rest-assured with that you've handled all error pathways in Rust. You can't do that in typescript. You can't have this guarantee in typescript. Leptos is a bit slower than SolidJS (while still so much faster than React), only because CURRENTLY, there's overhead to manipulating the DOM from wasm. Those benchmarks only test DOM manipulation. Is that all what your webapp does? No, that's not what happens for majority of webapps. For everything else, Rust compiled to WASM is miles faster. This means for any non-trivial webapp, a website in Rust will end up faster than even Vanilla JS, let alone SolidJS. As for size, WASM loads faster than JS, so you have to keep that in mind too. But yes, currently WASM payloads are heavier, but not by much.
@@balen7555 I want to believe, but I just don't think that's the whole picture. I would obviously agree that rust has more safety-first features, as you explained. But I think the hate on typescript is exaggerated polarisation. A lot of what you mentioned too in terms of speed also didn't address what I wrote above about simply using a web worker (this also saves you for a gluing nightmare, and keeping types, etc). I don't know what kind of web apps you make, but the kinds I make actually do a lot of DOM manipulation. It's really complex to co-ordinate measurements and DOM manipulations in such a way that avoid forced reflows too, which I'm not sure how Leptos would handle this, or how WASM would handle that even if the DOM-WASM relationship was optimised. I do a lot of UX animations (for example re-adjusting a side panel and having the items re-arrange themselves in a way that can't be done with CSS currently). I'll give you an example of what I'm talking about: In one of my apps, there is a part where a page of results are shown. The results appear in a boxes, each box has a paragraph. But there is only one sentence focussed in that paragraph. So the boundary (top, bottom) of that sentence needs to be measured, then the box needs to be "cut" in such a way that the top of the box is a little higher than the top of the focussed sentence and the bottom a bit below the bottom of the focussed sentenced, essentially 'focussing' the box on the sentence. The part that sucks the juice is forced reflows. For example, if I put the measuring and cutting logic inside each block as it is instantiated, then when the next block is rendered, the measurement will force a reflow of the whole page in order to obtain proper measurements because there has been a flagged change in from the previous boxes cutting, which affects the position of the current box. Very computationally intensive. And when you have 20 results on a page, it has to do it 20 reflows. I'm not sure if you're familiar with forced reflows. The general idea to solve it is to do all your measuring at one time, and all your cutting at another time - if you can. So what I did is I made a script that "registers" the boxes as ready-to-be-measured and ready-to-be-cut as soon as their layouts are calculated (but not painted). All the measuring happens at once, then all the cutting happens at once, orchestrated by the container of all the boxes. All this I can do within one frame, before the box is even rendered to the screen. That why there is no "flash" of a full box before it's sliced to its proper size. This is because the painting will hold because of the tightly-nit relationship between the rendering pipeline and javascript thread. If I was using Leptos, even assuming we're in the future and there's a good DOM-WASM interface, I would imagine that the main thread would not know to hold off on the repainting in the situation like the above. Because it's multi-threaded, even before the first measurement, the rendering pipeline would draw the boxes. You would have an influx of measurements at seemingly random times and then cutting at seemingly random times (from the perspective of the rendering pipeline interfacing with a separate thread - WASM). So even if I applied to the same concept as above, you might see "flashes" of drawing. All this to say I can't imagine a multi-threaded web app being tightly interconnected with the rendering pipeline of a browser, which is actually a big deal when it comes to more advanced web apps. This is for the same reason that things for example like, requestAnimationFrame, I don't think would play well in parallel. This problem would affect both a web worker and WASM. But yes I would agree that for an app that isn't really focussed on UX from a DOM perspective like mine above, and more focussed on security that you really don't want bugs or crashes (e.g., a bank app), rust and WASM would probably be a really good option. Especially when the ecosystem gets better. I thought this idea of Rust/WASM was really cool and wanted to implement it in an app I was working on, actually. I get excited about these technologies. Unfortunately I couldn't find a situation where it didn't cause more problems than it solved...
@@PeterBernardin You raise good points. But, regarding this statement " I would imagine that the main thread would not know to hold off on the repainting in the situation like the above. Because it's multi-threaded ...", multi-threading is opt-in. You don't magically get multi-threading in Rust. And multi-threading on WASM for the web will use web workers (currently). But, yes, your WASM code will I assume run on a different thread than the main JS thread. Currently, that doesn't matter for your example, because all DOM operations run on the the main JS thread. The downsides to using Rust for the frontend currently IMO are: - 'difficulty'. Rust forces you to explicitly handle a lot of things, memory, errors, and even asynchronicity relatively speaking. For a lot of code, that's something you don't want to think of. - immaturity Otherwise, I think in principle it should serve better than JS/TS. As for the hate on TS, I am sure everyone loves TS; it's what makes JS development bearable. Regardless, in the end, it's still a hack built on top of JS; so even though the type system is great, it's not sound at all. There is no true notion of types.
I tried leptos for a little bit and didn't like it. Compiles took several seconds, views use fake html with weird rules/restrictions and I spent more time writing types than actual logic. Also when I tried to make an API call I got an unreadable wasm runtime error with no source map. Is it just me or is this stuff just not ready for real world use yet?
i think we are "on the verge" but not there. i am somewhere in both camps. i recognize wasm has some pretty nasty error handling i also recognize its easier for me to create a long running service in rust :)
Hey. I want to write a simple blog from scratch. I would like to maintain only one service, so the project started with Sveltekit. But I really want to try this in Rust (because I hate typescript). Do you have any libs or framework ideas I can use for this?
Rust, Javascript.... "these two sides have nothing in common"? Hmm... I love Rust, I also love Javascript (No not Typescript). They are my current top two languages after many years of using many other languages including C, C++, Pascal, Ada, PL/M, Coral, Lucol, assembler and more. Am I weird? I love Rust for its priority on correctness, all that type checking, lifetime checking, disallowing uninitialized data and null/stale pointers etc, etc. I love JS for its dynamic typing, it's instant response when hacking (no compilation) and general freedom. I love them both because they are polar opposites. Seems I have nothing in common with myself! Am I weird?
What is that about:" service that will always work ? all errors will be handled". ... that is a pipe dream. Not all errors are recoverable, and if you ccan not ignore it up-to certain checkpoint, u are fkd.
of course, if you run out of memory (oom) there is no recovery, but you can still handle it. all errors are _handled_ whether you ignore them or not, in JS you don't know what errors do what or when and are often handled some distant point from where they were created thus making sensible recovery virtually impossible.
@@ThePrimeTimeagen I had a bad experience with Hibernate in Java, when in older version all methods threw checked exceptions. That was HELL. It may not be applicable to what you are saying in the vide, and how it is handled in Rust. In my 25 years working with JavaScript I have not had problems with catching errors after IE was killed. Even then it was not that big of an issue.
I keep wondering why which language would be good for backend if performance is your concern I'm contemplating between Node, go or rust I hear rust is pretty cool in terms of performance but I can't make a case for it with the steeper learning curve I mean imagine I was building a server that was handling < 1 million crud operation wouldn't node or go still suffice In terms of performance would it matter much if you use rust maybe you have a server with low specs would rust use your resources more efficient than node or go Or for the use case of < 1 million users it's just overkill
@@ThePrimeTimeagen Thanks for the reply Although I'm not totally sure what is meant by fastest like in what terms If I have a server serving files would rust and go outperform node ? In what way is it like if it takes node 300ms to serve files it'll take go like 150ms and rust 60ms is that how we know which is fast I hear Netflix uses node from a course I took a couple years back from ZTM the person teaching the course said so since node is like really optimized at doing these tasks (serving files efficiently) If the statement is true and Netflix are using it to serve video doesn't it mean for any startup node should be good enough even if it's though of as being slow
While Rust's performance benefits are impressive, its steep learning curve may hinder its adoption compared to JavaScript/TypeScript. For most web development tasks, availability of libraries and ease of development are prioritized over raw performance. Rust's strengths really shine in heavy real-time calculations, such as simulation projects, but for general applications, JavaScript will likely remain the more popular choice. However, as Rust's ecosystem continues to mature, it may become a more viable option for a wider range of web development tasks.
Ah thats because companies want webdevelopment to be easy so they can outsource it to some indian sweatshops. I understand. The best is offcoarse having the best of both worlds having performance and ease of use.
@@blackdereker4023 It's plagiarism. You're pretending to have written it and it's supposed to be a personal expression that came out of a human. To do otherwise is to be a fraud in an area that is most tied to your person.
@@okie9025 What would you use instead? If your application is CPU bound, it seems like Golang is a very good option, or if you want to really save on resources at scale. But for my purposes, I probably wouldn't reach for Golang.
@@balen7555 That "less simple" downside is a big one. Most projects are bound by development time, and Golang has a much smaller dev cycle and learning curve than Rust. But tbh, I would reach for Node/Deno for most projects, unless the application is *actually* CPU-bound.
God, I hope so. Sometimes I wonder if JS and Typescript were written specifically to cause as much suffering as possible. I wouldn't bet on it, though.
Rust has the potential to completely dominate if Python AI/ML stuff can be rewritten in Rust (or those Python libs which have C/C++ bindings ported to Rust should probably be sufficient). I am also really tired of Typescript and how slow it is when it comes to type checking and all the warts related to error handling. I am keeping an eye on Zig as well (though it is currently lacking the ecosystem that Rust has).
Not sure if ML/AI guys will ever consider switching, And most of the time if there needs to be performance gains, python AI/ML staff is re-written in C++ , so mostly this is where it might happen.
@@mishikookropiridze yeah python is really good for bashing out a model really quick. Most of the time you dont know if the model will work fully so why waste more time building in rust.
There is no 'silver bullet' or one language to rule them all. All of them have scopes of applicability beyond that they become increasingly burdensome to use (or not possible at all). Rust is a systems programming language, it fits were C or C++ may fit, ML modules can be implemented in it. Python is, however, good for prototyping, glue-like language that can be used interactively (hence jupyter) and that's the main reason it got popular in ML: when developing a model, one wants to focus on model, ease of visualization, not some low-level details and since the basic building blocks are implemented in C++/utilize vector instructions/GPUs, Python's ease of tinkering outweighs its poor generic performance since almost no number-crunching takes place in the Python part. Even when it starts to bite, there are ways around it (there are libraries allowing various strategies of JITting performance critical Python code: pypy, numba, pyjion, ...).
If Rust doesn't beat JavaScript then perhaps another language will rise up one day. The development community can do better and create something else far superior. Focus on speed and simplicity with a small footprint.
Speed is the last thing that new languages should focus on. If you really need speed, you should be ready to drop down to assembly if needed. Switching to a new language is not worth it. In fact, instead of making new languages, why not improve JS?
@@NathanHedglin 🤣 where are you getting those numbers ? A good chunk of server OS is still dominated by windows and that's more than 50% globally, Android uses modified Linux kernel BTW, it's not an official distribution of Linux. I can post links but RU-vid will delete my comment if I do, go research the market share OS.
@@noahg2 Windows isn't popular on servers, even M$ uses Linux on their cloud service (Azure). Web literally runs on Linux, and 500 most powerful supercomputers run Linux. No one uses Windows on a real server.
I dont think so. As much as everyone would love and think they would love it. Thats not how a majority of companies work. Specially when you're dealing with clients who change entire features over night and expect fast development.
Coming back to this after 9 months, I can say... No, rust is not new JS! HTMX manage to take a lot of wasm interested developers ( like full stack or backend ) who do not want to code in this insane language.
You said something that triggered me - signals. It's why I hate EVERYTHING react-like. Not because signals are bad, but because .. every. single. framework. that implements them, does it in a wonky, backwards way, that either impacts development speed, or runtime speed -- to a great degree. I feel weird saying this, but Objective-C had a better signals implementation than RxSwift's, and the Swift wrapper around it suffers for being very poorly documented. If that weren't true, no one would use RxSwift; we'd implement bind in an extension and be done with it.
@@ThePrimeTimeagen I have looked at solid, I just haven't used it for anything as of yet. I keep hearing the same thing -- it's better than many other implementations, despite the shortcomings of JS. I suppose this means I should give it a fair shake.