Coming from a React background, building frontends with Rust is immediately intimidating. Thanks so much for creating these videos to further expose these topics to novice devs like myself
thanks for the feedback! I should have mentioned this in the video but the decision between Dioxus and Leptos was more "hair splitting" than the DB decision, in that both have pretty similar capabilities and would be perfectly fine for this project. Leptos seems to be in a more mature state at the moment, but Dioxus has a really interesting long term vision of being like flutter in that it aims to support all platforms with one codebase. So choosing between the two is more like horse race betting and personal preference than matching capabilities to the requirements of the project. Axum vs actix is kind of similar, although they are more mature their difference in capabilities isn't really relevant for this particular project.
I would like to see you cover demo about Minikube, SurrealDb and TiKv. I used kubernetes and argocd to deploy it to cluster then I was able to access that app from browser. I followed the steps from docs and watched talk with Ryota how he did the same. His talk was not that long but maybe you can cover that topic as production solution. Great video!
I'm really excited about the stack and would be soo interested to see one addition: SurrealDB also is able to be embedded into Rust. People love to demo to-do apps, but in real life, if your to-do app didn't work offline it would drive you nuts. I would love to see this same stack, with the addition of an embedded Surreal instance in the front-end Dioxus, that would occasionally back up to the server side Surreal instance. This would provide a local-first, and poor connection tolerant setup. It's also something that sounds beyond my skill level to implement, so I'd love to get a head start haha.
Any terminal could be a key logger, irrespective of whether it requires you to log in. This really puts the idea behind login into perspective: www.warp.dev/blog/open-source-and-login-for-warp
8 месяцев назад
@@codetothemoon I'll never use a closed source terminal emulator. It's a security dark hole. I hope they pay you a lot for this promotion because they are certainly hell bent on locking down our terminal into a proprietary bs.
@@codetothemoon I’m off to a late start at 34 so I figured it’ll get me ahead of the curve. I’m thankful for great RUclips tutorials and chat bots. Your channel is great, thanks for all the info.
@@codetothemoon I should probably also mention I spent hours watching C tutorials, but I haven’t typed much code and can only read code and not recall much.
Thanks for pointing out, that a login is necessary. This brings me straight to the point. How can I provide my own login here by using an open source login provider like authentik or authelia for my home lab cloud? Could you make a video about the middleware and bindings needed for authentication and authorisation logic when using axum? That would be great! Thanks.
I made a video about doing this with actix-web, I suspect much of it may be relevant in an axum context as well. ruclips.net/video/S8Usi3zsLIs/видео.htmlsi=awi0Zbdl3hUJoonw
Funny you mention this, I originally had a section of the video comparing workflows to regular shell functions but cut it at the last minute. One value add of workflows is that you see the workflow inline as you are preparing to run it with argument descriptions. Because the contents of the workflow is placed in the terminal, you can also make slight modifications before running if necessary. Also, they are searchable via a fuzzy find. Regarding sharing - there is a mechanism for sharing a common pool of workflows with your team.
Not a big fan of using warp Terminal as a shell. There's enough of a problem with LLMs sucking in source code from everyone with publicly accessible code online using whatever licenses, and then selling usage of that LLM for profit. I don't want companies doing this with the entire shell. It's also mad shady because despite whatever intent or effort they might have to not transmit credentials like passwords and such, it's unavoidable if they don't know the context of the tool(s) being used that may make an input or even output a secret. My editor's contents, shell usage be a live service.
I think there's a natural tendency to assume worst case scenario when something like a terminal emulator requires you to log in. This post offers some perspective on this design decision www.warp.dev/blog/open-source-and-login-for-warp
valid points, same concern here. I try to not get blinded by comfort features, they will never outweight the security concerns for me. In the end we have to keep in mind that there is a company behind that wants to make some profit. And they invest in Ads (like here in the video) for a reason. It might be only a matter of time until something shady happens, and even if not the risk is too high for me.
Cool video. Would be interesting to create a stack based on Zig once it's matured enough. Although there are certainly projects like Bun that have already been released but I'm just talking about once Zig 1.0 releases. I'm not familiar with every project but for terminal there's Ghostty (being tested by request so no public release yet) and for graphics there's Mach.
Yeah performance seems to be a perennial concern for Surreal. They claim to have dramatically improved it in the recent 2.0 release, but I haven’t seen any concrete benchmarks
Yup. not logging into my terminal. No thx on the closed source AI terminal. I understand you have to take sponsorships tho and I appreciate your honesty
there are many that would agree with you! this post may give extra perspective on the decision to require login www.warp.dev/blog/open-source-and-login-for-warp
really enjoyed the video (and must lend my love to the Warp team, the AI is such a huge help in the terminal) - I'm new to Rust and have been leaning more toward Poem because I generally have to interface with other services and need to expose some open-api/swagger. Would you approach this topic too (automatic swagger generation based on your restful api)?
@@codetothemoon The top comment was worded a bit rude, sorry about that. The video has almost 6 minutes of just talking about warp and it felt like every chance you had to meantion it was taken. I also feel that it shouldn't be part of the tech stack it's similar to including vscode. Personally I don't agree with the terminal emulator itself and alot of their view points so I got a bit overdramatic. Other then the large sponser sections I think the merging of Dioxus, Axum, and SurrealDB will be helpful to alot of people.
I was quite interested in Dioxus until I read the following statement on the Dioxus webpage: "In the future, we plan to move to a custom web renderer-based DOM renderer with WGPU integrations (Blitz)." WebView, which is currently used, is really great, offers most of HTML 5 and CSS. I am so tiered of reinventing the wheel again and again. I doubt the custom solution will never get the same maturity and broad coverage of HTML, JS and Css.
What screen resolution do you record your videos at? I am somwewhat unsure if i should use my 2560x1440 screen resolution for videos as I fear it might be too small for others to see, appreciate some insight in regards your process.
Higher resolution doesn’t have to mean smaller - the key is to increase your font size (if code) or zoom in with your browser (if web). In this video I actually used a tool called puppeteer to take screenshots of the web pages, which is amazing because it can do so at a higher resolution than my monitor. All of my screen recordings are done in 4K
Why would storing our data in a file or folder (surreal lets you use a folder and it manages it's data in a series of files) be a bad thing? A script can run a backup however often you need and it's simple. And I missing something?
When is rust's compile time going to get better? I have a small actix API that takes 20 minutes to compile in prod mode. I love rust, but the compile times prevent me from using it in any bigger project.
Really dissappointed in you taking sponsor from and advertising Warp. Their closed-source and mandatory login ethos is outrageous and encompasses everything that's wrong with the tech scene. A terminal should never be closed-source, it's ridiculous. I'm sure you'd agree with me which is why I'm even more disappointed. Love your content. Please don't sell out 💓
thanks for your feedback! We're very fortunate to have so many great options for terminals, many of which are open source. If open source is more important to you than the features unique to Warp, then by all means use one of the open source ones. Warp's existence and my endorsement of it shouldn't be seen as a threat to that preference or the fantastic OSS community behind it. for context, I didn't just use Warp while recording this video. I'm endorsing it because I actually use it for my day to day work when nobody is looking.
@codetothemoon pretty much, but it's very similar to electron with more security features. Since on Win32 it uses Edge and on macOS/Linux it uses WebKit. Since you built a fullstack application for the web, this could've fit perfectly
@@Mempler dioxus supports web, desktop, and ios/android. the desktop and mobile is based on webview like tauri. however, dioxus is experimenting with wgpu rendering.
@@Mempler i would say it's more similar to flutter. mostly because it's an all-in-one platform, whereas react and react native are separated and even completely different dependencies. their goals seem to align more with flutter.
not sure how I feel about it yet either. they've made another major release since this video, I may have to circle back to it and see if anything has changed
I should have expanded a bit more on this. to your point, most of the Rust error messages are pretty good, but I personally find lifetime related ones hard to understand sometimes. Also some of the ones I've seen when working with Dioxus specifically were atrocious
I'ma be real with you, warp is such a shitty terminal compared to the other options we have (like alacritty or wezterm). Forcing users to create an account for a bloody terminal is really dumb. So is integrating AI into it.
I can relate to not wanting to have to have an account, but I don't understand why integrating AI into a terminal would be a bad idea. ooc, would you be willing to log in to your kitchen refrigerator if it did all of the cooking and grocery shopping for you?
To each their own. I've been using Warp over a year now and it's become my go to terminal. It's perfect for everyday use and the AI is truly a game changer even with the free tier limitations. The entire account system feels unnecessary even if it offers some benefits - but it's a minor inconvenience compared to the overall experience.
Very nice video that I can learn much about rust language but in 5 min you used lots of framework and names that I have to pause each 5 seconds and google it, you are so fast😂 5star
As a proof of concept, it's understandable, but Rust plus React feels like dealing with the worst of both worlds. Rust comes with a steep learning curve, React is overly complex with its aweful boilerplate, intricate state management, and convoluted hook system. Together, they bring none of the straightforwardness, ease and efficiency that JavaScript is widely known for. It’s like choosing to take your family across the country on a unicycle instead of a car. While it’s possible with enough training and determination, the journey is unnecessarily difficult, especially when there are much simpler and more efficient alternatives available.
I am still trying to understand why I need to login to my terminal. Nearly everything you showed can be done locally with a little bit of configuration. Tools like oh-my-ash are just straight forward.
I still don't understand why you don't just create a Symfony / Laravel app. The whole thing is 100 times easier and up to a certain point (which almost no web app will reach) fast and sufficient. The bottlenecks of webapps are not in the programming language. But yes, keep wasting all your time on all these implementations. I make money in the meantime working on my own projects on the side.
im so over AI being integrated into dev tools. If thats why you have to log into warp they are going to kill their terminal over search v2. ill just open a browser. no thanks.
@@codetothemoon It's been at least 12 years since we first heard of Rust, and despite the extensive marketing campaign it has received, it is still considered a niche programming language. Don't get me wrong, I'm not saying Rust is a bad programming language. In fact, it might have good features missed in C and C++, but its approach forces developers to either write everything from scratch or deal with the pitfalls of the 'extern-function approach' for integration with the outside world. The industry has invariably proven that this approach is a failure from day one. A very good example of this is the Dart programming language. It was originally intended to replace JavaScript, and despite being better than JavaScript in many ways, it miserably failed to do so. Similarly, Rust is unlikely to succeed in replacing C or C++. The reason is that Rust and C++ are fundamentally incompatible. The trend is clear for modern programming languages that have been successfully adopted: TypeScript interoperates with JavaScript; C++ interoperates with C, Kotlin interoperates with Java. Even Zig can transparently interoperate with C. Mojo also looks like a much more attractive alternative than Rust as it can run as fast as C, it offers memory-safe features like Rust with an easier and cleaner syntax while being compatible with Python. I see more future in replacing C/C++ with other approaches such as CPP2 or Carbon, which are projects by engineers at Microsoft and Google, respectively. These languages solve the problems with C and C++ while offering a cleaner syntax and interoperation with C/C++ code. As soon as the first production-ready version of either CPP2, Carbon, or Mojo gets released, which is about to happen soon, the future of Rust will resemble the present of the D programming language. To add more salt to the wound, Rust has already become too verbose and complex, so much so that even Rust developers are feeling frustrated with it. I know a few government agencies might be advocating for memory-safe languages, but it doesn't necessarily have to be Rust. In fact, there are memory safety languages out there with far greater adoption than Rust, such as Java, C#, Python, Swift, and Go. And if performance is also important, Rust has to compete with the already industry-established C and C++, now CPP2, Carbon, Mojo, Zig, and Go. As I said before, it is not a good time to learn Rust and reinvent the wheel in a language just for the sake of doing so. Rust didn't replace C or C++ and it never will. Just check GitHub, Stack Overflow, and other statistics. The truth is that much more code is being written in C and C++ than in Rust. It's been like that for decades. A new programming language, to succeed, needs to guarantee code reusability; otherwise, it will miserably fail.
@@codetothemoon It's been at least 12 years since we first heard of Rust, and despite the extensive marketing campaign it has received, it is still considered a niche programming language. Don't get me wrong, I'm not saying Rust is a bad programming language. In fact, it might have good features missed in C and C++, but its approach forces developers to either write everything from scratch or deal with the pitfalls of the 'extern-function approach' for integration with the outside world. The industry has invariably proven that this approach is a failure from day one. A very good example of this is the Dart programming language. It was originally intended to replace JavaScript, and despite being better than JavaScript in many ways, it miserably failed to do so. Similarly, Rust is unlikely to succeed in replacing C or C++. The reason is that Rust and C++ are fundamentally incompatible. The trend is clear for modern programming languages that have been successfully adopted: TypeScript interoperates with JavaScript; C++ interoperates with C, Kotlin interoperates with Java. Even Zig can transparently interoperate with C. Mojo also looks like a much more attractive alternative than Rust as it can run as fast as C, it offers memory-safe features like Rust with an easier and cleaner syntax while being compatible with Python. I see more future in replacing C/C++ with other approaches such as CPP2 or Carbon, which are projects by engineers at Microsoft and Google, respectively. These languages solve the problems with C and C++ while offering a cleaner syntax and interoperation with C/C++ code. As soon as the first production-ready version of either CPP2, Carbon, or Mojo gets released, which is about to happen soon, the future of Rust will resemble the present of the D programming language. To add more salt to the wound, Rust has already become too verbose and complex, so much so that even Rust developers are feeling frustrated with it. I know a few government agencies might be advocating for memory-safe languages, but it doesn't necessarily have to be Rust. In fact, there are memory safety languages out there with far greater adoption than Rust, such as Java, C#, Python, Swift, and Go. And if performance is also important, Rust has to compete with the already industry-established C and C++, now CPP2, Carbon, Mojo, Zig, and Go. As I said before, it is not a good time to learn Rust and reinvent the wheel in a language just for the sake of doing so. Rust didn't replace C or C++ and it never will. Just check GitHub, Stack Overflow, and other statistics. The truth is that much more code is being written in C and C++ than in Rust. It's been like that for decades. A new programming language, to succeed, needs to guarantee code reusability; otherwise, it will miserably fail.
@@codetothemoon tbh if I knew rust better I'd use it 💀 but yea def sveltekit. I had the misfortune of starting with js when I was just beginning to learn programming so it's my default still sorta lol
![Twenty One Pilots - “The Line” (from Arcane Season 2) [Official Music Video]](http://i.ytimg.com/vi/E2Rj2gQAyPA/mqdefault.jpg)
The code for the app we made in this video can be found here: github.com/MoonKraken/DrawsNotes
my heart sank when you said "blockchain" and then you fixed it lmao
Same here, my popcorn's dropped... xD
just trying to keep everyone guessing 🙃
I thought I learned something new! :P
Yes, we were listening!
Got me so good. This is possible, but very expensive
Coming from a React background, building frontends with Rust is immediately intimidating. Thanks so much for creating these videos to further expose these topics to novice devs like myself
it can indeed be intimidating! really glad you got some value out of them!
Awesome video Ken, as always! I think it was your video that first got me into SurrealDB, which I'm still very happy with! 😀
thanks, really happy you liked it! I continue to be impressed with Surreal as well!
Would love to see the SurrealDB TiKV set up video!
thanks for letting me know, I'll try to pencil this one into the schedule!
would love a bit more explanation why dioxus over leptos, axum over actix like you did with DB choice explanation
Cause it’s new 😂😂😂
thanks for the feedback! I should have mentioned this in the video but the decision between Dioxus and Leptos was more "hair splitting" than the DB decision, in that both have pretty similar capabilities and would be perfectly fine for this project. Leptos seems to be in a more mature state at the moment, but Dioxus has a really interesting long term vision of being like flutter in that it aims to support all platforms with one codebase. So choosing between the two is more like horse race betting and personal preference than matching capabilities to the requirements of the project. Axum vs actix is kind of similar, although they are more mature their difference in capabilities isn't really relevant for this particular project.
i use axum in production microservice(s) having used both axum is far more ergonomic for my use case (REST api to supplement the tonic gRPC side)
I would like to see you cover demo about Minikube, SurrealDb and TiKv. I used kubernetes and argocd to deploy it to cluster then I was able to access that app from browser. I followed the steps from docs and watched talk with Ryota how he did the same. His talk was not that long but maybe you can cover that topic as production solution. Great video!
thanks for the feedback, I'll add this to the list of video ideas!
Thanks for creating this video. It's nice to have such a deep overview of the tech stack and some of the potential issues.
lazy_static is outdated. Use once_cell::sync::Lazy, or std's LazyLock once it lands.
ahh thanks for pointing this out!
@@codetothemoon
Dioxus looks interesting. Can you make more videos on it. It will help noobs like me who's just starting out.
Looking good, Ken!
thank you!
I'm really excited about the stack and would be soo interested to see one addition: SurrealDB also is able to be embedded into Rust. People love to demo to-do apps, but in real life, if your to-do app didn't work offline it would drive you nuts. I would love to see this same stack, with the addition of an embedded Surreal instance in the front-end Dioxus, that would occasionally back up to the server side Surreal instance. This would provide a local-first, and poor connection tolerant setup.
It's also something that sounds beyond my skill level to implement, so I'd love to get a head start haha.
terminal with login is just officialy keylogger
Any terminal could be a key logger, irrespective of whether it requires you to log in. This really puts the idea behind login into perspective: www.warp.dev/blog/open-source-and-login-for-warp
@@codetothemoon I'll never use a closed source terminal emulator. It's a security dark hole. I hope they pay you a lot for this promotion because they are certainly hell bent on locking down our terminal into a proprietary bs.
@@codetothemoon This whole post is a cope
mega cool, I'm learning rust as my first language and going all in using something like this stack
wow, hats off to you! very brave for tackling Rust as your first language!
@@codetothemoon I’m off to a late start at 34 so I figured it’ll get me ahead of the curve. I’m thankful for great RUclips tutorials and chat bots. Your channel is great, thanks for all the info.
@@codetothemoon I should probably also mention I spent hours watching C tutorials, but I haven’t typed much code and can only read code and not recall much.
I shy away from Warp, but when you said vim motions, I'm sold.
On second thought, nah. I just added vi motions plugin for zsh. Warp is not too customizable like my current terminal emulator, alacritty.
Thanks for pointing out, that a login is necessary. This brings me straight to the point. How can I provide my own login here by using an open source login provider like authentik or authelia for my home lab cloud? Could you make a video about the middleware and bindings needed for authentication and authorisation logic when using axum? That would be great! Thanks.
I made a video about doing this with actix-web, I suspect much of it may be relevant in an axum context as well. ruclips.net/video/S8Usi3zsLIs/видео.htmlsi=awi0Zbdl3hUJoonw
Great video.
To go full rust stack shouldn't your editor also be a rust based editor like helix?😂
Hah, you’re probably right! Not using helix was a miss…
Warp workflows are just bash functions basically but with no ability to save it to code and be useful to others ?
Funny you mention this, I originally had a section of the video comparing workflows to regular shell functions but cut it at the last minute. One value add of workflows is that you see the workflow inline as you are preparing to run it with argument descriptions. Because the contents of the workflow is placed in the terminal, you can also make slight modifications before running if necessary. Also, they are searchable via a fuzzy find. Regarding sharing - there is a mechanism for sharing a common pool of workflows with your team.
Fish shell would be a better comparison, especially considering they''ve recently fully rewrote to Rust.
Love Rust
❤️ 🦀
Not a big fan of using warp Terminal as a shell. There's enough of a problem with LLMs sucking in source code from everyone with publicly accessible code online using whatever licenses, and then selling usage of that LLM for profit. I don't want companies doing this with the entire shell. It's also mad shady because despite whatever intent or effort they might have to not transmit credentials like passwords and such, it's unavoidable if they don't know the context of the tool(s) being used that may make an input or even output a secret. My editor's contents, shell usage be a live service.
I think there's a natural tendency to assume worst case scenario when something like a terminal emulator requires you to log in. This post offers some perspective on this design decision www.warp.dev/blog/open-source-and-login-for-warp
valid points, same concern here. I try to not get blinded by comfort features, they will never outweight the security concerns for me.
In the end we have to keep in mind that there is a company behind that wants to make some profit.
And they invest in Ads (like here in the video) for a reason.
It might be only a matter of time until something shady happens, and even if not the risk is too high for me.
Cool video.
Would be interesting to create a stack based on Zig once it's matured enough. Although there are certainly projects like Bun that have already been released but I'm just talking about once Zig 1.0 releases.
I'm not familiar with every project but for terminal there's Ghostty (being tested by request so no public release yet) and for graphics there's Mach.
the dryness is so great. 😆
Now we just need to figure out how to do styling using rust
hah so true!
i had high hopes for surreal but for my production rust services postgres smoked it in all my benchmarks
Yeah performance seems to be a perennial concern for Surreal. They claim to have dramatically improved it in the recent 2.0 release, but I haven’t seen any concrete benchmarks
Yup. not logging into my terminal. No thx on the closed source AI terminal. I understand you have to take sponsorships tho and I appreciate your honesty
there are many that would agree with you! this post may give extra perspective on the decision to require login www.warp.dev/blog/open-source-and-login-for-warp
@@codetothemoon btw excellent videos man, I bought my glove80 because of you and I love it. Keep it up 👍
How do i pass context from the web window to the app
Do you have the source code for this up on GitHub? If so, anyway I can get the link?
yep you can find it here! github.com/MoonKraken/DrawsNotes
really enjoyed the video (and must lend my love to the Warp team, the AI is such a huge help in the terminal) - I'm new to Rust and have been leaning more toward Poem because I generally have to interface with other services and need to expose some open-api/swagger. Would you approach this topic too (automatic swagger generation based on your restful api)?
This video feels like it has less production quality then any other video on your channel. The video seems to be purely made just too sponsor Warp.
Thanks for the feedback! What could I have done to make it better?
@@codetothemoon The top comment was worded a bit rude, sorry about that. The video has almost 6 minutes of just talking about warp and it felt like every chance you had to meantion it was taken. I also feel that it shouldn't be part of the tech stack it's similar to including vscode. Personally I don't agree with the terminal emulator itself and alot of their view points so I got a bit overdramatic. Other then the large sponser sections I think the merging of Dioxus, Axum, and SurrealDB will be helpful to alot of people.
I love the video! the multi-sponsored segments were a bit, much, I recommend making one big sponsor spot rather than scattered across the videos
Is there any service oriented architecture example for Rust?
Which DB can I use locally and install with Brew?
Surreal can. SQLite, duckdb are also your friends that can be installed with brew.
There are many, including SurrealDB. And Postgres, if you’re not doing all-Rust
I was quite interested in Dioxus until I read the following statement on the Dioxus webpage:
"In the future, we plan to move to a custom web renderer-based DOM renderer with WGPU integrations (Blitz)."
WebView, which is currently used, is really great, offers most of HTML 5 and CSS.
I am so tiered of reinventing the wheel again and again. I doubt the custom solution will never get the same maturity and broad coverage of HTML, JS and Css.
I just get lost in how to set up the project. dx new or cargo new?
you can do it either way, but dx new might get you up and running slightly faster!
When Warp supports zellij I'll give it a try
haven't tried zellij with warp yet - what issues did you run into?
@@codetothemoon Warp eats the alt key input, so zellij has no idea when I use it for my binds
It seems a lot of features of Warp don't work when running under Zellij or Tmux.
How Tailwind was included to Dioxus?
qdrant can do both semantic and keyword search, as in you should be able to store text data in it as well as vectors.
What screen resolution do you record your videos at? I am somwewhat unsure if i should use my 2560x1440 screen resolution for videos as I fear it might be too small for others to see, appreciate some insight in regards your process.
Higher resolution doesn’t have to mean smaller - the key is to increase your font size (if code) or zoom in with your browser (if web). In this video I actually used a tool called puppeteer to take screenshots of the web pages, which is amazing because it can do so at a higher resolution than my monitor. All of my screen recordings are done in 4K
Great point, thanks a lot, appreciate that really
Why would storing our data in a file or folder (surreal lets you use a folder and it manages it's data in a series of files) be a bad thing? A script can run a backup however often you need and it's simple. And I missing something?
it's probably fine for many scenarios, but if you want load balancing / sharding it's not really an option
When is rust's compile time going to get better? I have a small actix API that takes 20 minutes to compile in prod mode. I love rust, but the compile times prevent me from using it in any bigger project.
Really dissappointed in you taking sponsor from and advertising Warp. Their closed-source and mandatory login ethos is outrageous and encompasses everything that's wrong with the tech scene. A terminal should never be closed-source, it's ridiculous. I'm sure you'd agree with me which is why I'm even more disappointed.
Love your content. Please don't sell out 💓
thanks for your feedback! We're very fortunate to have so many great options for terminals, many of which are open source. If open source is more important to you than the features unique to Warp, then by all means use one of the open source ones. Warp's existence and my endorsement of it shouldn't be seen as a threat to that preference or the fantastic OSS community behind it.
for context, I didn't just use Warp while recording this video. I'm endorsing it because I actually use it for my day to day work when nobody is looking.
Why not Leptos?
check out the "build a chatbot" video I made, it happens to use Leptos
You forgot to use tauri, for the desktop experience, otherwise it wouldnt be an "all rust stack app"
Doesn’t Tauri just embed a web view?
@codetothemoon pretty much, but it's very similar to electron with more security features. Since on Win32 it uses Edge and on macOS/Linux it uses WebKit.
Since you built a fullstack application for the web, this could've fit perfectly
@@Mempler dioxus supports web, desktop, and ios/android. the desktop and mobile is based on webview like tauri. however, dioxus is experimenting with wgpu rendering.
@@crab-cake so effectively like react & react native
@@Mempler i would say it's more similar to flutter. mostly because it's an all-in-one platform, whereas react and react native are separated and even completely different dependencies. their goals seem to align more with flutter.
I firmly believe that Warp is a cancer of an idea, but other than that, a nice overview, as always.
Thanks! 🙏 and more Warp for us I guess 😎
Tbh the ORm syntax does not look very easy to deal with :/
not sure how I feel about it yet either. they've made another major release since this video, I may have to circle back to it and see if anything has changed
had me at blockchain 😂
😎
I want all Ada stack
I wish I could use warp but I don't have a mac
I believe they just released a Linux version!
Oh i did not know that thanks@@codetothemoon
Flutter in Rust when?
dioxus is alternative to flutter, react native and react
I think dioxus aims to be a Flutter alternative (though not nearly as production ready at the moment)
DRAWS stock to the moon
if only there were a way to place bets on these things!
iTerm2 and zsh doing all the same things which Warp does.
except, replace dioxus with bevy
Don't use warp and am not going to.
10:48 "you can get a lot of cryptic error messages, especially when working in Rust".
Isn't good error messages one of the selling points of Rust?
I should have expanded a bit more on this. to your point, most of the Rust error messages are pretty good, but I personally find lifetime related ones hard to understand sometimes. Also some of the ones I've seen when working with Dioxus specifically were atrocious
I'ma be real with you, warp is such a shitty terminal compared to the other options we have (like alacritty or wezterm). Forcing users to create an account for a bloody terminal is really dumb. So is integrating AI into it.
I can relate to not wanting to have to have an account, but I don't understand why integrating AI into a terminal would be a bad idea. ooc, would you be willing to log in to your kitchen refrigerator if it did all of the cooking and grocery shopping for you?
@@codetothemoon How is my fridge cooking and shopping??
To each their own. I've been using Warp over a year now and it's become my go to terminal. It's perfect for everyday use and the AI is truly a game changer even with the free tier limitations. The entire account system feels unnecessary even if it offers some benefits - but it's a minor inconvenience compared to the overall experience.
proprietary software = malware
Very nice video that I can learn much about rust language but in 5 min you used lots of framework and names that I have to pause each 5 seconds and google it, you are so fast😂 5star
thank you, glad you liked it!
I think Rust is already deprecated and it's time to do Mojo, no?
Hah! Maybe not quite yet… but in the future who knows
As a proof of concept, it's understandable, but Rust plus React feels like dealing with the worst of both worlds. Rust comes with a steep learning curve, React is overly complex with its aweful boilerplate, intricate state management, and convoluted hook system. Together, they bring none of the straightforwardness, ease and efficiency that JavaScript is widely known for.
It’s like choosing to take your family across the country on a unicycle instead of a car. While it’s possible with enough training and determination, the journey is unnecessarily difficult, especially when there are much simpler and more efficient alternatives available.
I am still trying to understand why I need to login to my terminal.
Nearly everything you showed can be done locally with a little bit of configuration. Tools like oh-my-ash are just straight forward.
I still don't understand why you don't just create a Symfony / Laravel app. The whole thing is 100 times easier and up to a certain point (which almost no web app will reach) fast and sufficient. The bottlenecks of webapps are not in the programming language.
But yes, keep wasting all your time on all these implementations. I make money in the meantime working on my own projects on the side.
Yost Flat
im so over AI being integrated into dev tools. If thats why you have to log into warp they are going to kill their terminal over search v2. ill just open a browser. no thanks.
Rust is a failure from day 1. It's not a good time to learn Rust
Howcome?
@@codetothemoon It's been at least 12 years since we first heard of Rust, and despite the extensive marketing campaign it has received, it is still considered a niche programming language. Don't get me wrong, I'm not saying Rust is a bad programming language. In fact, it might have good features missed in C and C++, but its approach forces developers to either write everything from scratch or deal with the pitfalls of the 'extern-function approach' for integration with the outside world. The industry has invariably proven that this approach is a failure from day one. A very good example of this is the Dart programming language. It was originally intended to replace JavaScript, and despite being better than JavaScript in many ways, it miserably failed to do so. Similarly, Rust is unlikely to succeed in replacing C or C++. The reason is that Rust and C++ are fundamentally incompatible.
The trend is clear for modern programming languages that have been successfully adopted: TypeScript interoperates with JavaScript; C++ interoperates with C, Kotlin interoperates with Java. Even Zig can transparently interoperate with C. Mojo also looks like a much more attractive alternative than Rust as it can run as fast as C, it offers memory-safe features like Rust with an easier and cleaner syntax while being compatible with Python.
I see more future in replacing C/C++ with other approaches such as CPP2 or Carbon, which are projects by engineers at Microsoft and Google, respectively. These languages solve the problems with C and C++ while offering a cleaner syntax and interoperation with C/C++ code. As soon as the first production-ready version of either CPP2, Carbon, or Mojo gets released, which is about to happen soon, the future of Rust will resemble the present of the D programming language. To add more salt to the wound, Rust has already become too verbose and complex, so much so that even Rust developers are feeling frustrated with it. I know a few government agencies might be advocating for memory-safe languages, but it doesn't necessarily have to be Rust. In fact, there are memory safety languages out there with far greater adoption than Rust, such as Java, C#, Python, Swift, and Go. And if performance is also important, Rust has to compete with the already industry-established C and C++, now CPP2, Carbon, Mojo, Zig, and Go. As I said before, it is not a good time to learn Rust and reinvent the wheel in a language just for the sake of doing so. Rust didn't replace C or C++ and it never will. Just check GitHub, Stack Overflow, and other statistics. The truth is that much more code is being written in C and C++ than in Rust. It's been like that for decades. A new programming language, to succeed, needs to guarantee code reusability; otherwise, it will miserably fail.
@@codetothemoon It's been at least 12 years since we first heard of Rust, and despite the extensive marketing campaign it has received, it is still considered a niche programming language. Don't get me wrong, I'm not saying Rust is a bad programming language. In fact, it might have good features missed in C and C++, but its approach forces developers to either write everything from scratch or deal with the pitfalls of the 'extern-function approach' for integration with the outside world. The industry has invariably proven that this approach is a failure from day one. A very good example of this is the Dart programming language. It was originally intended to replace JavaScript, and despite being better than JavaScript in many ways, it miserably failed to do so. Similarly, Rust is unlikely to succeed in replacing C or C++. The reason is that Rust and C++ are fundamentally incompatible.
The trend is clear for modern programming languages that have been successfully adopted: TypeScript interoperates with JavaScript; C++ interoperates with C, Kotlin interoperates with Java. Even Zig can transparently interoperate with C. Mojo also looks like a much more attractive alternative than Rust as it can run as fast as C, it offers memory-safe features like Rust with an easier and cleaner syntax while being compatible with Python.
I see more future in replacing C/C++ with other approaches such as CPP2 or Carbon, which are projects by engineers at Microsoft and Google, respectively. These languages solve the problems with C and C++ while offering a cleaner syntax and interoperation with C/C++ code. As soon as the first production-ready version of either CPP2, Carbon, or Mojo gets released, which is about to happen soon, the future of Rust will resemble the present of the D programming language. To add more salt to the wound, Rust has already become too verbose and complex, so much so that even Rust developers are feeling frustrated with it. I know a few government agencies might be advocating for memory-safe languages, but it doesn't necessarily have to be Rust. In fact, there are memory safety languages out there with far greater adoption than Rust, such as Java, C#, Python, Swift, and Go. And if performance is also important, Rust has to compete with the already industry-established C and C++, now CPP2, Carbon, Mojo, Zig, and Go. As I said before, it is not a good time to learn Rust and reinvent the wheel in a language just for the sake of doing so. Rust didn't replace C or C++ and it never will. Just check GitHub, Stack Overflow, and other statistics. The truth is that much more code is being written in C and C++ than in Rust. It's been like that for decades. A new programming language, to succeed, needs to guarantee code reusability; otherwise, it will miserably fail.
@@codetothemoon I answered to this but my comment gets removed.
at microsoft we are moving about 90% of our c# code over to rust. if its a failure i am a very well paid failure ;)
God no lol
haha, what would you use instead? if I couldn't use Rust I'd probably use SvelteKit
@@codetothemoon tbh if I knew rust better I'd use it 💀 but yea def sveltekit. I had the misfortune of starting with js when I was just beginning to learn programming so it's my default still sorta lol