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.
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.
Supposively bad typescript
Correct. Bad Typescript. You haven’t provided any of the type information to make this a TypeScript construct (this is just JavaScript)
Similarly, Async code starts to look really ugly and overengineered in rust.
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?
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.
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 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.
Another major issue I’ve encountered is libraries in Rust, or lack thereof. Every single library in rust is half-baked.
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.
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.
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.
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?
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).
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.
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)
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)