https://en.wikipedia.org/wiki/Poe’s_law

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?

This is pure junior energy. Or trolling, I honestly can’t tell.

Anti Commercial-AI license

That example is so insanely readable lol

Absolutely standard looking code for many languages.

If your primary exposure to programming is only typescript or JavaScript maybe you shouldn’t be jumping straight into something like rust. JS is a high level language and rust is aimed at the lower levels where things can’t be as automatic. There are many languages out there like C#, Kotlin and Swift that will help you get used to the idea of strong types and immutability.

Ok, I’m going to just assume this isn’t a troll.

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.

I dont even understand your issue? It’s like npm or deno which can run your code, manage your dependencies, etc. How can a JS/TS dev possibly not understand this?

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.

I dislike ? because I think you should be handling errors as they come instead of sending them up the stack. I also like the explicit .clone() but if you dont want to use it, you can also add Copy to your derive’s and this will make it happen automatically. module::function() generally pollutes code much less then static module.function() or static function() doesn’t it?

Let’s take a look at hashmaps vs json

I hate all of this code, why arent you using struct’s here? In rust its: struct Person {name String, age i32} and in typescript its type Person = {name: string age: number}

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

Sure

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

I know of &str and String, i’ve never heard of str though so you probably dont need it. &str is a string slice, aka a borrowed String. I generally say you shouldnt be using &str because generally if you get a lifetime error from using it, its because you’re doing it wrong, just use String while you’re learning the only real difference is that String is more verbose then ""

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.

“int” from C is i32, these are int’s and float’s of various bit sizes. i32 = int 32bit, i62 = int 64 bit, f32 = float 32, u32 = unsigned (only positive) int32. but you dont usually need to specify this, rust has type inference. Also speaking of C, what about double, long, short, long long, unsigned long long, unsigned short…

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 kind of agree? When async was initially designed it was done as a stackless minimal thing where we could build our own runners (like tokio) but no one really builds their own runners, they just use tokio.

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 believe you, show me this project. As a personal project I have made a monolithic web server, that handles api calls, webpage calls etc, it uses axum, tokio and serde and when I run cargo build --release it compiles down to a 1.9mb binary. The only way I can see this happening is if you’re not using a release build, which is a concept you should understand as a JS dev.

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.

This argument has happened a few times that I know of. This is done for security purposes. If someone ships a binary blob you have to trust it to run, as a community, it was decided that we shouldnt do this.

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

I kinda also agree with this one, a lot of rust libraries are still in 0.x, I wouldnt call them all “half baked” though. If you search youtube you can find plenty of people using these libraries in prod.

“expect breaking changes” in the readme.

This is not specifically a rust problem this happens with every popular language & framework.

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.

A garbage collector “freezes” you’re program when it runs usually. There are plenty of cases of people benchmarking rust against go, js, c#, java, etc rust performs vastly better.

Then use C or C++ if you really need performance. Both of them are way better designed than Rust.

Microsoft and Google came out and said that “~70% of their security flaws are a result of memory issues” or something like that. C and C++ are fundamentally flawed, which is why both of those companies have adopted rust.

There are apps with billions of users that run fine on php

True, but the number is going down, which implies a growing number of people choose to stop using PHP, we’re even doing it at work.

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

These are fighting words lol. I already mentioned Google and Microsoft have adopted rust for Windows, Chrome and Android. Other companies solving real world problems with rust include, Cloudflare, Dropbox, NPM, Yelp, Discord, Mozilla, Coursera, Figma, Facebook/Meta and Amazon.

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.

What are you building where the end user doesn’t care if the app performs well? Not caring about resource usage results in poor performance which results in dissatisfied users/customers which stop doing business with you. Have you heard about the unending war in JS land against bundle size?

So at this point I’m seeing very little reason to continue. I shouldn’t have to fight a programming language

No one is required to like every programming language, If you don’t like rust, stop using it.

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.

… 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.

(Wow, 14 posts in 2 hours on Lemmy… The old wisdom that the best way to start a discussion is to loudly complain about something rings true :P)

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.

It’s still a build system; most (good) build systems also manage downloading and resolving dependencies. Having them all as part of the same tool makes everything slot together nicely.

Syntax is very confusing for no reason.

It’s not no reason; dealing with ownership is a complicated problem. It’s just that most languages tend to hide it and let the programmer tangle themselves in knots.

You keep talking about it being obvious what the code does but… Using :: over . helps clarify, at the call site, that you are using a “static” function rather than having to make the programmer look up the definition of the lhs.

Js is way more readable.

Pop quiz: Is this a copy or a reference?

