When companies do what the market expect we praise them. When it's workers, we scorn them. This attitude is seriously fucked up.
When companies start hiring based on experience, adaptability, curiosity, potential and curiosity then you get to complain. Until that, anyone doing it should be considered a fucking genius.
The game doesn't exist without players. I could make more money if I worked at Meta or Amazon, but at what cost?
I understand the realities of Game Theory, but then one could argue that being blamed and criticized for one's choices is also part of the game. "Mr Wolfcastle, how do you sleep at night?" "On a big pile of money with many beautiful ladies"
It is, and this is highly judgmental and offensive. Nobody is doing this for "aggrandizement".
Also, all of this is just rationalization, and will keep being until:
1) People start blaming companies for not having the spine to say no to misguided projects by employees.
2) People start blaming Companies for not having the spine to hire people based on past experiences with the craft of programming itself, but rather asking them to have a certain box ticked in their CV.
If one wants to program in X in order to better feed their family and the market says they need to have used X professionally, it is in their right to do X at the workplace.
This is not only expected of them, this is how the whole industry is set up.
They're just following the rules, period.
For maximizing their gains in spite of wider consequences? Why? I thought that was genius level behavior in your book.
Why do you feel compelled to denounce this behavior on one side and praise it on another? That seems to be the very hypocrisy that you are shaking your fists against.
Worst one is the data pipeline we have. It’s some AWS lambda mess which uses curl to download a file from somewhere and put it into S3. Then another lambda turns up at some point and parses that out and pokes it into DynamoDB. This fucks up at least once a month because the guy who wrote the parser uses 80s BASIC style string manipulation and luck. Then another thing reads that out of DynamoDB and makes a CSV (sometimes escaped improperly) and puts that into another bucket.
I of course entirely ignore this and use one entire line of R to do the same job
Along comes a senior spider and says “maybe we can fix all these problems with AI”. No you can stop hiring acronym collectors.
Hmm. Can't say I agree here - at least not with the literal text of what you've written (although maybe we agree in spirit). I agree that _simplistic_ strong opinions about languages are a sign of poor thoughtfulness ("<thing> is good and <other thing> is bad") - but I'd very much expect a Staff+ engineer to have enough experience to have strong opinions about the _relative_ strengths of various languages, where they're appropriate to use and where a different language would be better. Bonus points if they can tell me the worst aspects about their favourite one.
Maybe we're using "opinion" differently, and you'd call what I described there "facts" rather than opinions. In which case - yeah, fair!
See, we can all generalize. Not productive.
Only thing I ever saw from Golang devs was pragmatism. I myself go either for Elixir or Rust and to me Golang sits in a weird middle but I've also written 20+ small tools for myself in Golang and have seen how much quicker and more productive I was when I was not obsessed with complete correctness (throwaway script-like programs, small-to-mid[ish]-sized projects, internal tools etc.)
You would do well to stop stereotyping people based on their choice of language.
That's pretty much another way of saying that stuff becomes a whole lot quicker and easier when you end up getting things wrong. Which may even be true, as far as it goes. It's just not very helpful.
FWIW I very much share your exact thoughts on Rust skewing metrics because it makes things too easy and because stuff almost immediately moves to maintenance mode. But that being said, we still have some tasks where we need something yesterday and we can't argue with the shot-callers about it. (And again, some personal projects where the value is low and you derive more of it if you try quickly.)
What do you think all programming discussions about languages, typing systems, runtime, tooling etc. aim for?
EXACTLY THAT.
If it was as easy as "just give me thing" then programming would have been a solved and 100% automated problem long time ago.
Your comment comes across as "if only we could fly, we would have no ground road traffic jams". I mean, obviously, yeah, but we can't fly.
Your comment also comes across a bit elitistic and from the POV of an ivory tower. Don't know if that was your goal, if not, I'd advise you to state things a bit more humbly.
I stated an opinion. You can reject it silently. Having the last word is not such a badass move as many people think. :)
(Mostly .Net, PHP and Ruby)
Even simple requirements can rule out languages for me. Like, if you need async or concurrency, Python is awful. If you need SQL in your code, Golang isn't great. If you are building a simple CRUD backend, Java is waste of time. If you aren't doing anything compute heavy or embedded, why even consider C++ or Rust. The list goes on.
I might personally love to kick off a greenfield project with Elixir, and it might tick all the technical boxes and meet the requirements. But then I have to pay a premium for senior engineers that know elixir or have to price in the time needed to upskill.
Or I could just do it in Rails where I can dip into a much larger talent pool and still meet the requirements. Much more boring but can get the job done just as well.
But in reality it rarely matters. If you were only allowed to use Java as a backend and your competitors could use anything your company would succeed or fail based on marketing and sales. The backend doesn't matter as long as they both have the same features.
I understand developer preference and different languages make things easier and make programming funnier. Languages have different limits.
As you become more senior you realize getting around those limits is part of the magic. If you come on to a project where the existing developer wants to write the backend in javascript because that's what they know I would rather use Javascript then wasting time trying to push a more 'pure' choice. Because in the end I am capable of writing it and what we will be judged on is if it works to achieve an objective not if it was the best language choice when using differentiation.
If speed of execution matters, then the language and tools you use for something also matters.
Hard to take you seriously when you do such weird generalized takes.
While it's a sad fact that fanboys and zealots absolutely do exist, most devs can't afford to be such and have to be pragmatic. They pick languages based on merit and analysis.
You should search for headlines on HN that say "written in Go" or "written in Rust" and then compare that to the number of headlines that say "written in JavaScript" or "written in Kotlin."
I’ve seen the more cynical hype-driven stuff, but it’s inevitably superficial on first glance, where I have seen some real curiosity and exploration in many “Project X - Built In Rust/Go/Cobol/D/Whatever” and I think they’re exploring the dynamics of the language and tooling as much as anything else.
You do seem to say Golang and/or Rust devs are zealots which, if it is indeed what you are saying, is boring and plain false.
I am especially valuable because I am fine reading and writing any of the languages involved. The management likes that, but there's a lot of difficulties solving the tribal problem, as the leads are basically all crazy zealots, and it's not as if purging one or two factions of zealots would avoid further zealotry from the survivors. The fact that I can work across all their tech doesn't make me many friends, as my work across systems shows their arguments have little merit.
For most work, in most cases, most languages are just fine. The completely wrong tool for the job is pretty rare, and the winning argument in most places is "we have the most people that have experience with tool X, or really want to try exciting new thing Y", for whatever the problem is, and whatever X might be.
Rust projects immediately become “done”??? They don’t also having changing requirements and dependencies? Why aren’t everyone at the best shops using it for everything if it massively eliminates work load?
" Version 0.2 - Unstable/buggy/slow unless you use exactly like the example - not going to get updated because I moved on to something else"
Rust is another programming language. It's easier to write code without a certain class of bugs, but that doesn't mean version 0.2 of a casual project is going to be bug-free.
It's easy to have no defects in functionality you never got around to writing because you ran out of time.
Doesn’t look like a con to me :)
I didn’t realise that the only requirement for well-written code is to have an expressive type system and memory safety.
Those people, if they really exist, are right.
Rewriting something in Go or Rust and announcing it is not being a Zealot.
Being enthusiastic about something shouldn't be a cause for us to judge them like this. We should be happy about them.
Learning new technologies on the go is pretty much the standard, but it's something that employers don't understand.