Says a lot about how prime never wastes time on stream and always gets to the point. But im not hating since hes one of most popular tech streamers so hes clearly doing something better than others
All of the feedback that Prime is giving here is really great, but there inherently is the problem: the vast majority of the issues that the original author of the article goes over are things that are dealt with by a more experienced Rust engineer. Going from playing with Rust to production Rust is a huge jump for most devs, myself included.
@@LtdJorge It's the maintainability that Go strives to overcome. When you've got millions of lines of code maintained by hundreds of programmers. Go was designed by programmers not for the fun of creating a new language but to solve the code complexity issue. To make code that is blazingly fast to write, modify, add new functionality as business requirements change -- and still be performant. Is it as fast as Rust - No. Is it faster to write in Go vs Rust -- yes. And remember development time is money. If I need raw speed it's cheaper to put it behind a load balancer and run 2 servers than it is to add weeks to a development cycle.
Is there evidence to support that rust is slower to write (AND maintain) than other languages? Specifically you cite adding "weeks to the development cycle" but I find many teams lose velocity from bugs in the system (current team specifically has Onduty rotations. I haven't really used rust professionally but I am pretty happy generating code using bard and like the wasm stuff so far
@@Saffat-HasanI agree! Time spent debugging is always “glossed over” by devs that don’t use Rust. Rust may take a bit more time to write, but once you’ve written it, you’re done. The code is **done**. Yes, done. You don’t look at it ever again. It’s such an insane paradigm shift that I can’t make the trade offs of any other language worth it. For example: I wrote a service in Rust. I probably could’ve gotten the bones of it working in something like C# a lot faster, but I probably would’ve run into a lot of runtime errors. Some of the assumptions I was making were bad assumptions to be making. Rust didn’t allow me to make them, and it forced me to write better code the first time. That service has been deployed in production for the last 4 months. It’s been running, solid, for 4 entire months. Not a single downtime event. No memory leaks. Nothing. It’s silly how reliable it is. Just having errors as types alone make Rust worth it! Exceptions are horrible awful things! Exceptions for errors make for terrible unreliable code. I don’t care how many try catch blocks you think you need, you’ll never get them all right. Errors as types though? You can’t get around handling all errors!
You can just do RUN --mount=type=cache,target=/target cargo build... And enjoy incremental builds. And it also works for production where you just drop cache every run if you want 100% clean build.
The only point I really felt on my skin so far was the async traits one. Its just as he said, async is great, traits are great, both of them together not so much, throw a closure that returns a future on the mix and you'll hate yourself in no time.
Re: virtual mounting I wonder if the culprit is linking. As in, they're using some system library that gets called out to from their compiled (from rust) binary. Inside the container, that virtually mounted binary would be linked to a, for example, glibc residing in the host OS/file system's `/lib` - *outside* of the container. I know Go tries to compile eveything into a single static binary, but not sure if it can do that with calls to (host) system libraries as well. If it can, then that might be why the article's author implicitly found Go to work better for them.
I never understood the complaints against Rust compile-times. Because it has an ML-inspired type system, you're getting significantly more tests for free than your C-descendant languages. What you'd have to manually write tests for, the Rust compiler auto-implements. Then, all you really need to do are integration tests.
I would just use a vmount to link the binary into the container and build locally. I have to build for a fairly old system at work and nobody ships cross-compilers that work for it. If you know how C linkers work and aren’t afraid to spend a day or two perusing the package repository of your OS and installing a few things manually, you can build a decent sysroot with everything you need and compile right on your mac. Skip that virtualization layer and the compile times decrease dramatically. Then vmount it into your container and problem solved! I’ve even made a nice little alias that I just prepend to my cargo commands and it configures the C linker paths, targets, sysroot dirs, etc for me
Yeah lifetimes are one of those rare uses that you’ll need to look up. I know (or b c d e whatever) and put it on the type. But where… well documentation is my friend. And in a year of rust I’ve only had to do it twice.
The question about virtual mounts and incremental reloads/recompiles might be dependent on their work environment. Then again they said personal/side projects so maybe less of an issue for them and it's just a knowledge gap. At my employer, we are restricted in our access to the latest tools, so things you Docker file watcher are two minor versions ahead of what we are currently approved for using. I'm looking forward to when it's approved for use though as it will dramatically improve development workflow
His problem might be x64/86 container running on M1 emulation (arm to x64/86) meaning that inside container it doesnt compile for arm so volume mount wouldn't work
Virtual Mounts might fail when you want output hot reloading because you probably get nasty situations with detecting file changes properly. Also, you'd need to recompile on the host machine an then somehow tell the container to reload your stuff inside the container
Bind mounts rely on the host file system so the container doesn't have to update a reference or anything. The software running in the container would need to detect an de change if he wanted hot reloading on that. That's as easy as compiling rust within the bind mount, and watching the directory for changes within the container. Entr can observe and rerun commands on file changes. Sounds pretty straight forward if you ask me.
Some chat gems summary of the S3 authentication misreading: - you upload a file to get authenticated - if you can upload the file, you are good to go - file sessions on S3 :D
I would do the Docker instance to provide a real connection for integration tests only, whereas I don't want to have to rely on that same fairly heavyweight mechanism for hundreds of unit tests. I want my unit tests to be as simple as possible, and sometimes the only way to increase coverage is to be able to simulate, using dep injected mock versions) otherwise impossible to recreate errors which never happen using the real DB instance.
It's not always the case, but DI/IoC solve problems caused by OOP mindset. I'm currently doing a bunch of VT100 parsing stuff and originally had a "trait of callbacks", which is a very OOP/patterns way of approaching things. Tests were a giant pain in the ass. Now I'm simply returning an enum from the scanner, and no IoC is required. The code is about 1/5 LOC, is much easier to understand, a more obvious solution (in 20/20 hindsight), and is more fun to write. In other words, to avoid having to inject Diesel or run a container at all (please don't do that, when used for "real" problems data seeding is extremely time consuming), have your route handler pull data out of the DB and then pass it to the logic, instead of having your logic interact with the DB. You can then have a few integration tests (that do interact with a real DB) to smoke test the route handlers. The meta-cognition in Rust seems to be based around data flow, instead of GoF design patterns. Think about where the data comes from, how to transform it, and where to send it. Those should be treated as distinct responsibilities.
I've written an S3 request sigining function in a postgres SQL function based on pg_crypto. SQL is my favorite language for backend logic that doesn't need to do extreme amounts of compute per request.
Yeah, not only Rust.. container in test to Java (Sorry, I use Java yet) is painful too, but to me running test in container is more complicated most of the time and more your application grow up more "unproductive" or too slow me is your test/delivery. Containers too me was only useful when I need third parties apps like RabbitMQ, Database and etc.
May I ask, were you developing natively in Linux? Because containers have 0 impact in performance for me (not kidding literally 0 -> a used a program for protein folding) Virtual Machines in other hand have a ton of overhead
@@jongxina3595 you shouldn't be rebuilding containers for development, you should be using a virtual mount with a live reload daemon/server or something running inside the dev container. The big question is why the author of that post didn't do that, maybe containers on macOS are much slower than Linux wrt live reload (owing to VMs/completely different storage device/network stack/kernel vs Linux)? Or not, who knows
Rust and Go are both great. They don't suffer from JVM issues like Java and didn't originate as proprietary technology like C#. You can't lose with either one.
Docker is the reason why I started running Asahi Linux despite being alpha quality. Asahi Linux (back in its pre-gpu accelerated state) is why I just bought a thicc x86 laptop and sold my MacBook.
So after taking advice and learning to type, I'm almost at my random style typing speed with correct typing and id say it was worth taking a few days to focus on. Are there any other super common annoying things newby devs do (like not knowing how to type for example)? I want to iron out these kinks and get a solid foundation. Any suggestions will be taken seriously so I appreciate you in advance 💪🧙♂️
The only go projects at work are kubernetes controllers. They take an awful long time to build, like several minutes on our CI agents. But this is probably because you essentially have to build the whole k8s API?
When RUST becomes hard? I mean when started reading "THE BOOK" everything is explained so well and not so complicated. Does the hard part comes in a large code bases or something? The Borrow checker seems so simple and elegant way to handle memory, in a few projects I believe we will not even think about it idk maybe I am wrong. Is the problem that there might not be good idiomatic way to structure projects and modules?
"JavaScript being a means to Purgatory", that one got me :D. I think Dante would certainly disagree and say, it's more like the 3rd inner circle to hell, followed by Brainfuck and Bracket.
I basically never bother with mocking out IO for databases (and most other things) anymore. I am currently writing Python at my job and use the testcontainers library for that. Even a lot of cloud resources can be emulated instead of mocked (GCP official emulators, AWS LocalStack, third party emulators, etc.). I actually think mocking out your SQL database is a huge anti-pattern especially when dealing with raw queries: There's so much API encoded between your stringly-typed query and the actual schema of the DB that you almost end up testing nothing as soon as there is no real DB with a real schema. ORMs slightly change that equation but not by much.
I feel this. I considered mocking a redis container to speed up tests but then quickly realised that the most uncertain part of the code under test are my redis calls. Am I removing from the correct end of the list? Am I selecting the correct number of elements? Etc.
I hope Primagen (or Primazen?) maintains his Xust (intentional) craze after 10 years. Rust, for my purpose, is an unsolicited distraction. I don't look for advice from Rust zealots. There are books for that. I don't want to listen from ten thousand fanboys why I should stop doing everything other than writing code in Rust. I didn't ask for any counselling. Maybe, I'm a hobbyist who plays with electronic components. The beauty of a programming language is not expressed by how many bells and whistles it puts together that fall apart every now and then, here and there. A programming language that allows creators to readily express their vision by allowing them to put together all the small elements of logic they build up inside their mental map, a language without hidden overheads is perfect to work with. As for bugs and vulnerabilities, they either happen in the compile stage or at the runtime, of which the latter is unpredictable. Neither of the cases is unprecedented in any programming language. Bugs and vulnerabilities are faults on the programmers' part. It is the duty of the person who writes the program to follow standard practices from the beginning and iron out inconsistencies once the project is complete. Rust won't make the logic of a solution magically better. A language that limits the activities of the programmer is not offering much extra from the existing ones. That is the duty of the programmer. Rust is relatively easy to learn, easier than learning C++. It does not have the nitty-gritty details of C and supports Unicode out of the box. Rust has better mutable/immutable variable concepts, confusing array/unappealing loop structures and a wonderful concept called borrow checker. Rust should never be someone's first target while learning to program for the first time. If someone chooses Rust as his first time programming language, he will learn Rust, not how computers work. Every language has its quirks. A language like C has libraries for almost all fields imaginable and compilers for nearly every CPU architecture that exists to date; Rust is slowly catching up with a long way to go. Nevertheless, envisioning all the things in the world will get oxidised at room temperature even those that aren't ready to react with oxygen contained in the thin air is frivolity without consideration. In Calcutta, the temperature is 42 degree Celsius. Sorry, we don't measure in the FPS standard. Is that weird? Not sure! The relative humidity is 73%. It's getting very difficult to type on a tiny screen. One thing I have in mind that I'd like to express is that I don't have any problem with Rust. I never liked it, I never disliked it either. Simply, it's not the be-all and end-all solution to every problem. People have other problems, too. I can't put up with Rust apologists, they can't put up with me. Either it's my problem or it is theirs or both. Now, thousands of Rust extremists will jump off for a holy battle.
Less a political ideology, and more just explicitly saying "we will exclude those who are intolerant of others so as to maintain a healthy and welcoming community"
@@bitcode_ right I do agree that there is probably a mathematical balance of percent personality vs percent content. Personality grows the channel while content would be the focus. I guess content would be unimportant and at 20% of this channel.
fwiw I once tried to build a js project sitting on my host in a wsl container (it needed an older node version) and the performance was horrible because (if i'm not mistaken) the folder was mounted with some slow network protocol, and it had to read tens of thousands of files in node modules.
I like to pretend that Prime makes a newbie like me feel comfortable with asking questions to critically problem solve problems I didn’t know I could have. 😂 Alas, seeing all the sources I have for Go and Rust, I am choosing Go. But it is on my bucket list to make a programming language, and I like the concept of a borrow checker. Life is just a lifelong learning process, with that said I expect to learn both lol. But time go to the IDE!
Hey prime, can you talk a little about how do you read the tech books (I mean how do you get the most out of it and learn the stuff init), great videos by the way
On Mac OS i find rust compilation inside a docker container too slow. I got a humble 2012 Macbook Pro, now I installed Pop Os Linux in it and using it for devel, much better 😁
It feels more like the guy was short on time and picked up the things that works for him without need to learn/invest more time into something before starting doing actual work.
Following up on the pronunciation of GQL: Like in the acronym GIF, the 'G' in GQL would make "Gah-Quill" the correct pronunciation, rather than "Yee-Quill"
@@nsk8ter524 I didn't use it with Rust but I used it for Java with Spring Boot and it is pretty fast in M1. I also tried to develop using the same setup on Windows, but it was TOO slow. I try to always use Linux but I was forced to use Windows on my last job and it was painful.
I find myself using Go over Rust when a library I need doesn't have Rust SDKs and I'm feeling too lazy to write a lib myself. Go is still great for backend but just isn't quite as fun to write as Rust, I don't feel as accomplished afterwards.
@@alkolaqi83 It means what it says? There are two reasons why, one of them should have been easy enough to infer from my original comment. 1. When I'm not being lazy or needing to get a POC out fast, I take the time to write the lib or create the bindings I need when they don't exist. So I'm literally acomplishing more. 2. I'm less familiar with Rust and when I do write it I try to do things I haven't done in the language before, so it's more work.
What's the rust book that you showed briefly? Is it beginner friendly, I've never used rust before but wanted to try it, also do they have an online playground similar to golang?
its actually jekyll. I am usubbing from twitch right now. ha ha. I act went from go to crab langauge (custom framework and then actix) and all of his points seem nonsensical to me.. Maybe I should write a medium article on Rust(TM). Disclaimer: Comment not sponsored by rust foundation.
I fixed my Rust compile times by just buying a top-of-the-line AMD CPU. It crunches through that code like nobody's business. Being a Rust developer also means that I'm earning enough to be able to afford that.
There was a similar issue a month or two ago on r/rust. TLDR? Docker bind mounts on anything but Linux suck ass. The person we talked with experienced something like 15x slow down when building in a bind mount.
If your goal is to learn stuff? No, not at all. If your goal is to have a product that multiple people work on, just a little bit. But we're all mad here. You must also be mad, or you wouldn't be here... :3
Why aren't your past streams available on Twitch anymore? Until last week I used to watch them (often the whole stream) whenever I got time for it, which is seldom at the same time you're actually streaming. Now I only see a handful of short clips. Makes me pretty sad as your streams contain a lot more interesting parts than what you post here on YT. Please re-consider & make them available again. Thanks! (To elaborate: on the "videos" tab there _all_ filters safe for the "Clips" one contain no videos at all. Not a single one.)
I once accidentally paused a Primagen video and it took me 10 minutes to realise he wasn't doing a dramatic silence
D R A M A T I C _ S I L E N C E
@@ThePrimeTimeagen when is the next live stream prime
Says a lot about how prime never wastes time on stream and always gets to the point. But im not hating since hes one of most popular tech streamers so hes clearly doing something better than others
10 minutes???
Man that's some immutable silence
@@RenderingUser I just assumed he was pushing the boundaries of what was acceptable in society
All of the feedback that Prime is giving here is really great, but there inherently is the problem: the vast majority of the issues that the original author of the article goes over are things that are dealt with by a more experienced Rust engineer. Going from playing with Rust to production Rust is a huge jump for most devs, myself included.
Yeah, the learning curve is real
Or mostly just not using Mac for compiling Rust in containers.
@@LtdJorge It's the maintainability that Go strives to overcome. When you've got millions of lines of code maintained by hundreds of programmers. Go was designed by programmers not for the fun of creating a new language but to solve the code complexity issue. To make code that is blazingly fast to write, modify, add new functionality as business requirements change -- and still be performant. Is it as fast as Rust - No. Is it faster to write in Go vs Rust -- yes. And remember development time is money. If I need raw speed it's cheaper to put it behind a load balancer and run 2 servers than it is to add weeks to a development cycle.
Is there evidence to support that rust is slower to write (AND maintain) than other languages? Specifically you cite adding "weeks to the development cycle" but I find many teams lose velocity from bugs in the system (current team specifically has Onduty rotations.
I haven't really used rust professionally but I am pretty happy generating code using bard and like the wasm stuff so far
@@Saffat-HasanI agree! Time spent debugging is always “glossed over” by devs that don’t use Rust.
Rust may take a bit more time to write, but once you’ve written it, you’re done. The code is **done**.
Yes, done. You don’t look at it ever again.
It’s such an insane paradigm shift that I can’t make the trade offs of any other language worth it.
For example: I wrote a service in Rust. I probably could’ve gotten the bones of it working in something like C# a lot faster, but I probably would’ve run into a lot of runtime errors. Some of the assumptions I was making were bad assumptions to be making. Rust didn’t allow me to make them, and it forced me to write better code the first time.
That service has been deployed in production for the last 4 months. It’s been running, solid, for 4 entire months. Not a single downtime event. No memory leaks. Nothing. It’s silly how reliable it is.
Just having errors as types alone make Rust worth it! Exceptions are horrible awful things! Exceptions for errors make for terrible unreliable code. I don’t care how many try catch blocks you think you need, you’ll never get them all right.
Errors as types though? You can’t get around handling all errors!
I went gigachad mode and migrated to HTML backend.
The truest programming language
You use HTML ? I use pigeons to deliver data packets
@@filipstudeny You use pigeons! pffff! I shout in binary at the top of my lungs
@@TechBuddy_ Binary ? I am sending atoms that made the data
@@filipstudeny I really want say quarks but no we'll stop it here.
You can just do RUN --mount=type=cache,target=/target cargo build... And enjoy incremental builds. And it also works for production where you just drop cache every run if you want 100% clean build.
The only point I really felt on my skin so far was the async traits one. Its just as he said, async is great, traits are great, both of them together not so much, throw a closure that returns a future on the mix and you'll hate yourself in no time.
That's why many people are working on it, their are so many edge case ^^
I love how comments are :
- teach him about traits
- tell him about docker
the guy clearly explained
You can mock S3 for tests by setting up a sidecar container with minio (s3 compatible oss object storage)
There is nothing better than Primagen reading abbreviations. I just love it 😂
I'd love more detail on why you prefer Rust to Go (usually? in general? In some contexts?), both subjective reasons and objective advantages.
Re: virtual mounting
I wonder if the culprit is linking. As in, they're using some system library that gets called out to from their compiled (from rust) binary. Inside the container, that virtually mounted binary would be linked to a, for example, glibc residing in the host OS/file system's `/lib` - *outside* of the container.
I know Go tries to compile eveything into a single static binary, but not sure if it can do that with calls to (host) system libraries as well. If it can, then that might be why the article's author implicitly found Go to work better for them.
maybe also readability and ease of use another reason why ?
I never understood the complaints against Rust compile-times. Because it has an ML-inspired type system, you're getting significantly more tests for free than your C-descendant languages. What you'd have to manually write tests for, the Rust compiler auto-implements. Then, all you really need to do are integration tests.
What if you want to build a fast code?
@@eng3d Rust is basically as fast as C, sometimes faster. And if you need speed more than anything else, you want to use FORTRAN.
I would just use a vmount to link the binary into the container and build locally. I have to build for a fairly old system at work and nobody ships cross-compilers that work for it. If you know how C linkers work and aren’t afraid to spend a day or two perusing the package repository of your OS and installing a few things manually, you can build a decent sysroot with everything you need and compile right on your mac. Skip that virtualization layer and the compile times decrease dramatically. Then vmount it into your container and problem solved! I’ve even made a nice little alias that I just prepend to my cargo commands and it configures the C linker paths, targets, sysroot dirs, etc for me
Is it just me or does prime look a lot like the gamer Dr Disrespect?
who dis?
Same 😂
their mustache-style look a like.
What's the advantage in switching between programming languages for your 'backend' constantly?
It's fun
Job security
Yeah lifetimes are one of those rare uses that you’ll need to look up. I know (or b c d e whatever) and put it on the type. But where… well documentation is my friend. And in a year of rust I’ve only had to do it twice.
same.. i do it so rarely that i have to re-remember how (i usually can guess into the right syntax)
Run all auxiliary services with docker-compose, and run the thing you're developing on bare metal, without container. Works great.
The question about virtual mounts and incremental reloads/recompiles might be dependent on their work environment. Then again they said personal/side projects so maybe less of an issue for them and it's just a knowledge gap.
At my employer, we are restricted in our access to the latest tools, so things you Docker file watcher are two minor versions ahead of what we are currently approved for using. I'm looking forward to when it's approved for use though as it will dramatically improve development workflow
His problem might be x64/86 container running on M1 emulation (arm to x64/86) meaning that inside container it doesnt compile for arm so volume mount wouldn't work
oh... sheee interesting. i don't use macs so this is a world i am completely confused by
At this point i want our small app with 15 users to migrate in Rust because its the new thing 🥴
i ackshually really like rust :)
B L A Z I N G L Y F A S T
Migrate to C and never look back nor front
Must adopt the next big thing! Must watch codebase become unmaintainable once the language dies!
@@tumescent win32kfull_rs.sys
Virtual Mounts might fail when you want output hot reloading because you probably get nasty situations with detecting file changes properly.
Also, you'd need to recompile on the host machine an then somehow tell the container to reload your stuff inside the container
Bind mounts rely on the host file system so the container doesn't have to update a reference or anything.
The software running in the container would need to detect an de change if he wanted hot reloading on that. That's as easy as compiling rust within the bind mount, and watching the directory for changes within the container. Entr can observe and rerun commands on file changes.
Sounds pretty straight forward if you ask me.
How in the world does Prime find these amazing articles?
over the universe, you can submit yours on the discord :)
He be using VIM news reader🌚
Some chat gems summary of the S3 authentication misreading:
- you upload a file to get authenticated
- if you can upload the file, you are good to go
- file sessions on S3
:D
reading is hard
@@ThePrimeTimeagen hardo' meter -> reading > writing code
but :P
writing code on paper no keyboard involved (oh my gud') > reading > writing code
I would do the Docker instance to provide a real connection for integration tests only, whereas I don't want to have to rely on that same fairly heavyweight mechanism for hundreds of unit tests. I want my unit tests to be as simple as possible, and sometimes the only way to increase coverage is to be able to simulate, using dep injected mock versions) otherwise impossible to recreate errors which never happen using the real DB instance.
1:58
When Prime tapped out "FMS" in Morse code, I felt that.
It's not always the case, but DI/IoC solve problems caused by OOP mindset. I'm currently doing a bunch of VT100 parsing stuff and originally had a "trait of callbacks", which is a very OOP/patterns way of approaching things. Tests were a giant pain in the ass. Now I'm simply returning an enum from the scanner, and no IoC is required. The code is about 1/5 LOC, is much easier to understand, a more obvious solution (in 20/20 hindsight), and is more fun to write.
In other words, to avoid having to inject Diesel or run a container at all (please don't do that, when used for "real" problems data seeding is extremely time consuming), have your route handler pull data out of the DB and then pass it to the logic, instead of having your logic interact with the DB.
You can then have a few integration tests (that do interact with a real DB) to smoke test the route handlers.
The meta-cognition in Rust seems to be based around data flow, instead of GoF design patterns. Think about where the data comes from, how to transform it, and where to send it. Those should be treated as distinct responsibilities.
I've written an S3 request sigining function in a postgres SQL function based on pg_crypto.
SQL is my favorite language for backend logic that doesn't need to do extreme amounts of compute per request.
"I know most those words (hesitates)....in that sentence" then goes straight to an ad. I was in tears 🤣
The entire article could have just been, "Build times on large codebases."
"guiquil" really cot me off guard tho
Multi stage build using cargo chef to cache the dependencies.
Yeah, not only Rust.. container in test to Java (Sorry, I use Java yet) is painful too, but to me running test in container is more complicated most of the time and more your application grow up more "unproductive" or too slow me is your test/delivery. Containers too me was only useful when I need third parties apps like RabbitMQ, Database and etc.
for real. containerization most certainly solved some issues whilst creating new issues
May I ask, were you developing natively in Linux?
Because containers have 0 impact in performance for me (not kidding literally 0 -> a used a program for protein folding)
Virtual Machines in other hand have a ton of overhead
@tablet tablete I dont think runtime performance suffer. He meant more like dev time. Takes time to build and reload these containers.
@@jongxina3595 you shouldn't be rebuilding containers for development, you should be using a virtual mount with a live reload daemon/server or something running inside the dev container. The big question is why the author of that post didn't do that, maybe containers on macOS are much slower than Linux wrt live reload (owing to VMs/completely different storage device/network stack/kernel vs Linux)? Or not, who knows
Rust and Go are both great. They don't suffer from JVM issues like Java and didn't originate as proprietary technology like C#. You can't lose with either one.
>didn't originate as proprietary technology like C#
Is it important how technology originated if it is open source now?
I mean technically go was proprietary technology and then google open sourced it. Like Microsoft did with C#…
What's wrong with JVM? IMO that's one of Java's key strengths!
(Saying this as someone who isn't particularly fond of Java, the language)
None of those points actually mean anything
Docker is the reason why I started running Asahi Linux despite being alpha quality. Asahi Linux (back in its pre-gpu accelerated state) is why I just bought a thicc x86 laptop and sold my MacBook.
mounting something in docker to get things done is a very unusual thing to do and not a common practice for building containers
The Rust Foundation copyright claimed this comment.
I think the author problem is with cross compilation on a Mac to Docker Linux. I switched from Rust to Zig due to this issue last year.
So after taking advice and learning to type, I'm almost at my random style typing speed with correct typing and id say it was worth taking a few days to focus on.
Are there any other super common annoying things newby devs do (like not knowing how to type for example)? I want to iron out these kinks and get a solid foundation. Any suggestions will be taken seriously so I appreciate you in advance 💪🧙♂️
DSA
@@ThePrimeTimeagen thank you 🥳
@@bobanmilisavljevic7857 What is DSA ?
@@tombenham9458 Data Structures and Algorithms. He made a great free course at frontendmasters about it, I recommend!
@@lucass5852 awesome to know. I wrote down that website the other day but now I have a great reason to check it out. Thanks for the help 💪
The only go projects at work are kubernetes controllers. They take an awful long time to build, like several minutes on our CI agents. But this is probably because you essentially have to build the whole k8s API?
I loved the live beep sounds. 😆
When RUST becomes hard? I mean when started reading "THE BOOK" everything is explained so well and not so complicated.
Does the hard part comes in a large code bases or something?
The Borrow checker seems so simple and elegant way to handle memory, in a few projects I believe we will not even think about it idk maybe I am wrong.
Is the problem that there might not be good idiomatic way to structure projects and modules?
6:20 Yeah, that's what you do, make a docker volume and compile outside docker.
"JavaScript being a means to Purgatory", that one got me :D. I think Dante would certainly disagree and say, it's more like the 3rd inner circle to hell, followed by Brainfuck and Bracket.
I'm so confused. I develop solely in containers via devcontainers. Rust compile performance is totally acceptable.
Switch from JS to C for frontend.
All programming languages are a memes to an end.
I basically never bother with mocking out IO for databases (and most other things) anymore. I am currently writing Python at my job and use the testcontainers library for that. Even a lot of cloud resources can be emulated instead of mocked (GCP official emulators, AWS LocalStack, third party emulators, etc.). I actually think mocking out your SQL database is a huge anti-pattern especially when dealing with raw queries: There's so much API encoded between your stringly-typed query and the actual schema of the DB that you almost end up testing nothing as soon as there is no real DB with a real schema. ORMs slightly change that equation but not by much.
I feel this. I considered mocking a redis container to speed up tests but then quickly realised that the most uncertain part of the code under test are my redis calls. Am I removing from the correct end of the list? Am I selecting the correct number of elements? Etc.
I hope Primagen (or Primazen?) maintains his Xust (intentional) craze after 10 years. Rust, for my purpose, is an unsolicited distraction. I don't look for advice from Rust zealots. There are books for that. I don't want to listen from ten thousand fanboys why I should stop doing everything other than writing code in Rust. I didn't ask for any counselling. Maybe, I'm a hobbyist who plays with electronic components. The beauty of a programming language is not expressed by how many bells and whistles it puts together that fall apart every now and then, here and there. A programming language that allows creators to readily express their vision by allowing them to put together all the small elements of logic they build up inside their mental map, a language without hidden overheads is perfect to work with. As for bugs and vulnerabilities, they either happen in the compile stage or at the runtime, of which the latter is unpredictable. Neither of the cases is unprecedented in any programming language. Bugs and vulnerabilities are faults on the programmers' part. It is the duty of the person who writes the program to follow standard practices from the beginning and iron out inconsistencies once the project is complete. Rust won't make the logic of a solution magically better. A language that limits the activities of the programmer is not offering much extra from the existing ones. That is the duty of the programmer. Rust is relatively easy to learn, easier than learning C++. It does not have the nitty-gritty details of C and supports Unicode out of the box. Rust has better mutable/immutable variable concepts, confusing array/unappealing loop structures and a wonderful concept called borrow checker. Rust should never be someone's first target while learning to program for the first time. If someone chooses Rust as his first time programming language, he will learn Rust, not how computers work. Every language has its quirks. A language like C has libraries for almost all fields imaginable and compilers for nearly every CPU architecture that exists to date; Rust is slowly catching up with a long way to go. Nevertheless, envisioning all the things in the world will get oxidised at room temperature even those that aren't ready to react with oxygen contained in the thin air is frivolity without consideration.
In Calcutta, the temperature is 42 degree Celsius. Sorry, we don't measure in the FPS standard. Is that weird? Not sure! The relative humidity is 73%. It's getting very difficult to type on a tiny screen.
One thing I have in mind that I'd like to express is that I don't have any problem with Rust. I never liked it, I never disliked it either. Simply, it's not the be-all and end-all solution to every problem. People have other problems, too. I can't put up with Rust apologists, they can't put up with me. Either it's my problem or it is theirs or both. Now, thousands of Rust extremists will jump off for a holy battle.
The prime has real physical books!
of course!
@@ThePrimeTimeagen I just ordered your book :-)
Considering that Rust is the only programming language with a political ideology, I will steer clear of it.
Less a political ideology, and more just explicitly saying "we will exclude those who are intolerant of others so as to maintain a healthy and welcoming community"
if you fire up a Common Lisp interpreter, one of those implementations draws an ascii menorah
@@worgenzwithm14z based
Everyday I learn how little I actually know about software engineer
Web developers and rustvestites like to circlejerk about their abstraction layers. You can safely ignore everything they talk about
You will be pleased to find about Vlang... which is like baby between Go and rust
Rust this, Go that. All I want is tendies, cute girl and a place to enjoy them (own a house)
THis guy has a great personality but almost takes away from the articles with too much personality. I lose track of what its about.
I would say that is what got him here, you should watch the stream sometime 😊
@@bitcode_ right I do agree that there is probably a mathematical balance of percent personality vs percent content. Personality grows the channel while content would be the focus. I guess content would be unimportant and at 20% of this channel.
fwiw I once tried to build a js project sitting on my host in a wsl container (it needed an older node version) and the performance was horrible because (if i'm not mistaken) the folder was mounted with some slow network protocol, and it had to read tens of thousands of files in node modules.
I like to pretend that Prime makes a newbie like me feel comfortable with asking questions to critically problem solve problems I didn’t know I could have. 😂
Alas, seeing all the sources I have for Go and Rust, I am choosing Go.
But it is on my bucket list to make a programming language, and I like the concept of a borrow checker. Life is just a lifelong learning process, with that said I expect to learn both lol.
But time go to the IDE!
:) get it!
Thanks for the video. I can't find that article anymore.
Hey prime, can you talk a little about how do you read the tech books (I mean how do you get the most out of it and learn the stuff init), great videos by the way
Bleeping R*st at the end is so brilliantly passive aggressive
Prime, can you start a service where you read us medium articles? It's the only way I can get through em'.
Do you mean JDSL? Glad it’s gaining more mainstream popularity.
1:49 It was GraphQL shortened as GQL
On Mac OS i find rust compilation inside a docker container too slow. I got a humble 2012 Macbook Pro, now I installed Pop Os Linux in it and using it for devel, much better 😁
It feels more like the guy was short on time and picked up the things that works for him without need to learn/invest more time into something before starting doing actual work.
Following up on the pronunciation of GQL: Like in the acronym GIF, the 'G' in GQL would make "Gah-Quill" the correct pronunciation, rather than "Yee-Quill"
9/10 times I'll choose Go instead of Rust for a server language.
However, this guy's article is more or less garbage full of non arguments
Maybe I'm mistaken but I seem to remember support for virtual mount on m1 is bad...
The container thing is nonsense, if you mount your project directory as the workspace any updates you make will propagate into the container.
I would suggest to use docker-compose volumes for solving the issue at 6:25
Going to guess that its beyond slow. The mac file system is hard for I/O with docker.
@@nsk8ter524 i get good i/o performance using virtiofs on docker mac m1.
@@nsk8ter524 I didn't use it with Rust but I used it for Java with Spring Boot and it is pretty fast in M1. I also tried to develop using the same setup on Windows, but it was TOO slow.
I try to always use Linux but I was forced to use Windows on my last job and it was painful.
8:53 Also Dart, Angular and Lit WCs.. :P
I find myself using Go over Rust when a library I need doesn't have Rust SDKs and I'm feeling too lazy to write a lib myself. Go is still great for backend but just isn't quite as fun to write as Rust, I don't feel as accomplished afterwards.
reasonable
“As acomplished” wtf is that even mean
@@alkolaqi83 It means what it says? There are two reasons why, one of them should have been easy enough to infer from my original comment.
1. When I'm not being lazy or needing to get a POC out fast, I take the time to write the lib or create the bindings I need when they don't exist. So I'm literally acomplishing more.
2. I'm less familiar with Rust and when I do write it I try to do things I haven't done in the language before, so it's more work.
Time to start writing that go,dart,and carbon so google ai overlords happy
nowadays heard rust hate issue, so many told us to not use rust, and Im gettig so suspicious.
What's the rust book that you showed briefly? Is it beginner friendly, I've never used rust before but wanted to try it, also do they have an online playground similar to golang?
I thought they do?
PETITION to make the reading prime reacts to be prime reads and visvual things should be prime reacts as it is RUST AND VIM ARE BLAZZINLY FAST
"JavaScript being means to purgatory"
This is the kind of "knowledge" that feeds AIs😂
its actually jekyll. I am usubbing from twitch right now. ha ha. I act went from go to crab langauge (custom framework and then actix) and all of his points seem nonsensical to me.. Maybe I should write a medium article on Rust(TM).
Disclaimer: Comment not sponsored by rust foundation.
Yep, that sounds about right
I previously wrote a comment which was recently removed, could I please know why? It was a just a simple question about the author's setup.
Today at work I deployed my first Rust app!
much excite!
How about using sccache as a rustc wrapper? It keeps an artifact cache like ccache, and can speed up compile times.
I fixed my Rust compile times by just buying a top-of-the-line AMD CPU. It crunches through that code like nobody's business.
Being a Rust developer also means that I'm earning enough to be able to afford that.
no
one
asked
I asked
And what cpu that would be
@@sumansaha295 5950X in my case
There was a similar issue a month or two ago on r/rust. TLDR? Docker bind mounts on anything but Linux suck ass. The person we talked with experienced something like 15x slow down when building in a bind mount.
I bought zero2prod because your flashed it on screen in another clip. The book is amazing.
The king returns
You wanna be a good butcher? You gotta sharpen them knives at home.
I am willing to try to use only rust in front, back, back-front, front-back and arounds. And I am still learning. Am I mad?
If your goal is to learn stuff? No, not at all.
If your goal is to have a product that multiple people work on, just a little bit. But we're all mad here. You must also be mad, or you wouldn't be here... :3
GEEEE KWELLLLL
Nothing like a nice Monday morning geekwelll
@@ThePrimeTimeagen geek wheel
Babe, wake up, it's ThePrimeTime.
did he just spend 40 minutes saying "jkweel"?
"All programming languages are means to an end."
Some are memes to an end. 😛
Why aren't your past streams available on Twitch anymore? Until last week I used to watch them (often the whole stream) whenever I got time for it, which is seldom at the same time you're actually streaming. Now I only see a handful of short clips. Makes me pretty sad as your streams contain a lot more interesting parts than what you post here on YT. Please re-consider & make them available again. Thanks!
(To elaborate: on the "videos" tab there _all_ filters safe for the "Clips" one contain no videos at all. Not a single one.)
I just realized that Prime presses a button to make the R and other F words censored.
Gee-Quill like See-Quill
cargo chef, next
: Bust.
fucking love that book
6:26 Shared compile cache with something like sccache?
Nice video about Ru**, I mean Go
You don't need to run everything on docker, just your dependencies..
Is cargo-wharf outdated ?