let a = b;

You can just look at it and immediately know what the code is doing even if you’ve never coded before.

You can’t really… The JSON map object syntax isn’t actually intuitive to non-programmers. I’d argue that the rust version is more intuitive, since they can probably make a good guess based on the word “insert”.

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

These are distinct types with distinct meanings. JS and TS sacrifice some performance to make them seem like the same type, which may or may not be justified in your project.

i32 i64 i8 f8 f16 f32 instead of a single unified “number” type like in typescript.

JavaScript has three number types, ints, floats and BigInts. The former two are both called “number”.

Even in C you can just write “int” and be done with it so it’s not really a “low level” issue.

No you can’t. int is different sizes on different platforms. (EDIT: I was thinking about long. If you need more than 32 bits (which you do to store a pointer), that’s where the problem lies)

yet you literally can’t write code without [tokio].

I’ve never actually used Tokio. :D

Why is it so bloated?

Are you compiling at the same optimisation level, stripping debug info and statically linking libcurl in both cases?

Another major issue I’ve encountered is libraries in Rust, or lack thereof.

This is a big problem, I agree. Though to be fair, I’ve also encountered it with both NPM and PIP. Perhaps worse so there, because the compiler isn’t backwards compatible.

They’re invulnerable to memory issues unless you write infinite while loop and suitable for 99% of applications.

No they aren’t~ It’s easy to write code that hitches every few seconds (which kills games). And you also overlook the fact that a garbage collector is, quite frankly, a miracle of optimising compilers. I remember back in university being warned to remove the “next” pointer of graph nodes because otherwise memory would leak.

Then use C or C++ if you really need performance. Both of them are way better designed than Rust.

I develop professionally in C and C++. No they aren’t. At all. C and C++ are so loaded with footguns it’s a surprise people can get anything done in them without triggering UB.

Also, any program you write should be extensively tested before release

True. But nobody does that. And even if they did… Why not use a language that makes testing easier and faster?

you’d catch those memory errors if you aren’t being lazy

Not in any sufficiently large codebase.

that’s enough for the entire programming space to rank it year after year the greatest language

If you find that everyone in the world except you seems to be involved in some elaborate conspiracy, please check your reasoning.

And the thing is, that’s fine, the issue I have is people lying and saying Rust is a drop in replacement for js

Ehh… I don’t think it is. I think people interested in stepping up their programming game should give it a go, but branding it as a “noob friendly” programming language is going to put people off programming.

Typescript is therefore better at making things quick

Thing is, these “quick” programs tend to spiral out into huge megaliths of software that span several servers and support millions of users. And then the only person who knows what everything does gets hit by a bus, and so you have to figure out what thousands of lines of Typescript, PHP and Python code does.

Python, JS and php are good for firing out quick solutions, but once you get to the point where maintenance starts becoming more important than new features, it falls off hard. There just isn’t enough structure in the language to make it easy to figure out what code is doing.

I’m about to just give up and move on

Honestly, I bounced off of Rust the first time I tried it as well. I got frustrated about code not working, and just… Stopped using it. I then tried it again a few years later and everything finally “clicked”. Perhaps it’s the same with you? Give it a break for a bit, but don’t write it off yet. Come back to it later to give it another go.

Rust isn’t an easy language to wrap your head around if you aren’t familiar with the problems it’s trying to solve, but it’s not trying to be. Think of it as the drill sergeant that makes you stand up straight and become a better programmer.

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.

Your LLM of choice needs better training.

I get the sense that you might appreciate golang.

rust is a systems/low overhead programming language. really not much of a point comparing js/ts and rust, since js is much higher level. you should be comparing it with c, c++, zig, maybe nim, etc

you also imply it’s pointless to have a language geared towards performance because computers are better now, but 1) programs run on more than just personal computers and you wouldn’t run js in an embedded system and 2) just because your computer can put up with poor performance and resource waste doesn’t mean that it’s sensible to do so (hello electron)

also, rust does more than just cosmetic improvements. it adds a layer of statically guaranteed memory safety that no other commercially viable programming language that i know of has. even if its syntax looked like ancient eldritch runes, it would still be an attractive language. the fact that it manages to do more than other languages while still having a decent syntax is amazing

you can dislike rust if you want that’s fine but you don’t need to try to shit on it just bc it’s not your cup of tea

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.

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)

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,
};

i32 i64 i8 f8 f16 f32 instead of a single unified “number” type like in typescript.

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).

Even in C you can just write “int” and be done with it so it’s not really a “low level” issue.

No, you can’t - https://en.wikipedia.org/wiki/C_data_types

• 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)

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.