I'll take salty C++ masochist for 5
If moving to another language erases 15 years of experience, you probably don't have a good grasp on the fundamentals...
15 years is just about enough to understand how initializing a variable works in C++: https://randomcat.org/cpp-initialization/initialization.png
ey yo, wtf? is that a meme image?
Perhaps the LinkedIn user should have considered learning "programming" instead of just C++
shh, Rust Is the New World Order
What the hell is going on with the kerning in that screenshot? My eyes, they bleed.
Wh atd oyou mean?
Do we have a c/keming?
If not, please make one, I wanna subscribe
Yeah, wth is this? It's so bad at points that it sometimes looks like two words.
Linux is going on.
This really implies a level of competence and understanding among the highest levels of management that I think we all know just isn't there.
Anti-Rust crusaders: "C is easy actually and Rust is pointlessly annoying and hard to learn"
Also anti-Rust crusaders:
ancient amateur C coder here (not even c++). picked up python about 5 years ago (cuz why not?). been playing around with rust for a bit (like it so far). only issue is recoded tools getting released under mit license instead of gpl (cuz, get off my lawn!).
Yep, agreed that the license change is an actual issue
nah, keep on, gpl is superior.
Disclaimer: the damn screenshot just won't load for me, so this is just a personal rant
Rust crusaders: it forces you to write good and safe code! This is superior to other languages!
Me: fucking fuck off, will ya. I need to become competent enough to write good and safe code (meaning think about problems before they happen), not some fucking kindergarten. Rust may be a good language, but the above argument sucks so very much
@onlinepersona the master plan to remove old senior devs is ... to train new senior devs.
That's a special kind of evil. A purer kind.
@onlinepersona ah, the time-honored tradition of The Big Rewrite 'cause it's cheap. Where do people get these horseshit ideas?
Probably from the same spot where they get the idea that languages literally designed within the first few decades of our profession are the pinnacle of technical excellence and can never be surpassed.
This whole circumstance just reminds me of COBOL. Nowadays you have scant few programmers for it, but the ones who do demand a big salary because it's such old specialized technology and often they have decades of experience in it. There's simply less COBOL programmers than there were in the languages heyday, and the ones trying to enter that market nowadays have a huge learning curve ahead of them.
The only reason most of these places that do that though, is because they wrote in COBOL to begin with decades ago, and didn't want to switch away to something more modern as other languages gained functionality and popularity.
I doubt C is ever going to go the way that COBOL has, it's too ubiquitous, but it does make one consider the language you write in and how compatible it may be not just with what exists today but what's going to exist years from the creation of that code.
The only reason most of these places that do that though, is because they wrote in COBOL to begin with decades ago, and didn’t want to switch away to something more modern as other languages gained functionality and popularity.
And it would've been much cheaper to rewrite once some years ago than to keep paying people to maintain it.
And in many cases, rewriting something improves the code substantially by finding bugs and fixing architectural issues. Old code doesn't mean it's correct, it's just old, and just today we had a high severity bug from code that was never properly tested and sat unchanged since near the start of the project.
I think that many a time people begin a project coding in a far-far-far too-low level programming-language: they're solving the wrong problem!
Build your prototype in a high level language, get the model/architecture correct .. and THEN begin replacing the slow bits with faster languages..
To me that seems right.
Haskell to begin-with, & when it solves ALL of the problem, correctly .. THEN you begin converting stuff to Crab-lang/Rust..
When you're still bashing 'round, trying to discover the form of the underlying problems in your problem .. that's the wrong time to be doing low-level stuff, to my eyes..
_ /\ _
The US government recommending memory safe languages has really given people worms in their heads
This is triggering me really good. Especially the part about seniors competing with juniors. Has this person ever met .... people?
I seriously doubt changing language would impact a senior that much...
Rust is one of the harder languages for beginners to learn because of its borrow checker and strict ownership model, but it shouldn't take more than a month or two for a competent senior to pick up.
It's going to be deeply unpleasant and seem like a problem if:
- You're writing dangerously bad C or C++ code already.
- You've only ever used Python or JavaScript.
- You try to shoehorn OOP and inheritance into it (Rust idioms are composition and functional programming).
- You refuse to use/learn pattern matching.
- You're a pedant about "pretty" syntax.
If someone is at a senior level and any of those apply, they probably shouldn't be at a senior level, though.
You’re a pedant about “pretty” syntax.
Oh I'm definitely whinging about it but it doesn't make me stop using Rust. People coming from C or especially C++ don't really have a leg to stand on, though, neither do people coming from ML. It's Haskell people who get hit hardest.
You’re writing dangerously bad C or C++ code already.
Shots fired. Must be footgun that went off somewhere.
Can confirm, I'm a senior and I didn't have much trouble with Rust. After a couple weeks, I was writing useful code. After a month, I generally stopped cussing at the compiler.
I'm still finding odd surprises here and there, but it's honestly no big deal. I'm about as productive in Rust as I am in Python, which I use at my day job, though I use them for very different domains.
Junior here. Rust was easy as fuck to learn, honestly. I just want a way out of junior hell with 4 YoE.
rust is leans more towards data oriented design than functional programming imo
Wait, so saving a ton of money by using a language that reduces production bugs is now a bad thing?
I'm a senior sw engineer, and I don't get paid because I know the vagueries of whatever language we're using, I get paid because I can lead a team that solves problems. I don't really care what the language is, but I do care that it's relatively easy to on-board someone in case we have turnover or something.
I don't know about you, but I'd rather be highly paid because I'm able to be really productive instead of highly paid because I'm literally the only shot the company has of fixing the bug.
This is such an incredible self-own.
Either:
-
C++ is such a horrific language and Rust is so vastly superior that a person with 6 months of experience in Rust can be as productive and valuable as someone with 30 years of experience in C++.
-
The person writing the post, and according to them C++ programmers in general, bring virtually nothing to the table other than knowing the syntax and semantics of C++, even after 30 years of programming.
Por que no los dos?
Sorry but you're wrong. It's both.
-
Bruh. Just put Rust on your resume. It's not like they'll actually check and you can still Google everything.
Thats why you learn programming, not C/python/java/Rust/etc
This is so fucking stupid, I can't even.
For your mental health, have some reasonable arguments about Rust: https://www.heise.de/hintergrund/Entwicklung-Warum-Rust-die-Antwort-auf-miese-Software-und-Programmierfehler-ist-4879795.html
Since it's in German, here are the key points of the article (written from memory - the article is quite old, so I might misremember - best read the article yourself):
- Software development is stuck in a vicious cycle regarding project budgets.
- Some competitors don't know better and just budget the "happy path", that assumes that everything during development goes right.
- The author uses a term for this which I like a lot: "Hybris of the programmer"
- Other competitors know better, but still have to lie in order to remain competitive when it comes to prices
- Therefore almost all software projects end up with a way too low budget
- So we get buggy software
- Some competitors don't know better and just budget the "happy path", that assumes that everything during development goes right.
- Rust might be a way out of this misery, because
- it is understood that it takes longer to develop something with Rust
- but on the flip-side the safety-guarantees rule out a lot of bugs
- so customers who choose to have their project implemented using Rust are fully aware of the higher costs, but also the higher quality
- and developers have a well known argument for the higher costs, and also have data that shows how this higher investment will yield a better quality product.
The first point applies to any kind of engineering anyway.
- Software development is stuck in a vicious cycle regarding project budgets.
Here's a shocking (/s) observation: it's about different things for different people.
For seniors like the author, it may be about companies trying to replace them with cheaper professionals. For companies, it may be about renewing the workforce. For product owners / tech leads, it could be about the opportunity of using a rewrite to pick a stack that better aligns with the problems they're trying to solve. For regulators it may be about its safety features and eliminating entire categories of common issues. For juniors, it may be about choosing a language they actually like working with.
is this the programmers' version of "Dey took 'er jerbs!! Durka der!!"
That's precisely it.
https://www.softpost.org/rust/difference-between-rust-and-c
So, this "senior developer" is .. braindead & still allowed to be working, then?
_ /\ _
I'm almost 22 and I have six years of intensive Rust usage, confirmed by many projects and contributions on Github. Switching to Rust was the best decision I ever made, because this post is partly true
This has been the nature of technical innovation since forever. Carriage mechanics were replaced by car mechanics and leech farmers were replaced by phlebotamists
Can't the same thing be said about COBOL developers a few decades ago?
