Why is the JavaScript ecosystem switching to Rust? 

Wait you are not using SQLX, which tests your SQL statements at compile time?

@@voidwalker7774 no, i'm using tokio-postgres and deadpool-postgres packages.

@@voidwalker7774, is this better than what he said he's using [tokio-postgres and deadpool-postgres]? Or is it only better if you're using tokio, because then they already _match_ ? I mean, at least from a *DB System* PoV, Postgres SQL > MySQL🤔 Thanks.

@@theintjengineer SQLX, gives pooling and a unified frontend for MariaDB, Postgres and SQLite. You write Raw SQL. And you have the option to check your SQL at compiletime against the DB you selected. Just look at the crate :)

​@himanshusharma6713 firstly, i don't use rust for small scale projects unless i don't need best performance, for basic things node.js has good performance. I choose rust because i do some cpu and memory intensive things. Second, when your code compiles that means your code is debugged, that means you don't need debugging. Updating could be hard but everything comes with costs. Rust is relatively new language and most of the tools are not hit to the 1.0, even most of my dependencies are like that, i still use it because i trust the maturity of the ecosystem, but most of the companies not. Because of that companies don't want to take that risk. It was also like that for C++, in 2000's still most of the cpu and memory intensive things was done with C, because C++ don't evaluated as mature enough to write that kinda things, so also rust faces that problem. And for other languages that you wrote i could say that things: C# - C# is an outdated language by most of the ways. Even most of the C# developers don't use newest .net and c# versions, and it's only slightly faster than modern php(even .net fanatics don't admit it), and far more memory consuming. It was semi successfull substituon of java in it's prime times but it's completely unsuccessfull in this time. But .net somehow achieve to be de facto official computer science education language, so every computer or software science student learning it, because of that it's achieved to live for 10 years. And because of that they become very comfortable that language they don't try new language for serious things. Go - Go is very fast and less memory consuming and also easy to write language. If i wouldn't decide to write my whole system with rust i definitely choose go with no doubt. Although i still could be able to deploy go apps, rust's "if its compiles it will work!" rule seduces and encourages me to do that choice, also go has more latency than rust, which in high traffic circumstances makes it significantly slower than rust. Mern Stack - The actual most hyped thing is react i suppose. It has most silly, most idiotish rules, one of them is: "you can not call a hook conditionally". This is most dumb thing, because in programming doing something conditionally is trivial. Because of that state changing and page changing without sending new http request is charming people. If they don't need good performance or they don't care about performance and they started coding by front-end development, people choose the go with that. And for your last opinions: I hate C# most, because the slowest and high memory consuming softwares which i used built with it and most of the slowness of our internet is because of firstly php, later c#. Also it's a product of windows, which is the probably most dangerous and harmful company in whole software world, it's always a reason of avoidance for me if a software built by microsoft, because of that i also hate typescript. I could understand why you're hate rust, because it's synthax is very hard to get familiar but with the help of ai you could write and debug rust codes easy if you're not a newbie developer. For me, Javascript, Go And Rust is ultimate stack for everything and if there is rust i don't think i use go for anything.

Can you advise what I need to know to also understand that I need to write my compiler for Vue

@himanshusharma6713 Rust is harder than Go. You can get results in Go from 0 to end of the week. That's why companies adopted it so quickly.

@himanshusharma6713 Company immediately rushed to PHP, Ruby, OCaml, Java and C# back in the early days. Companies won't bother to migrate Legacy software either. Companies are stupid.

Rust is what cpp wants to be not just typescript 😉

Now use it on a project where 2500+ devs are using it. Rust is what hobbyists WISHES web development is like and will always be an everchanging "toy". Typescript solves REAL problems NOW.

@@ZephrymWOW It is (in my opinion) unfathomable to think that 2500+ devs could manage type-consistency on a project in a language that is not strongly typed (meaning a first-class type system, with no Any-types) In my experience, as a project grows, (correct) types become increasingly more important.

Glad you enjoyed it!

and just like php extensions are written in C

Just like markdown is written in html

That depends on the library. "Python" libs can also be written in C or Rust.

