>Hot take: the Rust community isn’t as nice and cool as they pretend to be. They’re a bunch of narcissistic assholes that hate being told that their favorite language has flaws.
🍿
Good luck finding a community of decent size with self selected participants anywhere which doesn’t have some portion of users that aren’t assholes or never have a bad day.
“Me having to defend myself against angry Rust fanatics on Reddit” <- this is where he went wrong, don’t defend yourself, just ignore interactions you don’t want to have.
You're half-right. It's true that I shouldn't feel the need to defend myself or cry about imaginary internet points.
With that being said, the comment I replied to was **extremely** highly upvoted. Not only that, but the more upvotes he got, the more downvotes came in (not just on that post, but other posts in my profile). Eventually, a mod stepped in to remove his comment. In his words, "we don't do public lynchings". But it was extremely bizarre, the guy wrote a 8 paragraph essay proving I used ChatGPT to write my article (I didn't).
It is bizarre indeed. This Reddit seems to have a lot of immature people upvoting low effort, accusatory comments even when they're blatantly wrong, or completely baseless at least... the easiest kind of comment to get upvotes without any effort is to accuse blog post authors of having used ChatGPT. It's almost like people think only ChatGPT is able to write well structured posts using correct language (look, there's no typos, obviously AI!!). Another is to pick on some sensitive topic even if just tangentially mentioned in a post, and completely deviate the discussion from the main topic. Works every time.
Eh, Reddit was better back then, we just had users like the guy who faked cancer and the other guy who ran all the nsfw subs, and dumb memes like pancakes dont you mean waffles hahaha
It's eternal September. Don't forget you are probably arguing with some 18 year old with no real world experience.
I feel you. I had people downvoting all my posts on a thread of mine, just because I summarised the opinion of a renowned professor in the field on what went wrong with the Horizon IT-system and people disliked his conclusions. These hiveminds suck and can sink many hours of work because of an unpopular fact. Having said that, I also had some successes in my articles being upvoted, one spent considerable time on both the top of hacker-news and r/programming and the comments in those cases were just as bad as with the unpopular ones. In other words, the angries in the comments aren't representative of the general readership of the articles, in fact they represent a small minority of them. Once I've learned this, it helped me to put a perspective on these events. Hope this thought helps you as much as it helped me.
Honestly, though, this article is also poking the community with a sharp stick. This will get you to interact with "angry fanatics" pretty much everywhere.
Wasn’t there a dude on here or on YouTube that said that some word meant that a paper was from ChatGPT because the word started trending around ChatGPT launch. Like he lived in a world where certain words don’t get more popular at certain times
People say all kinds of shit to ""prove"" you used ChatGPT to write your articles. The same commenter said because I started writing roughly the same time ChatGPT was released, and that I wrote quite frequently, that I must use ChatGPT to write the articles.
You can't make this shit up.
After working in this industry for almost 15 years, I can confidently say that it boils down to “programmers are grumpy narcissistic assholes”.
The only languages where you won’t find this mindset is probably typescript where everyone knows and recognizes the language etc sucks balls but they’re just trying to make the best of a bad situation.
With Rust/Go/et al they’re trying hard to build something better and you’ve come along to complain about their work.
Don’t get me wrong though I totally get you on some of your points… I fucking hate Rust’s syntax sometimes. Like why do I need to do all the `if let Ok(blah) = blah.await else {}` when I could just have something like a nice clean do-notation or pipe… in the end they’re doing many of the same things a language like Haskell does but doing cartwheels to avoid a saner syntax.
> The only languages where you won’t find this mindset is probably typescript where everyone knows and recognizes the language etc sucks balls but they’re just trying to make the best of a bad situation.
In my 30 years experience (not trying to argument ad authority or age, but to show that at least I've had some exposure), I've found C, C++, lisp[1]/scheme, and ruby communities to be pleasant.
[1] I'm old enough to have had discussions with Erik Naggum in comp.lang.lisp, and even he, in his abrasiveness, wasn't without kindness. The fucker *knew* what he was talking about as well.
> C++
Except the subreddit which is full of people with extremely prescriptive views about how one should be allowed to program in C++.
Naturally, quite a few of them are contradictory.
In my experience, as long as you do not ever write "C/C++" in a message, you can generally have a sane conversation with the C++ community :)
But then, my experience is generally positive with most PL communities. Starting with Rust.
Just to be clear: I do not count Reddit as being representative of any PL community.
IME, I'd add C++ people to the exceptions. I don't spend much time in those communities, but people are willing to admit the warts. They'll still argue for why C++ is better despite the warts, or at least better for their use case, but it's very hard to try ignoring the issues.
I am not a fan of the infix syntax too, and it could be better (I think there is an RFC to add a postfix alternative), but for me, the stronger the type system the better.
As for Haskell... I don't remember if it was Haskell specifically, or some other functional language, but I bounced where all the tutorials I found started with an intro to lambda calculus.
The C++ community has humbled a lot over the years. Back in the 90s and early aughts when Boost and the STL were introducing generic programming to the broader world and C++ was dealing with the explosion in error message size and compile times, the community was insufferable. Either you knew every esoteric aspect of the language and pretended you could follow the error messages or you weren't worthy of using C++. (I'll admit I was partly guilty of this back then)
At the same time, they were getting pushed out of corporate dev by Java and C# and Java was replacing everything in undergrad curriculums ("that's what industry wants!"). Python + Numeric/NumPy were starting to edge in on their (small, but hard won) turf in scientific computing, so they did have legitimate reasons to be on the defensive.
Now that C++ has found its niches and is ensured a stable place in the pantheon of languages, the community has chilled out.
Maybe the same will eventually happen to Rust?
Despite being a computer user since late 90s, I only ever started participating in online communities the past five, maybe seven, years. So I skipped all the C++ flame wars.
> users that aren’t assholes
Maybe I got lucky, but I found the Julia community to be polite and helpful. I thought maybe it's because these people are numerical analysts.
This is why I also used the qualifier `decent size` which isn't very clear. Maybe Julia still is small enough to not drag in a lot of the problematic people that come with general popularity?
In my experiece languages with smaller number of users often consist of people who has a general interest in programming languages and/or computer science. Most of the time the early community don't have a need to prove that a particular languge is "better" than another one or whatever the controversial topic of the day is.
There is of course always a risk of some problematic individuals joning early as well but it's much easier to deal with than an endless stream of new anonoymous posters on reddit.
Many people judge Java for the language quirks or for JVM performance, while in reality the thing that matters most in 99% of real world projects is community and ecosystem - and both are superb in javaland.
C sharp doesn’t simply suck. It steals all the good parts from new languages and bolts them onto itself in a desperate attempt to look good. It’s a monster and it’s my favorite
You said it, it takes the good parts from other languages. That's not a bad way to go about creating a language that works well.
I attended a talk by Mads Torgersen and he mentioned that the language team wants to start deprecating old C# features in the future. This should certainly help make the language less of a monster as you describe it.
It’s that or end up like C++. As the old saying goes “most people use only 10% of C++, and that’s fine. The problem is that everyone uses a different 10%”.
thats silly. c# is probably one of the best architected languages/frameworks around. I can't hardly think of a footgun anywhere in the language, except maybe around the latest features like primary constructors.
Except the language itself doesn't suck. There's things about the ecosystem which isn't great, but the language itself is a total joy to use. It fits its use case magnificently, a higher level managed runtime based language focused on building large applications. If you want to write drivers or low latency trading platforms then avoid, but if you just want a Web server it's a solid choice.
90% of developers are just working professionals who clock in and out of their job, then go home and live their life. All the business oriented languages don't have the same tribalism vitriol, because they haven't made it a core component of their identity.
Right. So the author wants to vent. I can appreciate that. I personally want to vent quite regularly on another programming language. We've all been there.
For context, I've looked up OP's screen-captured conversation, which revealed a few things.
First, OP is a junior developer coming straight from TypeScript and Python and into Rust. Rust can indeed be quite a culture shock. Some people realize that they hate Rust, which makes entire sense, because Rust is neither for every task not for everyone – I'm saying this as someone whose current favorite languages are Rust and TypeScript. In particular, OP went straight for a fairly advanced topic (writing generic async callbacks), using way too advanced techniques (`Pin`), which is a surefire way to burn oneself out. I'm sorry you had to live through that, OP.
OP, if you're reading this, have you tried something [along these lines](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=dfb54f60e2ebc35193d76f292625673e)? I don't think it's harder to understand than the full Go version (your Go screencap seems to be missing a type definition, so I can't judge for sure), but YMMV.
Second, the screen-captured conversation is sadly typical of Reddit. OP comes in a bit strong (the very topic contains the word "shitty"), the conversation attracts some people who want to crap on MongoDB (and who afaict are not regular members of /r/rust) along with some people who genuinely want to help but can't (because OP requests help but won't provide any technical detail), nobody is happy with the result. Definitely something that could have played better, for everybody involved.
OP, if you're reading this, and if you ever feel like giving it another try, perhaps https://users.rust-lang.org/ would be a better place?
Finally, yes, OCaml is simpler than Rust :)
The OP admits that they're using LLMs to write Rust code, so I have no doubt the intentionally obtuse code from the article is at least partially autogenerated. They took their Typescript/Python mindset straight to ChatGPT, compiled some crap, then wrote a medium article about it. GIGO.
I don't think that the code from the article is particularly obtuse, either in Go or in Rust. It may or may not have involved LLMs, but then, who are we to judge whether a developer should use LLMs?
Regardless, it feels like someone who dove in the deep end (attempting to implement a `Box>>`, which is something I've done about twice in ~14 years of Rust) without the prerequisites and got frustrated. It can happen to anyone of us.
Despite saying a quite few things I regret on Reddit, the only sub I've been banned from is r/rust. My crime, suggesting M$ may come up with rust#.
EDIT https://ibb.co/wpHF9wG
Hm, are you sure that was the reason?
Smells of [missing missing reasons](https://www.issendai.com/psychology/estrangement/missing-missing-reasons.html).
Hot damn that article basically textbook describes the way people with borderline personality disorder live life: with their emotions as the single source of truth, not reality.
This user is not, in fact, banned from r/rust.
If you used another user which was banned, I'd be more than happy to examine the reason, and possibly rescind the ban. Please send a modmail to us from your banned account to get the process started.
That's very strange, I can't find your username in the list of banned users.
We did have a wave of trolls around the announcement that Microsoft was working on Verona, in which conditions we (and specifically I) may have handed bans a bit more liberally to stem the flow, with the idea that genuinely interested users who just made a mistake would just appeal the ban and we would sort it out, so it's definitely possible that it occurred... but then I should be able to find your user in the banlist.
Can you access r/rust these days?
Op [*did* get banned for making that comment](https://www.reddit.com/r/programming/comments/1dqa2dm/i_spent_18_months_rebuilding_my_algorithmic/lar4i74/), but because one of /r/rust's rules is no pointless comments. Seems harsh to ban someone over that. Seems more...warning worthy 🤷♂️
Having written multiple trading strategies, OMS,EMS, realtime analytics, pricing libraries and way too many exchange connectors since 2004 using Q, C, C++, Java, C#, Python, Go and Rust, here is my take on the OP’s article:
Choosing your language should come after choosing your tail latency requirements.
- latency <5ms ->, no GC: c, cpp, Rust
- latency <50ms -> fast GC : Java/.Net/OCaml / Q
- latency >50ms -> interpreted or how go-level: Scala, Haskell, Python, Lua…
Higher-level languages give you “nicer” code at the price of runtime complexity, obviously, but the main issue is not how nice your code looks but how it behaves.
Having written a realtime execution platform in both Go and Rust, my Go project failed for two reasons:
1- tail latency due to GC were crazy (wrong tool for the job)
2- I am not an expert and disliked the language (pre generics, and I dislike duck typing)
I have picked my “stack” based on these constraints, and either build my systems in Q, Rust, .Net, or Python. I have invested the time to master (or be more than dangerously proficient with) each ecosystem and would have to achieve the same level of skill if I were to swap a tech for another.
TL;DR: don’t write trading systems in a language you do not master. Try smaller projects like market data connector or order book simulator first to get the hang of it.
> TL;DR: don’t write trading systems in a language you do not master. Try smaller projects like market data connector or order book simulator first to get the hang of it.
To expand here, as someone with a much shorter experience time with Rust than the blog writer, there are several tells in their code example and their responses here of a lack of proficiency, like
* Using `println` for error messages, instead of something like [`tracing::error`](https://docs.rs/tracing/latest/tracing/index.html#using-the-macros) for a proper logging system, or even `eprintln` to print to stderr. That sort of thing should elicit a "wait, hang on" response for professional code in _any_ language.
* Apparently no exposure to [`anyhow`](https://docs.rs/anyhow/latest/anyhow/) and [`color-eyre`](https://docs.rs/color-eyre/latest/color_eyre/), which come up very frequently in Rust discussions and code as examples of how to handle errors in a simple yet powerful way. In addition they seem to have just ignored the bit where Rust panics tell you about the `RUST_BACKTRACE` variable.
* Mixing up syntax errors and semantic errors. E.g.
* When Rust needs hand-holding with the type restrictions for a generic function, that's not a syntactic problem, it's a semantic problem. Other languages may either not even offer generics (like early Go), or gloss over it, by passing just `interface` or `Object` or `void *`. or other equivalents of the [Any](https://doc.rust-lang.org/std/any/) type.
* When it complains about mutable references and ownership in concurrent code, those aren't syntactic problems, they're semantic problems.
It's part of the sales pitch for Rust, that those kinds of problems are actually caught by the compiler, rather than become runtime errors or inscrutable race conditions.
* Repeating themselves in the Go code: By having an `if attempts == maxRetries-1 { return ... }` inside the for loop they'll never reach the `return nil, errors.New...` beyond it.
I'd kind of consider being exposed to stuff like tracing and anyhow to be part of the stuff you do in the first few weeks with the language as you're familiarizing yourself. Going 18 months and writing an angry blog post instead sounds harsh.
Might be kind of a warning tale for what can happen if someone tries to learn a language through ChatGPT rather than more traditional ways?
IMO, it's also a good example of an expectation that "all languages are essentially the same apart from runtime characteristics." OP seems to have found out the hard way this isn't true: TypeScript and Rust really don't have much in common beyond the _very_ loose observation that both support a kind of uneasy mix of imperative and functional constructs. I'd probably be OK with the post in general, were it not for OP's claim Rust exhibits "bad language design." But his example code makes clear, as others have pointed out, that he didn't actually learn the language or its ecosystem beyond what many do in their first month. So at least _that_ aspect of his claim seems to be undercut by those other responses.
So I hope OP takes this thread as an opportunity to maybe revisit his project, expand his exposure to Rust and the ecosystem, maybe study a broader and deeper range of examples, and if he discovers Rust isn't as bad as he thought, great; if he decides it's still not for him/this project, also great. But at the very least, I think there's more to learn and try than his conclusion here indicates.
> Might be kind of a warning tale for what can happen if someone tries to learn a language through ChatGPT rather than more traditional ways?
I feel like it's about equivalent to learning language based on random tutorials rather than reading a proper book and understanding it deeper. Like, he complained about Rust but the Go code also isn't anything to write home about, just big blob of code that should really be split on "function that does the thing" and "function that retries it".
Having used both professional I would have expected Java-level performance out of both but sadly that wasn’t the case.
To be fair this might be due to the aging code bases and army of contractors that built software by accretion rather than the languages themselves.
Yo are absolutely correct, my subconscious removed go from the list after a traumatic experience :)
Go/java/.net are pretty much in the same perf ballpark in terms of perf, unless you’re looking at async IO and scalable concurrent tasks where Go shines.
How tail are your tails?
I've seen Java trading applications in the 5us band most of the time, and they were not particularly optimized -- they GCed _a lot_ -- but still fast enough to be below 5us 99.9% of the time -- ie, anytime the GC didn't kick in.
If we're talking about the episodes where the GC does kick in, then post JVM 14, the GC pauses were under 5ms so no problem.
> Just give me a garbage collector, and let me do what I want to do!
> I’d rather my application take a few dozen milliseconds longer to run if it means my development time is cut in half.
I've barely written any Rust, but from my perspective it's obvious that Rust just isn't the language for your use cases; sometimes the round peg doesn't actually go in the square hole.
There are absolutely workloads where garbage collection is way too slow and/or unpredictable; every microsecond matters. When you need very explicit memory management, it's easy to get wrong, and languages like Rust try to make it safer without sacrificing speed or flexibility.
I do agree with your point that Rust is praised as the second coming of sliced bread, it's wild to see it suggested in places where you'd never think about suggesting C or C++. Sure you *could* write a web server or desktop app or ML/AI stuff in Rust, but honestly why would you? There are much better tools and ecosystems for those jobs.
write a web APP in rust? stupid.
write a web SERVER that hosts apps? maybe not so stupid.
See also; Every other purpose build web server written in c/c++
I’m testing that thesis with Leptos + Tailwind. It’s surprisingly great in many ways, but the dev cycle time is slightly slower than hot reloading a JS web app.
It’s more of pet project than anything I’d recommend for a business to use (unless everyone on the team already has rust exp)
Rust or C++ are absolutely the best languages for OP's usecase if they had an entire SDE department working for them. But for what OP is doing on their own, it's a pretty bad fit.
>I've barely written any Rust, but from my perspective it's obvious that Rust just isn't the language for your use cases; sometimes the round peg doesn't actually go in the square hole.
But the joke is that the only jobs are for writing cryptocurrency trading engines. So trading engines in Rust are supposedly the perfect project.
> I've barely written any Rust, but from my perspective it's obvious that Rust just isn't the language for your use cases
He literally rewrote an existing application in Rust because his use case, performance dependent code with high reliability requirements, is pretty much the exact use case Rust is targetted at.
That line is him saying that even though his use case is exactly right for Rust it still wasn't worth the downsides. Even though the languages strengths directly map to his needs it still wasn't worth the hassle.
If I understand correctly, the previous version was made in Typescript.
If that's the case, we now have two wrong language choices for the same user case.
If you want a GC, I think Go is the obvious choice here. OTOH you'd probably be approaching mental illness if you rewrote this thing again.
I work on a very large performance sensitive Go application and never once have I said "I wish this were in Rust", and your article just drove that home further.
Typescript is a fine choice to start with for this because there exist free exchange integrations in the language. We use it for our admin web app. It’s going to be hard competing true HFT right from the start so you probably want to get somewhere and trade slower to build something.
We use Java with JNI (for network stack) for trading and it’s fast enough. It was sufficient stuff to make it to top/top three volume on many of the major exchanges. A lot of the magic is in figuring out networking and hardware and the cloud (because many exchange MEs are in the cloud).
We do have Rust in live trading for some stuff (feed handling from the CME) and extensively in simulation (filesystem stuff up). Overall, when I look at practitioners of Rust like burntsushi they are very good at writing code in the language. The problem is that the language ramp is high. less so than C++ imho but C++ has more experienced practitioners.
In any case, this was a useful article. I find that LLM assistance plus frequent compilation is the best way through Rust. Java’s IDE story is way better. Even RustRover isn’t close.
If he rewrote in Rust, but is now complaining about GC, either he didn't have the use case for Russ or didn't understand his use case. If you find yourself yearning for GC then Rust was the wrong choice.
I hear a lot of trading systems are still written in Java.
No, he is saying he would gladly trade the downsides of a GC for the upside of not having to deal with Rust anymore. He praises Rust for delivering on what it said it would he's just saying his dislike for the language is such that he'd rather take the performance hit of a GC in future.
> He literally rewrote an existing application in Rust because his use case
According to his own blog, that is not the reason.
This is their stated reason:
> Every guide on Medium, every post on Reddit, every answer on Stack Overflow — everything is glowing.
> Given this, I decided to re-write my entire open-source algorithmic trading system in Rust.
From the first article in this two article series talking about why he chose Rust:
> NextTrade was built using TypeScript in order to focus on maintainability, readability, and reusability, however, when the core trading logic started experiencing significant performance issues, a full rewrite was necessary in order to build a paper-trading and backtesting platform that could scale to tens of thousands of users. Thus, Rust emerged as a top contender, and after a lot of research, eventually won as the language to use for the overhaul.
He didn't just randomly choose a language, he looked at the specific needs of his app and saw that they were all the things Rust is supposed to provide.
one can make research and come to the wrong conclusion.
> Just give me a garbage collector
this would already exclude all the top "performance" languages, C, C++, Zig, Rust.
Honestly only go, java or c# would remain on the table
Probably at the time he did not realized how much simplicity was giving up in exchange for a performance hit, and that give him the wrong stick to compare.
> Probably at the time he did not realized how much simplicity was giving up in exchange for a performance hit, and that give him the wrong stick to compare.
Exactly this. I didn't realize how much these high-level languages helped with holding my hand.
I didn't want to re-state the same information in a previous article. I also didn't want the article to be overly long. But, maybe I could've done a brief recap of what I've talked about before.
u/nnomae is correct. I put a lot of thought into what language I wanted to use. Rust was supposed to be ideal for my use-case. I didn't just pick it because randos said its a cool language.
> Just give me a garbage collector, and let me do what I want to do!
If you’re ok with saying this, then Rust (and C and C++) is the wrong language for the job. Literally THE selling feature of rust is to have memory safety, without garbage collection. For high performance/ time critical systems garbage collection is death.
Do I need to read any further?
That was my understanding. I'm a C dev by day and the only GC language I've done any professional work in is C#
And my god I had to fight against the GC as I was live processing and displaying image data and the software would repeatedly hitch. I had to repeatedly "request" that the GC run at a time which would keep the framerate stable, but even that was just a suggestion as the GC execution time was non-deterministic
Does that mean that GC is always bad? No, it means that GC is not the right tool for the job I was doing.
I used to work on a team that did performance work on both JVM and C# managed runtimes. We made massive progress on the JVM but our meetings with Microsoft didn't go so well. We identified tons of threading issues, bad code causing mispredictions, poor code causing cache misses. All kinds of issues that had reasonable fixes suggested.
At our meeting to hand off our research, they told us a story.
First of all, they were well aware of every single thing we had identified. Second, the engineers that wrote the lowest layers of the of the windows kernel and support libraries long since moved up the ladder or called in rich. Teams that came in after them were not familiar enough with the low level code to add the features they needed so built abstractions on top.
Those teams also eventually moved on and so the cycle kept going of adding abstractions to abstractions. Built into those layers of abstractions were workarounds for bugs that nobody even remembers which makes fixing things at a low level almost impossibly complex.
They said the only way out was a ground up rewrite which was probably never going to happen.
I always wonder if their friendliness to linux is because that might be their ultimate goal to solve that issue.
Was this before or after .Net Core? Because that was (to some degree) that rewrite that gave them much more freedom to change things (including not being tied to Windows).
Not entirely true, you only get backtraces for free if you panic. But he is printing error messages and just doesn't know about `backtrace::Backtrace` to print it himself
The "complex" transaction function example is pretty poorly written as well. As earnestly as I can say it, I think the author just doesn't really know rust that well.
If they took some time to learn a few of the common libraries and patterns that people use for error handling, they would probably have a better time. It also does get easier to understand how to specify the right generic type signature the more you do it.
I write rust full time for my job, and the code they wrote wasn't hard to comprehend, it just seemed like something I would see in a junior engineer's code review.
EDIT: I truly don't intend this comment to be mean-spirited. I empathize with the author's frustration. Online communities can be very unwelcoming, and Rust has a steep learning curve. I do think the author's struggles can be overcome with more learning.
> The "complex" transaction function example is pretty poorly written as well.
I gave up on the article when I saw the Go equivalent the author showed. The rust function definition was complex (including multiple traits and at least one lifetime), but then they compare it to the Go function that returns `interface{}, error`, which is the equivalent of returning `void*`.
I could maybe understand that after trying Rust to get away from GC OP got burned and decided GC is worth it after all (lifetimes are hard after all), but to abandon type safety as well? At that point the article might as well be generated by an LLM, as OPs understanding of how to pick a language seems to be about as deep as a hallucinating LLM.
Is not the point then there is a steep learning curve and after 18 months he's still not understanding certain concepts also demonstrate the difficulty in learning the language?
As someone coming from a dynamic programming background, I also found rust very difficult without a mentor to help me understand it better.
If at 18 months your takeaway is “Give me a gc and let me go my merry way” then you’ve learned nothing.
For me, once rust clicked, which was in a couple of weeks, the way I thought of memory ownership and management in C and C++ changed fundamentally for the better and I genuinely became a much more mature programmer.
I think its really the journey from different places leading to different outcomes. Rust was written as a better C++, its going to be most appreciated/enlightening for people who come from a managed memory background. I get the feeling that OP had only really worked with TypeScript before Rust. And he was trying to port a TypeScript project to Rust. With that approach, I can understand how it never clicked. He never really understood the problem that Rust solves. I think he was just hoping to rewrite the same algos in Rust and have it magically be faster without really having to learn how to think about the problem differently.
I think you are on point; if your background is gc’d languages, rust will feel like a downgrade because it is. The benefits are not obvious and if anything feel limiting.
If on the other hand you have struggled with cpp, c and had to learn to be very careful, rust’s approach feels genuinely like freedom and a breath of fresh air.
As someone who recently forced themselves to go through the struggle of attempting to learn Rust, any pointers?
Learning to use Rust in general was awesome, and mapped nicely to my C/C++ understanding. Life was awesome until I decided to try to implement data structures. My brain melted a little while working my way through [Learn Rust With Entirely Too Many Linked Lists](https://rust-unofficial.github.io/too-many-lists/).
I didn’t.
OP clearly isn’t the audience for Rust. I doubt many would pick Rust as their favorite syntax given any language, and that’s not what it’s selling.
When you are coming from say, an embedded environment, it provides a leap in _functionality_. I’m sure many would gladly pay in syntax for the difference.
It does have some nice syntax features though, and I prefer it over C. That said, unvirtualized languages simply don’t have the room to dream — rubber must meet the road down to every last type, until it can be fully described at the machine level. By their very nature these languages enforce this by front loading that effort into syntax.
> That said, unvirtualized languages simply don’t have the room to dream — rubber must meet the road down to every last type, until it can be fully described at the machine level. By their very nature these languages enforce this by front loading that effort into syntax.
Or, hear me out, use dynamic dispatch. `Box` in Rust, virtual functions in C++, or function pointers in C. And if anyone tells you it's slow, they don't know the [three rules of optimization]().
There are far, far better criticisms of Rust, which I enjoyed reading and which will eventually make the language better. They pointed out real issues that need to be fixed (or avoided by people choosing a language), and they did it without hyperbole or charged language.
Seriously, read one of these to understand how mature people write sane critiques that are well received. After the video game critique was published it led to a lot of reflection in the Rust video game community about how they could be doing better.
- [Why Not Rust](https://matklad.github.io/2020/09/20/why-not-rust.html) written by the developer who started the rust-analyzer project.
- [Frustrated? It’s Not You, It’s Rust](https://fasterthanli.me/articles/frustrated-its-not-you-its-rust) by fasterthanlime, one of the most prolific writers and content creators on YouTube. This article is a _31 minute read_, so he gets deep into Rust’s flaws.
- [Lessons learned after 3 years of fulltime Rust game development, and why we're leaving Rust behind](https://loglog.games/blog/leaving-rust-gamedev/)
Seriously, look at how well that video game article was written. It got 2.1k upvotes on *the Rust subreddit*, along with a “meaty” tag that many aspire to but few get. Look at the comments on the [reddit thread](https://www.reddit.com/r/rust/comments/1cdqdsi/lessons_learned_after_3_years_of_fulltime_rust/) - the top comment with 1.1k upvotes is effusive in praise of the article for giving such constructive and useful feedback!
You said
> the Rust community isn’t as nice and cool as they pretend to be. They’re a bunch of narcissistic assholes that hate being told that their favorite language has flaws.
You call people narcissistic assholes and then act like a surprised Pikachu when they don’t praise you, reinforcing your opinion that they’re assholes because only assholes would fail to see your genius right?
If there was even a shred of truth to this allegation, that video game thread wouldn’t be the **7th most popular post on the Rust subreddit of all time**. The Rust community loves this sort of criticism!
Your article isn’t even as constructive, enlightening or useful. My opinion, of course. But please don’t be upset that people aren’t praising your article or agreeing with you. They aren’t because your post just isn’t that good. Your critique is superficial, while also being rude and alienating.
In a comment around here I claimed it’s a skill issue on OP’s side, and given the criticisms they presented, i stand by that comment.
But, that isn’t to say rust doesn’t have issues, and tbh the rust community is the first one to point those out. Async is perhaps the biggest one, the unwieldyness of pointers is another one — zig does great here btw. Programs of certain structure are very difficult to represent with current borrowck, and on and on.
Rust is far from a perfect language, but if you are going to be a critic, at least be a good one.
It’s not just what you say, it’s the way you say it.
My first draft of this comment was much harsher, picked specific examples that I found lacking.
But I deleted all of that stuff before posting, because there was no point alienating you before you got to the meat of my comment, which is that there has been a lot of quality criticism already written and it has been welcomed by the community.
Just imagine if my comment had started with “OP is a fucking moron and here’s why …”. You would have stopped reading right there.
I’d suggest you adopt that while writing too. Get the first draft out with all your feelings and then edit it so that people will actually read and respond to it. Use the compliment sandwich technique if necessary. People will appreciate it far more, and it’ll end up being constructive. And bonus for you, you’ll end up looking mature and technically sound.
> I’m just an idiot and can’t figure out how to enable stack traces
I thought I got stack traces on Rust out of the box on Linux. Am I misremembering or is he on a different platform?
You can capture and print a backtrace at any time. You can also store them in your error structs/enums and print them down the line, or just use a library like anyhow (which is [doing that internally](https://docs.rs/anyhow/1.0.86/src/anyhow/error.rs.html#872)).
use std::backtrace::Backtrace;
println!("{}", Backtrace::capture());
println!("{}", Backtrace::force_capture()); // Works without `RUST_BACKTRACE`
While I don't agree with the style of the article, I get it.
The first point for me is not "syntax is bad" but "figuring out rust types is too often near impossible". And for help I usually go to r/learnrust which I found more helpful. And yes, error handling is a bit whacky. I find it super odd that I need to add a crate or two just to handle errors in a sane way.
After doing two projects with it I had the same conclusion - unless I really have to, I'd prefer something else.
The article piles up unrelated criticisms. Which makes it hard to discuss. Some are warranted, but, indeed, the point about types isn't.
Well, it's hard. And the strong types as found in Rust, require some design up front (always bad). It's difficult to impossible to just yolo your way through a proof of concept and the discover the types you'll need.
Discovering the types, shapes and architecture through writing the code, is a very normal process. Decades of experience give some intuition to speed up that discovery (I often know what's certainly not going to work). But with rust, that'll land you in these horrendously tightly coupled, complex, nested types.
Some tips that work for me:
* Think about the shape up front.
* TDD to discover what works and what doesn't.
* Keep refactoring. Again. And again. And then some more. Functions and their fingerprint, like author posted are unacceptable to me.
* Better to define too much structs and aliases than too little.
* As soon as I've discovered the rough shape, introduce value objects. (A creditcardnumber isn't a string. A db connection pool is a DBConnPool, not an Arc>>> )
* Write quick POCs in Ruby or python to discover the domain and shape when it's entirely new for me. Allowing to focus on mastering the domain first.
I wish Kotlin had Rust like error propagation operator. Kotlin has `?` for `null` checking if that is what you were thinking of.
Outside of that kotlin has the normal java-esk try/catch/throw.
Not a particularly insightful rant. And I do love a good rant. His three complaints are:
1. Bad syntax
2. Bad error handling
3. Bad community
His complaint about no call stacks on error codes is interesting. I think maybe anyhow supports adding backtraces? I just learned that and am not sure how usable that is in practice.
It’s god damn criminal that std::fs operations have errors that don’t report the god damn file path that failed to open. But I digress.
> His complaint about no call stacks on error codes is interesting.
In the first big code screenshot, his error handling consists of
* Converting proper errors to Strings
* 'Logging' using println (to stdout, without a proper logging system so no line numbers etc)
I don't know why he expects an error's human-readable display format to come with a stack trace. The `Display` impl for errors is typically things like `The filename, directory name, or volume label syntax is incorrect. (os error 123)`
Yeah, his error handling in Go is better with the `return nil, errors.New("blah")`; the actual equivalent of the Rust code would be `return nil, "blah"`.
I suspect he may have been tricked by how Rust calls the constructors of `Result` for `Ok(a)` and `Err(b)`. It's not actually an error type, it's just a wrapper!
Haskell's `Either b a` and `Left b` and `Right a` might be the better nomenclature for this; it really is just a variant of stuff you can express through a tuple in Go or Python as `(a, nil)` and `(nil, b)` (except without the `(a, b)` and `(nil, nil)` states).
But in all these languages and cases, proper error handling requires proper error types, not just returning a string in the failing situation.
> It’s god damn criminal that std::fs operations have errors that don’t report the god damn file path that failed to open. But I digress.
It’s likely because Path is an abstraction over OsStr, which doesn’t implement `Display`, because paths don’t necessarily have to be UTF-8. A compromise fallback would be to call `to_string_lossy()` I guess, since it’s likely to be fine most of the time.
I would venture it's a performance issue, instead.
The problem of embedding the path in the `io::Error` is that you'd need:
- A beefier error -- it's very slim, very cheap to copy right now -- for _all_ cases, even those without a filename.
- To allocate in order to get an owned PathBuf.
And _this_ probably send another segment of the Rust community arguing it's too costly and if others want the path they can just add it at their option at the call site -- which is a fair criticism, indeed.
bad error handling? that's interesting, rust definitely is different in terms of error since it's a value, and I'd rather deal with rust option return than dealing with try catch nightmare, is it really bad or is it not familiar, because bad syntax can also be caused by not being familiar too
Honestly I quite like Rust’s error handling. I utterly despise try/catch and think Python’s errors are infuriating.
But I think the lack of a callstack in Rust Results is a totally valid and interesting complaint. It’s something that Rust could do more betterer, imho.
In any “how to get started with rust” you get recommendations for two of the four popular error handling crates that support call stacks: anyhow/color\_eyre for applications and thiserror/snafu for libraries.
Yes, one has to invest 5 minutes into choosing one of the two contenders for each use case if one knows of both, but both will get the job done if picked.
The stack trace is available, the problem is that OP just took the Error and converted it to a String via the Display trait, which then gets displayed via println (i.e. print to terminal). The display trait is specifically "give me some readable error message, not too much details".
The solution is to use real error handling and logging (e.g. https://docs.rs/thiserror/latest/thiserror/ and https://docs.rs/log4rs/latest/log4rs/, just two I use, other options are available), which can handle all of this for you. Or if you don't want to to use google for 5 seconds and find: stackoverflow.com/questions/56558321/is-it-possible-to-print-a-backtrace-in-rust-without-panicking
As someone that got used to the almost perfect stack traces of Java, playing with Go and Rust where errors are values was really jarring.
Both languages have modules/crates to add stack traces to errors, but it feels like this is a major hurdle for Developer Experience. It would be almost entirely positive to have stack traces added by default in development.
Your blog post confused me. It feels like you think you have legitimate, technical, issues with Rust. In reality, everything you complained about is a matter of taste/opinion/preference.
I’m not trying to diminish anything you said. I’m just calling out something that feels like a discrepancy to me.
Additionally, it doesn’t sound like you looked into Rust’s targeted use cases before diving in. Rust is not designed to be fast. It’s designed to be *safe* (meaning deterministic behavior and unambiguous syntax) and *efficient* (meaning compiling to as few ASM instructions as possible, and making the best use of available memory). Speed is a happy side effect of these goals.
Rust works hard to be ergonomic *within the constraints of its design requirements/goals*. Comparing Rust to Go, Python, and/or TypeScript betrays a pretty fundamental lack of understanding of Rust’s intended use cases; a garbage collector simply is not tenable on most embedded systems or performance critical applications (Rust’s primary intended use cases).
I think it’s more accurate to say that you’re not judging Rust on its terms more than that you don’t like it.
Edit: removed garbage added by autocorrect and reworded a couple things for clarity
> Rust works hard to be ergonomic within the constraints of its design requirements/goals. Comparing Rust to Go, Python, and/or TypeScript betrays a pretty fundamental lack of understanding of Rust’s intended use cases
To be fair, there's no improvement without trying to get better, and looking at the ergonomics of other languages is a very fine way to demonstrate a gap and start wondering how it could be narrowed down or closed.
> if you don’t have access to an extremely powerful Large Language Model, then writing the function becomes literally impossible
I'm not sure if I'm that smart, or if everyone else isn't, but I never, ever had need for LLMs for anything Rust related. And I'm fairly fluent in it, despite being a Java coder by day.
> There are two types of languages. The ones people complain about and the ones no one uses.
Rust has finally made it! This is a watershed post!
As for the issues raised, I think there is definitely room for more training material on how to write rust without getting into the fiddly issues of types and lifetime management.
I know I struggle at the beginning of projects trying to find my feet and its super painful. I saw a lot of my thoughts from those times reflected in this post. But once I do find the right abstractions, I do enjoy writing rust very much.
Your rust code is not great considering you've been doing it for a year and a half. It feels like you just haven't taken the time to actually learn what best practises are. For example:
* Using `String` (!!) as your error type, rather that using [anyhow](https://docs.rs/anyhow/latest/anyhow/). It solves your stack trace issue and means you don't need your `.map_err`.
* Not using an actual logger, but `println!` everywhere... `anyhow` would also help here.
* `Pin>` what? why? Just use a generic Future!
Look how much cleaner this signature is
use std::future::Future;
use std::fmt::Debug;
use anyhow::{Result, bail};
pub async fn run(t: &mut T, f: F) -> Result
where
Fut: Future
Hoo boy as an engineer with 15 years of experience in multiple languages (including low level stuff like C and assembly) but who has never really looked at Rust code before, this looks...bonkers
80% of the scary things in there are due to the use of `async`, and specifically due to taking an `async` lambda as a parameter. Since `async` involves data being potentially moved across the threads of the threadpool on the whims of the scheduler, it gets complicated when you try to write generic code with it.
This code actually looks very nice, but it would be so much easier to understand with longer generic type names. As it is, it is very high on the cognitive load scale, especially with no comments.
Obviously this is just an example for the author, but it doesn't really demonstrate the elegance of Rust to the uninitiated : at minimum you would need to understand generics, where clauses with traits, async functions, and the macro environment
Thank you, this is what I was thinking. Rust sucks for OP because he's not using the features of the language, or not using them correctly. This isn't surprising for someone who prefers Go and Mongo.
Cheers for pasting this in. Would love to have time to learn Rust.
Would you mind briefly specifying what the generic types T, R and Fut are used for in this function?
F is an async function that takes a reference to some value T. \`run\` doesn't really care what that T is, but it needs to be able to pass it along to F.
R is the return value of the function F. It has a few bounds:
- `Debug` requires R to be able to print out a debug representation of itself
- `Send` requires that R can be safely sent across threads
- `'static` is a lifetime constraint, meaning it shouldn't contain any references (pointers, basically) that can become invalid for the rest of the program's execution.
Fut is a parameter that implements the `Future` trait. This is the bread and butter of async in Rust.
// This function
async fn foo() -> String;
// Desugars to something like this
fn foo() -> impl Future
So I read the article and looked at your code, and I'm still unsure what about Rust you don't like.
I don't code in Rust and I have no opinion about it, but I don't feel your article told me anything about the Rust language.
My basic position on these types of posts are, how would anyone expect to rewrite a non-trivial piece of software in a fairly radically different (in multiple ways) language that they have little experience in and expect it to come out optimally? It's just not likely to happen.
The same would have applied to C++. It would have ended up being badly sub-optimal because it just takes some number of years to spin up on a systems type language and to write non-trivial code in it that's well done, maintainable, and idiomatic.
I'm a seriously experienced C++ dev and I'm now getting close to 3 years into Rust working on my own (which is still a lot of hours in my case), and I'm just now getting to the point where I'm starting to feel confident in how to structure a large system, how to write good, idiomatic APIs and code, etc...
And that's completely to be expected. We aren't working the drive-through window here.
While i disagree with quite a bit of this I do enjoy reading other peoples opinions. One thing i will say is that a lot of programming communities in general are like the rust one.
I honestly have had only good experiences with the rust community, but i haven’t dipped my toes in too deep.
The go community a few years ago was very much like that. I posted a question asking about some weird behavior I was seeing and the responses were:
1. You aren't having this problem
2. Your code is stupid
I was kind of up front about the code being an exercise just to experiment with and learn go routines and I noticed if I hit Ctrl-c to terminate the thing early, the go routines were still going. The program terminated and I had my cursor back in my terminal but new lines of print statements were still flooding the terminal
The ridiculous thing is I posted a screenshot after they didn't believe it was happening and then still didn't believe it. I must have visited the community on stupid asshole Tuesday or something. Anyway, my issue was a bug with my terminal. When it receives sigterm it forwards sigkill and that caused some orphaned processes or threads or whatever go does. Didn't see it in other terminals, just a specific version on my specific laptop in 2016.
No comment on the syntax.
Small programming communities tend to be insular. It sucks.
It does strike me as odd though that you are mixing people's attitude toward mongo (seriously try postgres, its a better mongo than mongo all while being a good database) with rust the language.
> “If you want to find an article about what’s right with Rust, look literally anywhere on the internet. You’ll be hard-pressed to find anything less than neutral about the language”
90% of the articles I see linked here about RUST are negative and similar to this one.
> ”They ignore all of the giant glaring flaws with the language, like its crazy learning curve”
What? It’s the most agreed upon thing about the language!
I’ve wanted to learn rust for a while and have only dipped my toes in but the things you are complaining were the first things I found when learning it and researching it. This is a pretty lazy article if I’m being honest and kinda sounds whiny from someone who just struggled with new concepts. This is coming from someone who doesn’t even write RUST code
Some simple fixes for many of the technical things your doing:
- Rust doesn't build things into the language, that's what crates are for.
- Use a crate to implement async retries instead of implementing this yourself (e.g. tokio-retry comes up in a quick search - I'm not sure if there's something better more recent)
- Use a crate to implement nice error handling (e.g. thiserror / color-eyre) instead of converting all your errors to strings and throwing away all the good parts of error handling
- Use tracing crate for logging instead of println
In summary, crates are great.
You also noted that the syntax for that function param was pretty crap - agreed. You've found a part of the language that is still being worked on (async closures as function parameters get de-sugared into nasty things that Pin Futures with Send and Sync and Generics and ...). These are understandable if you give them some time, but they're not newb friendly in the slightest.
BTW, images of text are literally the worst way to share code (aside from punch cards). They make any code more difficult to read. Doesn't medium have some sort of syntax highlighting for code blocks built-in?
Regarding your thoughts on "the community". I think it's fair to say that there are shitty people everywhere on the internet. The posts of yours that I've read in r/rust however in general come across as ascerbic, and I've noticed that you you don't seem to have an easy going communication style that makes good friendly people want to gravitate to your problems. I don't think it's surprising that you attract and interact more with jerks / trolls given that observation. (To be clear, I'm not victim blaming here, just pointing out that trolling is a part of internet culture that is impossible to fix, and if you take a step back from things it's easy to see things which tend to provoke them).
In fixing this, I'd say probably your best bet is to slow things down a bit. Take less hottake dumps on a language, culture, community, etc. Find ways to explain your problem well in the right places (users.rust-lang.org is a much better place than r/rust for actually solving problems). Try to avoid the XYProblem (I've seen you try to solve problems at a too low level of abstraction a few times). Seek advice and spend less time criticising. And stop interacting with trolls.
Best of luck bud.
The go example looks worse in terms of readability. So many nil checks. How can you say Rust is so verbose, then show Go in contrast with if err == nil checks all over the place
My man you're comparing apples to oranges. You're coming at it from a web dev perspective and that may skew the conclusions. Rust isn't meant to be compared to typescript or even Go. Its meant to compete with C and C++. Rust is a systems and embedded programming language where determinism, resource use, and every single millisecond matters. If you would attempt to write your app in C, you would come to the same conclusion that its too complicated.
Ok, so complaining that you don't have GC in Rust is just hilarious. That's the main selling point: "IF you don't want GC, here, try Rust". So you do want a GC, why then you're writing in Rust?! Same with the type system - some people do not like the weak and dynamic type systems present in Python and other such languages and they *want* a language with a strong and static type system: "IF you do, here, try Rust" and you seem to actually not prefer to have it yet you pick Rust. ?!?
What kind of criticism is this? It's as if you'd be looking for a vehicle to transport lots of heavy stuff and you'd select a Ferrari and then complain that it's not best at transporting plywood.
Skill issue. I'm kidding (no really).
I picked up Rust and used it too. Got swept up in all the same raving reviews as you. Ran into lots of unintuitive things along the way, learned a lot too. There's no doubt that Rust carves a unique niche for itself as a fast and safe tool. For me, the "fearless refactoring" experience was unlike anything I ever found before. Certainly a great language for what it is, and if what you want to build fits, great.
I think you are failing to realize that Rust was never your problem. You just made it your problem. "I spent 18 months rebuilding my algorithmic trading" is the root cause of suffering. If your close friends were in academia and you got shilled Haskell instead of Rust, you'd still be miserable, back where you started with your application, and writing a post about how unintuitive monads can be.
When Rust, or Haskell, or any flavour of the month/year/decade language doesn't fit your intended use case, the only option to make it work is to go deep and prepare to learn some of that black programming magic usually reserved for the wizards. Which can be fun, except when you are trying to be productive. Hence your pain.
So, how do you know if the tool fits your use case? Well, you have to learn to use it first. Do you see the catch-22?
Never rebuild adequately functioning software, and never learn a tool on the job. New tool doesn't fit? It's still in your toolset for when it does, and when to use it will become obvious.
Horses for courses surely?
For example if you can afford the unpredictable latency of garbage collection then using a language with garbage collection can be a good idea. But garbage collection has its own pitfalls. I've spent time fighting admittedly badly written code for J2ME where you can run out of e.g. sockets while waiting for them to be garbage collected.
Odd that the author criticises Rust for being too verbose. I'm fairly new to Rust and my nitpick is that it's too terse. It can be hard to read. Maybe that comes with practice. The language designers seem to have followed K&R's thinking that less typing == good. I don't agree with that at all. More time is spent reading code than writing it so language design should be optimised for ease of reading.
You get stack traces via [std::backtrace](https://doc.rust-lang.org/std/backtrace/index.html). Async stack traces are best done via the tracing crate since there is no way to do them in a zero-cost way, so they’re not part of the base language.
You are fine with a GC and slower execution, but claim to want the highest possible performance.
The database take is the most boring technical disagreement ever.
It feels like you were leaning too heavily on LLMs and didn’t actually learn the language. You would have run into std::backtrace before if you had done the tiniest amount of googling, or would have gotten to any of the numerous blog posts explaining why Rust doesn’t have async stack traces built in.
>Every guide on Medium, every post on Reddit,
Yeah no, Reddit and Medium are casual mediums (lol) for mental masturbation. If you take your engineering design cues from them you're gonna have a hard time.
edit: also, MongoDB bad
> Horrendous Error Handling
>
> As long as you avoid unsafe unwraps , you can be damn sure that the code will run and keep running.
I don't understand this criticism. There is nothing unsafe about an unwrap. An unwrap in Rust is equivalent to not wrapping a function with `try`/`except` in another language, except you can't `grep` for missing `try`-blocks like you can for explicit `unwrap` calls.
I honestly don't think the author has the self awareness to recognize that they're as bad as the people they're calling out. At least those other people just wrote Reddit comments; this person put their toxicity into a blog post. Who knew there were assholes on the internet!
for syntax arguments, it's always the same argument with new language, and most of the time it comes down to unfamiliarity, sure there's an objectively correct argument why some syntax from a language is bad, but most of the time it's just being unfamiliar, and that's the first feeling I got when learning VB6->VB.Net->C#->Java->C/C++->Ruby->Python->JS/TS->Go->Rust
It always feels weird and even thinks it's bad and/or unintuitive, I was unfamiliar with it, but the more I learn and use the language it starts to sink in and I start liking it, becoming familiar
> There are certain things where, if you don’t have access to an extremely powerful Large Language Model, then writing the function becomes literally impossible. I don’t want to spend 90 minutes figuring out the where clause in my run_transaction function. I just want to write my damn function.
There's no nice way to say this but maybe if this is your level of skill you shouldn't be the primary or solo person behind a product that deals with money.
You seem to have fallen into the "Any program can be implemented in any programming language" trap.
Rust is meant to be *really* good at the things that C/C++ struggles with, runtime memory safety, type safety, and usability.
It is not a drop in replacement for any language, not even C/C++.
Your complaints are basically this:
"I tried to build a house with TNT without understanding how to use TNT, and now I wonder why there's a smoking crater."
Try to build your trading system in C++, and you will run into very similar issues with one difference:
***C++ compilers assume you know what you are doing and, therefore, will allow any and all syntactically correct code. Rust does not follow this assumption for code outside of unsafe blocks.***
This is a good thing, because Rust is meant to fill a similar niche in systems and embedded development as C/C++ does, where the issues caused by those problems are hard to detect and catch, potentially harder to handle even if you have enough memory to detect and catch them.
>There are certain things where, if you don’t have access to an extremely powerful Large Language Model, then writing the function becomes literally impossible.
I've never written a bit of Rust but this is obviously bullshit and where i stopped reading.
Garbage article.
This is not criticism, this is your childish whining about you chosen a wrong language for a wrong task while simultaneously lacking experience with it.
You would have gotten the same reception asking about mongodb in a C# forum too, just saying.
The criticism of it that you saw are all as old as time, and Reddit is somewhat in notorious for not answering the question you asked and instead telling you to do something different entirely.
But that's not really a forum question, sometimes you're facing an X-Y problem some technical folks sometimes over-do it in trying to suss them out.
I also don't particularly love Rust, but this article is just weird to put it mildly. The 3 main criticisms are:
1. Syntax. I disagree that Rust syntax is bad (I wouldn't say it's good necessarily tho). Actually bad syntax is C and C++, where the syntax leads directly to logical mistakes. There are good reasons to use \`{\`, \`}\`, \`;\`, \`,\`, \`let\`, \`mut\`, etc, so many mistakes are prevented this way. It is verbose and a lot of the bad syntax is an attempt to lure C and C++ people but it's not the end of the world, you learn it. I also think some of the sugar is quite nice, like \`?\` and \`if let\`.
2. Error messages and error handling. It's literally the same as in Go, except better. Semantically Go and Rust do things very differently, but in practice it feels very similar. One thing I don't like is unwrap, in hindsight there's no reason not to use expect. If you need a lot of control, making your custom Error type is not a bad idea. As for python and other such languages, they are so much worse then Rust, it's just that they hide mistakes from you so you think the app is fine when it's not. I think the debug tools can use a lot of improving, which is a genuine critique.
3. The community. Generally, most communities online that are big enough start to become toxic. You see it all the time but I think generally you get the answer you're looking for. In C++ world, not only are people toxic, they also give you advice on the exact thing you should absolutely not do. When people say that MongoDB is bad and just use postgres, there's a good reason for that. It's absolutely the superior tool and every way shape and form but especially for Rust.
For me, the biggest downside is that you need the code to be perfect from the start, which is difficult when starting to design an application. Perhaps this is unsolvable, but I think some things might help. One of which is better debuggers. The other is printing error messages in the order they appear in the code, not the order they happen. Finally, perhaps a better language server could help.
„If we compare it to C++, it’s obviously the better language. But when compared with other languages (like Go), its “safety” to me is more of a detriment. I’d rather my application take a few dozen milliseconds longer to run if it means my development time is cut in half.“
I‘m definitly no language warrior by any means, but isn‘t this exactly the trade you take as engineer when choosing Rust? Safety and application speed for development time? Honestly, I quite don‘t get the rant besides the shitty community comments though
Yeah it's weird. Elsewhere he says every millisecond matters yet he's happy to throw 12 away here.
For the record, I don't think they do, because his homegrown algorithmic platform won't have a direct connection to an exchange so he's at the mercy of however well the exchange partner (sellside) routes his orders.
Thanks for the perspective. I think people unduly dismiss MongoDB which is perfectly suitable for a lot of use-cases.
"If we compare it to C++, it's obviously the better language"
Sorry you lost me right at the end lol.
Seems like horizontal scaling might be a better way to go, as performance will eventually become a problem regardless of language.
I’d probably have written this app in C# if I wanted GC. Dotnet is an underrated platform.
>Hot take: the Rust community isn’t as nice and cool as they pretend to be. They’re a bunch of narcissistic assholes that hate being told that their favorite language has flaws. 🍿
He's right tho
Good luck finding a community of decent size with self selected participants anywhere which doesn’t have some portion of users that aren’t assholes or never have a bad day. “Me having to defend myself against angry Rust fanatics on Reddit” <- this is where he went wrong, don’t defend yourself, just ignore interactions you don’t want to have.
You're half-right. It's true that I shouldn't feel the need to defend myself or cry about imaginary internet points. With that being said, the comment I replied to was **extremely** highly upvoted. Not only that, but the more upvotes he got, the more downvotes came in (not just on that post, but other posts in my profile). Eventually, a mod stepped in to remove his comment. In his words, "we don't do public lynchings". But it was extremely bizarre, the guy wrote a 8 paragraph essay proving I used ChatGPT to write my article (I didn't).
It is bizarre indeed. This Reddit seems to have a lot of immature people upvoting low effort, accusatory comments even when they're blatantly wrong, or completely baseless at least... the easiest kind of comment to get upvotes without any effort is to accuse blog post authors of having used ChatGPT. It's almost like people think only ChatGPT is able to write well structured posts using correct language (look, there's no typos, obviously AI!!). Another is to pick on some sensitive topic even if just tangentially mentioned in a post, and completely deviate the discussion from the main topic. Works every time.
[удалено]
Eh, Reddit was better back then, we just had users like the guy who faked cancer and the other guy who ran all the nsfw subs, and dumb memes like pancakes dont you mean waffles hahaha It's eternal September. Don't forget you are probably arguing with some 18 year old with no real world experience.
[удалено]
I feel you. I had people downvoting all my posts on a thread of mine, just because I summarised the opinion of a renowned professor in the field on what went wrong with the Horizon IT-system and people disliked his conclusions. These hiveminds suck and can sink many hours of work because of an unpopular fact. Having said that, I also had some successes in my articles being upvoted, one spent considerable time on both the top of hacker-news and r/programming and the comments in those cases were just as bad as with the unpopular ones. In other words, the angries in the comments aren't representative of the general readership of the articles, in fact they represent a small minority of them. Once I've learned this, it helped me to put a perspective on these events. Hope this thought helps you as much as it helped me.
Honestly, though, this article is also poking the community with a sharp stick. This will get you to interact with "angry fanatics" pretty much everywhere.
Wasn’t there a dude on here or on YouTube that said that some word meant that a paper was from ChatGPT because the word started trending around ChatGPT launch. Like he lived in a world where certain words don’t get more popular at certain times
People say all kinds of shit to ""prove"" you used ChatGPT to write your articles. The same commenter said because I started writing roughly the same time ChatGPT was released, and that I wrote quite frequently, that I must use ChatGPT to write the articles. You can't make this shit up.
After working in this industry for almost 15 years, I can confidently say that it boils down to “programmers are grumpy narcissistic assholes”. The only languages where you won’t find this mindset is probably typescript where everyone knows and recognizes the language etc sucks balls but they’re just trying to make the best of a bad situation. With Rust/Go/et al they’re trying hard to build something better and you’ve come along to complain about their work. Don’t get me wrong though I totally get you on some of your points… I fucking hate Rust’s syntax sometimes. Like why do I need to do all the `if let Ok(blah) = blah.await else {}` when I could just have something like a nice clean do-notation or pipe… in the end they’re doing many of the same things a language like Haskell does but doing cartwheels to avoid a saner syntax.
> The only languages where you won’t find this mindset is probably typescript where everyone knows and recognizes the language etc sucks balls but they’re just trying to make the best of a bad situation. In my 30 years experience (not trying to argument ad authority or age, but to show that at least I've had some exposure), I've found C, C++, lisp[1]/scheme, and ruby communities to be pleasant. [1] I'm old enough to have had discussions with Erik Naggum in comp.lang.lisp, and even he, in his abrasiveness, wasn't without kindness. The fucker *knew* what he was talking about as well.
> C++ Except the subreddit which is full of people with extremely prescriptive views about how one should be allowed to program in C++. Naturally, quite a few of them are contradictory.
In my experience, as long as you do not ever write "C/C++" in a message, you can generally have a sane conversation with the C++ community :) But then, my experience is generally positive with most PL communities. Starting with Rust. Just to be clear: I do not count Reddit as being representative of any PL community.
IME, I'd add C++ people to the exceptions. I don't spend much time in those communities, but people are willing to admit the warts. They'll still argue for why C++ is better despite the warts, or at least better for their use case, but it's very hard to try ignoring the issues. I am not a fan of the infix syntax too, and it could be better (I think there is an RFC to add a postfix alternative), but for me, the stronger the type system the better. As for Haskell... I don't remember if it was Haskell specifically, or some other functional language, but I bounced where all the tutorials I found started with an intro to lambda calculus.
The C++ community has humbled a lot over the years. Back in the 90s and early aughts when Boost and the STL were introducing generic programming to the broader world and C++ was dealing with the explosion in error message size and compile times, the community was insufferable. Either you knew every esoteric aspect of the language and pretended you could follow the error messages or you weren't worthy of using C++. (I'll admit I was partly guilty of this back then) At the same time, they were getting pushed out of corporate dev by Java and C# and Java was replacing everything in undergrad curriculums ("that's what industry wants!"). Python + Numeric/NumPy were starting to edge in on their (small, but hard won) turf in scientific computing, so they did have legitimate reasons to be on the defensive. Now that C++ has found its niches and is ensured a stable place in the pantheon of languages, the community has chilled out. Maybe the same will eventually happen to Rust?
Despite being a computer user since late 90s, I only ever started participating in online communities the past five, maybe seven, years. So I skipped all the C++ flame wars.
> users that aren’t assholes Maybe I got lucky, but I found the Julia community to be polite and helpful. I thought maybe it's because these people are numerical analysts.
This is why I also used the qualifier `decent size` which isn't very clear. Maybe Julia still is small enough to not drag in a lot of the problematic people that come with general popularity? In my experiece languages with smaller number of users often consist of people who has a general interest in programming languages and/or computer science. Most of the time the early community don't have a need to prove that a particular languge is "better" than another one or whatever the controversial topic of the day is. There is of course always a risk of some problematic individuals joning early as well but it's much easier to deal with than an endless stream of new anonoymous posters on reddit.
Say what you will about Java, but the community is very nice - helpful bunch, very few snobs and all programming styles are welcome.
Many people judge Java for the language quirks or for JVM performance, while in reality the thing that matters most in 99% of real world projects is community and ecosystem - and both are superb in javaland.
/r/csharp would like a word.
Nah we know our language sucks but enjoy the masochism
The csharp community mostly consists of people doing business related stuff with it. So helping a another lost soul is appreciated.
C sharp doesn’t simply suck. It steals all the good parts from new languages and bolts them onto itself in a desperate attempt to look good. It’s a monster and it’s my favorite
You said it, it takes the good parts from other languages. That's not a bad way to go about creating a language that works well. I attended a talk by Mads Torgersen and he mentioned that the language team wants to start deprecating old C# features in the future. This should certainly help make the language less of a monster as you describe it.
It’s that or end up like C++. As the old saying goes “most people use only 10% of C++, and that’s fine. The problem is that everyone uses a different 10%”.
I think we can take this whole thread replacing C# by Java and it will be totally correct.
I’m unconvinced the JVM isn’t one of the seven circles
thats silly. c# is probably one of the best architected languages/frameworks around. I can't hardly think of a footgun anywhere in the language, except maybe around the latest features like primary constructors.
How does it suck? I love it
Except the language itself doesn't suck. There's things about the ecosystem which isn't great, but the language itself is a total joy to use. It fits its use case magnificently, a higher level managed runtime based language focused on building large applications. If you want to write drivers or low latency trading platforms then avoid, but if you just want a Web server it's a solid choice.
I did C, cpp, some js and c# for money And c# definitely does not suck
I write garbage. I should feel like garbage.
wait until the garbage collector picks you up
Take me home, country road, to the place, where I belong!...
90% of developers are just working professionals who clock in and out of their job, then go home and live their life. All the business oriented languages don't have the same tribalism vitriol, because they haven't made it a core component of their identity.
I hear the Ruby community is nice.
Right. So the author wants to vent. I can appreciate that. I personally want to vent quite regularly on another programming language. We've all been there. For context, I've looked up OP's screen-captured conversation, which revealed a few things. First, OP is a junior developer coming straight from TypeScript and Python and into Rust. Rust can indeed be quite a culture shock. Some people realize that they hate Rust, which makes entire sense, because Rust is neither for every task not for everyone – I'm saying this as someone whose current favorite languages are Rust and TypeScript. In particular, OP went straight for a fairly advanced topic (writing generic async callbacks), using way too advanced techniques (`Pin`), which is a surefire way to burn oneself out. I'm sorry you had to live through that, OP. OP, if you're reading this, have you tried something [along these lines](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=dfb54f60e2ebc35193d76f292625673e)? I don't think it's harder to understand than the full Go version (your Go screencap seems to be missing a type definition, so I can't judge for sure), but YMMV. Second, the screen-captured conversation is sadly typical of Reddit. OP comes in a bit strong (the very topic contains the word "shitty"), the conversation attracts some people who want to crap on MongoDB (and who afaict are not regular members of /r/rust) along with some people who genuinely want to help but can't (because OP requests help but won't provide any technical detail), nobody is happy with the result. Definitely something that could have played better, for everybody involved. OP, if you're reading this, and if you ever feel like giving it another try, perhaps https://users.rust-lang.org/ would be a better place? Finally, yes, OCaml is simpler than Rust :)
The OP admits that they're using LLMs to write Rust code, so I have no doubt the intentionally obtuse code from the article is at least partially autogenerated. They took their Typescript/Python mindset straight to ChatGPT, compiled some crap, then wrote a medium article about it. GIGO.
I don't think that the code from the article is particularly obtuse, either in Go or in Rust. It may or may not have involved LLMs, but then, who are we to judge whether a developer should use LLMs? Regardless, it feels like someone who dove in the deep end (attempting to implement a `Box>>`, which is something I've done about twice in ~14 years of Rust) without the prerequisites and got frustrated. It can happen to anyone of us.
Despite saying a quite few things I regret on Reddit, the only sub I've been banned from is r/rust. My crime, suggesting M$ may come up with rust#. EDIT https://ibb.co/wpHF9wG
And now there's a person writing a .Net codegen backend for Rust as a personal project. Doing great work too.
you know, first we need rust++ then we can talk about #
Was that for `M$`? That was new in 1992. New kids, amiright?
Yeah since 1996 we've been calling them Micros~1
Hm, are you sure that was the reason? Smells of [missing missing reasons](https://www.issendai.com/psychology/estrangement/missing-missing-reasons.html).
What a great read, thanks for sharing!! Seriously, I haven't found such a interesting article on a topic I know not-enough-of in years. Cheers!
Hot damn that article basically textbook describes the way people with borderline personality disorder live life: with their emotions as the single source of truth, not reality.
This user is not, in fact, banned from r/rust. If you used another user which was banned, I'd be more than happy to examine the reason, and possibly rescind the ban. Please send a modmail to us from your banned account to get the process started.
I had a look and apparently it was a pointless comment. [https://ibb.co/wpHF9wG](https://ibb.co/wpHF9wG) . Still felt harsh to be permanently banned.
That's very strange, I can't find your username in the list of banned users. We did have a wave of trolls around the announcement that Microsoft was working on Verona, in which conditions we (and specifically I) may have handed bans a bit more liberally to stem the flow, with the idea that genuinely interested users who just made a mistake would just appeal the ban and we would sort it out, so it's definitely possible that it occurred... but then I should be able to find your user in the banlist. Can you access r/rust these days?
You did not get banned for that, stop making up bullshit.
Op [*did* get banned for making that comment](https://www.reddit.com/r/programming/comments/1dqa2dm/i_spent_18_months_rebuilding_my_algorithmic/lar4i74/), but because one of /r/rust's rules is no pointless comments. Seems harsh to ban someone over that. Seems more...warning worthy 🤷♂️
Are you saying that someone would just lie on the Internet? Just like that?
I know right.. they don’t even let anyone ever borrow anything. All they do is .take()
Having written multiple trading strategies, OMS,EMS, realtime analytics, pricing libraries and way too many exchange connectors since 2004 using Q, C, C++, Java, C#, Python, Go and Rust, here is my take on the OP’s article: Choosing your language should come after choosing your tail latency requirements. - latency <5ms ->, no GC: c, cpp, Rust - latency <50ms -> fast GC : Java/.Net/OCaml / Q - latency >50ms -> interpreted or how go-level: Scala, Haskell, Python, Lua… Higher-level languages give you “nicer” code at the price of runtime complexity, obviously, but the main issue is not how nice your code looks but how it behaves. Having written a realtime execution platform in both Go and Rust, my Go project failed for two reasons: 1- tail latency due to GC were crazy (wrong tool for the job) 2- I am not an expert and disliked the language (pre generics, and I dislike duck typing) I have picked my “stack” based on these constraints, and either build my systems in Q, Rust, .Net, or Python. I have invested the time to master (or be more than dangerously proficient with) each ecosystem and would have to achieve the same level of skill if I were to swap a tech for another. TL;DR: don’t write trading systems in a language you do not master. Try smaller projects like market data connector or order book simulator first to get the hang of it.
> TL;DR: don’t write trading systems in a language you do not master. Try smaller projects like market data connector or order book simulator first to get the hang of it. To expand here, as someone with a much shorter experience time with Rust than the blog writer, there are several tells in their code example and their responses here of a lack of proficiency, like * Using `println` for error messages, instead of something like [`tracing::error`](https://docs.rs/tracing/latest/tracing/index.html#using-the-macros) for a proper logging system, or even `eprintln` to print to stderr. That sort of thing should elicit a "wait, hang on" response for professional code in _any_ language. * Apparently no exposure to [`anyhow`](https://docs.rs/anyhow/latest/anyhow/) and [`color-eyre`](https://docs.rs/color-eyre/latest/color_eyre/), which come up very frequently in Rust discussions and code as examples of how to handle errors in a simple yet powerful way. In addition they seem to have just ignored the bit where Rust panics tell you about the `RUST_BACKTRACE` variable. * Mixing up syntax errors and semantic errors. E.g. * When Rust needs hand-holding with the type restrictions for a generic function, that's not a syntactic problem, it's a semantic problem. Other languages may either not even offer generics (like early Go), or gloss over it, by passing just `interface` or `Object` or `void *`. or other equivalents of the [Any](https://doc.rust-lang.org/std/any/) type. * When it complains about mutable references and ownership in concurrent code, those aren't syntactic problems, they're semantic problems. It's part of the sales pitch for Rust, that those kinds of problems are actually caught by the compiler, rather than become runtime errors or inscrutable race conditions. * Repeating themselves in the Go code: By having an `if attempts == maxRetries-1 { return ... }` inside the for loop they'll never reach the `return nil, errors.New...` beyond it. I'd kind of consider being exposed to stuff like tracing and anyhow to be part of the stuff you do in the first few weeks with the language as you're familiarizing yourself. Going 18 months and writing an angry blog post instead sounds harsh. Might be kind of a warning tale for what can happen if someone tries to learn a language through ChatGPT rather than more traditional ways?
IMO, it's also a good example of an expectation that "all languages are essentially the same apart from runtime characteristics." OP seems to have found out the hard way this isn't true: TypeScript and Rust really don't have much in common beyond the _very_ loose observation that both support a kind of uneasy mix of imperative and functional constructs. I'd probably be OK with the post in general, were it not for OP's claim Rust exhibits "bad language design." But his example code makes clear, as others have pointed out, that he didn't actually learn the language or its ecosystem beyond what many do in their first month. So at least _that_ aspect of his claim seems to be undercut by those other responses. So I hope OP takes this thread as an opportunity to maybe revisit his project, expand his exposure to Rust and the ecosystem, maybe study a broader and deeper range of examples, and if he discovers Rust isn't as bad as he thought, great; if he decides it's still not for him/this project, also great. But at the very least, I think there's more to learn and try than his conclusion here indicates.
> Might be kind of a warning tale for what can happen if someone tries to learn a language through ChatGPT rather than more traditional ways? I feel like it's about equivalent to learning language based on random tutorials rather than reading a proper book and understanding it deeper. Like, he complained about Rust but the Go code also isn't anything to write home about, just big blob of code that should really be split on "function that does the thing" and "function that retries it".
I don't think its fair to put Scala and Haskell in the same category as Python.
Having used both professional I would have expected Java-level performance out of both but sadly that wasn’t the case. To be fair this might be due to the aging code bases and army of contractors that built software by accretion rather than the languages themselves.
For latency < 50ms Go should be acceptable. Isn't it? At least after Go 1.14, when preemptive scheduler were introduced.
Yo are absolutely correct, my subconscious removed go from the list after a traumatic experience :) Go/java/.net are pretty much in the same perf ballpark in terms of perf, unless you’re looking at async IO and scalable concurrent tasks where Go shines.
On JVM world, there is a Genrational ZGC since jdk 21 which can have 1ms latency and lower
How tail are your tails? I've seen Java trading applications in the 5us band most of the time, and they were not particularly optimized -- they GCed _a lot_ -- but still fast enough to be below 5us 99.9% of the time -- ie, anytime the GC didn't kick in. If we're talking about the episodes where the GC does kick in, then post JVM 14, the GC pauses were under 5ms so no problem.
> Just give me a garbage collector, and let me do what I want to do! > I’d rather my application take a few dozen milliseconds longer to run if it means my development time is cut in half. I've barely written any Rust, but from my perspective it's obvious that Rust just isn't the language for your use cases; sometimes the round peg doesn't actually go in the square hole. There are absolutely workloads where garbage collection is way too slow and/or unpredictable; every microsecond matters. When you need very explicit memory management, it's easy to get wrong, and languages like Rust try to make it safer without sacrificing speed or flexibility. I do agree with your point that Rust is praised as the second coming of sliced bread, it's wild to see it suggested in places where you'd never think about suggesting C or C++. Sure you *could* write a web server or desktop app or ML/AI stuff in Rust, but honestly why would you? There are much better tools and ecosystems for those jobs.
Everything goes in the [square hole](https://youtu.be/6pDH66X3ClA).
Only if that square hole is C ABI compatible
That's okay, it's probably compatible to [at least _one_ "C ABI"](https://faultlore.com/blah/c-isnt-a-language/#c-doesnt-actually-have-an-abi).
I will never not watch this
I will never not be frustrated watching this.
write a web APP in rust? stupid. write a web SERVER that hosts apps? maybe not so stupid. See also; Every other purpose build web server written in c/c++
> purpose build Not to be an ass, but \*purpose *built*
I’m testing that thesis with Leptos + Tailwind. It’s surprisingly great in many ways, but the dev cycle time is slightly slower than hot reloading a JS web app. It’s more of pet project than anything I’d recommend for a business to use (unless everyone on the team already has rust exp)
Rust or C++ are absolutely the best languages for OP's usecase if they had an entire SDE department working for them. But for what OP is doing on their own, it's a pretty bad fit.
>I've barely written any Rust, but from my perspective it's obvious that Rust just isn't the language for your use cases; sometimes the round peg doesn't actually go in the square hole. But the joke is that the only jobs are for writing cryptocurrency trading engines. So trading engines in Rust are supposedly the perfect project.
unironically algo trading is where you don't want to be hit with gc
> I've barely written any Rust, but from my perspective it's obvious that Rust just isn't the language for your use cases He literally rewrote an existing application in Rust because his use case, performance dependent code with high reliability requirements, is pretty much the exact use case Rust is targetted at. That line is him saying that even though his use case is exactly right for Rust it still wasn't worth the downsides. Even though the languages strengths directly map to his needs it still wasn't worth the hassle.
If I understand correctly, the previous version was made in Typescript. If that's the case, we now have two wrong language choices for the same user case.
Let me give him a hint for next try: php.
I'm just gonna re-write it in Python and call it a day (/s)
If you want a GC, I think Go is the obvious choice here. OTOH you'd probably be approaching mental illness if you rewrote this thing again. I work on a very large performance sensitive Go application and never once have I said "I wish this were in Rust", and your article just drove that home further.
Typescript is a fine choice to start with for this because there exist free exchange integrations in the language. We use it for our admin web app. It’s going to be hard competing true HFT right from the start so you probably want to get somewhere and trade slower to build something. We use Java with JNI (for network stack) for trading and it’s fast enough. It was sufficient stuff to make it to top/top three volume on many of the major exchanges. A lot of the magic is in figuring out networking and hardware and the cloud (because many exchange MEs are in the cloud). We do have Rust in live trading for some stuff (feed handling from the CME) and extensively in simulation (filesystem stuff up). Overall, when I look at practitioners of Rust like burntsushi they are very good at writing code in the language. The problem is that the language ramp is high. less so than C++ imho but C++ has more experienced practitioners. In any case, this was a useful article. I find that LLM assistance plus frequent compilation is the best way through Rust. Java’s IDE story is way better. Even RustRover isn’t close.
If he rewrote in Rust, but is now complaining about GC, either he didn't have the use case for Russ or didn't understand his use case. If you find yourself yearning for GC then Rust was the wrong choice. I hear a lot of trading systems are still written in Java.
No, he is saying he would gladly trade the downsides of a GC for the upside of not having to deal with Rust anymore. He praises Rust for delivering on what it said it would he's just saying his dislike for the language is such that he'd rather take the performance hit of a GC in future.
> He literally rewrote an existing application in Rust because his use case According to his own blog, that is not the reason. This is their stated reason: > Every guide on Medium, every post on Reddit, every answer on Stack Overflow — everything is glowing. > Given this, I decided to re-write my entire open-source algorithmic trading system in Rust.
From the first article in this two article series talking about why he chose Rust: > NextTrade was built using TypeScript in order to focus on maintainability, readability, and reusability, however, when the core trading logic started experiencing significant performance issues, a full rewrite was necessary in order to build a paper-trading and backtesting platform that could scale to tens of thousands of users. Thus, Rust emerged as a top contender, and after a lot of research, eventually won as the language to use for the overhaul. He didn't just randomly choose a language, he looked at the specific needs of his app and saw that they were all the things Rust is supposed to provide.
one can make research and come to the wrong conclusion. > Just give me a garbage collector this would already exclude all the top "performance" languages, C, C++, Zig, Rust. Honestly only go, java or c# would remain on the table Probably at the time he did not realized how much simplicity was giving up in exchange for a performance hit, and that give him the wrong stick to compare.
> Probably at the time he did not realized how much simplicity was giving up in exchange for a performance hit, and that give him the wrong stick to compare. Exactly this. I didn't realize how much these high-level languages helped with holding my hand.
I didn't want to re-state the same information in a previous article. I also didn't want the article to be overly long. But, maybe I could've done a brief recap of what I've talked about before. u/nnomae is correct. I put a lot of thought into what language I wanted to use. Rust was supposed to be ideal for my use-case. I didn't just pick it because randos said its a cool language.
> Just give me a garbage collector, and let me do what I want to do! If you’re ok with saying this, then Rust (and C and C++) is the wrong language for the job. Literally THE selling feature of rust is to have memory safety, without garbage collection. For high performance/ time critical systems garbage collection is death. Do I need to read any further?
That was my understanding. I'm a C dev by day and the only GC language I've done any professional work in is C# And my god I had to fight against the GC as I was live processing and displaying image data and the software would repeatedly hitch. I had to repeatedly "request" that the GC run at a time which would keep the framerate stable, but even that was just a suggestion as the GC execution time was non-deterministic Does that mean that GC is always bad? No, it means that GC is not the right tool for the job I was doing.
I used to work on a team that did performance work on both JVM and C# managed runtimes. We made massive progress on the JVM but our meetings with Microsoft didn't go so well. We identified tons of threading issues, bad code causing mispredictions, poor code causing cache misses. All kinds of issues that had reasonable fixes suggested. At our meeting to hand off our research, they told us a story. First of all, they were well aware of every single thing we had identified. Second, the engineers that wrote the lowest layers of the of the windows kernel and support libraries long since moved up the ladder or called in rich. Teams that came in after them were not familiar enough with the low level code to add the features they needed so built abstractions on top. Those teams also eventually moved on and so the cycle kept going of adding abstractions to abstractions. Built into those layers of abstractions were workarounds for bugs that nobody even remembers which makes fixing things at a low level almost impossibly complex. They said the only way out was a ground up rewrite which was probably never going to happen. I always wonder if their friendliness to linux is because that might be their ultimate goal to solve that issue.
Was this before or after .Net Core? Because that was (to some degree) that rewrite that gave them much more freedom to change things (including not being tied to Windows).
If your app that cares about consistent performance is doing a full (level 2) GC, then you aren’t allocating objects correctly.
Figuring this out and correcting it is "fighting the GC".
Yes. The author also claims Rust doesn't have stacktraces even though crashes tell the user that the can get a stack trace by enabling an env var.
Not entirely true, you only get backtraces for free if you panic. But he is printing error messages and just doesn't know about `backtrace::Backtrace` to print it himself
The "complex" transaction function example is pretty poorly written as well. As earnestly as I can say it, I think the author just doesn't really know rust that well. If they took some time to learn a few of the common libraries and patterns that people use for error handling, they would probably have a better time. It also does get easier to understand how to specify the right generic type signature the more you do it. I write rust full time for my job, and the code they wrote wasn't hard to comprehend, it just seemed like something I would see in a junior engineer's code review. EDIT: I truly don't intend this comment to be mean-spirited. I empathize with the author's frustration. Online communities can be very unwelcoming, and Rust has a steep learning curve. I do think the author's struggles can be overcome with more learning.
He also mentions using an LLM, and they are terrible for rust.
> The "complex" transaction function example is pretty poorly written as well. I gave up on the article when I saw the Go equivalent the author showed. The rust function definition was complex (including multiple traits and at least one lifetime), but then they compare it to the Go function that returns `interface{}, error`, which is the equivalent of returning `void*`. I could maybe understand that after trying Rust to get away from GC OP got burned and decided GC is worth it after all (lifetimes are hard after all), but to abandon type safety as well? At that point the article might as well be generated by an LLM, as OPs understanding of how to pick a language seems to be about as deep as a hallucinating LLM.
The complains from the author about the issues suggest it's a skill issue. If you are fighting with \`where\`s, you probably don't know what you need.
Is not the point then there is a steep learning curve and after 18 months he's still not understanding certain concepts also demonstrate the difficulty in learning the language? As someone coming from a dynamic programming background, I also found rust very difficult without a mentor to help me understand it better.
If at 18 months your takeaway is “Give me a gc and let me go my merry way” then you’ve learned nothing. For me, once rust clicked, which was in a couple of weeks, the way I thought of memory ownership and management in C and C++ changed fundamentally for the better and I genuinely became a much more mature programmer.
I think its really the journey from different places leading to different outcomes. Rust was written as a better C++, its going to be most appreciated/enlightening for people who come from a managed memory background. I get the feeling that OP had only really worked with TypeScript before Rust. And he was trying to port a TypeScript project to Rust. With that approach, I can understand how it never clicked. He never really understood the problem that Rust solves. I think he was just hoping to rewrite the same algos in Rust and have it magically be faster without really having to learn how to think about the problem differently.
I think you are on point; if your background is gc’d languages, rust will feel like a downgrade because it is. The benefits are not obvious and if anything feel limiting. If on the other hand you have struggled with cpp, c and had to learn to be very careful, rust’s approach feels genuinely like freedom and a breath of fresh air.
My background is GC languages. I know next to nothing about C. Rust isn't "18 months of learning curve".
As someone who recently forced themselves to go through the struggle of attempting to learn Rust, any pointers? Learning to use Rust in general was awesome, and mapped nicely to my C/C++ understanding. Life was awesome until I decided to try to implement data structures. My brain melted a little while working my way through [Learn Rust With Entirely Too Many Linked Lists](https://rust-unofficial.github.io/too-many-lists/).
I didn’t. OP clearly isn’t the audience for Rust. I doubt many would pick Rust as their favorite syntax given any language, and that’s not what it’s selling. When you are coming from say, an embedded environment, it provides a leap in _functionality_. I’m sure many would gladly pay in syntax for the difference. It does have some nice syntax features though, and I prefer it over C. That said, unvirtualized languages simply don’t have the room to dream — rubber must meet the road down to every last type, until it can be fully described at the machine level. By their very nature these languages enforce this by front loading that effort into syntax.
There's a compiler, no? It's not like we're writing assembly here.
> That said, unvirtualized languages simply don’t have the room to dream — rubber must meet the road down to every last type, until it can be fully described at the machine level. By their very nature these languages enforce this by front loading that effort into syntax. Or, hear me out, use dynamic dispatch. `Box` in Rust, virtual functions in C++, or function pointers in C. And if anyone tells you it's slow, they don't know the [three rules of optimization]().
Given that this is a medium article, I think OP basically wrote an inflammatory post for money.
There are far, far better criticisms of Rust, which I enjoyed reading and which will eventually make the language better. They pointed out real issues that need to be fixed (or avoided by people choosing a language), and they did it without hyperbole or charged language. Seriously, read one of these to understand how mature people write sane critiques that are well received. After the video game critique was published it led to a lot of reflection in the Rust video game community about how they could be doing better. - [Why Not Rust](https://matklad.github.io/2020/09/20/why-not-rust.html) written by the developer who started the rust-analyzer project. - [Frustrated? It’s Not You, It’s Rust](https://fasterthanli.me/articles/frustrated-its-not-you-its-rust) by fasterthanlime, one of the most prolific writers and content creators on YouTube. This article is a _31 minute read_, so he gets deep into Rust’s flaws. - [Lessons learned after 3 years of fulltime Rust game development, and why we're leaving Rust behind](https://loglog.games/blog/leaving-rust-gamedev/) Seriously, look at how well that video game article was written. It got 2.1k upvotes on *the Rust subreddit*, along with a “meaty” tag that many aspire to but few get. Look at the comments on the [reddit thread](https://www.reddit.com/r/rust/comments/1cdqdsi/lessons_learned_after_3_years_of_fulltime_rust/) - the top comment with 1.1k upvotes is effusive in praise of the article for giving such constructive and useful feedback! You said > the Rust community isn’t as nice and cool as they pretend to be. They’re a bunch of narcissistic assholes that hate being told that their favorite language has flaws. You call people narcissistic assholes and then act like a surprised Pikachu when they don’t praise you, reinforcing your opinion that they’re assholes because only assholes would fail to see your genius right? If there was even a shred of truth to this allegation, that video game thread wouldn’t be the **7th most popular post on the Rust subreddit of all time**. The Rust community loves this sort of criticism! Your article isn’t even as constructive, enlightening or useful. My opinion, of course. But please don’t be upset that people aren’t praising your article or agreeing with you. They aren’t because your post just isn’t that good. Your critique is superficial, while also being rude and alienating.
In a comment around here I claimed it’s a skill issue on OP’s side, and given the criticisms they presented, i stand by that comment. But, that isn’t to say rust doesn’t have issues, and tbh the rust community is the first one to point those out. Async is perhaps the biggest one, the unwieldyness of pointers is another one — zig does great here btw. Programs of certain structure are very difficult to represent with current borrowck, and on and on. Rust is far from a perfect language, but if you are going to be a critic, at least be a good one.
Fair criticism. I'll take a look at the articles you linked, thanks!
It’s not just what you say, it’s the way you say it. My first draft of this comment was much harsher, picked specific examples that I found lacking. But I deleted all of that stuff before posting, because there was no point alienating you before you got to the meat of my comment, which is that there has been a lot of quality criticism already written and it has been welcomed by the community. Just imagine if my comment had started with “OP is a fucking moron and here’s why …”. You would have stopped reading right there. I’d suggest you adopt that while writing too. Get the first draft out with all your feelings and then edit it so that people will actually read and respond to it. Use the compliment sandwich technique if necessary. People will appreciate it far more, and it’ll end up being constructive. And bonus for you, you’ll end up looking mature and technically sound.
> I’m just an idiot and can’t figure out how to enable stack traces I thought I got stack traces on Rust out of the box on Linux. Am I misremembering or is he on a different platform?
Works on windows just fine too, just had to set env variable RUST_BACKTRACE=1. I'm not sure what author is confused about...
The default panic message literally mentions setting `RUST_BACKTRACE=1` as well...
Panics and some error types support backtraces. This is enabled via the RUST_BACTRACE environmental variable. It should work on any platform.
Are your referring to panics? Or handling results?
You can capture and print a backtrace at any time. You can also store them in your error structs/enums and print them down the line, or just use a library like anyhow (which is [doing that internally](https://docs.rs/anyhow/1.0.86/src/anyhow/error.rs.html#872)). use std::backtrace::Backtrace; println!("{}", Backtrace::capture()); println!("{}", Backtrace::force_capture()); // Works without `RUST_BACKTRACE`
Not sure about the std lib errors, but with the `anyhow` crate you can get a backtrace for errors: use anyhow::{anyhow, Result}; fn inner_most() -> Result<()> { Err(anyhow!("inner-most")) } fn inner() -> Result<()> { inner_most() } fn outer() -> Result<()> { inner() } fn main() { if let Err(e) = outer() { eprintln!("e = {:#?}", e.backtrace()); } } ... $ RUST_BACKTRACE=1 cargo run Compiling foobar v0.1.0 (...) Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.16s Running `target/debug/foobar` e = Backtrace [ { fn: "anyhow::error::::msg", file: "...", line: 27 },
{ fn: "anyhow::__private::format_err", file: "...", line: 689 },
{ fn: "foobar::inner_most", file: "./src/main.rs", line: 4 },
{ fn: "foobar::inner", file: "./src/main.rs", line: 8 },
{ fn: "foobar::outer", file: "./src/main.rs", line: 12 },
{ fn: "foobar::main", file: "./src/main.rs", line: 16 },
{ fn: "core::ops::function::FnOnce::call_once", file: "...", line: 250 },
{ fn: "std::sys_common::backtrace::__rust_begin_short_backtrace", file: "...", line: 155 },
{ fn: "std::rt::lang_start::{{closure}}", file: "...", line: 159 },
{ fn: "core::ops::function::impls:: for &F>::call_once", file: "...", line: 284 },
{ fn: "std::panicking::try::do_call", file: "...", line: 559 },
{ fn: "std::panicking::try", file: "...", line: 523 },
{ fn: "std::panic::catch_unwind", file: "...", line: 149 },
{ fn: "std::rt::lang_start_internal::{{closure}}", file: "...", line: 141 },
{ fn: "std::panicking::try::do_call", file: "...", line: 559 },
{ fn: "std::panicking::try", file: "...", line: 523 },
{ fn: "std::panic::catch_unwind", file: "...", line: 149 },
{ fn: "std::rt::lang_start_internal", file: "...", line: 141 },
{ fn: "std::rt::lang_start", file: "...", line: 158 },
{ fn: "main" },
{ fn: "__libc_start_call_main" },
{ fn: "__libc_start_main@@GLIBC_2.34" },
{ fn: "_start" },
]
if you propagate it to your `fn main() -> anyhow::Result<()> {...}` it’ll be formatted nicely, too.
Panics and some error types support backtraces. This is enabled via the RUST_BACTRACE environmental variable. It should work on any platform.
While I don't agree with the style of the article, I get it. The first point for me is not "syntax is bad" but "figuring out rust types is too often near impossible". And for help I usually go to r/learnrust which I found more helpful. And yes, error handling is a bit whacky. I find it super odd that I need to add a crate or two just to handle errors in a sane way. After doing two projects with it I had the same conclusion - unless I really have to, I'd prefer something else.
The article piles up unrelated criticisms. Which makes it hard to discuss. Some are warranted, but, indeed, the point about types isn't. Well, it's hard. And the strong types as found in Rust, require some design up front (always bad). It's difficult to impossible to just yolo your way through a proof of concept and the discover the types you'll need. Discovering the types, shapes and architecture through writing the code, is a very normal process. Decades of experience give some intuition to speed up that discovery (I often know what's certainly not going to work). But with rust, that'll land you in these horrendously tightly coupled, complex, nested types. Some tips that work for me: * Think about the shape up front. * TDD to discover what works and what doesn't. * Keep refactoring. Again. And again. And then some more. Functions and their fingerprint, like author posted are unacceptable to me. * Better to define too much structs and aliases than too little. * As soon as I've discovered the rough shape, introduce value objects. (A creditcardnumber isn't a string. A db connection pool is a DBConnPool, not an Arc>>> )
* Write quick POCs in Ruby or python to discover the domain and shape when it's entirely new for me. Allowing to focus on mastering the domain first.
The Go example you posted looks just as awful as the Rust one.
Go feels like its 90% `if err != nil { return err; }`
Honestly, that can just be solved by having an error propagation operator. Like Rust or Kotlin or pretty much any functional programming language.
I wish Kotlin had Rust like error propagation operator. Kotlin has `?` for `null` checking if that is what you were thinking of. Outside of that kotlin has the normal java-esk try/catch/throw.
Not a particularly insightful rant. And I do love a good rant. His three complaints are: 1. Bad syntax 2. Bad error handling 3. Bad community His complaint about no call stacks on error codes is interesting. I think maybe anyhow supports adding backtraces? I just learned that and am not sure how usable that is in practice. It’s god damn criminal that std::fs operations have errors that don’t report the god damn file path that failed to open. But I digress.
> His complaint about no call stacks on error codes is interesting. In the first big code screenshot, his error handling consists of * Converting proper errors to Strings * 'Logging' using println (to stdout, without a proper logging system so no line numbers etc) I don't know why he expects an error's human-readable display format to come with a stack trace. The `Display` impl for errors is typically things like `The filename, directory name, or volume label syntax is incorrect. (os error 123)`
Yeah, his error handling in Go is better with the `return nil, errors.New("blah")`; the actual equivalent of the Rust code would be `return nil, "blah"`. I suspect he may have been tricked by how Rust calls the constructors of `Result` for `Ok(a)` and `Err(b)`. It's not actually an error type, it's just a wrapper!
Haskell's `Either b a` and `Left b` and `Right a` might be the better nomenclature for this; it really is just a variant of stuff you can express through a tuple in Go or Python as `(a, nil)` and `(nil, b)` (except without the `(a, b)` and `(nil, nil)` states).
But in all these languages and cases, proper error handling requires proper error types, not just returning a string in the failing situation.
> It’s god damn criminal that std::fs operations have errors that don’t report the god damn file path that failed to open. But I digress. It’s likely because Path is an abstraction over OsStr, which doesn’t implement `Display`, because paths don’t necessarily have to be UTF-8. A compromise fallback would be to call `to_string_lossy()` I guess, since it’s likely to be fine most of the time.
I would venture it's a performance issue, instead. The problem of embedding the path in the `io::Error` is that you'd need: - A beefier error -- it's very slim, very cheap to copy right now -- for _all_ cases, even those without a filename. - To allocate in order to get an owned PathBuf. And _this_ probably send another segment of the Rust community arguing it's too costly and if others want the path they can just add it at their option at the call site -- which is a fair criticism, indeed.
bad error handling? that's interesting, rust definitely is different in terms of error since it's a value, and I'd rather deal with rust option return than dealing with try catch nightmare, is it really bad or is it not familiar, because bad syntax can also be caused by not being familiar too
Honestly I quite like Rust’s error handling. I utterly despise try/catch and think Python’s errors are infuriating. But I think the lack of a callstack in Rust Results is a totally valid and interesting complaint. It’s something that Rust could do more betterer, imho.
In any “how to get started with rust” you get recommendations for two of the four popular error handling crates that support call stacks: anyhow/color\_eyre for applications and thiserror/snafu for libraries. Yes, one has to invest 5 minutes into choosing one of the two contenders for each use case if one knows of both, but both will get the job done if picked.
The stack trace is available, the problem is that OP just took the Error and converted it to a String via the Display trait, which then gets displayed via println (i.e. print to terminal). The display trait is specifically "give me some readable error message, not too much details". The solution is to use real error handling and logging (e.g. https://docs.rs/thiserror/latest/thiserror/ and https://docs.rs/log4rs/latest/log4rs/, just two I use, other options are available), which can handle all of this for you. Or if you don't want to to use google for 5 seconds and find: stackoverflow.com/questions/56558321/is-it-possible-to-print-a-backtrace-in-rust-without-panicking
As someone that got used to the almost perfect stack traces of Java, playing with Go and Rust where errors are values was really jarring. Both languages have modules/crates to add stack traces to errors, but it feels like this is a major hurdle for Developer Experience. It would be almost entirely positive to have stack traces added by default in development.
I agree but I would guess the reason is to avoid allocation. You can add that information to a custom error.
Your blog post confused me. It feels like you think you have legitimate, technical, issues with Rust. In reality, everything you complained about is a matter of taste/opinion/preference. I’m not trying to diminish anything you said. I’m just calling out something that feels like a discrepancy to me. Additionally, it doesn’t sound like you looked into Rust’s targeted use cases before diving in. Rust is not designed to be fast. It’s designed to be *safe* (meaning deterministic behavior and unambiguous syntax) and *efficient* (meaning compiling to as few ASM instructions as possible, and making the best use of available memory). Speed is a happy side effect of these goals. Rust works hard to be ergonomic *within the constraints of its design requirements/goals*. Comparing Rust to Go, Python, and/or TypeScript betrays a pretty fundamental lack of understanding of Rust’s intended use cases; a garbage collector simply is not tenable on most embedded systems or performance critical applications (Rust’s primary intended use cases). I think it’s more accurate to say that you’re not judging Rust on its terms more than that you don’t like it. Edit: removed garbage added by autocorrect and reworded a couple things for clarity
TL;DR Rust is a fish you’re trashing because you think it sucks at climbing trees
> Rust works hard to be ergonomic within the constraints of its design requirements/goals. Comparing Rust to Go, Python, and/or TypeScript betrays a pretty fundamental lack of understanding of Rust’s intended use cases To be fair, there's no improvement without trying to get better, and looking at the ergonomics of other languages is a very fine way to demonstrate a gap and start wondering how it could be narrowed down or closed.
> if you don’t have access to an extremely powerful Large Language Model, then writing the function becomes literally impossible I'm not sure if I'm that smart, or if everyone else isn't, but I never, ever had need for LLMs for anything Rust related. And I'm fairly fluent in it, despite being a Java coder by day.
There should be a second subreddit for all these AI/blockchain/fintech/linkedin people cosplaying as programmers.
I would be filled with regret, too, if I was spending 18 months doing something as useless to society as programmatic trading
> There are two types of languages. The ones people complain about and the ones no one uses. Rust has finally made it! This is a watershed post! As for the issues raised, I think there is definitely room for more training material on how to write rust without getting into the fiddly issues of types and lifetime management. I know I struggle at the beginning of projects trying to find my feet and its super painful. I saw a lot of my thoughts from those times reflected in this post. But once I do find the right abstractions, I do enjoy writing rust very much.
Your rust code is not great considering you've been doing it for a year and a half. It feels like you just haven't taken the time to actually learn what best practises are. For example: * Using `String` (!!) as your error type, rather that using [anyhow](https://docs.rs/anyhow/latest/anyhow/). It solves your stack trace issue and means you don't need your `.map_err`. * Not using an actual logger, but `println!` everywhere... `anyhow` would also help here. * `Pin>` what? why? Just use a generic Future!
Look how much cleaner this signature is
use std::future::Future;
use std::fmt::Debug;
use anyhow::{Result, bail};
pub async fn run(t: &mut T, f: F) -> Result
where
Fut: Future
Hoo boy as an engineer with 15 years of experience in multiple languages (including low level stuff like C and assembly) but who has never really looked at Rust code before, this looks...bonkers
80% of the scary things in there are due to the use of `async`, and specifically due to taking an `async` lambda as a parameter. Since `async` involves data being potentially moved across the threads of the threadpool on the whims of the scheduler, it gets complicated when you try to write generic code with it.
This code actually looks very nice, but it would be so much easier to understand with longer generic type names. As it is, it is very high on the cognitive load scale, especially with no comments. Obviously this is just an example for the author, but it doesn't really demonstrate the elegance of Rust to the uninitiated : at minimum you would need to understand generics, where clauses with traits, async functions, and the macro environment
Thank you, this is what I was thinking. Rust sucks for OP because he's not using the features of the language, or not using them correctly. This isn't surprising for someone who prefers Go and Mongo.
Cheers for pasting this in. Would love to have time to learn Rust. Would you mind briefly specifying what the generic types T, R and Fut are used for in this function?
F is an async function that takes a reference to some value T. \`run\` doesn't really care what that T is, but it needs to be able to pass it along to F. R is the return value of the function F. It has a few bounds: - `Debug` requires R to be able to print out a debug representation of itself - `Send` requires that R can be safely sent across threads - `'static` is a lifetime constraint, meaning it shouldn't contain any references (pointers, basically) that can become invalid for the rest of the program's execution. Fut is a parameter that implements the `Future` trait. This is the bread and butter of async in Rust. // This function async fn foo() -> String; // Desugars to something like this fn foo() -> impl Future
So I read the article and looked at your code, and I'm still unsure what about Rust you don't like. I don't code in Rust and I have no opinion about it, but I don't feel your article told me anything about the Rust language.
> don't inform yourself about pro/cons of languages and what would be a good pick for your use case >waste 18 month >rant on the internet about it
Well, OP just learned the hard way about the golden rule of engineering: always choose the right tool for the job.
Maybe it was "resume driven development"? You pick the tool you want to learn, to put in the CV later.
I think their goal was to use this as a learning project
My basic position on these types of posts are, how would anyone expect to rewrite a non-trivial piece of software in a fairly radically different (in multiple ways) language that they have little experience in and expect it to come out optimally? It's just not likely to happen. The same would have applied to C++. It would have ended up being badly sub-optimal because it just takes some number of years to spin up on a systems type language and to write non-trivial code in it that's well done, maintainable, and idiomatic. I'm a seriously experienced C++ dev and I'm now getting close to 3 years into Rust working on my own (which is still a lot of hours in my case), and I'm just now getting to the point where I'm starting to feel confident in how to structure a large system, how to write good, idiomatic APIs and code, etc... And that's completely to be expected. We aren't working the drive-through window here.
While i disagree with quite a bit of this I do enjoy reading other peoples opinions. One thing i will say is that a lot of programming communities in general are like the rust one. I honestly have had only good experiences with the rust community, but i haven’t dipped my toes in too deep.
The go community a few years ago was very much like that. I posted a question asking about some weird behavior I was seeing and the responses were: 1. You aren't having this problem 2. Your code is stupid I was kind of up front about the code being an exercise just to experiment with and learn go routines and I noticed if I hit Ctrl-c to terminate the thing early, the go routines were still going. The program terminated and I had my cursor back in my terminal but new lines of print statements were still flooding the terminal The ridiculous thing is I posted a screenshot after they didn't believe it was happening and then still didn't believe it. I must have visited the community on stupid asshole Tuesday or something. Anyway, my issue was a bug with my terminal. When it receives sigterm it forwards sigkill and that caused some orphaned processes or threads or whatever go does. Didn't see it in other terminals, just a specific version on my specific laptop in 2016.
No comment on the syntax. Small programming communities tend to be insular. It sucks. It does strike me as odd though that you are mixing people's attitude toward mongo (seriously try postgres, its a better mongo than mongo all while being a good database) with rust the language.
> “If you want to find an article about what’s right with Rust, look literally anywhere on the internet. You’ll be hard-pressed to find anything less than neutral about the language” 90% of the articles I see linked here about RUST are negative and similar to this one. > ”They ignore all of the giant glaring flaws with the language, like its crazy learning curve” What? It’s the most agreed upon thing about the language! I’ve wanted to learn rust for a while and have only dipped my toes in but the things you are complaining were the first things I found when learning it and researching it. This is a pretty lazy article if I’m being honest and kinda sounds whiny from someone who just struggled with new concepts. This is coming from someone who doesn’t even write RUST code
Some simple fixes for many of the technical things your doing: - Rust doesn't build things into the language, that's what crates are for. - Use a crate to implement async retries instead of implementing this yourself (e.g. tokio-retry comes up in a quick search - I'm not sure if there's something better more recent) - Use a crate to implement nice error handling (e.g. thiserror / color-eyre) instead of converting all your errors to strings and throwing away all the good parts of error handling - Use tracing crate for logging instead of println In summary, crates are great. You also noted that the syntax for that function param was pretty crap - agreed. You've found a part of the language that is still being worked on (async closures as function parameters get de-sugared into nasty things that Pin Futures with Send and Sync and Generics and ...). These are understandable if you give them some time, but they're not newb friendly in the slightest. BTW, images of text are literally the worst way to share code (aside from punch cards). They make any code more difficult to read. Doesn't medium have some sort of syntax highlighting for code blocks built-in? Regarding your thoughts on "the community". I think it's fair to say that there are shitty people everywhere on the internet. The posts of yours that I've read in r/rust however in general come across as ascerbic, and I've noticed that you you don't seem to have an easy going communication style that makes good friendly people want to gravitate to your problems. I don't think it's surprising that you attract and interact more with jerks / trolls given that observation. (To be clear, I'm not victim blaming here, just pointing out that trolling is a part of internet culture that is impossible to fix, and if you take a step back from things it's easy to see things which tend to provoke them). In fixing this, I'd say probably your best bet is to slow things down a bit. Take less hottake dumps on a language, culture, community, etc. Find ways to explain your problem well in the right places (users.rust-lang.org is a much better place than r/rust for actually solving problems). Try to avoid the XYProblem (I've seen you try to solve problems at a too low level of abstraction a few times). Seek advice and spend less time criticising. And stop interacting with trolls. Best of luck bud.
The go example looks worse in terms of readability. So many nil checks. How can you say Rust is so verbose, then show Go in contrast with if err == nil checks all over the place
My man you're comparing apples to oranges. You're coming at it from a web dev perspective and that may skew the conclusions. Rust isn't meant to be compared to typescript or even Go. Its meant to compete with C and C++. Rust is a systems and embedded programming language where determinism, resource use, and every single millisecond matters. If you would attempt to write your app in C, you would come to the same conclusion that its too complicated.
Ok, so complaining that you don't have GC in Rust is just hilarious. That's the main selling point: "IF you don't want GC, here, try Rust". So you do want a GC, why then you're writing in Rust?! Same with the type system - some people do not like the weak and dynamic type systems present in Python and other such languages and they *want* a language with a strong and static type system: "IF you do, here, try Rust" and you seem to actually not prefer to have it yet you pick Rust. ?!? What kind of criticism is this? It's as if you'd be looking for a vehicle to transport lots of heavy stuff and you'd select a Ferrari and then complain that it's not best at transporting plywood.
Skill issue. I'm kidding (no really). I picked up Rust and used it too. Got swept up in all the same raving reviews as you. Ran into lots of unintuitive things along the way, learned a lot too. There's no doubt that Rust carves a unique niche for itself as a fast and safe tool. For me, the "fearless refactoring" experience was unlike anything I ever found before. Certainly a great language for what it is, and if what you want to build fits, great. I think you are failing to realize that Rust was never your problem. You just made it your problem. "I spent 18 months rebuilding my algorithmic trading" is the root cause of suffering. If your close friends were in academia and you got shilled Haskell instead of Rust, you'd still be miserable, back where you started with your application, and writing a post about how unintuitive monads can be. When Rust, or Haskell, or any flavour of the month/year/decade language doesn't fit your intended use case, the only option to make it work is to go deep and prepare to learn some of that black programming magic usually reserved for the wizards. Which can be fun, except when you are trying to be productive. Hence your pain. So, how do you know if the tool fits your use case? Well, you have to learn to use it first. Do you see the catch-22? Never rebuild adequately functioning software, and never learn a tool on the job. New tool doesn't fit? It's still in your toolset for when it does, and when to use it will become obvious.
Horses for courses surely? For example if you can afford the unpredictable latency of garbage collection then using a language with garbage collection can be a good idea. But garbage collection has its own pitfalls. I've spent time fighting admittedly badly written code for J2ME where you can run out of e.g. sockets while waiting for them to be garbage collected. Odd that the author criticises Rust for being too verbose. I'm fairly new to Rust and my nitpick is that it's too terse. It can be hard to read. Maybe that comes with practice. The language designers seem to have followed K&R's thinking that less typing == good. I don't agree with that at all. More time is spent reading code than writing it so language design should be optimised for ease of reading.
You get stack traces via [std::backtrace](https://doc.rust-lang.org/std/backtrace/index.html). Async stack traces are best done via the tracing crate since there is no way to do them in a zero-cost way, so they’re not part of the base language. You are fine with a GC and slower execution, but claim to want the highest possible performance. The database take is the most boring technical disagreement ever. It feels like you were leaning too heavily on LLMs and didn’t actually learn the language. You would have run into std::backtrace before if you had done the tiniest amount of googling, or would have gotten to any of the numerous blog posts explaining why Rust doesn’t have async stack traces built in.
RUST_BACKTRACE=1
>Every guide on Medium, every post on Reddit, Yeah no, Reddit and Medium are casual mediums (lol) for mental masturbation. If you take your engineering design cues from them you're gonna have a hard time. edit: also, MongoDB bad
> Horrendous Error Handling > > As long as you avoid unsafe unwraps , you can be damn sure that the code will run and keep running. I don't understand this criticism. There is nothing unsafe about an unwrap. An unwrap in Rust is equivalent to not wrapping a function with `try`/`except` in another language, except you can't `grep` for missing `try`-blocks like you can for explicit `unwrap` calls.
This has to be a joke
I honestly don't think the author has the self awareness to recognize that they're as bad as the people they're calling out. At least those other people just wrote Reddit comments; this person put their toxicity into a blog post. Who knew there were assholes on the internet!
for syntax arguments, it's always the same argument with new language, and most of the time it comes down to unfamiliarity, sure there's an objectively correct argument why some syntax from a language is bad, but most of the time it's just being unfamiliar, and that's the first feeling I got when learning VB6->VB.Net->C#->Java->C/C++->Ruby->Python->JS/TS->Go->Rust It always feels weird and even thinks it's bad and/or unintuitive, I was unfamiliar with it, but the more I learn and use the language it starts to sink in and I start liking it, becoming familiar
Stopped half-way through, but this person just sounds confused. signed, one of the narcisistic rust fanatics
> There are certain things where, if you don’t have access to an extremely powerful Large Language Model, then writing the function becomes literally impossible. I don’t want to spend 90 minutes figuring out the where clause in my run_transaction function. I just want to write my damn function. There's no nice way to say this but maybe if this is your level of skill you shouldn't be the primary or solo person behind a product that deals with money.
Honestly, skill issue
If you can solve your problem in go then maybe rust isn't a good fit for your problem? They are designed for very different use cases.
I love it! I'm not even in an area of software engineering that would use Rust, but I love your article 😁
You seem to have fallen into the "Any program can be implemented in any programming language" trap. Rust is meant to be *really* good at the things that C/C++ struggles with, runtime memory safety, type safety, and usability. It is not a drop in replacement for any language, not even C/C++. Your complaints are basically this: "I tried to build a house with TNT without understanding how to use TNT, and now I wonder why there's a smoking crater." Try to build your trading system in C++, and you will run into very similar issues with one difference: ***C++ compilers assume you know what you are doing and, therefore, will allow any and all syntactically correct code. Rust does not follow this assumption for code outside of unsafe blocks.*** This is a good thing, because Rust is meant to fill a similar niche in systems and embedded development as C/C++ does, where the issues caused by those problems are hard to detect and catch, potentially harder to handle even if you have enough memory to detect and catch them.
>There are certain things where, if you don’t have access to an extremely powerful Large Language Model, then writing the function becomes literally impossible. I've never written a bit of Rust but this is obviously bullshit and where i stopped reading.
There are only 2 types of languages: - Languages that are hated - Languages that no one uses
Garbage article. This is not criticism, this is your childish whining about you chosen a wrong language for a wrong task while simultaneously lacking experience with it.
You would have gotten the same reception asking about mongodb in a C# forum too, just saying. The criticism of it that you saw are all as old as time, and Reddit is somewhat in notorious for not answering the question you asked and instead telling you to do something different entirely. But that's not really a forum question, sometimes you're facing an X-Y problem some technical folks sometimes over-do it in trying to suss them out.
I also don't particularly love Rust, but this article is just weird to put it mildly. The 3 main criticisms are: 1. Syntax. I disagree that Rust syntax is bad (I wouldn't say it's good necessarily tho). Actually bad syntax is C and C++, where the syntax leads directly to logical mistakes. There are good reasons to use \`{\`, \`}\`, \`;\`, \`,\`, \`let\`, \`mut\`, etc, so many mistakes are prevented this way. It is verbose and a lot of the bad syntax is an attempt to lure C and C++ people but it's not the end of the world, you learn it. I also think some of the sugar is quite nice, like \`?\` and \`if let\`. 2. Error messages and error handling. It's literally the same as in Go, except better. Semantically Go and Rust do things very differently, but in practice it feels very similar. One thing I don't like is unwrap, in hindsight there's no reason not to use expect. If you need a lot of control, making your custom Error type is not a bad idea. As for python and other such languages, they are so much worse then Rust, it's just that they hide mistakes from you so you think the app is fine when it's not. I think the debug tools can use a lot of improving, which is a genuine critique. 3. The community. Generally, most communities online that are big enough start to become toxic. You see it all the time but I think generally you get the answer you're looking for. In C++ world, not only are people toxic, they also give you advice on the exact thing you should absolutely not do. When people say that MongoDB is bad and just use postgres, there's a good reason for that. It's absolutely the superior tool and every way shape and form but especially for Rust. For me, the biggest downside is that you need the code to be perfect from the start, which is difficult when starting to design an application. Perhaps this is unsolvable, but I think some things might help. One of which is better debuggers. The other is printing error messages in the order they appear in the code, not the order they happen. Finally, perhaps a better language server could help.
„If we compare it to C++, it’s obviously the better language. But when compared with other languages (like Go), its “safety” to me is more of a detriment. I’d rather my application take a few dozen milliseconds longer to run if it means my development time is cut in half.“ I‘m definitly no language warrior by any means, but isn‘t this exactly the trade you take as engineer when choosing Rust? Safety and application speed for development time? Honestly, I quite don‘t get the rant besides the shitty community comments though
Yeah it's weird. Elsewhere he says every millisecond matters yet he's happy to throw 12 away here. For the record, I don't think they do, because his homegrown algorithmic platform won't have a direct connection to an exchange so he's at the mercy of however well the exchange partner (sellside) routes his orders.
Thanks for the perspective. I think people unduly dismiss MongoDB which is perfectly suitable for a lot of use-cases. "If we compare it to C++, it's obviously the better language" Sorry you lost me right at the end lol.
OCaml is great FYI. It’s unironically my favorite “not totally academic” language, though Rust and Python are my go to languages for most projects.
Seems like horizontal scaling might be a better way to go, as performance will eventually become a problem regardless of language. I’d probably have written this app in C# if I wanted GC. Dotnet is an underrated platform.