Makes me believe most the devs that push this are juniors. A few seniors might give it a go but most know how god awful same language rebuilding is, let alone new-language building is
Just this fact makes me realize that most of those that use Rust and do that are completely green and inexperienced. Because otherwise they would know, re-writing any big thing without very good reasons more often than not ends in pain, new bugs and waste of time.
Nah, they are a way more mature community than JS children’s playground. PHP, .NET, Java are the technologies that actually keep the world going and get shit done
People need to understand the market segments rust is appealing to, mainly systems programmers… if he wanted a performant, compiled, garbage collected language he should have just used go. But he fell for the RIR meme and then wrote an article about “if only rust had a garbage collector”, which for me is the same as “I’m so mad my car isn’t also a boat”… it’s a different product for a different market segment …
@@chockman3833 If only Assembly had automatic garbage collection. Why aren’t lifetimes handled automatically by x86? The syntax on these vtable allocations are just too much sometimes.
@@houstonbova3136Assembly doesn't even handle the stack automatically lol I don't know if this is a genuine joke (I am assuming it was), but this is gold 😂😂
This. It's basically like an RPG where you can choose your archetype. *The Profiler.* Wielding your GC language, concurrency and threading are easy and often quite performant since you can rely on your (bytecode) compiler and runtime crafted by the highly intelligent elders. As you start to optimize, you will learn to work around the GC in order to minimize allocations and cleanup, and deploy tests to guard yourself against race conditions. *The Debugger.* As a scholar of the arcane C++, concurrency and threading are easy with smart pointers and copies, albeit at the cost of performance. As you start to optimize, you will learn to tame race conditions, crashes, dangling threads and nasal demons summoned from the realm of undefined behaviour. *The Compiler.* Similar to _The Debugger_, concurrency and threading are easy using reference counting and cloning, at the cost of performance. As you start to optimize, you will learn the way of the borrow checker, using your knowledge of pinning and interior mutability to refine and refactor your programs until all errors are quenched and the raw performance of your code is unleashed. ----- Overall, they are fairly balanced. If anything, _The Compiler_ sucks at low to mid levels, while _The Debugger_ is prone to blow up himself and their whole party, specifically in its older edition versions... ...i'll see myself out.
This. It's a bit like RPG archetypes: *The Profiler.* Wielding your GC language, concurrency is easy and often quite performant since you can rely on the (bytecode-)compiler and runtime crafted by the highly intelligent elders. As you start to optimize, you will learn to work around the GC to minimize allocations and cleanups, and implement tests to protect against race conditions. *The Debugger.* As a scholar of the arcane C++, concurrency and threading are easy with smart pointers and copies, albeit at the cost of performance. As you start to optimize, you will learn to tame race conditions, crashes, dangling threads, and the nasal demons summoned from the realm of undefined behavior. *The Compiler.* As with The Debugger, concurrency and threading are easy using reference counting and cloning, at the cost of performance. As you start to optimize, you will learn the way of the borrow checker, using pinning and interior mutability to refine your programs until all compilation errors are vanquished and the raw performance of your code is unleashed. ...I'll see myself out.
I think async syntax may abstract a little too much for the beginner, which means there's a performance hit they may not be aware of. From what I recall, adding async basically turns your code into a state machine.
Rust can be simple. For example, you probably don’t need generics or lifetimes for your use case. Your application is not a library and so it’s ok to be ad hoc and repeat yourself.
but when you try to build something atleast somewhat useful, you start to use frameworks and libraries, which are often over-engineered, so your code also get over-engineered pretty quickly
@@curio78 most applications are trivial and small. Huge projects are the few. A company may have a couple of big products or a platform, and 10 or more internal tools that are just forms or non-critical data processing apps. This "real apps are complex" is only true if you are making something actually complex (optimization of geometry for CNC machines or whatever), or the software changes for several years
Acually catched this article on medium before you covered it, the whole time I was reading it I was thinking about how you would react to this article, haha.
Well, it really depends on what your priority is. If you want to get something up and running quick, Rust is a terrible language. In fact, it could quite possibly be the worst language for that. Developing with Rust is slow. It writes safe, fast programs, but your code has to pass a lot of strict compiler checks.
@@taragnor I don't think it does. Javascript is the worst language ever invented as anything other than a joke and shouldn't be used for anything. There are other far more usable languages if you want something done quick.
@@isodoubIet Vanilla JS is terrible. Typescript is okay. It still has warts from JS (which sucks), but can do some of what Rust can, with a similar syntax for generics. You can even do some Rusty abstractions and code in Result and Option return types instead of relying on throwing. It's async is also relatively similar as well to Rust. Speed wise it's also not that bad for a scripting language. Python and Ruby are much slower. If the plan was to never port the system to Rust, I'd probably say they'd be better off choosing Go or C#, but the TS version is basically just a prototype design for an eventual switch to Rust. It's an okay choice. It's not the only choice, but I don't think it's awful.
@@taragnor TS is slightly harder to use incorrectly but it's still the same fundamentally borked technology. Getting the wrong answer faster is not an advantage. But all that aside, the guy didn't conclude "TS is better for developing a throwaway concept that I'll rewrite in a real language later". He concluded "TS is better _in general." This is a take so wild it has yet to be contacted by western civilization.
Going out of the "GC world" into a wild universe of self-managed memory can be akin to learning to breathe manually. Rust attempts to solve that issue by stunning you with a cattle prod every time you fail to take a breath on time (or take a breath when you weren't supposed to). This works for some people, but not for everyone and not in every situation. In its defense: it's not like there are no warnings about it... like, at least half the articles I've read on Rust before giving it a try were very explicit about how hard and frustrating it can be.
I don’t think that’s a fair comparison. The cattle prod stun would be panicking at runtime. Rust doesn’t even let you cross the door to take the breath outside. It’s much better to fail many times at compile time than to fail just one in production at runtime. Every one of those compile time errors would be a bug in a different (memory managed) language.
"I'm using Rust because the interwebs said it's fast. Also, I can't be bothered to spend 30 minutes to understand my own code without an LLM present." Pro tip - performant code in any language requires careful work by someone who knows WTF they're doing.
Can you expand a little about your problems with TS? I do Angular in my day job, and I've been using my own Result type, and it has been alright. Not as nice as Rust's but better than throwing exceptions around.
This guy is pretty infamous in the Rust subreddit. I obviously can't know what's in his heart-of-hearts, but every article he's posted has been pretty sloppy and transparently just advertising for his AI powered finance tools. I distinctly remember one where he claimed to have forked and "fixed" a finance crate, to the point where it warranted an announcement on the subreddit. But, all that he'd changed was a single statistical function to give a different result (that he preferred), and then deleted all the documentation and made himself the only author on the crate. In every interaction I've had with him, he's come across as quite unpleasant.
I “fixed” the finance crate to have a radically different design and fixed a bug. I deleted the documentation because it was outdated with the radically different design. Old design: put in a number (like 5) New Design: put in a duration (like 5 days) Apologies if I came across as unpleasant
Most articles criticizing Rust (including the one you mention) usually end up saying something along the lines of "C++ is better for my use case". That is a reasonable take. This article says instead "typescript is better (in general)", which is a troll take at best.
I think that once you understand what the different pointer types in Rust do and you know the reason for their necessity it gets much easier to read the types because you're not that lost anymore. Step by step its really easy actually. FnMut is a function that can mutate some state inside itself. It takes an argument that is a mutable reference to the ClientSession. and returns a pinned value. Pin just says that the value with type F cannot be moved to another memory location. This is to ensure that from one thread to another the memory location always stays the same. Box just say's that whatever is inside the lives on the heap. dyn says that you can use the api that the trait Future provides. Future is a pollable object that waits for some asynchronous operation to be completed, the of which is just a Result that can either be of the type R which must be Sendable across thread boundaries and have a 'static lifetime which means that the value lives for the entire lifetime of the application, think a string thats embedded in the executable. And then the Result can also be an error in which case it is a String that probably tells the caller of the function something about what went wrong. You really have to break these concepts down and try to understand them bit by bit. At which point you really do get faster at reading and understanding these types. You also learn what you need to skip and exclude from your mental stack so to speak if you only want to know what the function does and not why it is technically necessary to do all the pinning and fnmutting business.
Dude I've been using Rust for like 3 years straight, and I don't know what any of that stuff is in the beginning of your comment. What use case are you building for? What does it do? I find people use so much of Rust and I barely use any of it. Why don't you just throw everything complicated into an async thread and have it send messages back to the main thread and self terminate when done? All this pointer stuff I hear about sounds like trying to walk a tightrope. Maybe I'm an absolute moron and this is terrible, but I stopped learning Rust when I mastered handling everything async. I use it all the time, everywhere. Hundreds of threads at a time for each agent. Async threads starting and awaiting more async threads, on and on and on. Why not? I don't even recognize any of those pointer types. Honestly, I don't even know how a pointer differs from a variable name. I guess I'm a caveman, or cavecrab. I don't know, hitting everything with a club just works. Don't fix what ain't broke. My code runs faster than I need on 10 year old android devices I use for servers, so I've never looked into perf. There are so many rabbitholes in Rust, and I'm not scholarly enough to handle a lot of it, therefore, so much of it is just engaging. Sometimes I need something, and I go to The Book, and I return enlightened, but some stuff Rustaceans do regularly is just too much for little old me. Number types: I don't even use those different number types. Holy hell, why so many options? I want a number!!!!! I don't want to have to think about how big the number might get, and then select the right type - which I always have to look up because I didn't go to college and I refuse to memorize extremely random and long numbers that are related to the number (which is always a product of 2^x because computers) attached to either the letter "u" or letter "i" which for some wild reason link to two totally different, super random numbers (which are also always a product of 2^x because computers), and only one of them allows negative values because... drumroll, please... computers. I just want a number! How is that so much to ask for? The number types alone make me feel like I'm doing my taxes. I get triggered like Big Red when I see those types. There's "int"/"float" or (my favorite), straight up "num." Everything else is the damn computer's job! Am I a programmer or a mathematician? I failed Calc 1 four times, I came to programming because I thought I was safe from my one weakness. But that's my point. You know all this stuff about Rust, and you're probably better at it than me, but Rust is as hard as you make it. I feel like anyone complaining about Rust is trying to write Superman-Rust. I know a small sliver of Rust as well as I know my name, and that's all I've ever needed. I just can't comprehend people freaking out about using all this stuff. They're doing it to themselves. You can do so much with so little of Rust, and then you can improve pieces that are bad. I used to use Arc stuff for everything, but it got annoying, so I mastered multithreading or whatever it's called. Now I don't have to worry about all this locking insanity. There's so much in Rust. It's ridiculous to try to know even half of it. Last - but not least - I don't know a damn thing about lifetimes. I don't even know what they are. *mic drop*
I can't edit replies, so commenting again. Question: is it really that big of a impact to send the data as a message versus using those pointers? If so, what in the world are you building? Are you dealing with Google-level i/o?
@@GrizikYugno-ku2zs Your point is extremely valid. You can avoid a lot of the complexity associated with the lower level abstractions that rust provides by using higher level abstractions. But these higher level abstractions are often built on top of the lower ones to offer the safety and efficiency you expect from rust. But as always in engineering everything comes with a tradeoff. if you've found a way to program that works for you, thats awesome man more power to you but also keep in mind there have to be those that build the use case specific abstractions for everyone else. I am very curious about your usecase for "just a number" because there could be several solutions to your problem. You strike me as a domain level problem solver.
@@GrizikYugno-ku2zsI've never touched Rust, but for the different number types (which are common in most if not all languages): it is all about memory space efficiency. Why use 64-bits for a number when 8-bits will suffice? -- if you have an array, you can store 8x more "numbers" in the same amount of RAM if you can get by with "8-bits" vs "64-bits". For negative numbers: you eat one bit to store the negative sign -- if your value can never be negative, then use one of the unsigned number types so you double the size of the number that can be stored in the same amount of bits. These things just make more efficient use of the underlying hardware. Think of them as "hints" to the compiler so it can make more performant and memory efficient code when it executes.
One of the many things I love about Prime is he explains things - e.g. "shadowing". If I had the time I expect I could watch Prime learn (and stream) a language and end up understanding all the "what's" and "why's", just because he'll explain things if you ask. One of the best teachers I've seen, and I haven't even watched his courses yet. 🤙
@@Takyodor2 Right? Primeagen once talked about how you get into someone else's code and you think "oh, this is crap." So you start to rewrite it and as you encounter all the edge cases, your code looks more and more like the code you thought was crap. lol
For 95% of programmers code performance is actually not really your limiting factor. As long as you avoid accidential N² loops, your programs' performance is going to be limited by database access times. That is why gc languages are so popular. The right tool for the right job.
@amoskevitz The problem is, that's not true. It's not 95% of programmers, it's 95% (or more like 99%) of code. The problem with that is that for the remaining 5% you need a solution too. This is why you shouldn't pick your programming language based on the problem (unless you're happy with FFI); instead you should pick a programming language that supports the largest number of different paradigms and tools (like how rust supports both Rc and RAII for the different use cases).
@@thanhle-du3or when you can ship an MVP in a year rather than 3-4 years, then you can see how rapid development is more important. You don't need the utmost performance, so prioritize other more important things. Circle jerking all day about Rust or C is fine and all (not), but I'd rather get more done and optimize later. Rust evangelism won't get you from A to B faster when writing software.
that “rust is haskell dressed as C” imo is very wrong, when getting into crazy types like that, Rust is MUCH more difficult and unintuitive, if you think you can extract a closure into a function with parameters you encounter problems, if you try to do the opposite you also do, and as “friendly errors”, still they are considerably difficult. In haskell you are much more free to do that sort of stuff.
bro just used interface{} in the go example to not deal with any types, that is like throwing any everywhere in typescript and it does not help with your case man, this guy is so javascript brained
Swift / iOS Dev is also cult like.. now that I think about it, all fanatics of a language normally trend towards their language… which is really the point.
I feel like the fact that apparently their first version was written in TS of all things isn't really a good sign. Makes you wonder what exactly they're comparing it to.
You have to start somewhere. And first versions are usually written in popular languages, not languages that are good for the job. Maybe Go would have been better for this. But the borrow checker witnesses are everywhere and ringing the door bell to talk about Rust.
It took me a long time to learn the patterns and mindset required for Rust, and I'm still taking my time to learn it all piece by piece, but IMO it's been worth it. Perhaps it's just how my brain is wired, but writing Rust is incredibly satisfying for me. With any other language I am terrified it could spontaneously combust if there's weird data, whereas with Rust everything is clearly laid out, defined, and it all does exactly what it says with no edge cases or strange arbitrary behaviour. Honestly, it's mostly just personal preference and good teachers! Rust is really hard to learn. People will say, "oh but there's the book and tons of nice videos and written tutorials" but this really doesn't teach you the core of what makes Rust code different. Just preaching how cool it is does nothing, and while the learning resources are accessible, they do not help write the mental patterns that are valuable for writing Rust code.
I don't _love_ Rust, but I like it a lot more than C++. It also took me 6 months to get to grips with the borrow checker.. and even after that I scratched my head at some borrow checker corner cases. I think the language is somewhat unbalanced. Extremely verbose and explicit when it comes to integer arithmetic, for instance. Yet when it comes to references, it's all very implicit, and abstract. Zig has way more concrete terminology like "comptime". I think in that regard, Rust did miss the boat a little.
@@alwin5995 What "hell" are you speaking of? It's literally one of the easiest things in the language. Unsafe manual memory to interface with a C-FFI on the other hand is real hell, but needed.
Thanks for sharing your experience. How did you originally get into it? And in what projects have you used it so far? I've also heard several times now that it speaks to a particular set of people because of it's very stringent bottom up approach.
@@LinkEX I originally got into it because of a friend's recommendation. Didn't think much of it for a while, but I came across NoBoilerplate who made some excellent videos on the language and I was hooked. It was a while before I had the chance to really make anything, but I had fun when I did get the chance. Now I focus pretty much all my coding time on it, I'm working on a game with the Bevy engine (which taught me some very valuable lessons about program design) I would say to really just go for any kind of project and get a feel for what kinds of things you like doing with it. I recommend making some simple terminal programs that process files, handle user input, etc. first, then moving onto some larger stuff like API interactions or whatever you fancy. I will say that Rust expects a very specific kind of code. It is, generally speaking, "good code", so if you are doing it wrong it will be far more painful than most languages. You will have trouble trying to hack things together, whereas refactoring and laying things out will be extremely easy once you have an idea of what the structure should be. Also, if you are having trouble with lifetimes, I promise you that it is 100% possible to entirely avoid lifetimes unless your algorithm specifically requires manipulating them. Do not fall into the trap of adding lifetimes to everything and letting them corrupt your entire codebase, just try to re-think your solution and you'll find a way.
My own response to complaints about the Rust community, would be to cite my experiences with the World of Warcraft and No Man's Sky's player communities. World of Warcraft was a game which was highly competitive; during classic World of Warcraft, Naxxramas, the endgame dungeon, was sufficiently difficult that less than 5% of the overall playerbase was able to even enter it. As a result, WoW had a playerbase that was much more inclined towards elitism, and influenced by the immense competitive stress that that difficulty caused. No Man's Sky, by contrast, is the complete opposite. It's an almost exclusively PvE game with no elite or end game content, where resources are infinitely abundant and renewable, and where everyone can obtain anything. The community are correspondingly far more relaxed, friendly, and welcoming. When someone encounters a negative community related to any particular interest, therefore, I think it's important and constructive to realise that there are almost always structural variables which incentivise said negative behaviour; and that rather than simply complaining about said behaviour, it should be realised that if the structural elements are modified, the behaviour will improve by itself.
My favorite anecdote in terms of wow elitism is how at the end of Wrath with all the catchup mechanics the game was so accessible that everyone had amazing gear and everyone was "uh, i'm so great but all the noobs got my gear, so wish the game was harder" and Blizzard listened and in Cataclysm the same people whined that heroics are too hard.
I would say that the issue with rust is that some principles and good things make it look perfect while it's not : its use-case is not for everyone and it's not easy to jump to from any language. Because some Rust fans don't see what issues Rust has, they (a part of the community) don't explain problems that can happen in/with Rust and thus they attract a wrong audience. They really don't understand what issues people have with Rust and thus blame the people instead of helping them. Fans of Rust mostly can't see the difference between what people expect of a language and what Rust does. Between those fans, there are probably a part of inexperienced people (because it is a new language with growing community).
They laugh at us, and say we're at the bottom of the pyramid. But then we hit them with blazingly fast libraries written in C for the small but performance-critical parts of the code, and we suddenly got the holy trinity of speed of development, runtime and readability where it matters. 🐍📈
Also, while it looks horrendous at first what's so difficult in it? It's very clearly saying its intention if you spend like an hour or so to read the documentation of Pin/Box/Future/Send and have a basic knowledge of Rust. It becomes pretty self explanatory what that type composition meant to do...
@@balint133 Pin is not easy to understand at all; not only for humans, but also for the compiler itself (getting compile-time stack overflow on Unpin check isn't that fun); it might be "basic" in some uses, but absolutely not so in reasoning; that's why [Local]BoxFuture and async-trait exist: you just get something that 1) is a future 2) can be created from a future 3) captures lifetimes somewhat correctly 4) is a concrete sized type 5) *but*, not so conveniently compared to proper async fns, either requires you to either put Send on generics involved or can't be used with all runtimes so instead of dealing with all of {Pin,Box,Future,Send,dyn} you just need to think of Future and Send and Pin just becomes sort of an implementation detail oh, and also, it's way shorter and easier to read and write without sacrificing clarity, which is The Reason why alias form is preferred
@@tempname8263 I just opened the language website and there on the first page was a drop down with a bunch of examples. I have no idea why more languages don't do this.
@tempname8263 I just opened the language website and there on the first page was a drop down with a bunch of examples. I have no idea why more languages don't do this.
"BeefLang" I just opened the language website and there on the first page was a drop down with a bunch of examples. I have no idea why more languages don't do this.
In terms of higher than C++11, anything bigger than 11 has all the baggage of everything 11 and before. There's a lot of artifact foot guns built in to the reverse compatibility. The one horrible/great thing that came after Java 8 was that they were willing to just kill the unsafe functions and force people to update or stay in the old unsafe version.
Yeah, the fact that C++'s STL has this huge ball chain of forever backwards compatibility is what causes all those footguns, esoteric best practices, random terrible performance, and inconsistencies.
Yep, and safety is still opt-in. When you put me in charge, I'll just throw safety in the wind, and this will come back to bite me later. I'm a lot better of with Rust than even modern C++.
@@earx23 Unsafe code is just one aspect of "bad code". Rust won't prevent you from writing bad code. If you can't stop yourself from writing bad code, you need someone else to guide you until you can. Regardless of language.
Come wrote code for Google which is using c++20 with additional guidelines to ensure good code quality. They have annotations to ensure better thread safety when using mutexes and tons of other tools and code style guidelines to help. Still getting segfaults and other issues very often. It's not nearly as water tight as Rust.
Ok "skill issue" isn't actually a counter-argument to "I have issues with how difficult it is to learn how to use this tool properly, and as a result I do not recommend this tool."
“Just give me the garbage collector” perfectly sums up how uninformed this man was before choosing Rust. People choose Rust for performance and security because their difficult compiler forces you to write secure code while still granting the flexibility to be fast. This article 100% reads as I didn’t understand the idioms of the language I chose to work in and it’s Rust’s fault not mine.
How many times have I heard "We chose Rust for it's safety/types, not for its performance!" on twitter and in different articles... Furthermore, Rust evangelists generally advise to use Rust for everything. At least that has been my experience. I am soo close to muting the word Rust on twitter because of how much I hear about it, wanna guess how many of them preface with "Only use this when you need absolute performance"? Correct. Zero.
@@secondson4536 I'm using rust in 100k lines codebase, and not for performance, but for correctness and I'm very happy with it. best decision I've made. He defintely had skill issues. I did have struggles in previous "side projects" trying to learn rust over around 2 years (was working in TS in my main job), only when I was confident with my skills did I start with a real project. He jumped straight in and got destroyed, and now blames the languages, yes, Rust learning curve is steep, nobody is denying that. if you want easier language go with Go. but don't blame your incompetence on the language.
Also so many people saying how Rust is great because of all of those features, which normally have nothing to do with its speed. Yet when it is critisized people like you show up defending bad parts of the language (that are omitted from those praising articles) with either skill issue argument or the "Well its speed is why it is like this". Here you don't get one of the main points of this article: nothing really told this person about those bad parts, as though they don't exist. This person, probably just like me, heard from every corner of programming fan infested internet about how Rust is great with approximately 0% of them mentioning parts where you might encounter some issues.
@@secondson4536 I mean if they read the book they would have realized that it wasn’t going to be as “easy” as they had hoped for. I don’t know a single person who doesn’t recommend the official book as a first learning resource. And I’ve know plenty of people who have struggled because they refused to read it. In no way am I saying that it’s a perfect language. I’m just saying that the complaints this particular guy is making are in complete antithesis to the objective of the language itself. So stop putting words in my mouth saying that I’m claiming things. I understand his points. I also understand that he completely missed the point of Rust and is now painting it as a problem that anyone who bothered to learn what Rust is about before refactoring their entire project in it would have understood.
@@secondson4536 I'll give you one example so you can understand that it is really a skill issue. Async programming, there is several options such: regular threads model, green threads, minimal stack async , or eventloop, now each language chose its model. Go went with green threads + gargage collection, the downside is you have a larger stack for each thread, and the runtime is backed into the language, and obviously garbage collection. nodejs went with eventloop, where each task is blocking the whole thing ..... EACH language made compromises, there is no perfect solution. Rust made the compromise of no garbage collection, and minimum runtime, and so we ended up with this version of async, which consumes very low memory compared to others, very lightweight, but has strict rules to follow, such as Pin, which is basically helps moving variables between each async operations, but in order to understand all of this, your really have done the work, and know a lot of concepts of computer science, this is engineering, you need experience and know how, Rust is not a beginner friendly language, I would never suggest Rust to an average run out of the mill software developer, which are the majority unfortunately. I chose Rust knowing full well the downsides, but I need to parse large files without worrying about OOM, and to handle many clients without paying thousands per month in hosting, and to be able to deploy several times a day to production without worrying about breaking stuff. Choosing a language means evaluating the tradeoff, you can't chosse a language if you don't have the tools to know what those tradeoffs are. For context I've been programmig regularely for 15 years, and started dabbling with Rust in 2015. I'm not saying Rust is without flaws, but it is stupid to expect that there is a language that doesn't have flaws, and it is more stupid to expect the language authors to present design decision as flaws, when each language made those decisions thinking they are the best for them. they may not be for you though.
Algorithmic trading != HFT (high frequency trading). HFT uses algo trading, but you can trade slow with algorithms as well (and is done with virtually all institutional trade orders).
5:20 the biggest problem with Rust & async is that Rust _still_ hasn't cleaned its own house up about it, meaning it only very very recently has decided on how to do async functions in traits. That's a big problem because its standard library still hasn't fully caught up to it. & even its very latest release still doesn't seem to have closed the issue entirely as there are still corners which are unimplemented / causes compiler bugs when combined with aliases to traits which are sync but are aliasing async functions.
Yeah it all feels very "work in progress", but I don't envy the ppl that work on trying to solve this. Rust has to type check, memory lifetime check, static dispatch for generics (and probably more) all at compile time, which is hard enough to do for strictly synchronous code. Imagine the nightmare trying to create a standard solution for all these constraints in an asynchronous context, whew
I needed to make a CLI program for my company that covered quite a few data processing and report generation bases that was fast for invocation on servers. Of the selection of native-compiled languages, I went on a tour. The guy before me had already worked on a prototype in Rust. I tried to continue working on it. I went from positive on Rust to wanting to die QUICK. Eventually I settled on Nim. Remaking the program was EASY. New features are EASY. Refactoring is EASY. I ROCKETED past the old featureset the company had languished in for 20 years. I have never before worked in a language that has made my life this damn easy while producing executables with a speed that'll knock your socks off. I experimented with D back in the day and it never got CLOSE to Nim. My job is a JOY because of this damn language and I never want to go back. My rule of thumb: If you're not embedded, you can probably let a GC/RC do the hard work for you, and scoop up the advantage of not needing to write a line of memory code ever.
i hard agree, I've been porting a lot of my company's internal tools made in python 2.7 to nip and ive never felt this good about my code lol, i could optimize the code off of my head and seeing it actually made me smile
Sounds like a problem I faced but they forced scala on us out of the blue. It turned over half the staff within 6 months (including me) as one by one we simply rejected the idea. The most experienced people left first. Not only cause they interview better but because they spotted the obvious issues fastest. I was 2nd to leave the office of 50 people after 8 weeks. The other 20-25 left over the next 4-6 months. I only found out about it because I ran into somebody a year later who still worked there. After 8-10 months of this they did the entire project in python in 2 weeks. Some of these new "fancy" languages just don't work as well as people think they do.... Ironically I also hate python but at least I can get stuff done with it. How to confuse a python programmer? Ask them to show them a for loop. (Hint: python doesn't have the ability to do one naturally, it needs to use while to get the same result). Works even better when somebody does the loop with range btw :P
@@slider799 You can use for loops just fine in python. They're just wrapped in iterators (IE, range(), tuple.iter(), generators, etc.). I feel that python for loops are more similar to the `for (int i : myIteratorVariable) {}` syntax in C++. IMO, this is actually better than the standard non-uniform three-part for loop syntax (`for (variable initialization; conditional; incrementor) {}`). You can do much more with it without having to write nearly as much code. Also, this is what Rust does as well for it's for loops, so it isn't like Python is the only modern language doing this.
@@Kane0123 That mindset isn't good though, because you effectively eliminate your ability to use tools. If you switch between even 2 languages, then any improvements you make for your workflow - whether that's learning a new concept, reading the documentation of a library or learn about / fix a bug in your tooling, etc - will be 50% less effective already. Which is making near all improvement uneconomical. This I think is the reason why so many developers are stuck. Instead of mastering one thing and getting really good at it, they spread themselves thin and have to relearn the same thing over and over again, while at the same time not having the ability to fix problems in their workflow.
You can still implement helper functions in Rust even if you haven't fully wrapped your head around every single bit of its signature. Simply add the bits when the compiler tells you to as you reference the function elsewhere on the code. This approach has always worked for me.
34:54 It's the enthu, Prime. The childlike enthusiasm of discovering something new or finally realizing the potential in something that you are already aware of, it's what makes you an avid learner and a great developer. I wish people didn't lose that enthusiasm over time but they just do, it's what results in loss of interest and I fear eventually Burnout!
Fun Fact: Every human has skill issues. Therefore pointing to skill issues, because programming language is not optimally designed makes no sense. Sometimes, the skill issue is not the actual problem.
This perfectly describes my issues with C++, raw memory access with (until recently) no automated managed memory because "it's something the devs should do" is utterly insane, and not a gotcha for a design flaw. To add to your point, the idea of "skill issue" implies that especially on a team, everyone is 10x devs with no human error and knows exactly what they are doing 100% of the time. Obviously that's not the case which is why most devs try to automate much of the work to avoid these issues (checkers, linters, static analysers, CI, etc)
@@itermercator114 "raw memory access with (until recently) no automated managed memory " How old are you? Automated memory management has been in C++ since Cfront.
@@itermercator114 " C++, raw memory access with (until recently) no automated managed memory" Destructors have been in the language since Cfront. Vector has been in the standard since C++98.
"raw memory access with (until recently) no automated managed memory " How old are you? Automated memory management has been in C++ since Cfront. Vector has been in the standard since 98.
« To master C++, is like mastering Rust » I have never read anything close to such a high level of self-confidence about C++. I wonder whether he’s ever written a move constructor in C++, or even actually moved some data to realize since C++ does not have an affine type system, you can still read and write to the (now uninitialized) memory of the previous object. That kind of hot takes :D
I just started learning Rust and I'm working on a very similar project as the article author - I've landed on channels for a lot of what I want to do within the system and so far, it's working well and is pretty straightforward and intuitive to write. Not having any issues that the OP had.
I was reading in detail through the official tokio tutorials recently and all I can say, is that if you use Pin and you are not absolutely sure why you have to reach for it, you will not finish your project well. Generally it should be possible to never touch Pin. And as far as I understand, the main reason to use it, is to save an async boundary manually, so it doesn't drop for example in a switch when something else finishes sooner, making it possible to re-pull later. It is a too-manual way to manage awaits. Like mutex, it exists only in case you really need it and you know what your are doing. Channels on individual spawns are the way to go.
@@TheNoirKamui I was going to say that but I think in that case he needed to anotate the type to satisfy the trait bounds in the function signature. Technically he didn't "use" pin, he just needed to say that his function would receive a closure that returns a Future. Really its not even that big of a deal, it looks wierd the first time you see it, but then you understand why and move on, OP was beeing very dramatica about it, maybe if the had taken the time to learn instead of asking chat GPT he might have handled it better.
@jonnyso1 You are absolutely right. Considering there was no async in rust just a few years ago, it is amazing that it works. But there are still small gaps with async. For example tokio::join! will let you run 2 async functions that cary a lock over .await giving you a deadlock. Doing the same in spawn gives correctly an error. I remember bringing that up in some tokio chatroom and being told that they wouldn't fix that because it is all as expected and restricting otherwise... I also heard some people criticize the push vs pull model of the polling mechanism... though I don't understand that enough to comment. And lastly, the problem of async runtime lockin, that you can't just transfer your code to another runtime... That you can't just use a crate written for another runtime than yours. Rust async... is in some way amazing and in other kinda... Feels like much more inteligent people than me should think about how to improve it. But there is definitely space for improvement.
At some stock exchanges, everyone gets a fiber connection WITH THE SAME LENGTH AS EVERYONE ELSE. Just so everyone has the same latency to the server(s). It's just madness.
It's very hard to say anything in general about what the performance requirements for algo trading are like because every company is doing something slightly different. There are some companies doing the FPGA thing and worrying about speed of light delays, but there are also companies just running python. Jane Street famously runs OCaml (not super slow, but far from the fastest). There're probably extremely few people who can speak authoritatively about algo trading in general.
@@Takyodor2 Depends, do you want to have predictable prices at the gas station and grocery store? Do you want people to be able to afford to grow food? People think that some guy at work trading stocks on "hot tips" is somehow representative of the entire industry. People working there full time only make money by providing value to their customers.
@MaxHaydenChiz Buying groceries and growing crops worked fine for thousands of years before low-latency trading was invented. I wouldn't mind if stock trading disappeared as a whole, and companies could focus on providing good products instead of making the graph go up, but specifically low-latency trading is on a different level of unnecessary.
I don't understand why everyone just HAVE to write async code either. It doesn't make sense to use coroutines for like 95% of all problems if not 99% (not exaggerating). Why not just do it normal and multi threaded? It is NOT that hard. It is only coroutines that make it hard! STOP USING COROUTINES. You are NOT getting a performance benefit out of it.
@@okseaj The mongodb crate he was using has a massive signpost on the docs about how the offer a convenient non-async api if you flip on a feature flag. If you cant read the docs for the crate that has been ruining you for the past 18 months, idk what to tell ya.
@@leeroyjenkins0 I think this is a problem for people who has worked exclusively (or for all intents and purposes) in a single threaded environment with promises/futures/coroutines. Managing your own thread pool where you post tasks and work to and from is absolutely trivial in C++ and it is even easier in Rust. If you need async IO, use C++ and the OS utilities (epoll, poll, select, io_uring) and real parallelism with multi threading. Not only will your code be much, much easier to read and reason about, you don't sacrifice any performance either. Because coroutines comes with overhead. I think you are right, too, that the appeal is that it "looks synchronous" (guess what, a thread pool where you post tasks and await on the promise also looks synchronous, because you need to collect/wait at some point). I don't see how introducing tokio and async for downloading a bunch of files (as an example) is *easier* than having a simple thread pool where you post a lambda that downloads a file and signals back when it's done. Because the thread pool will not leak into every corner of your application, it will have a crystal clear API-surface. This is not to say that coroutines or async/await shouldn't be used. It works *superb* in JavaScript/typescript land. And it has its use cases. But I argue that is 1 out of a 100 times, if even that.
@@leeroyjenkins0 right, but that's my thing; you can get `const result = read().wait();` using hand rolled thread pools where you post a task and get a future back that you wait on. What's also better about this approach is that the API-surface is crystal clear. This large, obstructive and intrusive system doesn't loom over your entire code base making it hard to reason about, while also making performance (probably) less good, seeing as how coroutines always comes with an overhead. Handrolling your own thread pool and using message passing is trivial in C++ even, it's even easier in Rust (using channels for instance). We have all the building blocks, mutexes, atomics. We have ways of signalling readyness on sinks/channels, using for instance operating system utilities like epoll, poll, select etc. Using these are also easy. And they don't come with the mental context that using something incredibly intrusive like Tokio comes with. But yeah, I think you're right the appeal comes with that it "looks synchronous" but as I said, using read().wait() on a thread pool future is *exactly* that same thing (std::future in c++, I don't know the name off the top of my head Rust, but technically a mpsc channel works just fine here). Add to that that debuggability is many times easier with multi threading than it is with coroutines. Many, many times easier.
We wrote a bunch of our network applications in Nim in a company that has applications in Python, Golang and Rust. Nim beats all of them in terms of developer productivity and run time speed.
You don't use reference counting and synchronization primitives to "get around Rust". You use them because you are implementing systems that require these tools for correctness. They would still be necessary in any other language with concurrency, but Rust forces you to use them for correctness.
They always say it’s a skill issue because they want to see you suffer as they did. Once they overcome that skills issue themselves they will never admit how hard it was or that it is bad design or anything, they will tell you that it is just a skill issues and will take a popcorn and watch ur struggles 😂
I see Rust as largely a C replacement. C would not be my first language to build a trading platform with. It would be my first language to build an OS with. Just imagining writing a UI in Rust gives me nightmares.
@@sillymesilly By replacement, I mean C was pretty much the only language used for systems programming until Rust came to be popular. I dont literally mean C will just go away and Rust will be the new defacto thing
The `thiserror` crate in Rust is really nice for handling errors IMO. You can easily define errors that hold data, so any error where the message alone isn't enough to know what happened, can also have additional context.
My personal view on how nice the Rust community is: Reddit is the most toxic, but also an unofficial one. Discord has their share of toxic members (they increased their numbers after the remaining official teams moved to Zulip), overall very nice and friendly but you can end up ignored because of the amount of message traffic there. Zulip is the nicest and also the official one, I honestly never saw someone being toxic without consequences there. Besides the general community, on the Rust teams, there are around 2 or 3 members that are more prone to torvalds someone (yeah, I turned Linus into a verb), one of them sure did say quite unfair (to say the least) things to you. I did have very nice interactions with them before and I feel it is something like Linus Torvalds (heart in the right place, but can be very extra on particular occasions) and I hope they improve like Linus did in the past years.
17:50 ``` if err != nil { // handle error here } ``` I am surprised that people dislike this form of error handling - it's my favorite. Great point by Prime.
"Handling NULL's and bad arguments is good code." Should not be a hot take, but here we are, hundreds of languages later, trying to escape from: if pointer == NULL { dont_break_everything()}
I agree that C++ is about as hard to master as Rust. The difference is that until you're there, in contrast to Rust, C++ does have a pit of success where you obliviously write code that appears to work but is actually full of undefined behaviour, particularly if concurrency or threading is involved. Note that I really like using C++. But even the newer language features have their gotchas and footguns and can fail in surprising ways if you try to be an ounce more clever than you really are.
@@tinrab I agree that Rust tooling extremely nice and that it has many modern features are that either missing in C++ or much better integrated with the language (enums, pattern matching, interators and first and foremost result types for error handling). But C++ does have ranges, it does have std::expected. Yes, both can be clunky (to the point where you may think twice before reaching for them), but if you need them, they can get the job done. Much of what you do in Rust with macros you can do in C++ using templates, sometimes even easier so. For certain topics, the C++ library ecosystem is much more developed than in Rust-land (e.g. scientific computing, GPGPU), making up for some of the deficits in terms of language and standard library features. Also, while build systems in C++ can be a huge pain, at your job it might be that someone else solved the issue in some way and you don't have to deal with this too much. Or you have one of these days where you just have a project set up with Conan, and you add a library with just a click in your IDE and a single line (maybe one and a half) of CMake, and it just works. If you close your eyes and pretend your CMakeLists.txt is a toml file, it can almost feel like cargo. Now of course it is more effort to get to this point in C++ than in Rust, where these things just work out of the box. But I would argue that the time you need to spend on these things roughtly equalizes the time you spend with the borrow checker. I could be wrong, depending on the project. The true issue with C++ - to me - is that after this learning phase, you can write somewhat defect-free Rust code. Whereas you can write C++ code that compiles just fine, but may be full of edge cases where something breaks. So while the tooling is nice, the real value proposition is that if you are half-decent in Rust, you can contribute to a large codebase without running the risk of creating CVEs or hard-to-debug crashes. If you are half-decent in C++, on the other hand, you are just dangerous enough to write something broken that passes code review. But to really master both languages, I think it takes probably the same amount of time.
@@wolfgangrohringer820 C++ has all the things. Its just its things are spread out more. Rust on the other hand forces you to use them. Ironically sometimes in really broken ways. The worst thing for rust is all the useful stuff isn't written in rust cause its new and nobody (eg me) won't touch it cause it means writing wrappers around 100's of underlying code bases and then pretending the rust safety systems are working where 7 different code bases still own one pointer :) Rust expect a perfect world. We don't live in a perfect world. Last evaluation I did in it. To get it done in rust was $1B+ Costing or so.
I actually like C++ a lot, maybe it is because I'm used to it. And using modern C++ (Smart Pointers, Standard Library, etc.) and a modicum of programming good practices (programming patterns when applicable, etc.) is not difficult at all to write pretty safe and extremely fast code. I am not saying it is more or less safe than Rust, or better or worse, or whatever. But, when people portray it like this timebomb just waiting to misbehave, I just chalk it up to skill issues (how dare I!!!!!)
I think people whose first language is something else than C/C++ cannot appreciate Rust and complain about the way it is. Going from C to immediately C++ to Java to a bit of Python to Rust is like coming back home after long time of being gone.
This. Rust isn't for those high level devs. My programming journey was raw z80 assembler, then raw x86 (not even _64!) asm, then C, then C++. After, I learnt webdev with pure JS and PHP, then some Java for getting an actual job. Here I am coming back to Rust, and actually being able to appreciate it because I *worked* with assembly, I *worked* with low-level embedded C. I *know* what Rust brings to the table and why it's so special. I'm not saying that it's the best of it's kind, but I'm also saying that I'm never programming for a SBC again if its arch has a rustc target. Rust also got me really interested in functional programming with the way that it tries to make everything immutable by default, has everything be able to have a return value, has first class support for closures and all, as well as the traits system mimicking interfaces. Since I know Java, I might want to get into Scala or Clojure. Rust isn't just my new favorite language, it was a genuine awakening. I know that I sound like those crazy twitter rusties, but honestly I get it. Everything feels perfectly intuitive on an abstract sense while also making sense for my low-level old assembly programmer brain. I didn't even know that it was possible to marry these two parts of me.
@@meanmole3212 I just checked Gleam's homepage. So do you hate black people, hate trans people, or do you sympathize with Nazis? This is a pretty low bar for setting a community standard around decency.
@@MrKlarthums Why does the page not say that white lives matter since whites are a global minority in the world and about to go extinct as a result of uneven birthrates and immigration to their home countries, and that black people commit disproportioned amount of violent crimes against whites? Deportation and closed borders matter! World peace and a home to live for all people of the world! Is that statement a problem with you, or with THEM? If so, it seems you hate white people and you sympathize with silent on-going genocide. That's pretty unfortunate since all I am suggesting is that we set a low bar community standards surrounded around decency for everyone to enjoy equally. If you think this is "trolling" or "yep, you are a nazi", then explain to me what in my statement was wrong or trolling?
@@MrKlarthums Why does the page not say that v\/hite live5 m_4tter since whites are a global m1_nority in the world and about to go extinct as a result of uneven birthrates and 1mmigrati_on to their home countries, and that 8 l4ck people commit disproportioned amount of \/i0lent crimes against whites? D_3portati0n and closed borders matter! World peace and a home to live for all people of the world! Is that statement a problem with you, or with THEM? If so, it seems you hat_3 white people and you sympathize with silent g3n*cic|e. That's pretty unfortunate since all I am suggesting is that we set a low bar community standards surrounded around decency for everyone to enjoy equally. If you think I am trolling or the n-word, please correct me on what I said and correct my wrong statements. The numbers exist because of 1984 censorship.
34:56 I "recently" discovered that you can use catching an exception for correcting the user input (aka during something useful, instead of just throwing an error and or moving on). Ofc u can't use it everywhere but at that time i thought it was pretty neat (was like 6y ago)
The moment a language constantly battles against the programmer, I'm out. It can be as annoying as the forced indenting in Python to the idiotic loops and hoops you have to go through in Rust. I want to enjoy writing code. Fighting it, isn't enjoying it. And all that crap about milliseconds and "whichever language is the fastest"-futile discussions: don't fall for it. Choose a language that you enjoy writing in, and one that gets the job done. For me that's TypeScript most of the time. And when I want to get down to millisecond level, which I hardly need to do anymore, it's C++.
I don't want to be a jackass, but I can't ignore a small detail of your comment, so I apologize in advance... If Python's forced indenting is working against you to the point that you give up on the language, then I'm scared to see what your code looks like. Python has MANY disadvantages, but forced indenting is definitely not one of them. That's actually worse than saying that you hate C#, C++, or Java because the semicolon is mandatory... I mean, the forced indenting at least helps your code to be a little bit cleaner and easier to read. However, I do agree with the rest of your comment - you should always stick to languages that you actually enjoy writing in and that solves the problem that you're working on.
@@QueirozVini I'm capable of indenting the code as per my own choice. I don't want to have a compiler nagging when I align blocks of code using mixed tabs and spaces, which look fine by me, but apparently not by Python.
@@QueirozVini for most language i just put { } and auto format with my setting and my code never fall over the loops, why the heck I need do indenting my self when I always automatic everything with program
I built a bunch of trading algos at one of the largest banks, doing trillions of dollars in volume annually. I can tell you that speed depends a lot on the market dynamics. For equities, you tend to require a lot of speed because the market data isn't throttled. For most markets, you can get away with even python in the trading logic layer. Having said that, Rust is being looked at for the market data and execution layers in the tech stack. Pretty much anything trading infrastructure is a good fit because you do get the speed, safety, and great handling. Typically that has been dominated by C++ since forever. To me, it sounds like the writer chose to do the entire system in Rust, which probably isn't the best. Writing to databases doesn't need to be bare metal speed. These days, I like the idea of using an easy language that I can trust to maintain great uptime metrics for basic server infrastructure like database writing, which Go would be a great choice.
@@samuraijosh1595 in FX the two primary spot exchanges, EBS and Reuters, do anywhere from 50-80 billion on a normal day. Over the course of a year, you're in the trillions. Different story if you're talking equities which trades in the hundreds of millions.
@@samuraijosh1595 the two primary exchanges in FX, EBS and Reuters, do roughly 50-80 billion in spot volume daily. Over the course of the year, that is in the trillions. FX also trades primarily OTC, i.e. you're trading directly with a bank, not over the exchange.
"Average daily volume in total over-the-counter (OTC) foreign exchange instruments (including spot, outright forward, foreign exchange swap, and option transactions) was $1,021.0 billion in October 2023." - New York FED
Because with the huge amounts of footguns and UB even modern C++ sadly still has (especially once you want to write abstracted code), your "learning to not suck" won't help you much anymore because you'll always trip over _something_ that will then only be caught by ASan or UBSan. The advantage Rust gives you is that once you're over that "burden", the base understanding is what you need and you can code with more ease. Also, but this is personal taste, I prefer the "opt-in" fulfillment of Rust Traits compared to the "by-structure"/"-happenstance" nature of fulfilling Concepts in C++. Also the fact that it actually has a decent package manager.
I think the point about community is an important one. Rust has a pretty high learning curve, and unfortunately that can tend to attract people that prefer to pat themselves on the back rather than actually trying to build things together with others. At the language level though there's a lot of focus on things that make it more newcomer friendly such as good documentation, error messages, and tooling, which I see as a really good sign.
++1 In the early days I hated the Rust compiler. After reading a bit, I wanted to write something. And the compiler "hammered" me with nitpicking. I understand why. But let me be! I'm learning! Give me a flag to tell the compiler "I'm new, be gentle, this is not production"! I'll turn that off for production. Heck, turn it off automatically for release builds. Think about learning a foreign language. You want to start using is asap. That way you learn faster, in fact. But now imagine that on the other side you have an native who slaps you every time you use the wrong gender, or plural, or word order, or pronunciation, or accent. Can you understand if? Great! Let me be! We are communicating! That's important! I'll get better in time. You can maybe give me flags to relax certain checks only. Complain about my grammar mistakes, ignore my accent :-) Like any C/C++ compiler. I can turn off certain checks, and the defaults are not too annoying. Rust comes with -Wall by default, and no way to relax that :-)
They used to say Rust would replace C++. The reality today is that much more code is being written in C++, and the language is growing faster than ever. My best professional decision 15 years ago was to focus on well-stablished technologies such as C++, Python, JavaScript, SQL, etc, and not stress about reinventing the wheel in niche languages like Rust or whatever comes new.
Modern C++ (i.e. C++20 onwards) when written well can be extremely safe, the chances of getting a memory leak / buffer overrun / nullptr / race are minimal
@@markp8418assuming you don't use rare and obscure features like std::vector::pop_back. Otherwise you get undefined behavior and your console starts printing 42, even though you unplugged the computer.
Memory safety in Rust is a tricky issue, Go language allows data race conditions. But it offers good and clear ways to avoid it. Result: Websites specializing in software vulnerabilities announced 39 data race vulnerabilities in Rust applications. Versus 2 data race cases in Go applications. Although we know that Go applications are much more than Rust applications, concurrency and parallelism are used extensively. It's the same with the memory leak issue I've used a lot of C++ applications and never experienced a memory leak. I used two rust applications, One of them was leaking memory. Rust community deliberately shows the good side of its language as opposed to the bad side of other languages
@baxiry. I see more future in Go than in Rust. We'll see. In the meantime, I will focus on building things using traditional tools rather than learning everything new that comes out. At least that approach always works.
Can't agree more with "wrong duplication is better than wrong abstraction", i hate when for the sake of not writing the same 2-3 lines of code in different places we make the codebase unmaintainable by abstracting increasing the actual code complexity 10x and making almost impossible to change a little bit without breaking everything.
There is a point to the lack of null pointer crashes and suck. Sometimes, crashes are great: you get an error very soon, with a nice stack trace. Sending the error elsewhere (which is what most people will do when handling one) may mean anything from having a useless stack trace to broken program behavior in subtle ways.
Rust backtraces only apply to panics. He's talking about how a function returning Result::Err doesn't convey information about where it was constructed. You only know where it was handled, not where it originated.
@@jonnyso1 Depending on the codebase it could be easy to figure out. But like he points out in the video, if you use "?" to bubble up errors a lot and have an app that does lots of file IO, and your app errors with "No such file or directory"... What file did it not find? what function returned the error? Obviously you can code around those issues, but it's not always straight forward and doesn't come out of the box really.
@@dork_side That's what I didn't get, you need to specify what type of error you're returning, you can't just use ? and it bubbles everything, if your function is returning an error, you know which error it is, its right there on the signature, no ? Or is it some anyhow thing ?
@@jonnyso1 that only works if your function only has one failure mode. If you use IO and some other fallible thing that returns another error type in one of your functions you either have to use anyhow, make a custom error type that wraps both, box dyn error, etc. Eventually you usually get to a point where you can easily bubble up many similar errors from a potentially large codebase and tracing them back to the origin can be hard. There are ways to solve that problem yourself, but I can see how this could be a pain point when you’re used to exception stack traces.
@@dork_side You simply write a custom error type and use "thiserror" (or similar) to compose said errors. After that knowing where your error comes from becomes dead simple.
feels like a 100% skill issue. The problem with rust, however, is that it's new and cryptic. That adds somewhat to the skill requirement, but that's not the problem here. I haven't written a single line of rust, but can already 'get' what's going on. The problem is the lack of software architecture design experience.
@@curio78 any lang is just a fancy system for translating high-lvl abstractions into machine instructions. In a way, it's just a tool designed to be used by a specific person to do a specific job, nothing more. But intent must always come first, because every work is defined and driven by some intent. Any work without an intent is meaningless. Tools only make the job easier.
@curio78 sounds like you tried rust for 10 minutes and gave up. it's not _that_ unreadable. it's actually fairly readable for most things, but takes time like any language to get used to.
@@curio78 anyone who says rust is unreadable hasn't used it for long enough. The syntax is absolutely fine once you use it for a while. You could use the same argument for C as well. My dad is used to writing Visual Basic and thinks C is unreadable.
@@eyz-4 I never said it was unreadable, it's just that I can get (almost)all the benefits of safety with c++ RAII and proper software design. But it's way less brain taxing, although pretty much as verbose and cryptic as rust
If you didn't write a single line of Rust, you don't really get it. Try writing, and the compiler will slap you around until you lose any appetite for Rust :-) At least in the beginning.
@@faithful451 But if you're new and learning, be humble instead of writing a whole blog post saying the language is shit and badly designed. Otherwise don't complain when people dunk on your intelligence. You pretty much asked for it.
@@hagaiak agreed on being humble, that goes both ways though. If someone's having trouble and asking for help, humbly help them instead of 'dunking on their intelligence' .
Personally I believe that boiling people's problems with a language down to a "skill issue" is kind of dumb. Every problem you can have is a skill issue. If the language is Turing complete then you can do everything in it (technically). You have a problem with your error handling? Skill issue. If you were a better programmer there would be no errors to handle and why would you need to handle what doesn't exist? A ridiculously steep learning curve is a giant glaring con for a language. If you have to "git gud" for years on end to be able to write some decent code in a language then is it even a language worth learning?
That's true. By following that logic memory unsafety in C or C++ is also a skill issue so there is almost no reason to learn Rust in the first place. Instead you just can become better at C++ and learn how to write memory safe code.
@@bionic_batman That but unironically. Herb Sutter relates that Microsoft's experience with Rust has been that from C to C++ there's a large safety delta, and from C++ to Rust there's a small safety delta, and even that's largely because it's harder to commit code that doesn't compile than to commit code that fails a static analyzer.
taking years is an extreme exaggeration. 3-4 weeks is realistic for the average programmer. assuming they go through the book and actually commit themselves to learn it. that's still a lot compared to something like javascript though which is realistically probably around 2 weeks on average. you're not just picking up javascript with javascript. you have to learn all of the tooling and all of that. go is probably a week, although i learned go in a couple of days.
Memory safety in Rust is a tricky issue The Go language allows data race conditions. But it offers good and clear ways to avoid it. Result: Websites specializing in software vulnerabilities announced 39 data race vulnerabilities in Rust applications. Versus 2 data race cases in Go applications. Although we know that Go applications are much more than Rust applications, concurrency and parallelism are used extensively. It's the same with the memory leak issue I've used a lot of C++ applications and never experienced a memory leak. I used two applications for Rust. One of them was leaking memory. We must admit that the Rust community deliberately shows the good side of its language as opposed to the bad side of other languages
Last observation is that I don't think enough of the glowing articles and videos about Rust focus on these challenges. There is not enough emphasis that rust development kind of needs to be focused on a niche where the performance benefits and long term reliability outweigh the cost of half a year skilling up your dev team before they can really leverage those benefits. That's a pretty high bar, and definitely something I will be considering for any platform development work I will be leading going forward. So... informative!
Great post. The async stuff at the start reminded me of issues I constantly have with FP-TS on TypeScript. I guess functional programming just gets harder as you push it to do more.
I unironically got a massive migraine reading and trying to write a simple cli argument parser in rust, that has never happened - not even when going from C# to C++ to C to Python to php to javascript Not once, but doing rust gave me a full migraine where I just cant go near the computer, its insane
I’m confused any time someone says rust is good for CLI apps because strings are annoying in rust. Tbf, I haven’t used clap or any crates to handle the arguments. That said, I certainly wouldn’t say it’s any worse than C++.
@@jishani1 what? I *unironically* got a massive migraine, what on earth are you talking about, its a descriptor to how people joke about getting migraines - I literally, unjokingly got a massive migraine
That post reminds me of the old line that REAL PROGRAMMERS can write Fortran in any language. Learning a new programming language isn't just learning new syntax, just as learning a natural language isn't just learning new vocabulary. This sentence is German to English without grammar adjusting translated. With programming languages it naturally gets frustrating when the familiar patterns no longer work and you have to learn new ways of structuring your programs.
One of the huge balancing acts with Rust is when to write stuff yourself vs falling back on the community crates. If you wanna GSD you just gotta use the classics - anyhow, thiserror, serde, tokio, etc. or you're gonna wind up with pin box, dyn error shenanigans.
22:15 is definitely more indicative of Redditors than it is the Rust community. Redditors HATE giving you real advice instead of just shitting on your already made decisions.
(That said, I don't have any more anecdotes for how the Rust community is compared to the others. So I defer to the bad experiences you seem to have had)
Rust people will be nice to you as long as you have a rainbow flag in your bio and at least one thread where you defend sex change surgery for children
As a member of the PHP community for maybe 10 years now, I can tell you we're pretty nice because the language was so bad for so long, and it was a punching bag for that whole time, that there isn't that holier than thou attitude you'll find in other languages. We had to collaborate and get on with one another if we were to find success using this language.
yeah calling a language garbage with bad designs when after admitting you can't even properly structure error message is so weird . Rust is so great because it humbled many of these dudes with god complex thinking they actually know everything , a truly smart & humble person will sit down and learn these stuff instead of lashing out and insulting everyone and everything edit: typos
I had a short look at Rust and noped out immediately. If I want something that looks like C++, I'd use C++. The speed argument is dumb, study after study finds that GC'd languages are _theoretically_ a little faster, but in practice is either doesn't matter (GC performance has come a long way), or people are making non-optimal memory management choices, which make the GC-less language actually slower. There are so many good languages to chose from. I know and love Kotlin and Scala, but I heard good things e.g. about Julia and Elixir, and Swift seems decent too. Don't buy the hype, use the language that fits you and your problem at hand.
I personally dislike that so much emphasis is placed on memory management when it comes to performance. Yes, languages like C/C++/Rust with a more manual memory management approach can be faster than GC. However there's a lot more to performance than just memory management and often times those other aspects are far more important. If you use Rust but use the wrong data structures and algorithms it's probably going to be dramatically worse than say a GC language with the right ones. That said I do really like Rust.
OK if you need a part of your program to be performant and other part you don't worry too much about it then write the performant part in C and the rest in some GC language then link them together what's so hard about this
Yeah, really what GC-less languages give you is a much more predictable performance. The thing with GC is that you never know when the GC is going to kick in and create a slowdown in your code. In many cases though, the GC doesn't actually have that big of a performance hit, which is why it's not really a great idea to use a systems programming language like Rust for everything.
@@rusi6219 The thing is the GC isn't buying you as much as you think it is. The fact that the GC pervades the entire language design can in fact make things substantially worse. Compare for example C++ where closing a file stream is as easy as letting it go out of scope, versus something like C# where you need to be mindful of what's a "disposable" and place all such objects in a using block or try... finally. RAII languages like Rust or C++ understand that memory allocation is just one of the many types of resources a program needs to manage, and provide a general solution suitable for all of them. It's a simple solution, which only asks you to consider what objects own what and then you're set. Once you've internalized this way of thinking, GC languages just seem awkward and limiting. GC pressure is something you straight up _don't have to think about_ in C++ or Rust.
@rusi6219 The thing is the GC isn't buying you as much as you think it is. The fact that the GC pervades the entire language design can in fact make things substantially worse. Compare for example C++ where closing a file stream is as easy as letting it go out of scope, versus something like C# where you need to be mindful of what's a "disposable" and place all such objects in a using block or try... finally. RAII languages like Rust or C++ understand that memory allocation is just one of the many types of resources a program needs to manage, and provide a general solution suitable for all of them. It's a simple solution, which only asks you to consider what objects own what and then you're set. Once you've internalized this way of thinking, GC languages just seem awkward and limiting. GC pressure is something you straight up _don't have to think about_ in C++ or Rust.
I 100% get where this guy is coming from with the answers received, it's always what's infuriated me most about programming. No other community does what they do here. Imagine asking in a woodworking forum "I'm building a canoe and the epoxy is giving me trouble can you give me advice on how to work it?" and you get a dozen answers that are some variation of "You're building a canoe? Are you an idiot? Build a deck instead you moron." You don't need a deck, you need tips on using epoxy, but everyone feels smugly justified with the non-answers they gave you. When you bring that up you get dog-piled on for having "skill issues". Who would ever want to be a part of that?
I've never come across someone saying to build another project instead. Only advice about approaching the project in different ways, or writing the language in a more efficient manner according to the language itself, and not according to other languages. But if that's what you're talking about then a more comparable comparison is if a woodwork community told you to use a different tool, or to not use a chainsaw as if you use a hand saw.
Sometimes its warranted ("How do I get the pixel size of the screen on a headless server?" "You don't. You're definitely approaching this wrong") but other times its really not (Canoe vs deck) and sometimes theres a middle ground ("The bindins to mongo are attrocious in rust, it's just... not a good idea to use mongo when working in rust becaue of it") but in this case its also the added assholeishness of the rust community that call a binding issue a skill issue ofthe user making it all worse.
I also know asm, and to be fair you can't compare anything to asm because of how simple it is. It all depends on your instruction set but it's often very simple to follow. Unless you're named x86_64 and literally have some instructions called javascript_float_round_towards_zero. I hate x86_64 so much.
@@fleefie Since all high level languages reduce to machine code, the comparison is fair. One primary benefit of high level languages is to move programming closer to how humans communicate. FORTRAN and C were modest steps in that direction. BASIC, Pascal, Java, Javascript, Python etc were steps in that direction too. I think Rust is a step backward in that trend. IMO, any new computer language should move closer to natural language, not further away from it. I know your javascript_float_round_towards_zero is meant to be sarcasm, but I never found x86 baffling or strange. I spent over 10 thousand hours writing x86 assembler. I liked it a lot.
Lua is beautiful for it. Factorio is a great environment, for a more static "you said you could wait" and runtime "please don't break" code. A common pattern for a storage which should be there and needs to be: a.b = a.b or {} . "assign itself or give it a new [storage] ". Stupid, simple, 100% functional. Since assignment states allow returning values from functions, you can even do a.b = a.b or error("barf") , which Perl has in spades with open(FH, $dir) or die("") . Most of the time: *if not a.b then* works, as a false or nil (the value of non-assignment) passed to a not is true. *if not a.b then return end*
I love how "using Rust" and "rebuilding a huge platform" are synonymous
Rrir folks are to blame.
Real talk, this is another failing of the Rust community. Bamboozling people into thinking this is somehow a good idea to begin with.
Makes me believe most the devs that push this are juniors. A few seniors might give it a go but most know how god awful same language rebuilding is, let alone new-language building is
Just this fact makes me realize that most of those that use Rust and do that are completely green and inexperienced. Because otherwise they would know, re-writing any big thing without very good reasons more often than not ends in pain, new bugs and waste of time.
Is not it a mandatory rite of passage for any rust convert?
"PHP has the nicest community" === "we're all in this shit together"
Trauma bonding is real
your probably js kiddo lol
Nah, they are a way more mature community than JS children’s playground. PHP, .NET, Java are the technologies that actually keep the world going and get shit done
====
@@kphaxx =====
Rust has more videos on TH-cam than actual lines of code working in production
bruhhhhh 💀💀🤣🤣🤣🤣
wow😂😂😂
Chill 😂
spot on
Tfw
People need to understand the market segments rust is appealing to, mainly systems programmers… if he wanted a performant, compiled, garbage collected language he should have just used go. But he fell for the RIR meme and then wrote an article about “if only rust had a garbage collector”, which for me is the same as “I’m so mad my car isn’t also a boat”… it’s a different product for a different market segment …
@@chockman3833 If only Assembly had automatic garbage collection. Why aren’t lifetimes handled automatically by x86? The syntax on these vtable allocations are just too much sometimes.
@@houstonbova3136Assembly doesn't even handle the stack automatically lol
I don't know if this is a genuine joke (I am assuming it was), but this is gold 😂😂
@@tablettablete186 Definitely a satirical interpretation of the video 😅
@@houstonbova3136 that’s exactly my point man!
@@houstonbova3136 Congrats, the joke was amazing 😅😅😅
Maximum performance _and_ async is extremely hard in any language
This. It's basically like an RPG where you can choose your archetype.
*The Profiler.* Wielding your GC language, concurrency and threading are easy and often quite performant since you can rely on your (bytecode) compiler and runtime crafted by the highly intelligent elders. As you start to optimize, you will learn to work around the GC in order to minimize allocations and cleanup, and deploy tests to guard yourself against race conditions.
*The Debugger.* As a scholar of the arcane C++, concurrency and threading are easy with smart pointers and copies, albeit at the cost of performance. As you start to optimize, you will learn to tame race conditions, crashes, dangling threads and nasal demons summoned from the realm of undefined behaviour.
*The Compiler.* Similar to _The Debugger_, concurrency and threading are easy using reference counting and cloning, at the cost of performance. As you start to optimize, you will learn the way of the borrow checker, using your knowledge of pinning and interior mutability to refine and refactor your programs until all errors are quenched and the raw performance of your code is unleashed.
-----
Overall, they are fairly balanced. If anything, _The Compiler_ sucks at low to mid levels, while _The Debugger_ is prone to blow up himself and their whole party, specifically in its older edition versions...
...i'll see myself out.
This. It's a bit like RPG archetypes:
*The Profiler.* Wielding your GC language, concurrency is easy and often quite performant since you can rely on the (bytecode-)compiler and runtime crafted by the highly intelligent elders. As you start to optimize, you will learn to work around the GC to minimize allocations and cleanups, and implement tests to protect against race conditions.
*The Debugger.* As a scholar of the arcane C++, concurrency and threading are easy with smart pointers and copies, albeit at the cost of performance. As you start to optimize, you will learn to tame race conditions, crashes, dangling threads, and the nasal demons summoned from the realm of undefined behavior.
*The Compiler.* As with The Debugger, concurrency and threading are easy using reference counting and cloning, at the cost of performance. As you start to optimize, you will learn the way of the borrow checker, using pinning and interior mutability to refine your programs until all compilation errors are vanquished and the raw performance of your code is unleashed.
...I'll see myself out.
I think async syntax may abstract a little too much for the beginner, which means there's a performance hit they may not be aware of.
From what I recall, adding async basically turns your code into a state machine.
C# has you covered on both fronts… according to Microsoft at least
I'm happy how Java approached this. Just 1 line of config to enable virtual threads.
Rust can be simple. For example, you probably don’t need generics or lifetimes for your use case. Your application is not a library and so it’s ok to be ad hoc and repeat yourself.
This ^
but when you try to build something atleast somewhat useful, you start to use frameworks and libraries, which are often over-engineered, so your code also get over-engineered pretty quickly
@@curio78 most applications are trivial and small. Huge projects are the few. A company may have a couple of big products or a platform, and 10 or more internal tools that are just forms or non-critical data processing apps. This "real apps are complex" is only true if you are making something actually complex (optimization of geometry for CNC machines or whatever), or the software changes for several years
Profound statement. Don't repeat yourself, unless you've got something important to say, then do that. Repeat yourself.
That first sentence is funny
Acually catched this article on medium before you covered it, the whole time I was reading it I was thinking about how you would react to this article, haha.
Let's go
Not the biggest fan of Rust myself but "it's worse than typescript" is a wild take.
Sad but true
Well, it really depends on what your priority is. If you want to get something up and running quick, Rust is a terrible language. In fact, it could quite possibly be the worst language for that. Developing with Rust is slow. It writes safe, fast programs, but your code has to pass a lot of strict compiler checks.
@@taragnor I don't think it does. Javascript is the worst language ever invented as anything other than a joke and shouldn't be used for anything. There are other far more usable languages if you want something done quick.
@@isodoubIet Vanilla JS is terrible. Typescript is okay. It still has warts from JS (which sucks), but can do some of what Rust can, with a similar syntax for generics. You can even do some Rusty abstractions and code in Result and Option return types instead of relying on throwing. It's async is also relatively similar as well to Rust. Speed wise it's also not that bad for a scripting language. Python and Ruby are much slower.
If the plan was to never port the system to Rust, I'd probably say they'd be better off choosing Go or C#, but the TS version is basically just a prototype design for an eventual switch to Rust. It's an okay choice. It's not the only choice, but I don't think it's awful.
@@taragnor TS is slightly harder to use incorrectly but it's still the same fundamentally borked technology. Getting the wrong answer faster is not an advantage.
But all that aside, the guy didn't conclude "TS is better for developing a throwaway concept that I'll rewrite in a real language later". He concluded "TS is better _in general." This is a take so wild it has yet to be contacted by western civilization.
I spent 18 months rebuilding my house using a Swiss army knife. I'm filled with regret.
With a Swiss Army Knife™, you would be done in 18 weeks.
Well that's obviously a skill issue
@ProgrammingLearner-iy3ej Yes. People also don't write things directly into binary because of skill issues 😂
After that you get to be extremely skilled. So its probably worth it.
Swiss Army knife is the ultimate abstraction. It's like writing in Clojure.
“The wrong duplication is better than the wrong abstraction” I wish I’d heard this when I was starting out!
Going out of the "GC world" into a wild universe of self-managed memory can be akin to learning to breathe manually. Rust attempts to solve that issue by stunning you with a cattle prod every time you fail to take a breath on time (or take a breath when you weren't supposed to). This works for some people, but not for everyone and not in every situation. In its defense: it's not like there are no warnings about it... like, at least half the articles I've read on Rust before giving it a try were very explicit about how hard and frustrating it can be.
I don’t think that’s a fair comparison. The cattle prod stun would be panicking at runtime. Rust doesn’t even let you cross the door to take the breath outside. It’s much better to fail many times at compile time than to fail just one in production at runtime. Every one of those compile time errors would be a bug in a different (memory managed) language.
I like to think of rustc as Mr Miyagi. You'll be miserable for a bit but will come out better on the other side.
@@Turalcar Rust == Pai Mei
This is the most based explanation of Rust I've ever seen. I always said it feels like pulling your own teeth out, but I'm stealing this.
@@bradclements1815 Oh crab! here comes the web-dev poison!
"I'm using Rust because the interwebs said it's fast. Also, I can't be bothered to spend 30 minutes to understand my own code without an LLM present."
Pro tip - performant code in any language requires careful work by someone who knows WTF they're doing.
Harrison Ford: _"If we would have asked people what they wanted, they would have asked for faster C++"_
@@ToveriJuri haha oh wow :D
hahahahah @@ToveriJuri
he should've just sticked typescript or phyton, heck for a person like that i think lua is a great languaje HAHAH
@@Pepo.. or just use go.
After a session of Rust, I literally feel nauseous when I switch to Typescript because the error handling is so good in Rust.
Its because Typescript is a bastard child of Javascript which is a broken language
Typescript is gold leaf applied to poop.
@@7th_CAV_Trooper 😂
Can you expand a little about your problems with TS? I do Angular in my day job, and I've been using my own Result type, and it has been alright. Not as nice as Rust's but better than throwing exceptions around.
That's bad, you shouldn't feel that way about getting errors. They are your friends, and the debugger is your friend also.
"If you don't have access to an LLM..." So he used ChatGPT to convert TypeScript to Rust?
Never mind the probable abuses of direct conversions that follow the original codes layout, but didn't take advantage of the right way to write rust
😂😂
He didn't want to spend 30 minutes understanding the where block. If he doesn't have 30 minutes to invest...
"WHY MY PROGRAM DOES NOT JUST COMPILE???"
Certainly
This guy is pretty infamous in the Rust subreddit. I obviously can't know what's in his heart-of-hearts, but every article he's posted has been pretty sloppy and transparently just advertising for his AI powered finance tools. I distinctly remember one where he claimed to have forked and "fixed" a finance crate, to the point where it warranted an announcement on the subreddit. But, all that he'd changed was a single statistical function to give a different result (that he preferred), and then deleted all the documentation and made himself the only author on the crate. In every interaction I've had with him, he's come across as quite unpleasant.
I “fixed” the finance crate to have a radically different design and fixed a bug. I deleted the documentation because it was outdated with the radically different design.
Old design: put in a number (like 5)
New Design: put in a duration (like 5 days)
Apologies if I came across as unpleasant
@@StarksTech lol
The article where a game dev reviews Rust after using it for 3 years is much better, though maybe too long for Prime to react on stream.
Est 96 minutes? I'll read it at work...
Most articles criticizing Rust (including the one you mention) usually end up saying something along the lines of "C++ is better for my use case". That is a reasonable take. This article says instead "typescript is better (in general)", which is a troll take at best.
@@tinrab Dunno about the rest but talking about the orphan rule is 100% on point and justified.
@pyrocentury Can you please share the link to the article?
I'd like the link for the article as well
I think that once you understand what the different pointer types in Rust do and you know the reason for their necessity it gets much easier to read the types because you're not that lost anymore.
Step by step its really easy actually.
FnMut is a function that can mutate some state inside itself. It takes an argument that is a mutable reference to the ClientSession.
and returns a pinned value.
Pin just says that the value with type F cannot be moved to another memory location. This is to ensure that from one thread to another the memory location always stays the same.
Box just say's that whatever is inside the lives on the heap.
dyn says that you can use the api that the trait Future provides.
Future is a pollable object that waits for some asynchronous operation to be completed, the of which is just a Result that can either be of the type R which must be Sendable across thread boundaries and have a 'static lifetime which means that the value lives for the entire lifetime of the application, think a string thats embedded in the executable. And then the Result can also be an error in which case it is a String that probably tells the caller of the function something about what went wrong.
You really have to break these concepts down and try to understand them bit by bit. At which point you really do get faster at reading and understanding these types. You also learn what you need to skip and exclude from your mental stack so to speak if you only want to know what the function does and not why it is technically necessary to do all the pinning and fnmutting business.
Dude I've been using Rust for like 3 years straight, and I don't know what any of that stuff is in the beginning of your comment.
What use case are you building for? What does it do? I find people use so much of Rust and I barely use any of it.
Why don't you just throw everything complicated into an async thread and have it send messages back to the main thread and self terminate when done? All this pointer stuff I hear about sounds like trying to walk a tightrope.
Maybe I'm an absolute moron and this is terrible, but I stopped learning Rust when I mastered handling everything async. I use it all the time, everywhere. Hundreds of threads at a time for each agent. Async threads starting and awaiting more async threads, on and on and on. Why not?
I don't even recognize any of those pointer types. Honestly, I don't even know how a pointer differs from a variable name.
I guess I'm a caveman, or cavecrab. I don't know, hitting everything with a club just works.
Don't fix what ain't broke.
My code runs faster than I need on 10 year old android devices I use for servers, so I've never looked into perf. There are so many rabbitholes in Rust, and I'm not scholarly enough to handle a lot of it, therefore, so much of it is just engaging. Sometimes I need something, and I go to The Book, and I return enlightened, but some stuff Rustaceans do regularly is just too much for little old me.
Number types: I don't even use those different number types. Holy hell, why so many options? I want a number!!!!! I don't want to have to think about how big the number might get, and then select the right type - which I always have to look up because I didn't go to college and I refuse to memorize extremely random and long numbers that are related to the number (which is always a product of 2^x because computers) attached to either the letter "u" or letter "i" which for some wild reason link to two totally different, super random numbers (which are also always a product of 2^x because computers), and only one of them allows negative values because... drumroll, please... computers.
I just want a number! How is that so much to ask for? The number types alone make me feel like I'm doing my taxes. I get triggered like Big Red when I see those types. There's "int"/"float" or (my favorite), straight up "num." Everything else is the damn computer's job! Am I a programmer or a mathematician? I failed Calc 1 four times, I came to programming because I thought I was safe from my one weakness.
But that's my point. You know all this stuff about Rust, and you're probably better at it than me, but Rust is as hard as you make it. I feel like anyone complaining about Rust is trying to write Superman-Rust. I know a small sliver of Rust as well as I know my name, and that's all I've ever needed. I just can't comprehend people freaking out about using all this stuff. They're doing it to themselves. You can do so much with so little of Rust, and then you can improve pieces that are bad. I used to use Arc stuff for everything, but it got annoying, so I mastered multithreading or whatever it's called. Now I don't have to worry about all this locking insanity. There's so much in Rust. It's ridiculous to try to know even half of it.
Last - but not least - I don't know a damn thing about lifetimes. I don't even know what they are.
*mic drop*
I can't edit replies, so commenting again.
Question: is it really that big of a impact to send the data as a message versus using those pointers? If so, what in the world are you building? Are you dealing with Google-level i/o?
This is a great explanation. As a n00b, thank you.
@@GrizikYugno-ku2zs Your point is extremely valid. You can avoid a lot of the complexity associated with the lower level abstractions that rust provides by using higher level abstractions. But these higher level abstractions are often built on top of the lower ones to offer the safety and efficiency you expect from rust. But as always in engineering everything comes with a tradeoff. if you've found a way to program that works for you, thats awesome man more power to you but also keep in mind there have to be those that build the use case specific abstractions for everyone else. I am very curious about your usecase for "just a number" because there could be several solutions to your problem. You strike me as a domain level problem solver.
@@GrizikYugno-ku2zsI've never touched Rust, but for the different number types (which are common in most if not all languages): it is all about memory space efficiency. Why use 64-bits for a number when 8-bits will suffice? -- if you have an array, you can store 8x more "numbers" in the same amount of RAM if you can get by with "8-bits" vs "64-bits".
For negative numbers: you eat one bit to store the negative sign -- if your value can never be negative, then use one of the unsigned number types so you double the size of the number that can be stored in the same amount of bits.
These things just make more efficient use of the underlying hardware. Think of them as "hints" to the compiler so it can make more performant and memory efficient code when it executes.
One of the many things I love about Prime is he explains things - e.g. "shadowing".
If I had the time I expect I could watch Prime learn (and stream) a language and end up understanding all the "what's" and "why's", just because he'll explain things if you ask.
One of the best teachers I've seen, and I haven't even watched his courses yet. 🤙
It's amazingly unbelievable how much you are wrong 😅 but with experience, you will get that, probably.
@@georgytioro Sodd off, and don't let the door hit you on the way out.
@@georgytiorocould you explain why you feel this way? I also feel like Prime is great
"Magick always comes at a price"
- Gaius to Merlin
Finished rewatching that show this week. Didn't expect a BBC Merlin reference in a Prime comment section
Yup. ImageMagick always comes with a price. Of having to modify esoteric XML configuration files to be able to do anything useful.
@@privacyvalued4134 you talking about Java?
I've been coding in Java for 24 years, watching people chase the latest languages.
Did you ever learn any other language, for the sake of learning something outside your bubble, or nah? Or are you Java till you die?
Your code would work on like 3 billions devices!
My condolences
I can't do it. I don't even use open source applications built on java except intellij. I have PTSD and a phobia
Me too bro, me too
Web devs should not be allowed to complain about other programming languages.
Sincerely,
A web dev
Web devs shouldn't be allowed to complain about any software when they don't even know how to use the tools they're paid to use.
sincerely,
anon
I think this applies on a higher level; don't complain about stuff until you're knowledgeable enough to understand the stuff.
@@Takyodor2 Yes, but that doesn't sound as good as a joke comment 😁
@@Takyodor2 Right? Primeagen once talked about how you get into someone else's code and you think "oh, this is crap." So you start to rewrite it and as you encounter all the edge cases, your code looks more and more like the code you thought was crap. lol
You comment deserves 1000.000 likes.
For 95% of programmers code performance is actually not really your limiting factor. As long as you avoid accidential N² loops, your programs' performance is going to be limited by database access times. That is why gc languages are so popular.
The right tool for the right job.
@@amoskevitz still doesn't hurt to strive for excellence
@amoskevitz The problem is, that's not true. It's not 95% of programmers, it's 95% (or more like 99%) of code. The problem with that is that for the remaining 5% you need a solution too. This is why you shouldn't pick your programming language based on the problem (unless you're happy with FFI); instead you should pick a programming language that supports the largest number of different paradigms and tools (like how rust supports both Rc and RAII for the different use cases).
these kind of take is why the performance of every application is going to shit as days pass
@@thanhle-du3or when you can ship an MVP in a year rather than 3-4 years, then you can see how rapid development is more important. You don't need the utmost performance, so prioritize other more important things. Circle jerking all day about Rust or C is fine and all (not), but I'd rather get more done and optimize later. Rust evangelism won't get you from A to B faster when writing software.
that “rust is haskell dressed as C” imo is very wrong, when getting into crazy types like that, Rust is MUCH more difficult and unintuitive, if you think you can extract a closure into a function with parameters you encounter problems, if you try to do the opposite you also do, and as “friendly errors”, still they are considerably difficult. In haskell you are much more free to do that sort of stuff.
bro just used interface{} in the go example to not deal with any types, that is like throwing any everywhere in typescript and it does not help with your case man, this guy is so javascript brained
"There is no other programming community that's as cult-like as Rust" wait till this guy heard about Vlang...
Laughs in Haskell.
Also I have nothing but respect for Haskell, its practitioners, and its secret police force, and orgy initiations.
So culty I've never seen vlang dev 😂.
Or Gleam
Swift / iOS Dev is also cult like.. now that I think about it, all fanatics of a language normally trend towards their language… which is really the point.
Haskell cool aide is the sweetest of all.
I feel like the fact that apparently their first version was written in TS of all things isn't really a good sign. Makes you wonder what exactly they're comparing it to.
He was probably more familiar and proficient with TS at the moment of starting, what's wrong with that?
You have to start somewhere. And first versions are usually written in popular languages, not languages that are good for the job. Maybe Go would have been better for this. But the borrow checker witnesses are everywhere and ringing the door bell to talk about Rust.
@@svuvicheverything. Chosing a platform based on familiarity instead of purely techical characteristics is a sign of incompetence.
@@vitalyl1327choosing a platform you literally cannot use because it's technically superior is just as incompetent. Life is funny that way sometimes.
@@svuvich Do you know what 'algorithmic trading' is?
"now that I know Rust"
We need friendliness in tech communities, and irl too. It makes everything easier
This is why I like Primeagen. He fosters a friendly community.
@@7th_CAV_Trooper he is the chosen one! :D
@@antontsvil245 but I still don't feel like I can openly admit to being a C# enjoyer. Lol
Clearly a bot. Get bent buddy.
@@antontsvil245 did you say be nice and touch some grass
It took me a long time to learn the patterns and mindset required for Rust, and I'm still taking my time to learn it all piece by piece, but IMO it's been worth it. Perhaps it's just how my brain is wired, but writing Rust is incredibly satisfying for me. With any other language I am terrified it could spontaneously combust if there's weird data, whereas with Rust everything is clearly laid out, defined, and it all does exactly what it says with no edge cases or strange arbitrary behaviour.
Honestly, it's mostly just personal preference and good teachers! Rust is really hard to learn. People will say, "oh but there's the book and tons of nice videos and written tutorials" but this really doesn't teach you the core of what makes Rust code different. Just preaching how cool it is does nothing, and while the learning resources are accessible, they do not help write the mental patterns that are valuable for writing Rust code.
wait until u get into hell with smart pointers.
I don't _love_ Rust, but I like it a lot more than C++. It also took me 6 months to get to grips with the borrow checker.. and even after that I scratched my head at some borrow checker corner cases. I think the language is somewhat unbalanced. Extremely verbose and explicit when it comes to integer arithmetic, for instance. Yet when it comes to references, it's all very implicit, and abstract. Zig has way more concrete terminology like "comptime". I think in that regard, Rust did miss the boat a little.
@@alwin5995 What "hell" are you speaking of? It's literally one of the easiest things in the language. Unsafe manual memory to interface with a C-FFI on the other hand is real hell, but needed.
Thanks for sharing your experience.
How did you originally get into it? And in what projects have you used it so far?
I've also heard several times now that it speaks to a particular set of people because of it's very stringent bottom up approach.
@@LinkEX I originally got into it because of a friend's recommendation. Didn't think much of it for a while, but I came across NoBoilerplate who made some excellent videos on the language and I was hooked.
It was a while before I had the chance to really make anything, but I had fun when I did get the chance. Now I focus pretty much all my coding time on it, I'm working on a game with the Bevy engine (which taught me some very valuable lessons about program design)
I would say to really just go for any kind of project and get a feel for what kinds of things you like doing with it. I recommend making some simple terminal programs that process files, handle user input, etc. first, then moving onto some larger stuff like API interactions or whatever you fancy.
I will say that Rust expects a very specific kind of code. It is, generally speaking, "good code", so if you are doing it wrong it will be far more painful than most languages. You will have trouble trying to hack things together, whereas refactoring and laying things out will be extremely easy once you have an idea of what the structure should be.
Also, if you are having trouble with lifetimes, I promise you that it is 100% possible to entirely avoid lifetimes unless your algorithm specifically requires manipulating them. Do not fall into the trap of adding lifetimes to everything and letting them corrupt your entire codebase, just try to re-think your solution and you'll find a way.
My own response to complaints about the Rust community, would be to cite my experiences with the World of Warcraft and No Man's Sky's player communities. World of Warcraft was a game which was highly competitive; during classic World of Warcraft, Naxxramas, the endgame dungeon, was sufficiently difficult that less than 5% of the overall playerbase was able to even enter it. As a result, WoW had a playerbase that was much more inclined towards elitism, and influenced by the immense competitive stress that that difficulty caused.
No Man's Sky, by contrast, is the complete opposite. It's an almost exclusively PvE game with no elite or end game content, where resources are infinitely abundant and renewable, and where everyone can obtain anything. The community are correspondingly far more relaxed, friendly, and welcoming.
When someone encounters a negative community related to any particular interest, therefore, I think it's important and constructive to realise that there are almost always structural variables which incentivise said negative behaviour; and that rather than simply complaining about said behaviour, it should be realised that if the structural elements are modified, the behaviour will improve by itself.
My favorite anecdote in terms of wow elitism is how at the end of Wrath with all the catchup mechanics the game was so accessible that everyone had amazing gear and everyone was "uh, i'm so great but all the noobs got my gear, so wish the game was harder" and Blizzard listened and in Cataclysm the same people whined that heroics are too hard.
I would say that the issue with rust is that some principles and good things make it look perfect while it's not : its use-case is not for everyone and it's not easy to jump to from any language.
Because some Rust fans don't see what issues Rust has, they (a part of the community) don't explain problems that can happen in/with Rust and thus they attract a wrong audience. They really don't understand what issues people have with Rust and thus blame the people instead of helping them. Fans of Rust mostly can't see the difference between what people expect of a language and what Rust does.
Between those fans, there are probably a part of inexperienced people (because it is a new language with growing community).
Snake 🐍 at the bottom of pyramid reporting for duty
It's at the bottom, because it's the foundation for all the prototype programs that are finalized in languages higher up...
They laugh at us, and say we're at the bottom of the pyramid. But then we hit them with blazingly fast libraries written in C for the small but performance-critical parts of the code, and we suddenly got the holy trinity of speed of development, runtime and readability where it matters. 🐍📈
White space is syntax snake :D
Python: at least it's not Ruby (even when Ruby has improved some 10x, if not 100x, since they rewrote their compiler/interpreter)
@@fg786 while using C
the moment you write Pin
True. At some point _even Clippy_ recommends using aliases
Exactly, my instant first thought upon seeing that was "that looks exactly like the BoxFuture type alias."
Also, while it looks horrendous at first what's so difficult in it? It's very clearly saying its intention if you spend like an hour or so to read the documentation of Pin/Box/Future/Send and have a basic knowledge of Rust. It becomes pretty self explanatory what that type composition meant to do...
@@balint133 Pin is not easy to understand at all; not only for humans, but also for the compiler itself (getting compile-time stack overflow on Unpin check isn't that fun); it might be "basic" in some uses, but absolutely not so in reasoning;
that's why [Local]BoxFuture and async-trait exist:
you just get something that
1) is a future
2) can be created from a future
3) captures lifetimes somewhat correctly
4) is a concrete sized type
5) *but*, not so conveniently compared to proper async fns, either requires you to either put Send on generics involved or can't be used with all runtimes
so instead of dealing with all of {Pin,Box,Future,Send,dyn} you just need to think of Future and Send
and Pin just becomes sort of an implementation detail
oh, and also, it's way shorter and easier to read and write without sacrificing clarity, which is The Reason why alias form is preferred
Rust is easy, you just have to use it both at work and personal projects for 5+ years without polluting your mind with any other language.
I failed and switched to BeefLang. Never been happier (unironically)
Is that even possible?
@@tempname8263 I just opened the language website and there on the first page was a drop down with a bunch of examples. I have no idea why more languages don't do this.
@tempname8263 I just opened the language website and there on the first page was a drop down with a bunch of examples. I have no idea why more languages don't do this.
"BeefLang"
I just opened the language website and there on the first page was a drop down with a bunch of examples. I have no idea why more languages don't do this.
In terms of higher than C++11, anything bigger than 11 has all the baggage of everything 11 and before.
There's a lot of artifact foot guns built in to the reverse compatibility.
The one horrible/great thing that came after Java 8 was that they were willing to just kill the unsafe functions and force people to update or stay in the old unsafe version.
You're free to not use the old stuff. The footgun potential is WILDLY exaggerated.
Yeah, the fact that C++'s STL has this huge ball chain of forever backwards compatibility is what causes all those footguns, esoteric best practices, random terrible performance, and inconsistencies.
Yep, and safety is still opt-in. When you put me in charge, I'll just throw safety in the wind, and this will come back to bite me later. I'm a lot better of with Rust than even modern C++.
@@earx23 Unsafe code is just one aspect of "bad code". Rust won't prevent you from writing bad code. If you can't stop yourself from writing bad code, you need someone else to guide you until you can. Regardless of language.
Come wrote code for Google which is using c++20 with additional guidelines to ensure good code quality.
They have annotations to ensure better thread safety when using mutexes and tons of other tools and code style guidelines to help.
Still getting segfaults and other issues very often.
It's not nearly as water tight as Rust.
Ok "skill issue" isn't actually a counter-argument to "I have issues with how difficult it is to learn how to use this tool properly, and as a result I do not recommend this tool."
Maybe, but the way that person failed in error handling shows he didn't even look at a basic documentation.
“Just give me the garbage collector” perfectly sums up how uninformed this man was before choosing Rust. People choose Rust for performance and security because their difficult compiler forces you to write secure code while still granting the flexibility to be fast.
This article 100% reads as I didn’t understand the idioms of the language I chose to work in and it’s Rust’s fault not mine.
How many times have I heard "We chose Rust for it's safety/types, not for its performance!" on twitter and in different articles... Furthermore, Rust evangelists generally advise to use Rust for everything. At least that has been my experience. I am soo close to muting the word Rust on twitter because of how much I hear about it, wanna guess how many of them preface with "Only use this when you need absolute performance"? Correct. Zero.
@@secondson4536 I'm using rust in 100k lines codebase, and not for performance, but for correctness and I'm very happy with it. best decision I've made. He defintely had skill issues. I did have struggles in previous "side projects" trying to learn rust over around 2 years (was working in TS in my main job), only when I was confident with my skills did I start with a real project. He jumped straight in and got destroyed, and now blames the languages, yes, Rust learning curve is steep, nobody is denying that. if you want easier language go with Go. but don't blame your incompetence on the language.
Also so many people saying how Rust is great because of all of those features, which normally have nothing to do with its speed. Yet when it is critisized people like you show up defending bad parts of the language (that are omitted from those praising articles) with either skill issue argument or the "Well its speed is why it is like this".
Here you don't get one of the main points of this article: nothing really told this person about those bad parts, as though they don't exist. This person, probably just like me, heard from every corner of programming fan infested internet about how Rust is great with approximately 0% of them mentioning parts where you might encounter some issues.
@@secondson4536 I mean if they read the book they would have realized that it wasn’t going to be as “easy” as they had hoped for. I don’t know a single person who doesn’t recommend the official book as a first learning resource. And I’ve know plenty of people who have struggled because they refused to read it.
In no way am I saying that it’s a perfect language. I’m just saying that the complaints this particular guy is making are in complete antithesis to the objective of the language itself. So stop putting words in my mouth saying that I’m claiming things.
I understand his points. I also understand that he completely missed the point of Rust and is now painting it as a problem that anyone who bothered to learn what Rust is about before refactoring their entire project in it would have understood.
@@secondson4536 I'll give you one example so you can understand that it is really a skill issue. Async programming, there is several options such: regular threads model, green threads, minimal stack async , or eventloop, now each language chose its model. Go went with green threads + gargage collection, the downside is you have a larger stack for each thread, and the runtime is backed into the language, and obviously garbage collection. nodejs went with eventloop, where each task is blocking the whole thing ..... EACH language made compromises, there is no perfect solution. Rust made the compromise of no garbage collection, and minimum runtime, and so we ended up with this version of async, which consumes very low memory compared to others, very lightweight, but has strict rules to follow, such as Pin, which is basically helps moving variables between each async operations, but in order to understand all of this, your really have done the work, and know a lot of concepts of computer science, this is engineering, you need experience and know how, Rust is not a beginner friendly language, I would never suggest Rust to an average run out of the mill software developer, which are the majority unfortunately. I chose Rust knowing full well the downsides, but I need to parse large files without worrying about OOM, and to handle many clients without paying thousands per month in hosting, and to be able to deploy several times a day to production without worrying about breaking stuff. Choosing a language means evaluating the tradeoff, you can't chosse a language if you don't have the tools to know what those tradeoffs are. For context I've been programmig regularely for 15 years, and started dabbling with Rust in 2015. I'm not saying Rust is without flaws, but it is stupid to expect that there is a language that doesn't have flaws, and it is more stupid to expect the language authors to present design decision as flaws, when each language made those decisions thinking they are the best for them. they may not be for you though.
Algorithmic trading != HFT (high frequency trading). HFT uses algo trading, but you can trade slow with algorithms as well (and is done with virtually all institutional trade orders).
5:20 the biggest problem with Rust & async is that Rust _still_ hasn't cleaned its own house up about it, meaning it only very very recently has decided on how to do async functions in traits. That's a big problem because its standard library still hasn't fully caught up to it. & even its very latest release still doesn't seem to have closed the issue entirely as there are still corners which are unimplemented / causes compiler bugs when combined with aliases to traits which are sync but are aliasing async functions.
I'm just sticking to doing enum powered state machines. It's more work, but it's very understandable.
Yeah it all feels very "work in progress", but I don't envy the ppl that work on trying to solve this. Rust has to type check, memory lifetime check, static dispatch for generics (and probably more) all at compile time, which is hard enough to do for strictly synchronous code. Imagine the nightmare trying to create a standard solution for all these constraints in an asynchronous context, whew
I needed to make a CLI program for my company that covered quite a few data processing and report generation bases that was fast for invocation on servers. Of the selection of native-compiled languages, I went on a tour. The guy before me had already worked on a prototype in Rust. I tried to continue working on it. I went from positive on Rust to wanting to die QUICK. Eventually I settled on Nim. Remaking the program was EASY. New features are EASY. Refactoring is EASY. I ROCKETED past the old featureset the company had languished in for 20 years. I have never before worked in a language that has made my life this damn easy while producing executables with a speed that'll knock your socks off. I experimented with D back in the day and it never got CLOSE to Nim. My job is a JOY because of this damn language and I never want to go back. My rule of thumb: If you're not embedded, you can probably let a GC/RC do the hard work for you, and scoop up the advantage of not needing to write a line of memory code ever.
The TLDR - pick the right language for the problem. Maybe you don’t need rust level performance.
i hard agree, I've been porting a lot of my company's internal tools made in python 2.7 to nip and ive never felt this good about my code lol, i could optimize the code off of my head and seeing it actually made me smile
Sounds like a problem I faced but they forced scala on us out of the blue. It turned over half the staff within 6 months (including me) as one by one we simply rejected the idea. The most experienced people left first. Not only cause they interview better but because they spotted the obvious issues fastest.
I was 2nd to leave the office of 50 people after 8 weeks. The other 20-25 left over the next 4-6 months. I only found out about it because I ran into somebody a year later who still worked there. After 8-10 months of this they did the entire project in python in 2 weeks.
Some of these new "fancy" languages just don't work as well as people think they do....
Ironically I also hate python but at least I can get stuff done with it. How to confuse a python programmer? Ask them to show them a for loop. (Hint: python doesn't have the ability to do one naturally, it needs to use while to get the same result). Works even better when somebody does the loop with range btw :P
@@slider799 You can use for loops just fine in python.
They're just wrapped in iterators (IE, range(), tuple.iter(), generators, etc.).
I feel that python for loops are more similar to the `for (int i : myIteratorVariable) {}` syntax in C++.
IMO, this is actually better than the standard non-uniform three-part for loop syntax (`for (variable initialization; conditional; incrementor) {}`).
You can do much more with it without having to write nearly as much code.
Also, this is what Rust does as well for it's for loops, so it isn't like Python is the only modern language doing this.
@@Kane0123 That mindset isn't good though, because you effectively eliminate your ability to use tools. If you switch between even 2 languages, then any improvements you make for your workflow - whether that's learning a new concept, reading the documentation of a library or learn about / fix a bug in your tooling, etc - will be 50% less effective already. Which is making near all improvement uneconomical. This I think is the reason why so many developers are stuck. Instead of mastering one thing and getting really good at it, they spread themselves thin and have to relearn the same thing over and over again, while at the same time not having the ability to fix problems in their workflow.
You can still implement helper functions in Rust even if you haven't fully wrapped your head around every single bit of its signature. Simply add the bits when the compiler tells you to as you reference the function elsewhere on the code. This approach has always worked for me.
22:44 teej mentioned
"We don't do that here"
Lets go!
Obviously this video declines in quality around the 22:30 mark
34:54 It's the enthu, Prime. The childlike enthusiasm of discovering something new or finally realizing the potential in something that you are already aware of, it's what makes you an avid learner and a great developer. I wish people didn't lose that enthusiasm over time but they just do, it's what results in loss of interest and I fear eventually Burnout!
Fun Fact: Every human has skill issues.
Therefore pointing to skill issues, because programming language is not optimally designed makes no sense. Sometimes, the skill issue is not the actual problem.
This perfectly describes my issues with C++, raw memory access with (until recently) no automated managed memory because "it's something the devs should do" is utterly insane, and not a gotcha for a design flaw. To add to your point, the idea of "skill issue" implies that especially on a team, everyone is 10x devs with no human error and knows exactly what they are doing 100% of the time. Obviously that's not the case which is why most devs try to automate much of the work to avoid these issues (checkers, linters, static analysers, CI, etc)
@@itermercator114 "raw memory access with (until recently) no automated managed memory "
How old are you? Automated memory management has been in C++ since Cfront.
@@itermercator114 " C++, raw memory access with (until recently) no automated managed memory"
Destructors have been in the language since Cfront. Vector has been in the standard since C++98.
"raw memory access with (until recently) no automated managed memory "
How old are you? Automated memory management has been in C++ since Cfront. Vector has been in the standard since 98.
« To master C++, is like mastering Rust » I have never read anything close to such a high level of self-confidence about C++. I wonder whether he’s ever written a move constructor in C++, or even actually moved some data to realize since C++ does not have an affine type system, you can still read and write to the (now uninitialized) memory of the previous object. That kind of hot takes :D
Rust channels are actually amazing. Including several types of channels like oneshot etc. The tokio docs are great on it as well.
I just started learning Rust and I'm working on a very similar project as the article author - I've landed on channels for a lot of what I want to do within the system and so far, it's working well and is pretty straightforward and intuitive to write. Not having any issues that the OP had.
I was reading in detail through the official tokio tutorials recently and all I can say, is that if you use Pin and you are not absolutely sure why you have to reach for it, you will not finish your project well. Generally it should be possible to never touch Pin. And as far as I understand, the main reason to use it, is to save an async boundary manually, so it doesn't drop for example in a switch when something else finishes sooner, making it possible to re-pull later. It is a too-manual way to manage awaits. Like mutex, it exists only in case you really need it and you know what your are doing.
Channels on individual spawns are the way to go.
@@TheNoirKamui I was going to say that but I think in that case he needed to anotate the type to satisfy the trait bounds in the function signature. Technically he didn't "use" pin, he just needed to say that his function would receive a closure that returns a Future. Really its not even that big of a deal, it looks wierd the first time you see it, but then you understand why and move on, OP was beeing very dramatica about it, maybe if the had taken the time to learn instead of asking chat GPT he might have handled it better.
@jonnyso1 You are absolutely right. Considering there was no async in rust just a few years ago, it is amazing that it works. But there are still small gaps with async. For example tokio::join! will let you run 2 async functions that cary a lock over .await giving you a deadlock. Doing the same in spawn gives correctly an error. I remember bringing that up in some tokio chatroom and being told that they wouldn't fix that because it is all as expected and restricting otherwise...
I also heard some people criticize the push vs pull model of the polling mechanism... though I don't understand that enough to comment.
And lastly, the problem of async runtime lockin, that you can't just transfer your code to another runtime... That you can't just use a crate written for another runtime than yours.
Rust async... is in some way amazing and in other kinda... Feels like much more inteligent people than me should think about how to improve it. But there is definitely space for improvement.
@@TheNoirKamuiNever hold a mutex over an `await` point.
The async "safe" Mutex should be banned on Rust, they are not a good solution.
37:35 forget about FPGAs and code... They are literally putting data centers in building NEXT TO THE EXCHANGE to minimize the delay.
This is insane.
At some stock exchanges, everyone gets a fiber connection WITH THE SAME LENGTH AS EVERYONE ELSE. Just so everyone has the same latency to the server(s). It's just madness.
@@piff57paff I often feel like those resources could have been put to better use by doing, like, _anything else with them_
It's very hard to say anything in general about what the performance requirements for algo trading are like because every company is doing something slightly different. There are some companies doing the FPGA thing and worrying about speed of light delays, but there are also companies just running python. Jane Street famously runs OCaml (not super slow, but far from the fastest). There're probably extremely few people who can speak authoritatively about algo trading in general.
@@Takyodor2 Depends, do you want to have predictable prices at the gas station and grocery store? Do you want people to be able to afford to grow food? People think that some guy at work trading stocks on "hot tips" is somehow representative of the entire industry. People working there full time only make money by providing value to their customers.
@MaxHaydenChiz Buying groceries and growing crops worked fine for thousands of years before low-latency trading was invented. I wouldn't mind if stock trading disappeared as a whole, and companies could focus on providing good products instead of making the graph go up, but specifically low-latency trading is on a different level of unnecessary.
I don't understand why everyone just HAVE to write async code either. It doesn't make sense to use coroutines for like 95% of all problems if not 99% (not exaggerating).
Why not just do it normal and multi threaded? It is NOT that hard. It is only coroutines that make it hard! STOP USING COROUTINES. You are NOT getting a performance benefit out of it.
OP was probably not aware given his background
@@okseaj The mongodb crate he was using has a massive signpost on the docs about how the offer a convenient non-async api if you flip on a feature flag. If you cant read the docs for the crate that has been ruining you for the past 18 months, idk what to tell ya.
@@leeroyjenkins0 I think this is a problem for people who has worked exclusively (or for all intents and purposes) in a single threaded environment with promises/futures/coroutines.
Managing your own thread pool where you post tasks and work to and from is absolutely trivial in C++ and it is even easier in Rust.
If you need async IO, use C++ and the OS utilities (epoll, poll, select, io_uring) and real parallelism with multi threading. Not only will your code be much, much easier to read and reason about, you don't sacrifice any performance either. Because coroutines comes with overhead.
I think you are right, too, that the appeal is that it "looks synchronous" (guess what, a thread pool where you post tasks and await on the promise also looks synchronous, because you need to collect/wait at some point).
I don't see how introducing tokio and async for downloading a bunch of files (as an example) is *easier* than having a simple thread pool where you post a lambda that downloads a file and signals back when it's done. Because the thread pool will not leak into every corner of your application, it will have a crystal clear API-surface.
This is not to say that coroutines or async/await shouldn't be used. It works *superb* in JavaScript/typescript land. And it has its use cases. But I argue that is 1 out of a 100 times, if even that.
@@leeroyjenkins0 right, but that's my thing; you can get `const result = read().wait();` using hand rolled thread pools where you post a task and get a future back that you wait on.
What's also better about this approach is that the API-surface is crystal clear. This large, obstructive and intrusive system doesn't loom over your entire code base making it hard to reason about, while also making performance (probably) less good, seeing as how coroutines always comes with an overhead.
Handrolling your own thread pool and using message passing is trivial in C++ even, it's even easier in Rust (using channels for instance). We have all the building blocks, mutexes, atomics. We have ways of signalling readyness on sinks/channels, using for instance operating system utilities like epoll, poll, select etc. Using these are also easy. And they don't come with the mental context that using something incredibly intrusive like Tokio comes with.
But yeah, I think you're right the appeal comes with that it "looks synchronous" but as I said, using read().wait() on a thread pool future is *exactly* that same thing (std::future in c++, I don't know the name off the top of my head Rust, but technically a mpsc channel works just fine here).
Add to that that debuggability is many times easier with multi threading than it is with coroutines. Many, many times easier.
We wrote a bunch of our network applications in Nim in a company that has applications in Python, Golang and Rust.
Nim beats all of them in terms of developer productivity and run time speed.
nim vs julia
You don't use reference counting and synchronization primitives to "get around Rust". You use them because you are implementing systems that require these tools for correctness. They would still be necessary in any other language with concurrency, but Rust forces you to use them for correctness.
They always say it’s a skill issue because they want to see you suffer as they did. Once they overcome that skills issue themselves they will never admit how hard it was or that it is bad design or anything, they will tell you that it is just a skill issues and will take a popcorn and watch ur struggles 😂
I see Rust as largely a C replacement. C would not be my first language to build a trading platform with. It would be my first language to build an OS with.
Just imagining writing a UI in Rust gives me nightmares.
Isn't Zig a replacement for C?
@@dwight4kye
How is it C replacement if C still a language to make OS. If you make OS then it is good for anything.
@@sillymesilly By replacement, I mean C was pretty much the only language used for systems programming until Rust came to be popular.
I dont literally mean C will just go away and Rust will be the new defacto thing
@@sillymesilly Good point.
This is so true... I came from weakly typed languages and getting used to duplication in strongly typed languages. It's so hard at first.
Snake 🐍 and big yellow square 😂🤣😂
The `thiserror` crate in Rust is really nice for handling errors IMO. You can easily define errors that hold data, so any error where the message alone isn't enough to know what happened, can also have additional context.
My personal view on how nice the Rust community is: Reddit is the most toxic, but also an unofficial one. Discord has their share of toxic members (they increased their numbers after the remaining official teams moved to Zulip), overall very nice and friendly but you can end up ignored because of the amount of message traffic there. Zulip is the nicest and also the official one, I honestly never saw someone being toxic without consequences there.
Besides the general community, on the Rust teams, there are around 2 or 3 members that are more prone to torvalds someone (yeah, I turned Linus into a verb), one of them sure did say quite unfair (to say the least) things to you. I did have very nice interactions with them before and I feel it is something like Linus Torvalds (heart in the right place, but can be very extra on particular occasions) and I hope they improve like Linus did in the past years.
17:50
```
if err != nil {
// handle error here
}
```
I am surprised that people dislike this form of error handling - it's my favorite. Great point by Prime.
until u work with real world project.. 60% of ur codebase littered with that.. not fun at all. tagged union is way better for that
@@_slier This is extremely similar to tagged union in practice.
Perhaps I don't understand your point?
"Handling NULL's and bad arguments is good code." Should not be a hot take, but here we are, hundreds of languages later, trying to escape from: if pointer == NULL { dont_break_everything()}
I agree that C++ is about as hard to master as Rust. The difference is that until you're there, in contrast to Rust, C++ does have a pit of success where you obliviously write code that appears to work but is actually full of undefined behaviour, particularly if concurrency or threading is involved.
Note that I really like using C++. But even the newer language features have their gotchas and footguns and can fail in surprising ways if you try to be an ounce more clever than you really are.
C++ is pretty chill tbh
@@tinrabyou just want a language to do the work for you how about stop being lazy and do the work you're supposed to do
@@tinrab I agree that Rust tooling extremely nice and that it has many modern features are that either missing in C++ or much better integrated with the language (enums, pattern matching, interators and first and foremost result types for error handling).
But C++ does have ranges, it does have std::expected. Yes, both can be clunky (to the point where you may think twice before reaching for them), but if you need them, they can get the job done. Much of what you do in Rust with macros you can do in C++ using templates, sometimes even easier so. For certain topics, the C++ library ecosystem is much more developed than in Rust-land (e.g. scientific computing, GPGPU), making up for some of the deficits in terms of language and standard library features.
Also, while build systems in C++ can be a huge pain, at your job it might be that someone else solved the issue in some way and you don't have to deal with this too much. Or you have one of these days where you just have a project set up with Conan, and you add a library with just a click in your IDE and a single line (maybe one and a half) of CMake, and it just works. If you close your eyes and pretend your CMakeLists.txt is a toml file, it can almost feel like cargo. Now of course it is more effort to get to this point in C++ than in Rust, where these things just work out of the box. But I would argue that the time you need to spend on these things roughtly equalizes the time you spend with the borrow checker. I could be wrong, depending on the project.
The true issue with C++ - to me - is that after this learning phase, you can write somewhat defect-free Rust code. Whereas you can write C++ code that compiles just fine, but may be full of edge cases where something breaks. So while the tooling is nice, the real value proposition is that if you are half-decent in Rust, you can contribute to a large codebase without running the risk of creating CVEs or hard-to-debug crashes. If you are half-decent in C++, on the other hand, you are just dangerous enough to write something broken that passes code review.
But to really master both languages, I think it takes probably the same amount of time.
@@wolfgangrohringer820 C++ has all the things. Its just its things are spread out more. Rust on the other hand forces you to use them. Ironically sometimes in really broken ways. The worst thing for rust is all the useful stuff isn't written in rust cause its new and nobody (eg me) won't touch it cause it means writing wrappers around 100's of underlying code bases and then pretending the rust safety systems are working where 7 different code bases still own one pointer :)
Rust expect a perfect world. We don't live in a perfect world. Last evaluation I did in it. To get it done in rust was $1B+ Costing or so.
I actually like C++ a lot, maybe it is because I'm used to it. And using modern C++ (Smart Pointers, Standard Library, etc.) and a modicum of programming good practices (programming patterns when applicable, etc.) is not difficult at all to write pretty safe and extremely fast code.
I am not saying it is more or less safe than Rust, or better or worse, or whatever. But, when people portray it like this timebomb just waiting to misbehave, I just chalk it up to skill issues (how dare I!!!!!)
I think people whose first language is something else than C/C++ cannot appreciate Rust and complain about the way it is. Going from C to immediately C++ to Java to a bit of Python to Rust is like coming back home after long time of being gone.
This. Rust isn't for those high level devs. My programming journey was raw z80 assembler, then raw x86 (not even _64!) asm, then C, then C++. After, I learnt webdev with pure JS and PHP, then some Java for getting an actual job. Here I am coming back to Rust, and actually being able to appreciate it because I *worked* with assembly, I *worked* with low-level embedded C. I *know* what Rust brings to the table and why it's so special. I'm not saying that it's the best of it's kind, but I'm also saying that I'm never programming for a SBC again if its arch has a rustc target. Rust also got me really interested in functional programming with the way that it tries to make everything immutable by default, has everything be able to have a return value, has first class support for closures and all, as well as the traits system mimicking interfaces. Since I know Java, I might want to get into Scala or Clojure.
Rust isn't just my new favorite language, it was a genuine awakening. I know that I sound like those crazy twitter rusties, but honestly I get it. Everything feels perfectly intuitive on an abstract sense while also making sense for my low-level old assembly programmer brain. I didn't even know that it was possible to marry these two parts of me.
2022: Rust is the best
2023: Go is the best
2024: Zig is the best
2025: Gleam is the best
2026: ???????
Gleam is the best for making political statements on their main page, Rust comes close
@@meanmole3212 I just checked Gleam's homepage. So do you hate black people, hate trans people, or do you sympathize with Nazis? This is a pretty low bar for setting a community standard around decency.
@@MrKlarthums Why does the page not say that white lives matter since whites are a global minority in the world and about to go extinct as a result of uneven birthrates and immigration to their home countries, and that black people commit disproportioned amount of violent crimes against whites? Deportation and closed borders matter! World peace and a home to live for all people of the world!
Is that statement a problem with you, or with THEM? If so, it seems you hate white people and you sympathize with silent on-going genocide. That's pretty unfortunate since all I am suggesting is that we set a low bar community standards surrounded around decency for everyone to enjoy equally.
If you think this is "trolling" or "yep, you are a nazi", then explain to me what in my statement was wrong or trolling?
@@MrKlarthums
Why does the page not say that v\/hite live5 m_4tter since whites are a global m1_nority in the world and about to go extinct as a result of uneven birthrates and 1mmigrati_on to their home countries, and that 8 l4ck people commit disproportioned amount of \/i0lent crimes against whites? D_3portati0n and closed borders matter! World peace and a home to live for all people of the world!
Is that statement a problem with you, or with THEM? If so, it seems you hat_3 white people and you sympathize with silent g3n*cic|e. That's pretty unfortunate since all I am suggesting is that we set a low bar community standards surrounded around decency for everyone to enjoy equally.
If you think I am trolling or the n-word, please correct me on what I said and correct my wrong statements. The numbers exist because of 1984 censorship.
It's Mojo baby, yeah
34:56 I "recently" discovered that you can use catching an exception for correcting the user input (aka during something useful, instead of just throwing an error and or moving on).
Ofc u can't use it everywhere but at that time i thought it was pretty neat (was like 6y ago)
The moment a language constantly battles against the programmer, I'm out. It can be as annoying as the forced indenting in Python to the idiotic loops and hoops you have to go through in Rust. I want to enjoy writing code. Fighting it, isn't enjoying it. And all that crap about milliseconds and "whichever language is the fastest"-futile discussions: don't fall for it. Choose a language that you enjoy writing in, and one that gets the job done. For me that's TypeScript most of the time. And when I want to get down to millisecond level, which I hardly need to do anymore, it's C++.
Great 👍
I don't want to be a jackass, but I can't ignore a small detail of your comment, so I apologize in advance...
If Python's forced indenting is working against you to the point that you give up on the language, then I'm scared to see what your code looks like. Python has MANY disadvantages, but forced indenting is definitely not one of them. That's actually worse than saying that you hate C#, C++, or Java because the semicolon is mandatory... I mean, the forced indenting at least helps your code to be a little bit cleaner and easier to read.
However, I do agree with the rest of your comment - you should always stick to languages that you actually enjoy writing in and that solves the problem that you're working on.
@@QueirozVini I'm capable of indenting the code as per my own choice. I don't want to have a compiler nagging when I align blocks of code using mixed tabs and spaces, which look fine by me, but apparently not by Python.
@@QueirozVini for most language i just put { } and auto format with my setting and my code never fall over the loops, why the heck I need do indenting my self when I always automatic everything with program
to each his own, but I hate writing C++. Rust just works. C++ always crashes and is a pain pain pain to debug or collaborate with other devs on.
I built a bunch of trading algos at one of the largest banks, doing trillions of dollars in volume annually. I can tell you that speed depends a lot on the market dynamics. For equities, you tend to require a lot of speed because the market data isn't throttled. For most markets, you can get away with even python in the trading logic layer.
Having said that, Rust is being looked at for the market data and execution layers in the tech stack. Pretty much anything trading infrastructure is a good fit because you do get the speed, safety, and great handling. Typically that has been dominated by C++ since forever.
To me, it sounds like the writer chose to do the entire system in Rust, which probably isn't the best. Writing to databases doesn't need to be bare metal speed. These days, I like the idea of using an easy language that I can trust to maintain great uptime metrics for basic server infrastructure like database writing, which Go would be a great choice.
@@samuraijosh1595 in FX the two primary spot exchanges, EBS and Reuters, do anywhere from 50-80 billion on a normal day. Over the course of a year, you're in the trillions. Different story if you're talking equities which trades in the hundreds of millions.
@@samuraijosh1595 the two primary exchanges in FX, EBS and Reuters, do roughly 50-80 billion in spot volume daily. Over the course of the year, that is in the trillions. FX also trades primarily OTC, i.e. you're trading directly with a bank, not over the exchange.
"Average daily volume in total over-the-counter (OTC) foreign exchange instruments (including spot, outright forward, foreign exchange swap, and option transactions) was $1,021.0 billion in October 2023."
- New York FED
Tbh if rust requires so much effort to learn it, why not just learn to not suck at C++? It's all a "skill issue" by this logic
You took the words right out of my mouth.
Because with the huge amounts of footguns and UB even modern C++ sadly still has (especially once you want to write abstracted code), your "learning to not suck" won't help you much anymore because you'll always trip over _something_ that will then only be caught by ASan or UBSan.
The advantage Rust gives you is that once you're over that "burden", the base understanding is what you need and you can code with more ease.
Also, but this is personal taste, I prefer the "opt-in" fulfillment of Rust Traits compared to the "by-structure"/"-happenstance" nature of fulfilling Concepts in C++. Also the fact that it actually has a decent package manager.
I think the point about community is an important one. Rust has a pretty high learning curve, and unfortunately that can tend to attract people that prefer to pat themselves on the back rather than actually trying to build things together with others. At the language level though there's a lot of focus on things that make it more newcomer friendly such as good documentation, error messages, and tooling, which I see as a really good sign.
++1
In the early days I hated the Rust compiler.
After reading a bit, I wanted to write something.
And the compiler "hammered" me with nitpicking.
I understand why.
But let me be! I'm learning!
Give me a flag to tell the compiler "I'm new, be gentle, this is not production"!
I'll turn that off for production. Heck, turn it off automatically for release builds.
Think about learning a foreign language. You want to start using is asap. That way you learn faster, in fact.
But now imagine that on the other side you have an native who slaps you every time you use the wrong gender, or plural, or word order, or pronunciation, or accent.
Can you understand if? Great! Let me be! We are communicating! That's important! I'll get better in time.
You can maybe give me flags to relax certain checks only.
Complain about my grammar mistakes, ignore my accent :-)
Like any C/C++ compiler. I can turn off certain checks, and the defaults are not too annoying.
Rust comes with -Wall by default, and no way to relax that :-)
They used to say Rust would replace C++. The reality today is that much more code is being written in C++, and the language is growing faster than ever. My best professional decision 15 years ago was to focus on well-stablished technologies such as C++, Python, JavaScript, SQL, etc, and not stress about reinventing the wheel in niche languages like Rust or whatever comes new.
Modern C++ (i.e. C++20 onwards) when written well can be extremely safe, the chances of getting a memory leak / buffer overrun / nullptr / race are minimal
@@markp8418 Agree
@@markp8418assuming you don't use rare and obscure features like std::vector::pop_back. Otherwise you get undefined behavior and your console starts printing 42, even though you unplugged the computer.
Memory safety in Rust is a tricky issue,
Go language allows data race conditions. But it offers good and clear ways to avoid it. Result: Websites specializing in software vulnerabilities announced 39 data race vulnerabilities in Rust applications. Versus 2 data race cases in Go applications. Although we know that Go applications are much more than Rust applications, concurrency and parallelism are used extensively.
It's the same with the memory leak issue
I've used a lot of C++ applications and never experienced a memory leak.
I used two rust applications, One of them was leaking memory.
Rust community deliberately shows the good side of its language as opposed to the bad side of other languages
@baxiry. I see more future in Go than in Rust. We'll see. In the meantime, I will focus on building things using traditional tools rather than learning everything new that comes out. At least that approach always works.
Can't agree more with "wrong duplication is better than wrong abstraction", i hate when for the sake of not writing the same 2-3 lines of code in different places we make the codebase unmaintainable by abstracting increasing the actual code complexity 10x and making almost impossible to change a little bit without breaking everything.
Not all trading algorithms require millisecond precision. You're thinking only about HFTs, dawg.
erlang's biggest strength is that it never crashes, which is also its biggest weakness, because now we have more software doing things in the world
Can you do a video on what you currently think about GO? Are you still using it? Did you ditch it after not liking it? Curious..
He did this already. Search the you tubes
There is a point to the lack of null pointer crashes and suck. Sometimes, crashes are great: you get an error very soon, with a nice stack trace. Sending the error elsewhere (which is what most people will do when handling one) may mean anything from having a useless stack trace to broken program behavior in subtle ways.
Rust backtraces only apply to panics. He's talking about how a function returning Result::Err doesn't convey information about where it was constructed. You only know where it was handled, not where it originated.
If you know where it were handled, you can easlity figure out where it came from, no ?
@@jonnyso1 Depending on the codebase it could be easy to figure out. But like he points out in the video, if you use "?" to bubble up errors a lot and have an app that does lots of file IO, and your app errors with "No such file or directory"... What file did it not find? what function returned the error?
Obviously you can code around those issues, but it's not always straight forward and doesn't come out of the box really.
@@dork_side That's what I didn't get, you need to specify what type of error you're returning, you can't just use ? and it bubbles everything, if your function is returning an error, you know which error it is, its right there on the signature, no ? Or is it some anyhow thing ?
@@jonnyso1 that only works if your function only has one failure mode. If you use IO and some other fallible thing that returns another error type in one of your functions you either have to use anyhow, make a custom error type that wraps both, box dyn error, etc. Eventually you usually get to a point where you can easily bubble up many similar errors from a potentially large codebase and tracing them back to the origin can be hard. There are ways to solve that problem yourself, but I can see how this could be a pain point when you’re used to exception stack traces.
@@dork_side You simply write a custom error type and use "thiserror" (or similar) to compose said errors. After that knowing where your error comes from becomes dead simple.
Primeagen just smacked me in the face with his completely brushed over and non-chalant "no-squeal"
feels like a 100% skill issue. The problem with rust, however, is that it's new and cryptic. That adds somewhat to the skill requirement, but that's not the problem here. I haven't written a single line of rust, but can already 'get' what's going on. The problem is the lack of software architecture design experience.
@@curio78 any lang is just a fancy system for translating high-lvl abstractions into machine instructions. In a way, it's just a tool designed to be used by a specific person to do a specific job, nothing more. But intent must always come first, because every work is defined and driven by some intent. Any work without an intent is meaningless. Tools only make the job easier.
@curio78 sounds like you tried rust for 10 minutes and gave up. it's not _that_ unreadable. it's actually fairly readable for most things, but takes time like any language to get used to.
@@curio78 anyone who says rust is unreadable hasn't used it for long enough. The syntax is absolutely fine once you use it for a while. You could use the same argument for C as well. My dad is used to writing Visual Basic and thinks C is unreadable.
@@eyz-4 I never said it was unreadable, it's just that I can get (almost)all the benefits of safety with c++ RAII and proper software design. But it's way less brain taxing, although pretty much as verbose and cryptic as rust
If you didn't write a single line of Rust, you don't really get it.
Try writing, and the compiler will slap you around until you lose any appetite for Rust :-)
At least in the beginning.
thats why in my company we just Arc everything, Arc
"Horrible Error Messages" most obvious indication of a skill issue
skill issues exist, everyone has them. Let's all all help each other overcome them without being assholes
@@faithful451 lol, I am glad I don't learn rust else once I ask questions the answer will be always skill issue.
@@faithful451 But if you're new and learning, be humble instead of writing a whole blog post saying the language is shit and badly designed.
Otherwise don't complain when people dunk on your intelligence. You pretty much asked for it.
@@hagaiak agreed on being humble, that goes both ways though. If someone's having trouble and asking for help, humbly help them instead of 'dunking on their intelligence' .
With Fable, you can transpile f# to rust. So, if he likes ocaml, try f# and transpile it to rust for the performance. Btw the f# comunity is the best!
Personally I believe that boiling people's problems with a language down to a "skill issue" is kind of dumb. Every problem you can have is a skill issue. If the language is Turing complete then you can do everything in it (technically). You have a problem with your error handling? Skill issue. If you were a better programmer there would be no errors to handle and why would you need to handle what doesn't exist? A ridiculously steep learning curve is a giant glaring con for a language. If you have to "git gud" for years on end to be able to write some decent code in a language then is it even a language worth learning?
That's true. By following that logic memory unsafety in C or C++ is also a skill issue so there is almost no reason to learn Rust in the first place.
Instead you just can become better at C++ and learn how to write memory safe code.
@@bionic_batman That but unironically.
Herb Sutter relates that Microsoft's experience with Rust has been that from C to C++ there's a large safety delta, and from C++ to Rust there's a small safety delta, and even that's largely because it's harder to commit code that doesn't compile than to commit code that fails a static analyzer.
taking years is an extreme exaggeration. 3-4 weeks is realistic for the average programmer. assuming they go through the book and actually commit themselves to learn it. that's still a lot compared to something like javascript though which is realistically probably around 2 weeks on average. you're not just picking up javascript with javascript. you have to learn all of the tooling and all of that. go is probably a week, although i learned go in a couple of days.
Memory safety in Rust is a tricky issue
The Go language allows data race conditions. But it offers good and clear ways to avoid it.
Result: Websites specializing in software vulnerabilities announced 39 data race vulnerabilities in Rust applications. Versus 2 data race cases in Go applications.
Although we know that Go applications are much more than Rust applications, concurrency and parallelism are used extensively.
It's the same with the memory leak issue
I've used a lot of C++ applications and never experienced a memory leak.
I used two applications for Rust. One of them was leaking memory.
We must admit that the Rust community deliberately shows the good side of its language as opposed to the bad side of other languages
"If you were a better programmer, there would be no errors to handle". Bruh
Last observation is that I don't think enough of the glowing articles and videos about Rust focus on these challenges. There is not enough emphasis that rust development kind of needs to be focused on a niche where the performance benefits and long term reliability outweigh the cost of half a year skilling up your dev team before they can really leverage those benefits. That's a pretty high bar, and definitely something I will be considering for any platform development work I will be leading going forward. So... informative!
"give me garbage collection"
just use go dog
Great post.
The async stuff at the start reminded me of issues I constantly have with FP-TS on TypeScript. I guess functional programming just gets harder as you push it to do more.
I unironically got a massive migraine reading and trying to write a simple cli argument parser in rust, that has never happened - not even when going from C# to C++ to C to Python to php to javascript
Not once, but doing rust gave me a full migraine where I just cant go near the computer, its insane
I’m confused any time someone says rust is good for CLI apps because strings are annoying in rust. Tbf, I haven’t used clap or any crates to handle the arguments. That said, I certainly wouldn’t say it’s any worse than C++.
As opposed to an ironic massive migraine?
@@TehKarmalizer Most of the people saying Rust is good for CLI apps probably are using clap :-)
@@jishani1 what?
I *unironically* got a massive migraine, what on earth are you talking about, its a descriptor to how people joke about getting migraines - I literally, unjokingly got a massive migraine
I like rust for parsing, but I can't imagine writing a Parser without any special libraries
That post reminds me of the old line that REAL PROGRAMMERS can write Fortran in any language.
Learning a new programming language isn't just learning new syntax, just as learning a natural language isn't just learning new vocabulary. This sentence is German to English without grammar adjusting translated. With programming languages it naturally gets frustrating when the familiar patterns no longer work and you have to learn new ways of structuring your programs.
"Doctor! Doctor! It hurts when I do this!"
One of the huge balancing acts with Rust is when to write stuff yourself vs falling back on the community crates.
If you wanna GSD you just gotta use the classics - anyhow, thiserror, serde, tokio, etc. or you're gonna wind up with pin box, dyn error shenanigans.
Some positive and inspiring Zig hype is what I need right now :p
you need Odin, not Zig.. your welcome
Elixir's pattern matching and guards (and crashing itself) are a perfect example of such assertions built into the language philosophy.
22:15 is definitely more indicative of Redditors than it is the Rust community. Redditors HATE giving you real advice instead of just shitting on your already made decisions.
(That said, I don't have any more anecdotes for how the Rust community is compared to the others. So I defer to the bad experiences you seem to have had)
Rust people will be nice to you as long as you have a rainbow flag in your bio and at least one thread where you defend sex change surgery for children
As a member of the PHP community for maybe 10 years now, I can tell you we're pretty nice because the language was so bad for so long, and it was a punching bag for that whole time, that there isn't that holier than thou attitude you'll find in other languages. We had to collaborate and get on with one another if we were to find success using this language.
Seems like a lot of words to say "I have skill issues"
yeah calling a language garbage with bad designs when after admitting you can't even properly structure error message is so weird .
Rust is so great because it humbled many of these dudes with god complex thinking they actually know everything , a truly smart & humble person will sit down and learn these stuff instead of lashing out and insulting everyone and everything
edit: typos
@@クールなビデオ the emperor is fully clothed
I had a short look at Rust and noped out immediately. If I want something that looks like C++, I'd use C++. The speed argument is dumb, study after study finds that GC'd languages are _theoretically_ a little faster, but in practice is either doesn't matter (GC performance has come a long way), or people are making non-optimal memory management choices, which make the GC-less language actually slower. There are so many good languages to chose from. I know and love Kotlin and Scala, but I heard good things e.g. about Julia and Elixir, and Swift seems decent too. Don't buy the hype, use the language that fits you and your problem at hand.
I personally dislike that so much emphasis is placed on memory management when it comes to performance. Yes, languages like C/C++/Rust with a more manual memory management approach can be faster than GC. However there's a lot more to performance than just memory management and often times those other aspects are far more important. If you use Rust but use the wrong data structures and algorithms it's probably going to be dramatically worse than say a GC language with the right ones.
That said I do really like Rust.
OK if you need a part of your program to be performant and other part you don't worry too much about it then write the performant part in C and the rest in some GC language then link them together what's so hard about this
Yeah, really what GC-less languages give you is a much more predictable performance. The thing with GC is that you never know when the GC is going to kick in and create a slowdown in your code. In many cases though, the GC doesn't actually have that big of a performance hit, which is why it's not really a great idea to use a systems programming language like Rust for everything.
@@rusi6219 The thing is the GC isn't buying you as much as you think it is. The fact that the GC pervades the entire language design can in fact make things substantially worse. Compare for example C++ where closing a file stream is as easy as letting it go out of scope, versus something like C# where you need to be mindful of what's a "disposable" and place all such objects in a using block or try... finally. RAII languages like Rust or C++ understand that memory allocation is just one of the many types of resources a program needs to manage, and provide a general solution suitable for all of them. It's a simple solution, which only asks you to consider what objects own what and then you're set. Once you've internalized this way of thinking, GC languages just seem awkward and limiting. GC pressure is something you straight up _don't have to think about_ in C++ or Rust.
@rusi6219 The thing is the GC isn't buying you as much as you think it is. The fact that the GC pervades the entire language design can in fact make things substantially worse. Compare for example C++ where closing a file stream is as easy as letting it go out of scope, versus something like C# where you need to be mindful of what's a "disposable" and place all such objects in a using block or try... finally. RAII languages like Rust or C++ understand that memory allocation is just one of the many types of resources a program needs to manage, and provide a general solution suitable for all of them. It's a simple solution, which only asks you to consider what objects own what and then you're set. Once you've internalized this way of thinking, GC languages just seem awkward and limiting. GC pressure is something you straight up _don't have to think about_ in C++ or Rust.
@@isodoubIetidk man I just write C and am content with my life 🤷🏻♂️
I love listening to Prime so that can have hot takes about things I understand nothing about (yet).
anytime someone says "try to do something clever" we should all have a red flag.
I 100% get where this guy is coming from with the answers received, it's always what's infuriated me most about programming. No other community does what they do here.
Imagine asking in a woodworking forum "I'm building a canoe and the epoxy is giving me trouble can you give me advice on how to work it?" and you get a dozen answers that are some variation of "You're building a canoe? Are you an idiot? Build a deck instead you moron." You don't need a deck, you need tips on using epoxy, but everyone feels smugly justified with the non-answers they gave you. When you bring that up you get dog-piled on for having "skill issues".
Who would ever want to be a part of that?
I've never come across someone saying to build another project instead. Only advice about approaching the project in different ways, or writing the language in a more efficient manner according to the language itself, and not according to other languages.
But if that's what you're talking about then a more comparable comparison is if a woodwork community told you to use a different tool, or to not use a chainsaw as if you use a hand saw.
Sometimes its warranted ("How do I get the pixel size of the screen on a headless server?" "You don't. You're definitely approaching this wrong") but other times its really not (Canoe vs deck) and sometimes theres a middle ground ("The bindins to mongo are attrocious in rust, it's just... not a good idea to use mongo when working in rust becaue of it") but in this case its also the added assholeishness of the rust community that call a binding issue a skill issue ofthe user making it all worse.
OK now you just blatantly lying. I have always got friendly useful answers and help from Rust community, and many others did too of course.
@@maniacZescias long as you believe in the transvestite religion and sex change for kids they'll be nice to you
"atrocious semantics" -- I agree. As an old assembly language programmer, I find assembler easier to follow. (And more enjoyable.)
I also know asm, and to be fair you can't compare anything to asm because of how simple it is. It all depends on your instruction set but it's often very simple to follow. Unless you're named x86_64 and literally have some instructions called javascript_float_round_towards_zero. I hate x86_64 so much.
@@fleefie Since all high level languages reduce to machine code, the comparison is fair. One primary benefit of high level languages is to move programming closer to how humans communicate. FORTRAN and C were modest steps in that direction. BASIC, Pascal, Java, Javascript, Python etc were steps in that direction too. I think Rust is a step backward in that trend. IMO, any new computer language should move closer to natural language, not further away from it.
I know your javascript_float_round_towards_zero is meant to be sarcasm, but I never found x86 baffling or strange. I spent over 10 thousand hours writing x86 assembler. I liked it a lot.
unless you program rust every day, your forget speed is 10x that of learning speed
I enjoy learning rust to improve my way understanding of core CS concepts that I skipped / missed by being self taught
That "orelse return null" gives me Perl vibes.
I went back to writing some Perl for some personal scripting tasks. I haven't found anything comparable as a utility scripting language.
Lua is beautiful for it. Factorio is a great environment, for a more static "you said you could wait" and runtime "please don't break" code. A common pattern for a storage which should be there and needs to be: a.b = a.b or {} . "assign itself or give it a new [storage] ". Stupid, simple, 100% functional. Since assignment states allow returning values from functions, you can even do a.b = a.b or error("barf") , which Perl has in spades with open(FH, $dir) or die("") . Most of the time: *if not a.b then* works, as a false or nil (the value of non-assignment) passed to a not is true. *if not a.b then return end*
Regarding language performance, unless all your development is CPU bound just choose the language that's most productive for you.
I have to strongly disagree that the frustrations you find with rust are a skill issue. It's bad design
Absolutely correct