0:16 when you are in a high throughput api situation the first thing people usually do is add an API load balancer, or an extra 10 bucks to the machine. I agree that rust has very interesting properties and should be i.e. a first choice for embedded & runtime development. But flipping the whole api stack from FastAPI to Rust to get a 2-4x requests per instance (fastapi is pretty fast) wont help you in real high throughput situations… at least before worrying about read and writes to your DB. At scale compute and bandwidth is cheap… unlike your time.
This is a very good point! However, if you're doing really CPU-intensive work, scaling horizontally can become fairly inefficient. Hiring 100s of machines with 0.5 vCPUs will eventually outstrip the cost of having an engineer or two write the performance critical parts of the applications in Rust. Further, while FastAPI is really fast, thanks to (current) Python, it's inherently single-threaded. Robyn makes it easier to use multiple threads thanks to Rust crates like Rayon. Definitely agree with your point if you've already got a large application :)
That's only true for services that are just doing network calls to other services like databases and stuff. For any compute intensive stuff where you want to take advantage of better hardware or more cores, you'll definitely see why Rust is so good. (or maybe a simpler lang like Go).
@@IsaacHarrisHoltFastAPI were intended to covers general use cases. Once you got specific needs then you can of course use optimized version of what you need and yeah it does not need to be in python. The benefit of learning new framework are minuscule by then. If its cpu core performance then there are plenty of it besides rust that are already exist there within C libs usually. Rust is good but its still lack a lot of production ready libs that peoples usually needs. Clients don't care what we used. They cared for time to deliver and costs.
Robyn does also cover general use cases, but it gives you some flexibility. Of course there are other ways to achieve the same. This is just one way of doing things
@@IsaacHarrisHolt I just don't see any benefit learning new stuff just to follow trends. There is no such thing as perfect stack. Experiences from using it matter by a lot.
I’m seeing a lot of libraries adopting Rust as the main building block recently, and for a good reason I suppose. Though Isaac, what’s your take on Zig as compared to Rust, we’ve got Bun and TigerBeetle build using Zig
The thing with rewriting a performance critical python system in another language is that you already know that this thing is going to be used for a while, and you also know you need it to work without any flaws, and you are probably willing to put a bit of extra work into it. Zig doesn't offer the safety or correctness (type system) that rust offers, and if you're already rewriting it from python under these circumstances, the zig argument of "easier to write than rust for c/c++ programmers" isn't really that relevant. Certain projects that rely on a lot of stuff that zig's `comptime` system is excellent for and for whatever reason doesn't need the guardrails rust puts for you (e.g. you're writing it for yourself only) certainly might enjoy zig to a greater extent than rust, but thats a way smaller niche than the giant pool of potential rust applications in the current world of software. Rust isn't the be-all-end-all, but it makes it hard to argue for other languages that do not go beyond it in most of the areas people care about.
@@mikkelens very interesting take, thanks a lot! But don’t you think Zig overcomes much of the safety concerns (bound checks, deferring allocations, etc.) without sacrificing flexibility? It’s more concise I’d say than Rust and less bloated since Rust is filled with macros and standard feature updates that keep growing, which adds a lot of complexity. Also, for systems where you require fine grain control over the memory, such as in embedded systems, I see that eventually Zig would overcome C in this domain since Rust don’t offer you much in this unsafe environment
Very philosophical argument there. Some may believe that safety and correctness come from good design, and the ability to control how the system operates as you build it. The responsibility here rests on the programmers. Some may believe that safety and correctness are better achieved by using tools that remove control and restrict design. The responsibility here rests with the tooling, and whatever decisions were made by the central planning committee who provides those tools. This discussion has been active for the last 40 years in programming.. and much longer than that in general engineering. The 2 points of view are never going to agree with each other. The proponents of the restrictive approach will point out cases where programmers have shipped software with bugs .. therefore cannot be trusted to write code. The proponents of personal responsibility will point out cases where entire countries have collapsed due to the inherent problems with central planning and control. It is not surprising that people’s choices in these areas of programming tools strangely correlate to their political views, and positions on many contemporary controversies.
These are all very interesting points. Personally, I think Zig and Rust can both be used reasonably interchangeably - they both achieve the same thing, but have different philosophies and ways of going about it. Zig will definitely give you more control, and you'll likely be able to achieve higher speeds using it as a result. However, Rust's performance is also incredible, and it's relatively easy to write performance Rust code. Probably easier than Zig. That said, it's fairly easy to write crap code in both languages. To be honest, I can't offer much more of an opinion here - I haven't used Zig much outside of the Impatient Devs video I did. I've used Rust more, though not extensively, and not for any large projects.
It´s great that new framworks arise, but programmers keep in mind that, new and faster doesnt mean better. Robyn is rather young and probably not as used as fastapi meaning that fastapi is more mature and thus more suitable for your needs. And if you hear in your head "but it is faster so my app will be faster" well it wont. Most of web apps are slow not because of framework they use, but because of their code, their app design, their queries to database. If you want to see 3x 10x 100x speedup improvements, start with your code, your implementation, your queries to database, rather than looking for an error somewhere else. With all that said if you are keen on experimenting and you have new project go ahead and try Robyn or any other framework practice makes perfect, but keep in mind that all that glitters is not gold.
I 100% agree with this take! I mostly wanted to show off the library a bit because I think it's a really cool project maintained by some really great people. And yes, you're right about async stuff. Robyn won't reduce request times much if at all, but it may be able to improve throughput by providing a better underlying server and so on. Also, the simple Rust integration is great for CPU-bound tasks.
This is quality content, I can’t help but feel that all the gifs and other hallmarks of garbage programming content cheapen your work a bit I don’t think you should want to emulate fireship when you actually have something useful to say
@@IsaacHarrisHolt Yeah, exactly. That is one thing I think many of the developers who develop and try and “sell” developers a new framework, OSS library, toolkit etc forget. Is that what you have built isn’t “unique” or solves a problem for us that we couldn’t solve before. IMO I think that is why business oriented developers make for such great innovators. Look at React, nextJs or FastAPI. They got created when people needed it the most. I think for the next generation of developers that want to create Open source tech that gets mass adoption is to really look into what the problems current developers are facing and come up with a solution that is better than current implementations. I think for Robyn to rival FastAPI it needs to literally have everything that FastAPI offers (web sockets, JWT a really fast WSGI/ASGI). Speed I think is what could give Robyn it’s edge. I love FastAPI (Used to develop a lot of projects in flask. But as soon as I learned about FastAPI I left flask for good whenever I wanted a heavyweight backend or a heavyweight API). And also the fact that I can switch between WSGI is not a bad thing. It’s a good think and means I not locked in. I hate libraries that literally shove down shit my throat and force me to use things I don’t need or want to use. A love a flexible, adaptable and straightforward library.
Totally fair! You don't have to use Python. I like it because it's really easy to be productive and has a great ecosystem
6 місяців тому
@@IsaacHarrisHolt With Rust it's even easier according to my experience. Type checking is superior, error handling is superior, metaprogramming is superior, abstraction is superior. And it offers top speed always.
True. But this type of interoperability comes handy when you need to integrate existing Python code and libraries, especially from other teams that only write Python.
This is all relative. If you were doing APIs in Python without a major reason it was already a problem. I love python. I am a python engineer and it sucks at performance.if you have something simple, why dont do it in java or .net. they are terrible languages but they work. If rust has a great backend API, it is even better. Ps. If you do backend in js, please, stop if you dont have good reasons.
The main benefits of doing things in Python are ecosystem and developer velocity. Also, you might only have a single CPU-intensive route amongst 100 other routes. Not a lot of point rewriting your entire app in a more difficult language for that
It depends what team you got. pypy3 with granian and async Python can pump some good RPS. So do JS backends on Bun. Why hire new people or learn different languages if your team is comfortable with Python or JS?
@@minciNashu tried Granian, it 7x my RPS (using Quart as web framework). Unfortunately it doesn't work with Vercel..so my usage is limited to the local server.
Remember when python developers invented wsgi so no python app is bound to a particular web server or framework? Yes, gen z ruining all once again with their "innovation"
This is a very... close-minded take. There are plenty of ways to do things, and the industry as a whole is trending back towards simpler things. Why can't that be the case here too?
![Lp. Сердце Вселенной #60 РОЖДЕНИЕ ЛОЛОЛОШКИ [Финал] • Майнкрафт](http://i.ytimg.com/vi/YoR0pAV9FVQ/mqdefault.jpg)
0:16 when you are in a high throughput api situation the first thing people usually do is add an API load balancer, or an extra 10 bucks to the machine. I agree that rust has very interesting properties and should be i.e. a first choice for embedded & runtime development. But flipping the whole api stack from FastAPI to Rust to get a 2-4x requests per instance (fastapi is pretty fast) wont help you in real high throughput situations… at least before worrying about read and writes to your DB. At scale compute and bandwidth is cheap… unlike your time.
This is a very good point! However, if you're doing really CPU-intensive work, scaling horizontally can become fairly inefficient. Hiring 100s of machines with 0.5 vCPUs will eventually outstrip the cost of having an engineer or two write the performance critical parts of the applications in Rust.
Further, while FastAPI is really fast, thanks to (current) Python, it's inherently single-threaded. Robyn makes it easier to use multiple threads thanks to Rust crates like Rayon.
Definitely agree with your point if you've already got a large application :)
That's only true for services that are just doing network calls to other services like databases and stuff. For any compute intensive stuff where you want to take advantage of better hardware or more cores, you'll definitely see why Rust is so good. (or maybe a simpler lang like Go).
@@IsaacHarrisHoltFastAPI were intended to covers general use cases.
Once you got specific needs then you can of course use optimized version of what you need and yeah it does not need to be in python.
The benefit of learning new framework are minuscule by then.
If its cpu core performance then there are plenty of it besides rust that are already exist there within C libs usually.
Rust is good but its still lack a lot of production ready libs that peoples usually needs.
Clients don't care what we used. They cared for time to deliver and costs.
Robyn does also cover general use cases, but it gives you some flexibility. Of course there are other ways to achieve the same. This is just one way of doing things
@@IsaacHarrisHolt I just don't see any benefit learning new stuff just to follow trends.
There is no such thing as perfect stack. Experiences from using it matter by a lot.
Rust really adopt everywhere now, glad I have more Python web framework to use.
Yes, it's great! More Rust-Python to come 😉
I'll give this one a shot. My experience with FastAPI has been plagued by weird hangups.
Let me know how you find it!
The addition of memes is a nice touch, keep it up Issac!!!
Will do, thanks!
I’m seeing a lot of libraries adopting Rust as the main building block recently, and for a good reason I suppose. Though Isaac, what’s your take on Zig as compared to Rust, we’ve got Bun and TigerBeetle build using Zig
The thing with rewriting a performance critical python system in another language is that you already know that this thing is going to be used for a while, and you also know you need it to work without any flaws, and you are probably willing to put a bit of extra work into it. Zig doesn't offer the safety or correctness (type system) that rust offers, and if you're already rewriting it from python under these circumstances, the zig argument of "easier to write than rust for c/c++ programmers" isn't really that relevant. Certain projects that rely on a lot of stuff that zig's `comptime` system is excellent for and for whatever reason doesn't need the guardrails rust puts for you (e.g. you're writing it for yourself only) certainly might enjoy zig to a greater extent than rust, but thats a way smaller niche than the giant pool of potential rust applications in the current world of software. Rust isn't the be-all-end-all, but it makes it hard to argue for other languages that do not go beyond it in most of the areas people care about.
@@mikkelens very interesting take, thanks a lot! But don’t you think Zig overcomes much of the safety concerns (bound checks, deferring allocations, etc.) without sacrificing flexibility? It’s more concise I’d say than Rust and less bloated since Rust is filled with macros and standard feature updates that keep growing, which adds a lot of complexity. Also, for systems where you require fine grain control over the memory, such as in embedded systems, I see that eventually Zig would overcome C in this domain since Rust don’t offer you much in this unsafe environment
Very philosophical argument there.
Some may believe that safety and correctness come from good design, and the ability to control how the system operates as you build it. The responsibility here rests on the programmers.
Some may believe that safety and correctness are better achieved by using tools that remove control and restrict design. The responsibility here rests with the tooling, and whatever decisions were made by the central planning committee who provides those tools.
This discussion has been active for the last 40 years in programming.. and much longer than that in general engineering.
The 2 points of view are never going to agree with each other.
The proponents of the restrictive approach will point out cases where programmers have shipped software with bugs .. therefore cannot be trusted to write code.
The proponents of personal responsibility will point out cases where entire countries have collapsed due to the inherent problems with central planning and control.
It is not surprising that people’s choices in these areas of programming tools strangely correlate to their political views, and positions on many contemporary controversies.
These are all very interesting points. Personally, I think Zig and Rust can both be used reasonably interchangeably - they both achieve the same thing, but have different philosophies and ways of going about it.
Zig will definitely give you more control, and you'll likely be able to achieve higher speeds using it as a result. However, Rust's performance is also incredible, and it's relatively easy to write performance Rust code. Probably easier than Zig.
That said, it's fairly easy to write crap code in both languages.
To be honest, I can't offer much more of an opinion here - I haven't used Zig much outside of the Impatient Devs video I did. I've used Rust more, though not extensively, and not for any large projects.
@@steveoc64 totally agree, and interesting note on the political side lol
Need a uv-Video ;)
Sadly I don't do much in the way of Python content any more - it's pretty much all Gleam now!
Great video. What is the IDE and terminal settings you have used could you please provide steps to setup.
I use AstroNvim with ZSH terminal, OMZ and P10k
Granian is another interesting Rust-based Python library..it's a server runner.
It increased my RPS by 7x !!
Interesting! I'll have to take a look
It´s great that new framworks arise, but programmers keep in mind that, new and faster doesnt mean better. Robyn is rather young and probably not as used as fastapi meaning that fastapi is more mature and thus more suitable for your needs. And if you hear in your head "but it is faster so my app will be faster" well it wont. Most of web apps are slow not because of framework they use, but because of their code, their app design, their queries to database. If you want to see 3x 10x 100x speedup improvements, start with your code, your implementation, your queries to database, rather than looking for an error somewhere else. With all that said if you are keen on experimenting and you have new project go ahead and try Robyn or any other framework practice makes perfect, but keep in mind that all that glitters is not gold.
I 100% agree with this take! I mostly wanted to show off the library a bit because I think it's a really cool project maintained by some really great people.
And yes, you're right about async stuff. Robyn won't reduce request times much if at all, but it may be able to improve throughput by providing a better underlying server and so on.
Also, the simple Rust integration is great for CPU-bound tasks.
Thanks for covering this! Do you have a discord server?
In the description!
we need uv video!!!
On the list!
Please, make the video on uv. I'm really interested :)
On the list!
Thank you, and your channel looks interesting, I've just subscribed to it
Thanks! I hope you found the video useful
Nowdays all thtr implement Rust is looking some sexy :D .... Knowing Rbyn this 2024 when checking alternatives to sanic. Thanks 4 this video.
You're welcome! I hope you find it useful
This is sick
I agree!
Nice content why Batman running 😂😂
🏃💨
Just started fast api😂 too late i guess
FastAPI is still great! I use it in production at the moment
This is quality content, I can’t help but feel that all the gifs and other hallmarks of garbage programming content cheapen your work a bit
I don’t think you should want to emulate fireship when you actually have something useful to say
Appreciate the feedback! I'd love to be able to do more useful animations etc., but it's difficult to find the time at the moment :)
Is it cool, yeah.
Will i use it, most likely not
That's fair! There's a cost to switching
@@IsaacHarrisHolt Yeah, exactly. That is one thing I think many of the developers who develop and try and “sell” developers a new framework, OSS library, toolkit etc forget. Is that what you have built isn’t “unique” or solves a problem for us that we couldn’t solve before.
IMO I think that is why business oriented developers make for such great innovators.
Look at React, nextJs or FastAPI. They got created when people needed it the most.
I think for the next generation of developers that want to create Open source tech that gets mass adoption is to really look into what the problems current developers are facing and come up with a solution that is better than current implementations.
I think for Robyn to rival FastAPI it needs to literally have everything that FastAPI offers (web sockets, JWT a really fast WSGI/ASGI). Speed I think is what could give Robyn it’s edge.
I love FastAPI (Used to develop a lot of projects in flask. But as soon as I learned about FastAPI I left flask for good whenever I wanted a heavyweight backend or a heavyweight API). And also the fact that I can switch between WSGI is not a bad thing. It’s a good think and means I not locked in.
I hate libraries that literally shove down shit my throat and force me to use things I don’t need or want to use.
A love a flexible, adaptable and straightforward library.
I use Rust instead of Python.
Totally fair! You don't have to use Python. I like it because it's really easy to be productive and has a great ecosystem
@@IsaacHarrisHolt With Rust it's even easier according to my experience. Type checking is superior, error handling is superior, metaprogramming is superior, abstraction is superior. And it offers top speed always.
True. But this type of interoperability comes handy when you need to integrate existing Python code and libraries, especially from other teams that only write Python.
@@vurmyr Of course.
Good content, terrible and exhausting montage. Please take a breath.
Thanks for the feedback!
This is all relative. If you were doing APIs in Python without a major reason it was already a problem.
I love python. I am a python engineer and it sucks at performance.if you have something simple, why dont do it in java or .net. they are terrible languages but they work. If rust has a great backend API, it is even better.
Ps. If you do backend in js, please, stop if you dont have good reasons.
The main benefits of doing things in Python are ecosystem and developer velocity. Also, you might only have a single CPU-intensive route amongst 100 other routes. Not a lot of point rewriting your entire app in a more difficult language for that
It depends what team you got.
pypy3 with granian and async Python can pump some good RPS. So do JS backends on Bun.
Why hire new people or learn different languages if your team is comfortable with Python or JS?
@@minciNashu tried Granian, it 7x my RPS (using Quart as web framework).
Unfortunately it doesn't work with Vercel..so my usage is limited to the local server.
.NET/C# is great for backends, simple ones too
Remember when python developers invented wsgi so no python app is bound to a particular web server or framework? Yes, gen z ruining all once again with their "innovation"
This is a very... close-minded take. There are plenty of ways to do things, and the industry as a whole is trending back towards simpler things. Why can't that be the case here too?
@IsaacHarrisHolt because frameworks come and go.
Also, Robyn is not a simpler thing.
Fastapi is not comparable with rust frameworks. Everything you do in Fastapi takes 10 times less than in any rust framework.
Because it's written in Python. Like a Robyn app :)