@@MrRaitiz There's "ext-php-rs", which lets you build PHP extensions in Rust.

@@Gramini Yes. Can also be written in assembly.

got bored at 7m eh?

same here i didnt expect i would like rust untill i tried it

That is true, and i take screenshoot at that part

if by pleasant you mean simplicity then you are wasting your time looking into rust.

Not stable enough in what sense?

Not my experience, it's good for completion but makes tons of subtle mistakes otherwise in a Rust context

​@@workflowinmind depends on the AI, copilot works amazing especially with workspace access while chatgpt just barely scrapes by I literally typed "i" once and copilot made nearly a perfect generation of the if statement i wanted and only thing i needed to change was a integer it used.

It was 👀

Glad you found it useful! You can embed Rust in the browser or in node. In the browser this is going to be by using wasm, which can be interacted with directly by javascript, and in node this can be either through the native extensions (napi) or through wasm, both work.

@@chrisbiscardi ​ - Thanks for the quick response. When I was asking about embedding in the browser I was asking specifically about native since you made it clear the distinction between native and Wasm, and it was clear that generating Wasm was a strong feature of Rust, which obviously works in the browser. So for clarity on this point my takeaway is that “No, you cannot embed Rust natively in the browser, but you can embed it natively on the server with Node” which I post in case someone else has the same question in the future.

Keep in mind though that such constant has to be constant at compile time. You cannot ask for user input and store than in a const or something.

This is true, however the const keyword is not a variable declaration. Its important to know that const refers to creating an item that is evaluated at compile time, and its usage in the compiler is such that the computer value will be inlined wherever it is used. Its like a compile-time find-and-replace for the name of the const using the computed value. Similarly the static keyword exists which is closer to a variable, but IMO mentioning either of these isn't really what people think of when they think of every day use variables. Rust heavily discourages the use of global state and accessing static mut items requires unsafe Rust which I consider out of scope for this introductory level video.

you know you can import the libs from c++

Can you explain how it’s a poor language from software engineering perspective?

Go doesn’t even have the most common math operators for integers

@@ITSecNEO ​ Hi, I hadn't replied because I actually have a life. Today, the first of January, I've got some time to procrastinate, so let me give you an answer. First of all, programming languages aren't a religion. They are just tools, like a hammer. Falling in love with a programming language is like falling in love with a hammer. Now, my comment was a bit taken out of context. I am not saying that Rust is wrong. I am just stating a fact: it lacks the overwhelming amount of libraries that you would find in C and C++ ecosystems, and I know that some Rust lovers might struggle to admit that fact. I am also aware that Rust can somehow import 'extern' C/C++ code. Actually, there is nothing innovative with that approach. Almost every programming language that I know can do the same thing and probably in better ways. Java with the Java Native Interface (JNI), Python with PyBind11/Shiboken/SIP/Boost::Python, JavaScript with Node native modules, and so on. The list also includes those languages that are self-proclaimed C++ killers but have miserably failed to replace C or C++ in the same way Dart failed to replace JavaScript. The problem with Rust integrating with other languages like C++ is that the two programming languages are fundamentally incompatible. I am not a Rust expert, but just to give you an example, many GUI libraries generally rely on OOP patterns such as inheritance, which allows extending functionalities in a more streamlined way. However, Rust doesn't even support inheritance, which closes the door to many design patterns that heavily rely on that OOP feature. Yes, I know there are traits in Rust, but they are not the same, and achieving the same flexibility might be more painful. Yes, I know composition is generally better than inheritance, but that is a different conversation. In fact, I am not saying that C++ is better than Rust as a programming language. It is very likely that Rust is better in many aspects, just as Dart is better than JavaScript. However, that is a different conversation. My point is that replacing a programming language such as C and C++ by using an incompatible programming language imposes too many challenges that could make it just another failure in that respect. There is a lot of code written in C and C++ that cannot be easily replaced by an incompatible programming language, no matter how good or better it is supposed to be. The industry has infallibly proven that that approach is more likely to fail. Instead, I see other approaches more likely to succeed in replacing C++. We can see examples of this in the industry. For example, TypeScript is a very good example of how you can migrate code from JavaScript to another programming language while maintaining compatibility. You just change the extension of a file from .js to .ts, and you start seeing results right away. This is also why C++ is a very successful language in terms of adoption. Because it was compatible with C right away, you just compile a C program with a C++ compiler, and you start seeing progress in code migration. I believe more in those approaches. This means that languages such as Carbon and CPP2 might have better chances to succeed than Rust if the first production-ready version of those languages gets released. However, it has been about 12 years since we first heard of Rust, and in 2024, it is still more like a niche programming language, and honestly, it hasn't yet replaced C and C++. In any case, I will be open to migrating code to Rust if I ever see that it offers as much or more than the C and C++ ecosystems offer today. More importantly, however, I will consider migration if I can achieve transparent integration of my code without having to contend with the pitfalls associated with the 'extern-function approach'. Regarding Golang, I like that it has a lot of support for cloud services while being relatively easy to learn and use in concurrency contexts. It also provides a descent performance. However, I will not give it a chance unless I have a compelling reason to use it. In the end, it is just another tool.

