This entire post is so ignorant it can be summed up in a one paragraph analogy:

“Why do everyone love screwdrivers so much? I drove in nails perfectly with my hammer, but the screwdrivers are so bad at it! Who even designed them? What a horrible design!”

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.

Somewhat agreed, but it’s a very difficult problem to solve. No language has yet come up with the perfect build tool. JS is on what, like the 12th build tool in as many years now? Some serious throwing stones in glass houses vibes here.

Syntax is very confusing for no reason. You can’t just look at rust code and immediately know what it does.

Strongly disagree on this point. Those extra glyphs in Rust are not just cosmetic, each one means something very specific and conveys very important information.

Having to pollute your code &, ? and .clone() everywhere to deal with ownership

You don’t “deal with” ownership, it’s an incredibly powerful tool you use. This just sounds like you haven’t really understood what the borrow checker is actually doing and the hundreds of problems it solves for you. I can not count how many times now I’ve been working in another language and had the thought “I could solve this with the borrow checker”

Js is way more readable.

JS is not more readable, JS is just far less detailed. It omits a vast swath of information such that you have almost no idea what it’s actually doing. It feels easier to you because you don’t care about any of the details, but those details become vitally important when things stop working and you’re trying to figure out why. This sounds to me like you’ve never had to write any actually complicated code. If all you’re trying to do is chain together a series of HTTP calls and maybe parse a tiny bit of JSON, yeah, Rust is like using a nuke to kill an ant.

Similarly, Async code starts to look really ugly and overengineered in rust.

A little bit, but mostly because doing async right is really complicated. Once again no language has a really great solution to this problem yet, they all involve tradeoffs.

Multiple string types like &str, String, str, instead of just one “str” function.

Once again it seems you don’t really understand the difference between owned and borrowed values or stack vs. heap allocation and why it matters. Really there’s only one type of String which is String, the others are just different ways of borrowing a String (with different tradeoffs).

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

If all you want is a “int” you can just use i64 for everything and “be done with it” as you say, you’ll just be adding a ton of wasted memory and needless overhead for no good reason. Seems like you just don’t like strong typing. I’m surprised you even bother with TypeScript instead of just using JavaScript.

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.

You absolutely can write code without using #[tokio:main], you can even use tokio without that, it just saves you having to write a bunch of boilerplate to initialize tokios executer and pass your async functions to it. You can even use async functions without tokio, you just need to provide your own executor. Async in Rust is still pretty new and some of the rough edges are still being worked out, it will get smoother, but honestly the things you’re complaining about aren’t even the annoying parts about 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.

I have no idea what you’re doing to generate code sizes like that, but I guarantee you could get a significantly smaller program in Rust that does exactly what the C code is doing. As for embedded this is patently false. I personally use Rust regularly on embedded devices that don’t even have 32mb of RAM on them.

With cargo you literally have to compile everything instead of them shipping proper binaries. Why???

This isn’t a cargo thing, this is a Rust compiler thing. The Rust ABI hasn’t been standardized which means currently there’s no guarantee that Rust code compiled by one version of the compiler can successfully link against code compiled by a different version. Until not that long ago C++ actually had the same problem. This will eventually get fixed, but the language team feels things are still moving too fast to define a concrete standard yet.

Another major issue I’ve encountered is libraries in Rust, or lack thereof. Every single library in rust is half-baked.

Rust is still pretty new, so a lot of libraries are still in active development, but there are already many excellent and very well documented libraries. Axum is literally one of the newest web frameworks in Rust and didn’t even exist that long ago. I’ve seen far worse documentation for JS libraries (and don’t even mention C, the gold standard there is practically a man page that’s just a glorified header file).

As for “memory safety”, it’s a buzzword. Just use a garbage collector.

Memory safety is not “just a buzzword”, there’s a reason all the top vulnerabilities for decades now are all memory safety issues. As for a garbage collector, good luck with that when writing embedded software or a kernel.

