UnCube: A speedcubing timer for the 21st century.

QaspR@lemmy.world · 25 days ago

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.