Iâm making this post after endless frustrations with learning Rust and am about to just go back to TypeScript. Looking at Rust from the outside, youâd think it was the greatest thing ever created. Everyone loves this language to a point of being a literal cult and its popularity is skyrocketing. Itâs the most loved language on Stackoverflow for years on end. Yet I canât stand working in it, it gets in my way all the time for pointless reasons mostly due to bad ergonomics of the language. Below are most of the issues Iâve encountered:
-
Cargo is doing too many things at once. Itâs a build system but also a package manager but also manages dependencies? Idk what to even call it.
-
Syntax is very confusing for no reason. You canât just look at rust code and immediately know what it does. Having to pollute your code &, ? and .clone() everywhere to deal with ownership, using :: to refer to static methods instead of a âstaticâ keyword. Rust syntax is badly designed compared to most other languages I used. In a massive codebase with tons of functions and moving parts this is unreadable. Letâs take a look at hashmaps vs json
let mut scores = HashMap::new();
scores.insert(String::from("Name"), Joe);
scores.insert(String::from("Age"), 23);
Supposively bad typescript
const person = {
name: "joe",
age: 23
}
Js is way more readable. You can just look at it and immediately know what the code is doing even if youâve never coded before. Thatâs good design, so why do people love rust and dislike typescript then?
-
Similarly, Async code starts to look really ugly and overengineered in rust.
-
Multiple string types like &str, String, str, instead of just one âstrâ function
-
i32 i64 i8 f8 f16 f32 instead of a single unified ânumberâ type like in typescript. Even in C you can just write âintâ and be done with it so itâs not really a âlow levelâ issue.
-
Having to use #[tokio:main] to make the main function async (which should just be inbuilt functionality, btw tokio adds insane bloat to your program) yet you literally canât write code without it. Also whatâs the point of making the main function async other than 3rd party libraries requiring it?
-
Speaking of bloat, a basic get request in a low level language shouldnât be 32mb, itâs around 16kb with C and libcurl, despite the C program being more lines of code. Why is it so bloated? This makes using rust for serious embedded systems unfeasible and C a much better option.
-
With cargo you literally have to compile everything instead of them shipping proper binaries. Why??? This is just a way to fry your cpu and makes larger libraries impossible to write. It should be on the part of the maintainer to build the package beforehand and add the binary. Note that i donât mean dependencies, I mean scripts with cargo install. There is no reason a script shouldnât be compiled beforehand.
Another major issue Iâve encountered is libraries in Rust, or lack thereof. Every single library in rust is half-baked. Axum doesnât even have a home page and its docs are literally a readme file in cargo, howâs that gonna compare to express or dotnet with serious industry backing? If you write an entire codebase in Axum and then the 1 dev maintaining it decides to quit due to no funding then what do you do? No GUI framework is as stable as something like Qt or GTK, literally every rust project has like 1 dev maintaining it in his free time and has âexpect breaking changesâ in the readme. Nothing is stable or enterprise ready with a serious team with money backing it.
As for âmemory safetyâ, itâs a buzzword. Just use a garbage collector. Theyâre invulnerable to memory issues unless you write infinite while loop and suitable for 99% of applications.
âBut muh performance, garbage collectors are slow!â
Then use C or C++ if you really need performance. Both of them are way better designed than Rust. In most cases though itâs just bikeshedding. Weâre not in 1997 where we have 10mb of ram to work with, 9/10 times you donât need to put yourself through hell to save a few megabyes of a bundle size of a web app. There are apps with billions of users that run fine on php. Also, any program you write should be extensively tested before release, so youâd catch those memory errors if you arenât being lazy and shipping broken software to the public. So literally, what is the point of Rust?
From the outside looking in, Rust is the most overwhelming proof possible to me that programmers are inheritly hobbists who like tinkering rather than actually making real world apps that solve problems. Because itâs a hard language, itâs complicated and itâs got one frivelous thing it can market âmemory safety!â, and if you master it youâre better than everyone else because you learned something hard, and thatâs enough for the entire programming space to rank it year after year the greatest language while rewriting minimal c programs in rust quadrupling the memory usage of them. And the thing is, thatâs fine, the issue I have is people lying and saying Rust is a drop in replacement for js and is the single greatest language ever created, like come on itâs not. Its syntax and poor 3rd party library support prove that better than I ever can
âOh but in rust you learn more about computers/low level concepts, youâre just not good at codingâ
Who cares? Coding is a tool to get shit done and I think devs forget this way too often, like if one works easier than the other why does learning lower level stuff matter? Itâs useless knowledge unless you specifically go into a field where you need lower level coding. Typescript is easy, rust is not. Typescript is therefore better at making things quick, the resourse usage doesnât matter to 99% of people and the apps look good and function good.
So at this point Iâm seeing very little reason to continue. I shouldnât have to fight a programming language, mostly for issues that are caused by lack of financial backing in 3rd party libraries or badly designed syntax and Iâm about to just give up and move on, but Iâm in the minority here. Apparently everyone loves dealing with hours and hours of debugging basic problems because it makes you a better programmer, or thereâs some information Iâm just missing. Imo tho think rust devs need to understand thereâs serious value in actually making things with code, the ergonomics/good clean design of the language, and having serious 3rd party support/widespread usage of libraries. When youâre running a company you donât have time to mess around with syntax quirks, you need thinks done, stable and out the door and I just donât see that happening with Rust.
If anyone makes a serious comment/counterargument to any of my claims here I will respond to it.
Coming from Java where you have no standard tool and two current defacto standards (Maven and Gradle) which do similar things in a less clean or standardised way, I think Cargo is one of the least contentious parts of the Rust experience.
Correct. Bad Typescript. You havenât provided any of the type information to make this a TypeScript construct (this is just JavaScript)
It should be something likeâŠ
interface Person { name: string, age: number, } const person: Person = { name: "joe", age: 23, }
And the Rust equivalent being something like
struct Person { name: String, age: u8, } let person = Person { name: "joe".to_string(), age: 23, };
Those all have different sizes and capabilities. The lack of these requires the JS JIT compiler to try and guess (and deoptimise when itâs wrong).
No, you canât - https://en.wikipedia.org/wiki/C_data_types
I agree the Rust Async experience feels a little messy, and the lack of an opinionated default makes even the foothills a steeper climb than we might hope. However given all that itâs trying to achieve (in terms of Rust drives for efficiency and safety) I donât have any better ideas right now.
I donât know how youâre getting to 32MB. A release build of the most basic form of a get request is not that bad.
A simple chatgpt generated one app to get the content of an HTTPS URL, using reqwest and tokio is 4MB. I expect this can be reduced with options.
However yes, the default Rust build (with all of the panic machinery and more) is bigger than C. But Rust doesnât have to be the best choice for every niche, to be an excellent choice for several. With that reasoning your return to TypeScript is equally flawed.
Coming from Java, Rustâs young ecosystem is definitely noticeable. Itâs taking a while for it to grow, to mature, and for clearly dominant frameworks to emerge for various problem-spaces.
Java, like Rust, is not opinionated about the frameworks, but the size and age of the community means that clearly dominating frameworks emerge with huge contributor bases - Rust just isnât quite there yet.
Again, coming from Java (which has a number of excellent GC implementations), Rust takes this a lot further (an alternative to null, protection against aliasing bugs). While Iâm still fundamentally a Java developer, what Rust achieves here is significant.
Tell me you donât pay to run anything large on cloud infrastructure without telling you donât pay to run anything large on cloud infrastructure. Thereâs a cost to CPU and RAM. Java does okay on the first, but has a long history of doing poorly on the second (câmon Valhalla - a Java enhancement project that will help here).
Of your post, this is very nearly the only part I can somewhat agree with. Our industry primarily has more of a need for âsolution now pleaseâ than âoptimal solution laterâ. Engineering time matters. The learning curve and cycle time of Rust are barriers.
Also, while Rust is a very safe language to refactor in, itâs not quick to refactor in. The less ceremony and strictness there is, the easier it is to experiment and then refactor. This is, in part, why I think Python does so well in the ML/Data-science space - that niche is more R than D in the R&D balance of software development.
So again, Rust suits some development needs better than others, now. However as it matures I think we will see it grab little pieces of the niches previously occupied by other languages. As itâs tools and libraries get better, and as the pool of familiar developers increases, Rustâs strength are going to translate more easily into dollars without costing time.
Â
Iâm not ready to switch to Rust fully. But neither am I putting it aside - and I look forward to its continued improvements in libraries, language, tooling and adoption in more and more places.
(I can say that Iâm not planning on using TypeScript for any more than our front-end development though)