The rest of your rant basically boils down to “my particular simple use case doesn’t see much value from what Rust provides”, which is fine. If you don’t need the power of Rust, use something weaker, not every problem needs the nuclear option, sometimes you just need something quick and dirty that will run a few times before it falls over. Hell, sometimes a quick Perl script is the right solution. I mean, not often, but it does sometimes happen. When you do find a problem that your quick and dirty approach isn’t working on then you’ll see the value in Rust.

… the issue I have is people lying and saying Rust is a drop in replacement for js

I am genuinely curious whether you’ve actually seen this claim before, or if you badly misunderstood or are simply exaggerating a claim about Rust being a good language for web servers, or if you simply made this up as a straw-man. I can’t imagine anyone who knows what they’re talking about using those words I that order.

All your arguments can be applied when comparing ts to js. You can just use the succinct and readable js. Why waste time dealing with this type is implicitly any?

Get things done with js and chill.

Even though most of the specifics you point to are wrong, it’s a good point overall:

Rust, being #1, should be better than all other languages. The fact that it’s just decent makes it seem overhyped, and all the downvotes on haters make it look like a cult.

Back when it was small, the cult-like following was OK. But now that the language is becoming more mainstream I think the Rust evangelizers need to tone it down a bit or they risk pushing people away.

On your point, TypeScript is a decent language too. There can be two good things.

OP: “typescript is easy and rust is ugly”

Typescript :

export type PayloadActionCreator<
  P = void,
  T extends string = string,
  PA extends PrepareAction<P> | void = void
> = IfPrepareActionMethodProvided<
  PA,
  _ActionCreatorWithPreparedPayload<PA, T>,
  // else
  IsAny<
    P,
    ActionCreatorWithPayload<any, T>,
    IsUnknownOrNonInferrable<
      P,
      ActionCreatorWithNonInferrablePayload<T>,
      // else
      IfVoid<
        P,
        ActionCreatorWithoutPayload<T>,
        // else
        IfMaybeUndefined<
          P,
          ActionCreatorWithOptionalPayload<P, T>,
          // else
          ActionCreatorWithPayload<P, T>
        >
      >
    >
  >
>

Then use C or C++ if you really need performance.

And that’s where I stopped. I’m a real working programmer who’s done tons of work in C++, so I know firsthand that it absolutely sucks compared to Rust. Go back to Typescript if you hate Rust so much.

You have to keep in mind, when you write JavaScript, there’s an entire runtime written in C++ to run it under the hood, with some crazy optimizations to make it reasonably performant. What type of languages do you use to write that runtime? A systems programming language like Rust and C++.

You don’t have to use Rust if you don’t like it. Not everything must be written in Rust. The whole pick a language also involves a lot of picking your tradeoffs. Picking a interpreted/JIT language for speed of development is a perfectly valid tradeoff, but not one you can universally make. Sometimes the performance cost becomes really expensive currency-wise, where you can save thousands of dollars on server costs by simply having a more efficient application that only needs a fraction of the hardware to run it. Even in JavaScript, a fair chunk of libraries you use end up calling to C++ native code because it would be too slow in pure JavaScript. Sometimes the tradeoff is pick the popular language so it’s easier to hire for cheaper.

Even at the dawn of time, most computers shipped with a variant of BASIC so people could write simple applications easily. But if you wanted to squeeze out every bit of power in your Apple II or C64, you sure did reach for assembly. Assembly sucks so we made C, then C++. Rust is still a language that’s made to eventually compile to assembly/binary and have the same performance as if you wrote it in assembly.

And low spec hardware still exists: the regular Pis have gotten pretty fast but if you run on an RP2040 then suddenly, you’re back in like 300MHz dual core land with pitiful amounts of memory, so you do need to write optimized and fast code for those.

Rust’s type system is actually really, really good. Most of the time, if it compiles it runs. It eliminates a ton of errors other than memory safety: the system is so powerful you can straight up make invalid state unrepresentable. You can’t forget to close a connection, you can’t pass the wrong data, you can’t forget to unlock a lock. It does a lot more to enforce correctness of a program well beyond memory safety.

