My favourite is always;

Lemme quickly write this test, it passes great, if I make this little change it’ll fail. It’s still passing, damn.

You’re not wrong but I think when you’re teaching someone just having 1 parent and 1 child class makes for a bad example I generally prefer to use something with a lot of different children.

My go-to is exporters. We have the exporter interface, the generic exporter, the accounting exporter and the payroll exporter, to explain it.

At school, the only time I used inheritance was 1 parent (booking) and 1 child (luxury) this is a terrible example imo.

Same, I always remember this with interfaces and inheritance, shoehorned in BS where I’m only using 1 class anyway and talking to 1 other class what’s the point of this?

After I graduated as a personal project i made a wiki for a game and I was reusing a lot of code, “huh a parent class would be nice here”.

In my first Job, I don’t know who’s going to use this thing I’m building but these are the rules: proceeds to implement an interface.

When I have to teach these concepts to juniors now, this is how I teach them: inheritance to avoid code duplication, interfaces to tell other people what they need to implement in order to use your stuff.

I wonder why I wasn’t taught it that way. I remember looking at my projects that used this stuff thinking it was just messy rubbish. More importantly, I graduated not understanding this stuff…

It’s not as if nothing is being done on GitHub we have both: rust-lang/spec which is being folded into rust-lang/reference.

I’m not sure why we don’t have an official spec, I assume that reference was originally for rustc in particular and might include some internal weirdness instead of being a proper spec. Kinda like how gcc has some internal magic that isn’t strictly to C spec.

I guess what happened was: spec for rustc -> developed rustc -> ferrocene developed from rustc spec -> “we don’t have a generic rust language spec”

I don’t get why we’re taking a swing at Linus here. The article only mentions him in relation to the rust for Linux project being slow going. But, it IS going and the US government has only stated that “you need a plan to move to a memory safe language by 2025 or you might be liable if something bad happens as a result of the classics (use after free/double free/buffer overflow/etc.)” but I don’t think Linux would count it’s free software and it does have a plan.

Well, I’m not American.

In Australia you either bring your own lunch or you bring cash for the school shop. If you have no lunch then the school feeds you from the shop and charges the parents later.

Hang on, does this say “schools charge transaction fees when you pay for lunch online”??? As in, a parent puts $20 on their child’s tab for lunch and the school taxes it so the kid only gets $18? That’s wild.

I could swear it was higher earlier this year/last year but looking at the survey results, Linux climbed to 2% this survey. I think maybe that half remembered headline was something like “Linux is higher than MacOS at 1.5% market share” or something like that instead?

“You can turn it off”, “it’s an optional feature”, they didn’t even last a year! What ever happened to slowly boiling the frog?

I can’t be bothered to build them but looking at the releases on GitHub openssl 3.4.0 is 17.5mb and rustls is 2.6mb. both of these releases are source files not binaries but I don’t see how rustls could possibly be larger than openssl.

Just looked it up, looks like you’re right. The Go GC has to pause when it sweeps and it looks like the JVM has multiple GC implementations but all of them have to pause for sweeps. I don’t really use either language so I didn’t know how the magic worked.

Ahh! Of course! The problem with Concord was the price! That’s why no one cared during its free beta weekend!

Huh, I knew Go’s GC ran on another thread but not the JVM, cool.

This is because rust doesn’t do proper tree shaking of code and bundles everything into it even if it’s not necessary.

This isn’t true. a simple:fn main() { println!("Hello World!); } compiles into the same size binary as:

fn main() { println!(hello_world()); }

fn hello_world() -> String { String::from("Hello World!") }

fn another_function() -> String { String::from("Completely unused function") }

So why are the complexities of Rust worth it to save like 10ms loading a website? Not that as a language I like php that much due to no typing, but performance for a web app really isn’t that important.

if the amount of rust, c and c++ in web infrastructure doesnt convince you that performance is important then I guess we’ll have to agree to disagree here.

Rust again isn’t that good for embedded either due to the large binary size

I’m not sure about this one, I’ve never worked on embedded but I’m not convinced. There’s an embedded rust book and their target hardware is a device with 256kb of flash memory, and 48kb of RAM.

This can also be solved with a file hash. When you compile the app, ensure the compiled file hash matches the hash of the binary in cargo. So you can get the best of both worlds

This doesn’t address security at all, the only thing a hash does is tell you that the file you download was the file that was uploaded. If I upload malware in my library to cargo, cargo generates a hash for my library, then you download my library. The only thing the hash tells you is that you did indeed download my malware. It’s also harder to audit my library because cargo has a binary blob instead of my code, you have to go to my repo in order to find the malware, and you better hope I haven’t done something clever like add the malware in locally instead of in the repo, so it’s only there when I build to upload to cargo.

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.

My phone app(also google phone app) is only 91mb’s, Google Pixel 6, everything up to date.

IMO the best way to start in a new language is to rewrite some of your previous projects in that language.

I generally start out by rewriting a couple simple 1-3 function console apps, basic leet code stuff like; palindrome, fizzbuzz, reverse an array in place, etc, and some simple unit tests for them. Then I go ahead and rewrite some of my previous projects or uni assignments in that language.

At that point I generally have a good understanding of basics and have an idea of how to approach a new project. When I got to this point in rust I then started on threading, async, why it’s easy to return a String and an ordeal to return &str, etc.

Something I’ve always found funny about the “AI will replace programmers soon” is that this means AI’s can create AI’s and isn’t this basically the end of the economy?

Every office worker is out of a job just like that and labourers only have as long as it takes to sort out the robot bodies then everyone is out of a job.

You thought the great recession was bad? You ain’t seen nothing!

The performance is just a “nice to have”.

Python package management, especially at scale is infuriating. At work we use python microservices in docker containers and it infuriates me trying to update the one our team is responsible for.

I always like to rant that python 3rd party package management tools are a mistake. We should’ve gone for an “as simple as possible” setup instead of all this.

So I’m sceptical of UV on principle since it’s yet another 3rd party package manager but if it can do all of this and not be a nightmare I’ll be ok with it.

Imagine voting for Voldemort