Force her to read this. https://discord.com/blog/why-discord-is-switching-from-go-to-rust
I kid of course. If you don't need the raw performance rust development absolutely will slow you down. It is hard.
But I don't actually understand your vitriol. I would understand if we were back in the days when Ruby was all the rage among people who couldn't program. Near as I can tell it had no redeeming qualities. I hated it with a fiery passion. But now all the rubyists had gone to either python or... Rust. While the people who think this or that one language is the be and end of all are still annoying, rust at least does have a use case. Secure, performant, and predictable. But if you don't need edge case performance then prioritizing coding speed and readability might favor something else.
I also find go a funny hill to die on. I am sure it is great and I should probably have given it a try for prototyping my project. Maybe if you preferred c or zig or something.
see, you are confused because you have never used it
you just don't stop liking things like the handy build system, the simple, clear syntax, the simple rules for everything that you can master quite quickly, or, like i did, slowly by fiddling with things and seeing what happened
that extra 5% performance you get from rust isn't worth the doubling of complexity, the 100x of compile time, and the 1000x less readable syntax
just scanning through that article as well... i was already aware of this issue with Go's GC and it isn't fair to say it's a forever problem either, the smarts of the GC get better and better over time, and there is ways to bypass it, this is the thing, if you write code as though you are going to 100% entrust the reuse of memory in this way to the GC, you will have trouble at scale, the simple fact is that this degree of control requires you to bypass the GC and use free lists and write your code with the thought in mind that later you may need to take the memory reuse out of the hands of the GC, and the scheduling too, this can also be a problem
it's actually not hard to solve these problems if you don't build out a whole system like this isn't going to be an issue ever as you squeeze to the edge of capabilities
doing the same level of scale in C++ and C are also both extremely challenging to achieve, but it's just not true you can't do it with Go
it just requires ... you know... fully writing your own memory management and scheduling code, you know, like the old days, like exactly the same how it has to be done from the start with Rust, C++, or java
making a decision to not use a language that gets you to MVP and doesn't take forever to retrain your programmers, and for which this kind of edge case of the last 10% of juice you are trying to squeeze out of your hardware, when for still less cost and time, you can get advanced systems programmers like me to ... you know... write algorithms... that fix the scheduling and memory management problem
but no, instead swallow the kool-aid from nutscrape incorporated and use their absurdly complex language with its ridiculous objects and traits and lifecycles and shit so you can look cool to your hipster friends
no, fuck you
i got better things to do than wait 5 minutes to compile a simple server on a 100x a day basis, thanks
also, it's just plain wrong that rust doesn't have a garbage collector
it does, but it requires you to hold its hand all the way through
also their solutions for fixing their LRU cache problem are just bullshit, their code was generating too much garbage, but whatever they say it's gotta be facts right? just because their engineers are not fucking competent to actually understand how this shit works