I think one thing to mention is that Rust is highly specific in what it does. In most of the examples you mentioned, string types, tokio::main, you can essentially just say that rust is more explicit. When initializing an integer variable in C using int, it’s not specified what use the integer is or whether it’s signed or not. i32, uint16_t you can see how it’s specified. Using tokio::main before your main function just specifies that you’re using the tokio asynchronous executor for your async code. In the case of string types, they all have different implementations which just help with being specific.

The reason I like Rust is because I know what’s happening when I read it. Did I have to read the whole async book to understand how the tokio::main stuff works? Yes. But now I understand exactly how it works. The problem I have with using Javascript is that it doesn’t have that high amount of explicitness(is that a word?). At the end of the day, if you’re using it for a personal project or you’re arguing for language supremacy, it really just comes down to personal preference.

That example is so insanely readable lol

Absolutely standard looking code for many languages.

Frankly, all of your points sound quite ignorant. Syntax is literally just a matter of getting used to it. Comparing HashMap ergonomics doesn’t make sense, you should rather compare to struct construction. There are many good reasons for different string types and number types. There are good reasons not to bake in async. Rust documentation is in the code for a very good reason and it’s actually really nice to read docs like that (obviously read it on docs.rs, not in the code itself).

I could go on but there are answers to all of your specific qualms if you just bothered to look for yourself.

Rust syntax is badly designed compared to most other languages I used

It really isn’t badly designed. Yeah there are more symbols than you are used to from JS/Typescript world. But more symbols does not mean bad syntax. It makes things more explicit which IMO makes things easier to read and understand what is going on. Rather than all the implicit behavior in JS/TS.

Let’s take a look at hashmaps vs json

What is the point of this? Lets compare two different things to prove no point! Look I can do it to:

let person = Person {
  name: "joe".to_string(),
  age: 23
}

const scores = new Map();

scores.set('Name', Joe);
scores.set('Age', 23);

Why would you construct a map like this? That is not what maps are for in either JS or rust. But either way all these examples are easy to read and can tell what they are doing even if you have not coded the language before. Now you do need more of an understanding of rust code to read some rust code but not these examples given.

Every single library in rust is half-baked.

That is just hyperbole. Many rust libraries are very mature now. Not having a website is not a sign of maturity and the docs for axum are very good in rust docs site. If you really want a webserver with a website then you have actix-web. Many rust projects do have sites like this or even books on how to use them. And if you look at the JS ecosystem, how many libraries do you use there that have nothing more then a readme on their github page? IMO I tend to find far worst documentation for JS libraries then I do for rust ones - if you look beyond the big things like react.

No GUI framework is as stable as something like Qt or GTK

This is true of basically all languages but C/C++ and maybe JS. Most languages just lean on these for good UIs, but there is a lot of effort ATM in getting nicer GUI support in native rust. It will come with time but a GUI library is a complex thing to make.

literally every rust project has like 1 dev maintaining it in his free time and has “expect breaking changes” in the readme

This is just more untrue hyperbole.

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.

One of the things I love about rust is I don’t need to spend hours and hours debugging basic problems because the language is explicit and makes me think better about things upfront. Rather then spending hours wondering why something is producing weird output at runtime because something somewhere else got a "1" instead of a 1. It takes a bit more effort to get something to compile, but I find vastly fewer surprises at runtime then I do in other languages. And it is those runtime bugs that take the most amount of time to solve.

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

You also don’t want things to break in production and have to spend hours and hours debugging some weird edge case.

@cybergazer
> Syntax is very confusing for no reason.

This comment alone (followed by your examples) tells me you don’t understand what problems Rust is trying to solve.

Welcome to compiled systems programming languages? What’d you expect?

I would very much like to address some of these points, since I don’t think you are making a good argument here.

I shall preface this by saying that comparing Rust to TypeScript is a bad idea. They are meant for fundamentally different things and you should not regard Rust as a TypeScript replacement. I will do my best to show why Rust took the paths it did whilst being as brief as possible, but if TypeScript is your measuring stick, you should stick to it.

First of all, cargo does a lot of stuff. This is true, but you are comparing Rust to TypeScript here, and therefore you should compare cargo to npm, npm is the same thing. It does everything all at once, and everyone loves it. Cargo doing everything it does is meant to be a convenient way to interact with Rust projects. That being said, if you don’t like Cargo, you can use rustc directly. You can compile Rust code much the same way you would C/C++, with a Makefile.