bro really coding in C++ 💀

why would that matter? only twitter people care about that stuff. rust has trade-offs good and bad and that's really all that matters to people who aren't weirdos

I don't know which news you're referring to specifically but speaking generally: IMO you won't get away from having people in charge of the development of a language anywhere you end up. Whether its a BDFL or a foundation or a spec group or implementors (browsers, compilers, runtimes) or something else, there's always someone at the end of the day that can make decisions you don't agree with. Rust is a great language but it is also not the last language and its problems are not unique

and maybe that would be great actually, because procedural macros are not great last time I tried to write one.

Macros are definitely tough to write compared to everyday Rust. Luckily it seems like there was a macros working group (very) recently approved to work on this. It'll still be awhile before there's anything to show for it but it's a thing now: github.com/rust-lang/wg-macros

What do you think about the existing web frameworks? I only used actix-web for a single endpoint hello world server with custom error handler yesterday. Yes, rails is simpler, but I can't judge it just from that tiny experiment.

@@blenderpanzi I checked actix-web, rocket and looked a little bit at axum - they are very similar to each other but they're more like micro frameworks - think express for javascript or flask for python. In my opinion, rust should have something like rails or laravel - generator for project, sqlx configured out of the box, cli program to generate scaffolding, configuration in place for web templates, api + plugins for authorization. In that way you can startup your project in few seconds when currently you spend whole evening just to configure project structure and connection to database.

uniffy?

​@@climatechangedoesntbargain9140you mean uniffi ? Yes it does exist. Still I cannot say it's easy to set up a new project with it. Compare it to something like creating a project with react native or flutter or even creating native project

@@gorudonu sorry, uniffi indeed

@no1youknowz could be fine too. Indeed I intend to write transpiler to take use of Rust advanced compiler/analyzer.

It's possible to do this today with crates like Yew and Leptos. We don't need to wait for a wasm dom api, although it would be nice to have that api.

@@chrisbiscardi then why aren’t we doing it? what’s blocking?

@@monawwarabdullah7438 not sure what you mean. I'm already doing it and there's nothing blocking me from doing it.

Rust is not the cause of Prisma's effect on cold boot times. Rust boot times in serverless environments are some of the lowest I've seen for any language.

haha, unfortunately you're going to be disappointed in the next video; I'm mostly a dark mode user 😅. I gave this video as a presentation recently in-person which I find works much better with light-mode themes, which is why everything here is light-mode.

Sounds like it's time for you to pick a project to work on.