Multiple string types: As compared to TypeScript, this would seem like an unnecessary complication, but let’s compare it to C++ for a second. In C++ you have two string types as well, namely const char * and std::string. These are ‘basically’ the same as &str and String respectively. It comes down to whether or not you want your string to be heap allocated or not. Allocation is not something you get any control over in TypeScript and for that reason it is possible to have a single unified string type. Also, TypeScript hides the internal representation of strings from you, which is convenient, but can be a real pain in the butt if you’re trying to do low-level manipulations.

I would agree that Rust’s syntax can be quite terse, but this is due in part to it being a strongly typed language, unlike TypeScript, which is very weakly typed and can therefore simplify a lot of things.

Async code looks ugly in rust. Yeah, it does. Mostly because it’s not doing the same thing that it would be in TypeScript. TypeScript async code and Rust async code are fundamentally different. If you have a look at async code in modern C++ you will see a lot of the same complexity as you do in Rust, since it’s more closely related to what Rust does.

You say that rust has many different integer types, yet in C you can ‘just write int and be done with it’. This is patently false. Here is a catalog of Rust integer types and their C/C++ equivalents:

• i8 -> char
• u8 -> unsigned char
• i16 -> short
• u16 -> unsigned short
• i32 -> int (This is the only one you would get if you just write int.)
• u32 -> unsigned int
• i64 -> long long
• u64 -> unsigned long long

In TypeScript you have just number, that’s true, but it’s a managed language. Again, this hides the complexity from you, but it comes at a steep cost. If you actually want to do low-level manipulations, you have to drop down to something like a Uint32Array type, which is exactly equivalent to [u32] in Rust.

Having to use #[tokio::main] to make an async main. This makes me think you don’t understand how async code works. The reason you can just write async code in TypeScript is because there is a runtime. Your code doesn’t just run. You need a browser or a Node.JS server or something similar. That is what tokio is (kind of). This also addresses the bloat argument for tokio. Rust does not have a runtime, and therefore when you want to write async code, you need to add one. In TypeScript land, you just get the runtime whether you want it or not.

As for GET requests being 32MB, I don’t understand what you mean here. The request itself will never be that large. If you are complaining about the binary size, though, you are likely compiling in debug mode. Switch to release mode and add -C opt-level=3 to the compiler flags and you’ll get a binary that’s way smaller.

About the libraries, Rust is a young language. Libraries can be hard to find for specific purposes, but that will change over time. Axum doesn’t have a home page, btw, because the docs.rs page is more than good enough.

Memory safety is not a buzzword. In mission-critical software (which you would never write in TypeScript, because it’s buggy as all hell), memory safety is something you have to have. If you are using C/C++, your memory safety is ‘trust me bro’. ‘Just use a garbage collector’ is not an argument. When people want memory safety, it’s exactly because they don’t want a garbage collector. I won’t go into the specific details, but you are pigeon-holing Rust in with languages like TypeScript and Java, which are designed for different use-cases. Again, Rust is not a ‘better TypeScript’ and you should not use it if TypeScript is what you need.

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.

Not true. Most memory errors that end up being exploited don’t cause any bugs and are extremely hard to predict and test for. Rust provides a way for you to write robust software that has some strong guarantees about what the memory of your program looks like. If done correctly, it eliminates the risk that you may have forgotten a scenario in which your program would not be memory safe.

‘Just use C/C++’: No. C++, for starters, tends to be much slower than Rust and C is way too low-level to get anything useful done without first having to re-invent the wheel. Rust is a modern language, C and C++ are relics of the past. They are rife with problems and technical debt and the fact that they are designed by committee is the reason for that.

If you don’t see any reason to continue with Rust, then don’t. People like Rust for reasons that would not make any sense to you as a TypeScript programmer. Rust is a good programming language, TypeScript is a patch on top of a broken language. TypeScript is meant to be easy to use and is therefore hard to use for anything other than what it was designed to do.