The answer is mostly social/funding IMO. You could totally build tsc and the typechecking in another language, but what typescript "is" is defined entirely by what's in the microsoft/TypeScript repo and how that code works. So *if* you pursued this project, you would take on the burden of effectively tracking every PR into that repo in addition to building a whole second implementation of the compiler and typechecker. The TS src/ directory is conservatively estimated at 300k lines of TS (I used tokei to count). This is fundamentally a lot of work to replicate in addition to there being very valid reasons to build a language's compiler in its own language so its unlikely that the microsoft/TypeScript repo switches away from TS. This is actually where I would prefer to see the effort happen as it has the most chance of success IMO. The most common approach is to not replicate the typechecking at all and instead just try to build the compiler. This is what swc does: swc.rs/docs/migrating-from-tsc That all said, there actually *are* attempts to write a TS typechecker in Rust. At least two that I know of. enzo and stc. Enzo explicitly declares that they aren't chasing 1:1 parity with TSC, while I *believe* stc is still trying to, but stc is very early in its lifecycle. Enzo is also mentioned as being part of oxc, which is the tooling vite/rolldown are going to use. * enzo: github.com/kaleidawave/ezno * stc: github.com/dudykr/stc * github.com/web-infra-dev/oxc * oxc/ezno: github.com/web-infra-dev/oxc#-ezno-type-checker

@@chrisbiscardi I get it.. But lets take esbuild - (as I understand) they are just trimming typscript out, leaving plain JS. And if you want typechecking - well - they say - check yourself.. This just feels like a hot patch, which on the surface works fast, but actually doesn't do what I would want it to do, and doesn't entirely resolve the issue. I might be wrong.

Um, I didn't go look if Vite has made any statements about it but I'd assume Vite comes from French (fast, quick) and then his pronunciation is in the ballpark.

The first thing I would say is that JavaScript is also compiled these days. Chrome, for example, has a multi-stage compiler process including an optimizing compiler for turning JavaScript into machine code (ex TurboFan: v8.dev/docs/turbofan). Yes, Rust has a strong focus on being able to achieve performance using various knobs. The focus on zero-cost abstractions helps a lot here to be able to use high-level language constructs without paying a runtime cost. But at the end of the day there is more to performance than "use X language". IMO unless you're benchmarking your use case any statement along the lines of "X is faster than Y" is mostly theoretical, and applying that at the language level is even more fraught. For example, even if Rust is faster for a given algorithm as you suggested, is the overhead expended calling it across the FFI boundary worth it?

@@chrisbiscardi I wasn't thinking about using Rust to develop web front-ends, but libraries and CLI tools, where there is no overhead to crossing the boundary. That being said, I really wish we'd get rid of JS' monopoly on the FE. If only wasm didn't seem opposed to the idea.

If you have the time and energy to learn it, its a great language to know, but without knowing what kinds of programs you write, etc I can't make any blanket suggestions.

@@chrisbiscardi well I do frontend, currently angular, but I’ve been wanting to get more into backend and I was searching for a good language, although I know it doesn’t matter that much. I’ve hear a lot about rust, and mostly hear good things, so I might just jump into it

@@goo2581 yeah, choice of language won't matter too much when just getting started building small web APIs and such, you could use JS for that too. Rust can definitely be a great backend language to add to your toolbox. Axum in particular has a wonderful set of examples that can help as you're learning: github.com/tokio-rs/axum/tree/8854e660e9ab07404e5bb8e30b92311d3848de05/examples

@@chrisbiscardi yeah, I’ll check it out, note that I’m not new to backend, I used to work with C# and I’ll start to work again, for work-related purposes, but I want to make some personal projects with something new and better

@@goo2581 oh yeah, then you'll do fine. It'll just take a bit of time to get used to the language and whatnot.

There are some. Deno is the most well known and viable one. It still uses v8 under the hood though, just like node (bun uses JavaScriptCore). Building a competing JavaScript *engine* (like v8/jsc) is something nobody is doing afaik.

Yeah I use Deno wherever I can 'cause of its toolchain (lsp, formatter, etc) since I use helix and it is just simpler and more performant. But I actually meant I would love a javascript engine, not wrappers around v8 or javascriptcore like bun.

@brielov it's a tough project so I see why it hasn't been taken on. v8 is a million lines of code iirc and at the end of all that work you still end up with a JavaScript engine, which v8 already is. Even Servo, which I consider a wildly ambitious project, uses Rust bindings to spidermonkey for the JS engine afaik.

@@brielov There's an engine called Boa, but it's still very much new and doesn't support the entire ECMA specification yet and also lacks important performance optimizations. It might be possible to build a runtime around it once it matures though