The author has a list of reasons (VC money, business culture, managers, fear of the unknown).
I, personally, have observed this reduction over my career, and I have my own idea of why that might be, my own phrasing of it. Perhaps it gets at the same thing as the author from a different angle.
I think the reason, plain and simple, is that most developers aren't really in it for the passion anymore, but rather the money.
When I first started coding, I didn't get paid. I didn't think I ever would. I was just having fun building stuff for myself. I, and the other people like that, moved into the workforce and brought that level of curiosity. Of hacker spirit.
However, as the idea of "programming makes money" became more well known, and bootcamps + college both upped their game, more and more people started coding just with the hopes to make money. To get good enough to make money, not care about "huh, how does the bootloader actually work" or "Why did chrome just crash, let me open up gdb...".
At the same time, I think other people who came into tech when it was a less obvious career path (and thus was something you usually discovered based on having some initial interest outside of "I want a paycheck") are getting older. They're getting older, having kids, and now also have a reason to treat their job as a 9-5. "Chrome crashed, I could open gdb and figure it out... but I'd rather watch my kid's soccer game".
I think new hackers still form, but they're diluted by programming becoming a career path desired for money, not just for a love of programming itself. I think existing hackers, over time, also often become less hacker due to life slowly grinding them down.
This site is a prime example. There can't be a post about a non-mainstream programming language without someone's comment saying "I don't get the point of this, it is really hard to hire for/it would be really hard to pick up for junior developers."
It seems every small project, library, language is evaluated in the context of the average FAANG developer, or whether it would fit in a startup environment. Hacking, as in enjoying the art of programming computers, is going the way of the dodo, especially on this site. The few remaining hackers are massively outranked by the "I only know Javascript" average dev, the Silicon Valley-adjacent MBAs and the huge number of those that somehow are here just to post and comment about non-programming topics.
On the rare occasion there's a post on Lisp or software-defined radios, for example, you often see the same faces. It seems that on here, the nucleus of hackers has remained more or less constant since 2010, while all other demographics flooded in.
As an average hacker, I must say that I don't give a rat's arse anymore about most mainstream programming topic you can find on this site's front page.
I comment way more on non-programming topics because that's where I think I can contribute - most people on here are better programmers than I am but I have life experiences that are fairly unusual for this particular bubble. I do read the technical posts but I don't have much to say.
As for the 'somehow', I was raised by hackers and I used to be one - I'm too much of a generalist to fully commit to it but I'm 'culturally' a hacker/hacker adjacent. I imagine our ranks are growing for various reasons, which might explain some of the shift.
I think this also describes those working on software in general. Everyone uses the same interesting-to-hackers low level parts of the stack. But the nature of software is that _use_ scales infinitely, so roughly the same small quantity of developers are needed the same as was needed in the 90s.
But technology use has exploded, so there's huge demand for developers working higher up in the stack, because the need for domain specific apps has exploded and that part doesn't scale. So the 90s hackers continue but are now dwarfed by app developers and web developers are many orders of magnitude more numerous.
Unfortunately because software is a commodity the use of the low level parts of the stack doesn't translate to money for the hackers working on them. Because just as it's a niche interest for developers in that area, so it's a niche business case to make money out of working in that area.
I'd like to add that the pipeline for child/adolescent hackers that existed in the pre-00s is basically non-existent. The only major path that still exists that I can think of is game modding.
I'm a third-generation techie on both sides of my family (my paternal grandpa (b. ~1915) got started working with TVs and their mechanical parts and my maternal grandmother (b. mid 1920s) learned C in the 70s) and there are several parts of my upbringing that I don't think could be replicated. For instance, I got started with web work in the 90s, which meant that a.) nobody knew what they were doing and the lack of formal structure combined with the cultural appreciation for competence meant that children could do 'real' work and I loved helping with 'real' work and b.) there was no age limit to participation and no legal liability since most of it wasn't commercial.
There were also child-specific parts of the Web that were built by actual children instead of corporations meant to siphon money from parents. A large draw was being able to act without needing adult intermediaries. I could make a website about Sailor Moon or toys or start a chat/IRC room and control the discussions I had and kick adults or anybody who was inappropriate. (10 year olds are great dictators).
There are almost no pathways into tech now that revolve around tech as play and I think that's where a lot of hackers came from.
I don't think I agree. Many of the old pathways don'ts exist anymore, but they've been replaced with new ones. Look at the maker community ("makers" are mostly just hackers by a different name), or look at the resurgence of hobbyist electronics.
I think electronics is a great example, actually, because I often hear old electronics nerds lament that hobbyist electronics is essentially impossible because most things a surface-mount these days. But what they don't realize is that designing and assembling circuits with surface-mount components is well within the realm of the hobbyist and is very common. This is proven by the wealth of wonderful projects they are engaging in.
The difference with electronics is that the soldering techniques are different. They're not really any more difficult, but require a different set of skills that the graybeards often haven't learned.
For that matter, my great grandfather was the type that actually built cabinets, or did plumbing, electrical, etc in his home. The most I've done is run an ethernet cable or change a light fixture or switch. That's not a critique of younger generations, just pointing out that a desire to learn, understand and do things has always existed. It just presented a bit differently.
If anything the problem is that today's kids have too many options. And sure, some are commercial.
That’s actually the exact same story of how I ended up in computer science instead of pure mathematics. I was interested in pure logic and set theory, but I could flex the same muscles learning programming language theory and end up with much better odds of paying off student loans by the time I’m 30
People only have so much time in life. If I could enjoy my work 30% more that would be great. Is it worth making less than half income though?
This is so true: as I've made more, my github has grown more silent.
If that’s the calculation—if you find yourself doing the calculation—probably not. However, if you can’t make yourself not do it (build software, build hardware, figure out maths or better ways to put maths into words, write fiction, ...), if you find yourself doing it even at your most busiest and staying up at night when every other minute of your day is occupied, then... Many such people have found they still need the income, and every one of them that I’ve seen is deeply unhappy because of it.
I've never once thought of it in those terms, but now that you pose the question... for me the answer is "yes, absolutely, no question about it."
If Harvard started admitting 50,000 students a year, the density of Zuckerbergs would be a lot lower. They'd still be there, but harder to find.
Unfortunately.
Not sure the concentration of Zuckerbergs and the concentration of hackers is particularly related, except maybe the latter attracts the former.
Zuckerberg's no genius, he was in the right place at the right time near the right people. He's competent, but no more than most of the people here. His morals (or the flexibility thereof) were what made him rich.
Interestingly, he enrolled in CS at a time it was believed to be a dead career, with offshoring replacing expensive American engineers.
Imagine Einstein was told "oh, you have such a nice idea about relativity, let's time frame it to 2 days, and then get back to reviewing patents"
Basically I just really like TypeScript. Languages I’ve worked with or tried out for the pure hackery spirit of exploration: assembly, C, C++, Java, Ruby, Python, Clojure(script), Lisp, Elm, C# (did lots of neat stuff with that, thanks Unity!), PHP, scala, go, Pascal, VB, probably a couple more I forget. More tech stacks than I can think of.
FOR ME, TypeScript is just so good for what I want to do that I just don’t want to mess about with other tools or “spend innovation tokens”. I just wanna build stuff!
My take is a bit worse than the GP: Theres people interested in that but nowadays they sell their skills for money. That's why you see lots of ransomware, darkweb sells and whatnot.
Even the torrent-ing has shown the change of culture: back in the Napster, kazaa, imem days, people (layman) shared just because. Now theres not that much interesting material, and a lot of it is behind private trackers that make you jump through hoops to get in the club.
There are plenty of hacker culture areas, they just aren't the same as the 90's and 00's. Neither were the 90's the same as the 80's. In fact, I'd argue the 00's were nothing like the 90's either.
The spaces are there. You'll need to abandon the thing you know. (And for many of us, that's hard, because the thing we know is also feeding us - but that, too, was always true)
When computers were small, dumb, and did very little on their own, creative integration of heterogeneous pieces was rewarded and rewarding. Computers are now large, complicated, distributed, and part of a whole ecosystem. The kind of "hacker-shaped" grit that makes someone do something neat gluing a telephone receiver to a TV tuner? Well that's a fun Adafruit demo, but you could have done it easier and faster on a Raspberry Pi, and hell, there's already the scragglypete/tv-phoner repo that you really should have used (if you'd done a bit of research before you whipped out the glue gun, you'd have found the StackOverflow post from three months ago where someone went "Hey, I want to glue my telephone receiver to my TV tuner" and they were directed to that project). And while we're on the subject, that's not nearly as useful as the telephone-receiver-glued-to-a-tv-tuner emulator in this Docker container, because it does exactly what your workbench solution does but you can deploy eighty of them in one minute with a few shell commands and some money thrown at AWS...
Hacking is less cowboy-shaped for the same reason there are fewer cowboys... Eventually, the pioneer towns give way to the skyscrapers and city streets because once the wilderness is tamed, the city is way more powerful, comfortable, and productive than the cowboy life.
There’s a huge component of this that’s worth recognizing:
—
The current legal landscape and lack of anonymity makes most hacking a non-starter
—
In the early days someone could explore really far as long as they didn’t call up a government agency or try to steal property. They could play pranks, hook up Rube-Goldberg call chains that circumnavigated the planet, break apart any hardware they owned and assemble it in to anything else, dig in to the binary of any file on a computer, rip apart the memory of any process, post the results in a magazine or even collaborate openly online.
And most of the world had no idea. The only time they got in trouble was when authorities saw something they didn’t like and even then most of the time they had no laws to leverage (there are some significant notable examples that got the book thrown at them but those were outliers).
Now?
Now you can be retroactively targeted for making an emulator for a decades-old game system.
Or sharing a single piece of copyrighted content.
Or getting close breaking to the DMCA.
Or (insert wacky future laws here).
The risk is extremely high and the rules are way too thorny. Working for a company means you’re going to have clear guidelines about what you can and can’t use and therefore protection from the worst of the legal minefield that is the US. It also means you have a cushion for if/when you’re targeted.
Does anyone know how many true hackers are growing up right now who have already taken their first steps at learning and who have had their posts wiped from the internet or their inboxes “graced” with cease and desist letters (or worse), or their accounts outright terminated? I don’t think there even is a way to know.
How many of those kids would be crazy enough to keep being public, and how many of those would learn enough through private self-discovery that they can significantly contribute to the hacking scene as adults?
Anecdata:
I had a job recently that paid competitively, but the boss soon replaced interesting work with boring work (for me: writing boilerplate that's already been solved a thousand times over, or any FE work), so my passion petered out, which was quite obvious to everyone involved, so the relationship ended.
However, I'm with a client now, and we're building something really cool (using LLMs; I get access to H100 soon; etc) and I'm working every spare minute I can get away with, without being paid for overtime.
I feel like a "hacker" again with this role, learning new things, stretching the capabilities of the system given various constraints, and every second link I open in my browser is arxiv.
(That said, I grew up in South Africa, where cyber laws lagged behind the world's for a good few years, so we knew every trick in the book, yet were untouchable, haha!)
Tho, people you call hackers fairly often do not actually like actual work involved in actually doing the programming work. They like tinkering with technology, reading about it, but they do not like creating and maintaining software.
And fairly often, people dismissed by hackers as not passionate, because they are using boring technology, are passionate about actually finishing functional software.
I think that hackers are still around -- I see them a lot -- but they aren't as publicly visible anymore. They aren't interested in making money, and so they won't be in most mainstream technical fora (including HN), because of the cultural shift that made chasing dollars the main thing.
But they are in more private fora, and they get together in person (at conventions, hackerspaces, etc.).
I don't think the hacker community has grown smaller, but I think most of the web has changed so that it's not as appealing to people who want to talk hacker stuff.
All of which is to say -- like when people ask what happened to the old web, back when it was actually good -- they're still there, but they're harder to see in the increasingly dense forest of commercially-minded places.
To me, bootcamps are a complete red flag when considering candidates. I don't think I ever saw a single good hire out of a bootcamp (and we just flat out stopped interviewing them at one point because the signal to noise ratio just became too low).
People are hacking social media a lot for growth and money, but the best secrets are very illusive and flooded out by lies, novice content, boilerplate advice, and outright scams... The actual hackers quietly scrape pennies off of the net in micro-transactions until they start racking up as thousands of dollars, most of the time though it's heavily coordinated group activity rather than the lone kid in his parent's house like it used to be... The hacker kid now is too busy shilling crypto scams, playing video games, revving stonks, or working on yet another GPT tool that no one really needs IMO. :P
Beyond this, priorities shift over time. The priorities of someone in their early 20's that is single will be different than someone in their late 40's with children heading towards college, or even younger children. As you mention, there's also the boot camps and people that simply come in without interest in the technology aspects.
In the end, there's many more people that will get into the gritty details today than decades ago, but there's also many more people that are more concerned about getting work done. This is part of why entropy is really hard to overcome. Trying to get movement in a company towards a new approach can be very hard. If company X is using Java or C#, their developers have likely been using it for many years, know it well and don't see a reason to shift. And for the most part, they are right. You can get work done in many languages, scale and adapt in many ways. Most applications don't even need to scale that much. Most apps are line of business apps that only a few dozen people ever even see and for those that aren't, you can scale vertically quite a bit before you really need to go horizontal.
It's different if you re starting something public facing and want to utilize newer tooling for horizontal scale from the start. Aside: Why CockroachLabs doesn't expose a web api for database queries directly for the likes of Cloudflare Workers or Deno Deploy is beyond me... In the end, it depends on what market you're serving. Getting something working means far more than an optimal approach in one way or aother.
Random datapoint, everyone I knew who was deeply passionate about compilers seemed to be going to work for Apple for a while. They could have written a new research compiler in their basement - but Apple is where LLVM was happening.
there's enormous pressure to be normal. being weird is... like... someone's going to be uploading video of you and mocking you.
there's also the thing where its more expensive to have a normal life, financial pressures say "do financial things". like... the us world is shaping to be "high road" qua Stewart Brand whereas hackers thrive in "low road" environments.
there's also sort of this ... how do I say it ... hackers & that legendary online culture was sort of a product of a people without obligations. seeing your kids soccer game is much more important than debugging a program for fun. being monks for code & computers is not culturally sustainable.
Are there any communities and/or forums of people who are passionate about building and hacking purely for the sake of passion that I can join?
as the total number of programmers grows, so too does the pocket, but at a smaller rate than the rest of the bell
so, numbers-wise, yes, there will be fewer hackers per average programmer. it becomes harder to find them too, since most people will probably spend most of their time swimming around the middle of the curve
but i think their number overall is still increasing. just have to grit your teeth and jump to discord to find them :)
AKA just getting older
It may be difficult for a child to become fascinated with a particular technology once it becomes ubiquitous. It's a testable hypothesis too, because if that were true then you should see hackers appear in different geographic regions at different times due to how unevenly these technologies are distributed.
The confounding factor, I think, for computer technology at least, is that by the time they become ubiquitous in the third world, they may no longer be simple enough to "get started" on.
How did you make a living?
I've seen it as well.
I don't agree with what the author says are reasons for it. They just don't fit.
From what I've seen, hackers (in the truest sense) don't advertise. They have deep knowledge, but you only find how deep when you get into discussions with them, and most of the time they have no goodwill to engage in that because of two things, people who are dunning kruger; and social media.
Many of the learning paths have also been removed and are harder to find, the internet used to be freer than it is now. You have companies that dictate what stays up simply by using the court system as a coercive measure. The recent Quad9 thing shows just how bad this is getting across the board internationally. Copyright is being used to coerce, compulse, and limit actual innovation.
Hackers used to get by with their skills via certifications and jobs, many times they can't get certified now that only a single company handles testing in most places. I can't tell you specifically how they fail you, but its certainly not based upon whether you just have the knowledge.
The number of real hackers out there are significantly less because there has been less opportunity, and less resources that are easily found to get into it.
Many have worked very hard for their knowledge and some volunteer and help others, but there's an active trend to harass those that contribute like that, and volunteer psychology says you stop giving when it starts costing you. Dealing with a high number of deceitful people leads you to test them before providing any goodwill. If the hacker's don't like what your response implies they don't engage, and you are none the wiser.
Its not about life grinding them down, there are a lot of intelligent people who have stopped giving back because they see what providing that support is doing for society in general, its going in a direction that will inevitably fail because life will be intolerable, and volunteering is at a much higher cost to them personally than it ever was before.
Its like that adage that most people know, what you do in small things that don't matter shows what you will do in large things that matter. If you lie cheat and steal in friendly games, do you want them managing your company's finances? A smart person wouldn't.
There are also a lot of crazies out there that are really indoctrinated now too and they don't even realize it. They like the idea of something, but ignore everything else that would be needed to make it work. Completely irrational in some cases and can't even reason or think critically. Its sad.
You aren't architecting a new programming language, man, you're talking to a guy about computers because you're wearing a shirt of a computer thing he liked. He wanted to talk to you because he had a mutual passion he wanted to share, and you openly challenged him in front of other people. Sorry, you were a shitty friend.
It’s notable how little this article actually discusses the delivery of any form of value. The tech is not the end in itself, it’s a means to an end - and we live in an age with so many well matured and valid options that for many of the problems we seek to solve what tech we use isn’t necessarily a critical decision.
The author answers their own question - where have the hackers gone? We are getting on with it and building stuff. This kind of language flame war stuff just isn’t as important as it once (debatably) was. It’s a dying trope.
Thinking on the initial mistake our author made - framing the conversation rigidly through their own frame of reference - I’ve personally found Matthew Syed’s work on cognitive diversity helpful in understanding and addressing this. [1]
[1] https://graphic-designer-richmond.co.uk/2021/01/business-boo...
I find the soil, surface, atmosphere analogy useful.
Also, I am one of those many many Python programmers who don’t know much about Python. Fascinating how you can be quite productive in tech, even so. Perhaps that’s the glory of Python. But for the record, nobody cares about the specifics of import, or anything else, unless it is likely to influence a problem or solution that we are grappling with.
I’m curious about Python… but I also have a job to do and a deadline.
None of that is to imply the friend is wrong or inferior in some way
I am however now worried if I said anything about Go lol
Rather than assume what's going on in the other person's head, ask them. Assume good faith until evidence to the contrary. It allows less judgement and negativity, which leads to more fruitful conversation.
> He instead emphatically talked about how much he loved that "the Go developers knew that all you need is a for loop. Someone brought Scala into my company and I hate the mental shift."
All you need is a for loop? Interesting! Why did they say that? What design decisions informs this approach?
If someone with neither experience in scala or go were to choose one language for this project, why would they use Go or Scala?
If the guy truly has no idea what he's talking about, then it should be evident just by him speaking and you asking questions. If he does, then at best you learn something new or at worse hear a different perspective. Be an active listener and engage with what the other person is saying. You can be critical without being judgmental. It's sort of impossible to have bad faith in this way, because you're taking what the other person is saying seriously instead of writing them off.
1. https://knowyourmeme.com/memes/oh-you-love-x-name-every-y
Today the same amount of knowledge makes you barely passable in a single niche domain. Consider web development. To get really good at modern web development, you need to know modern javascript, CSS and html. You need to understand how browsers work and all the quirks of how http requests and loads webpages - including what dozens of http headers do and how they interact. You need to understand the browser rendering process, performance tools, accessibility and debugging tools. And learn dozens of javascript libraries, like react, express, webpack, database wrappers, and so on. It’s accomplishment to learn all of that. But if you do, you still only know web programming. That knowledge doesn’t really translate to operating systems work, mobile development, databases, AI, embedded, etc.
Most professional programmers only have the inclination and capacity to learn one ecosystem. And, even then usually with big holes in their knowledge. True polyglots are rare because the mountain you need to climb to get there is higher. But we also depend on polyglots to guide us toward useful tools. Language / ecosystem choice still matters. It matters for performance, velocity, security and compatibility. But how can you really evaluate that stuff unless you’ve spent time debugging Go programs, or tried to squeeze every last drop of performance out of a big legacy Java monolith?
We’re left talking imperfectly from our own experiences. And living in whichever niche of programming we’ve carved out for ourselves. The days of everyone being all terrain programmers is over.
The cambrian explosion is happening within subfields too (e.g. AI -- everyone is a specialist within a specialty).
An argument that suggests people dont want to talk about the things you want to talk about and then uses fabricated classes of thinkers to suggest the things you care about are the grounded ones is just well written flame bait. You can easily find a set of people online who can argue about the garbage collector behaviour of several languages: thats actually pretty cool. But saying people arent hackers because they dont want to discuss it the same way is literally defining a set of people to exclude them from your “group”.
He talks about a "friend" and then proceeds to say things like "To be honest, I suspect he didn't know or think much about them" or "This was not a fruitful conversation".
How is that supposed friend, who might very well be aware of this person's blog, going to feel after reading this? Is it a cultural thing and this is not offensive everywhere?
The irony is that the main page says "I ♥ people; look for ways to make them happy, and empower them."
You are absolutely correct. This place is populated with quite a few nerds. Nerds typically have subpar social skills, which is is both fueled by and results in a lack of empathy.
>"I ♥ people; look for ways to make them happy, and empower them."
The propaganda arm of the Soviets is called "Pravda", which means "truth". It's like people who say "I'm such a nice guy", "I'm very humble", or this author saying "I love people and my friend" but then they talk shit about their friend in this very article.
Listen not to what someone says, observe what they do. "Actions speak louder than words" and all that.
>I wanted to talk about its garbage collector (1, 2), its cooperative scheduler that many people think is a preemptive scheduler, its very loose approach to correctness… and he didn't want to talk about any of that.
This is not the way an emotionally intelligent person approaches a conversation. The idea that a conversation should be a demonstration of ones own knowledge is a pretty common notion I see with socially-stunted geek types. Growing up with a narrow or minimal social group will do that, it's no one's fault, but it's a pretty clear indicator this person's advice on interpersonal relationships shouldn't be taken too seriously.
In the same way you can tell immediately from a blogpost that someone is an inexperienced engineer, the takeaway from this one for me is that the author is an inexperienced friend.
But in a reply to your comment there's already someone talking about nerds not getting on with "MBA types", like this is some American high school film and not real life...
Recently, I most frequently notice it when people discuss potential job losses from AI automation. Regardless of whether or not this is good for society, it's absolutely bizarre how many folks around here (and some other places, like related subreddits,) gleefully dance on the grave of artists of all people. Some seem to disdain creatives wanting to participate in our economy using their hard-won skills and vocation, almost as if their doing so is oppressive to non-artists. Others seem to think it appropriate to act like they've just beaten them in a game. The majority of folks around here seem to act pretty reasonably about it but that vocal minority is obnoxious, to say the least.
Accuracy of their predictions aside, it's just a disgusting way to talk about people whose careers, they imagine, were just unexpectedly flushed down the toilet through no fault of their own. Unsurprisingly, these people usually have the least sophisticated, and least useful philosophical understanding of what art is. I imagine this is a cognitive limitation directly related to their empathic limitations.
Perhaps unsurprisingly, this falls down on several points. It's just a disgusting way to talk about your fellow human beings when it's your own failures tripping you up. I imagine this is a cognitive limitation directly related to their own empathic limitations.
In conversations about AI, people usually want changed behavior and similar concrete shifts. Empathy is viewed as a lever to produce those changes. When the changes are not forthcoming, the conclusion people reach is that clearly it's because the emotional experience of empathy isn't happening. This avoids considering awkward and unpleasant questions such as if there may be other good reasons why those changes are not forthcoming from a person who may be experiencing sincere and genuine empathy.
I spent a lot of years as a professional software engineer. Many of those left me daily on the receiving end of people for whom calling on the empathy of others was their preferred means of shaping behavior. I had to learn to set aside those emotions in order to preserve my own judgment. Now I see, daily, the same kind of people deploring that the tools they taught me to resist are not working.
What I see in this blog post is someone relating a story in which an awkward encounter is anonymized. The anonymization is itself a form of empathy in action - the person is not called out specifically, only the conversation. There's plenty of room to criticize the author in what is presented, but we really have no idea who missed what cues in that conversation. It's not a kind comment on either person.
I suspect this might be like the folks who put down windows administrators.
I think it's sort of like "windows has a gui, anyone could do that", which might mean they're not special like me.
This dude just wanted a pretense for a blog post about Very Strongly Held Feelings Concerning PLangs.
It's negative when someone's not having fun. Or more to the point, when someone feels the need to post on the internet about how defective the "friend" they were arguing with is.
But I do think there's a lack of empathy displayed in his strong value judgments. His "here are the different things people think about" breakdown is interesting. But there's a flavor of "and these specific people are bad and wrong" here that I don't like. I think he should have kept going to "and here's why they focus on those things" with the same amount of appreciation.
Friends don’t have to agree on everything. Calling your friend a jerk because their interests don’t align with yours is… odd?
I'll try to be more mindful in the future, but I think "the original characterization doesn't trash him" is defensible. If he sees the blog and thinks its unfair, he's perfectly able to reach out (we're not actually very close). I make it clear we value different things but I never explicitly say "this guy sucks" _because I don't believe that._ He's a fantastic dev who's built great systems, but I wish we had a better framework for chatting about Golang.
Edit: I've updated the language with a few more details to better reflect how that whole interaction went down, which was a playful chat between two seasoned devs with ~12 companies between them. I didn't want to spend too much of the article on the anecdote, so I originally cut out some surrounding context (he was excited to "get into it," it's not like I just came at him when he said "I like Go").
In Spanish there's a saying, la confianza da asco, that could be translated more or less as "familiarity sucks". You often treat your friends and family worse than you would to strangers. It also means that if a good friend doesn't talk truth to you, who will?
In fact, I really can't stand when I talk to someone and they seem to agree unconditionally with everything I say; it's not believable. Surely they disagree, why can't they express their feelings? Why is no one willing to go on a limb and be wrong or criticized? I find it particularly prevalent in the tech circles, when talking to parents of other kids in the SF Bay area. Everything is very picture perfect, and I can't believe it, so I feel I can't trust the people speaking. They're too nice, too polished.
I like my friends who will disagree with me (most of the time respectfully) and allow me to say stupid things and forgive me for my imperfections, and equally for theirs.
The description is undiplomatic, could be written in a more roundabout way, but this could be read as even more haughty and rude. I'd say that as human collectives we need to maintain a grip on reality, and it is wasteful and dangerous to live in a web of polite lies.
In reality, there are vast cultural differences between different English speaking regions, which foreigners often overlook due to the shared language. California, New York, Miami, Johannesburg, New Zealand, and rural Yorkshire are all technically "Anglophone" in some broad reductive sense, yet are as culturally distinct (or even moreso) as, say, Sweden and Greece.
The GC being preemptive might be part of a group choice at selection time, whether the language is painful to read and/or write is a permanent factor in your quality of life at work until you eventually move to another project.
Of course whether they are not emphatic enough is more a matter of whether the author sees it as a criticism of their friend.
Who hasn’t occasionally mentioned to one friend how another friend annoyed you?
On the other hand, it’s not something you do in public. I’d be just a tad upset this person didn’t tell me how they felt and instead told everyone but me.
That feels like such a new and toxic dynamic enabled by the fact that anyone can (and is incentivized to) blog online.
The normal (at least in Canada) seems to be as you suggest. I'm perfectly ok with being the weird one though.
We need to consider whether we should foster more empathy or simply adapt to the existing landscape. Being practical and discerning, sometimes to the point of discrimination, has proven effective in areas like space exploration, business, and even the natural process of evolution. And tech, too. Over the past 30 years, the tech industry has achieved remarkable feats, feats that would seem magical to people living a century ago. This success stems from swiftly testing new ideas and people, and discriminating between those who can deliver results and those who cannot.
However, such judgment or discrimination can pose problems. While it might be beneficial in natural systems, facilitating improvement, it isn't perceived positively in our society. We aim for fairness and equality for everyone. The term "discriminate", even though integral to nature and many productive systems, often carries a negative connotation in sociology. And indeed when we look at examples of unfairness and inequality in history, they are generally seen as immoral. But I wonder if that is because the inequality was often means to an end for someone else's decadence.
Here's a difficult question: should tech become more empathetic or continue to discriminate based on ability? If we become less judgmental of skills, we might not achieve as much. If we continue to be unempathetic, that will cause social friction. While I don't have a definitive answer, it's certainly worth considering.
In my tentative opinion (since I don't feel particularly adamant about it), we should continue assessing individuals based on their technical understanding in the tech realm, but within reason. We need to maintain humility, recognizing our limited knowledge and potential to misjudge others. Our critiques should be measured, and we should avoid letting our assessments of others' technical skills cloud our perception of their worth in other areas. After all, one can possess excellent personal attributes yet lack technical skills or be unfit for a specific tech project. In that sense, I lean more heavily towards the fundamentally non-empathetic approach. But that's just N=1. The important part of my message here is that we need to acknowledge the equity/empathy-effectiveness trade-off and be conscious of it.
Friends are people you can talk like this about and they are still your friend afterwards.
Don't worry. The friend is probably imaginary just for the story.
That's the whole appeal of many programming languages, they massively simplify the mental model (for a price).
I've been a lot happier and more productive since I switched to a slow language (which younger me would have been sad to hear).
The explicit choice in the design of Go is to prefer fast reading over fast writing, which helps maintainability and debugging.
Complex language features are terrible for maintainability: the reader may not know the feature, it may interact in unexpected ways with other language features, or have other non-obvious pitfalls. Debugging these things are ultimately a waste of time, and time is the highest price of all. And for what?
I believed this to be literally the case, that Go was designed for the "lowest common denominator", i.e. to make that area of programming at Google more accessible than it was previously. Have I been misinformed?
One key indicator of whether impaired empathy is the result of ADHD is that everything tends to be communicated as either starting from or directly referring to the person forming the communication almost as if narcissistic, but not necessarily with a selfishness intent.
I personally think people can make empathy mistakes without having a permanent neurological disorder.
Please stop and go educate yourself.
ADHD is at times co-morbid with autism, but they are not the same thing, have different neurological causes, symptoms and treatments.
Sincerely, a diagnosed ADHD, non-autistic person that self-identifies as an empath (i.e. the opposite of a psychopath. I can read body language and empathise with people better than most. It's not always as fun as one might think.)
A common misconception is that empathy means love and compassion for everybody. No. It just means being able to easily put yourself in other people's shoes and feel their mental states. Empathy alone doesn't turn you into Mother Theresa.
Anyway, I think the author missed the point a bit with his friends argument about "Go developers knew that all you need is a for loop". It's not just an "atmosphere " argument. The programming language literally restricts you to using for loops. That's a surface property of Golang (or maybe it used to be, haven't used it in a couple years).
Golang has been designed to have a minimal and thus very smooth surface. Those issues the author mentioned about Python, that's rough surface.
The article then digresses into the main point which is that engineering leaders are afraid of spending innovation tokens without giving evidence that this is more so the case than it was before.
Not sure if it's relevant, but Twitter starting on Ruby was them spending an innovation token. They then realised there was a big large scale low latency high throughput situation that Ruby didn't have a suitable ecosystem for, so they hired a team that had experience scaling these sorts of systems specifically with Scala. Picking Scala was in that sense the safe choice, the risky one would have been to try and get the existing Ruby codebase to apply the concepts from Scala (which is now more than a decade later a reasonable thing to do in Ruby).
isn't Kubernetes mostly Go? Just sounds like an arbitrary limit. I say that when I try to limit shell scripts to a single-scroll in editor.
There is a FOSDEM talk about it.
ummmm me
(I mean I hate Go but in a hypothetical world where I liked Go, me)
If I see someone wearing a political t-shirt, they're clearly virtue signaling. If I ask them about it, I might expect political slogans, but often they won't even be able to manage those slogans, much less explanation of a party platform.
If I see someone wearing a branded beer shirt, they're likely to be able to represent for their shirt-beer. Most of the time I'd only expect advertising slogans, but once in a while maybe they'll have something interesting to say. They're going to be generally more informed than the political shirt crew.
A programming language t-shirt is much more niche and advertises that the wearer has an interest in that language and wants the world to know about it. This goes far beyond the virtue signaling of the political shirt crowd. If all they can do is repeat slogans (like most of the beer-shirt-wearers), I'd be disappointed, too.
> innovation tokens are completely made up, it's like talking about the finite number of "love tokens" you can give your spouse in a given year.
You can't complain that "'atmosphere' questions are extremely based in feelings" and then just get high on feelings like this.
The amount of "love tokens" you can give your spouse in a year is absolutely finite, because they take time and attention. You can see easily this in the complaints that come in advice columns and relationship subs. And innovation tokens are no more made up than anything else. Time and attention are finite at work just as much as at home.
Hackers didn't go anywhere. The solution to the puzzle is that hacking is an ethos not generally suited to creating profitable businesses. However, we've seen a massive expansion in business use of computers, and most of those businesses are trying to be profitable. Yes, a bunch of those early companies were populated by hackers because that's who knew how to use computers then. But the industry has changed as more and more people have seen it as a professional career, not a way to feed a hacking habit.
Hacking is still alive and well if you know where to look for it. People are still doing lots of weird and wonderful things. But they are, thank goodness, not doing them as much at their day jobs. And as a person who has had to clean up other people's "play", I say: hooray! Play at home. Play in disposable playpens. Production is for shit that works.
This blog post was very painful to read without suffering second hand embarrassment.
if thats the case, then I formally suggest that such people can get in the sea.
I might be somewhat unfair, but that was my reading.
> innovation tokens are completely made up
So are programming languages.
Innovation tokens are there to make sure that a business can complete a project vaguely on time and vaguely on budget.
Look the reason why people were able to get away with pissing away millions of dollars in pointless re-writes of things is because the speed of business based on those systems was slower. Now, if your site is down, then customers flee.
I mean sure, writing your own database for your SaaS company might be a thing, but its almost certainly expensive and pointless. You're on the hook for scaling it, recovering it when it fails, and finding and fixing all the bugs.
In short, this article, I feel, encourages a damaging, selfish side of CS that I think should be phased out.
Perhaps the more important metric is supply of devs relative to demand. The top paying languages, according to the Stack Overflow's 2022 survey, are generally less popular: Clojure, Erlang, F#, LISP are the top 4. While certainly not an ideal metric (e.g., perhaps salaries are skewed due to more senior devs using these languages), this hints that the demand is certainly there relative to supply as companies are willing to pony up some decent cash for these devs.
Maybe, but personally I don't feel it has such a significant contribution as number of positions you can apply to. In these languages you basically can find a dozen of positions worldwide open at any given moment of time and apply to them, in JS you can find hundreds upon hundreds of positions every day and just filter and keep applying, and it still can take weeks or months to get an offer, a lot of your applications aren't even processed at that moment, which could be the case with less popular tech positions as well.
I think this reflects a larger cultural trend of fear, pessimism, and scarcity.
When we have spare capacity and a belief that we'll have spare capacity in the future, it's psychologically much easier to take risks, be whimsical, try things, explore, and give the benefit of the doubt.
When times are lean, the natural human response is to hunker down, hoard what we have, hustle, and do our best to survive.
It's just not a great time in the world right now.
Also what is missing from much of today's programming training is a problem solving attitude. The focus seems to be overwhelmingly on tools and arguments about tools, not about how to solve problems.
It feels like those things can be better framed as ‘runtime/tooling’, ‘language/libraries’ and ‘ecosystem’.
And under that taxonomy it isn’t wrong for people who say they like a ‘language’ to not be talking about the runtime or the tooling.
Like, take JavaScript (the good parts at least): I like that language! And I separate that out mentally from the fact that I hate the browser runtime, and I don’t have much love for the node ecosystem. I have complicated feelings about working in javascript as a result. But I still consider myself an admirer of the core good ideas at the heart of the JavaScript language.
The surface matters a lot. You have to live there.
I feel like saying positive things about Go is a bit of a fucking minefield, because somebody (especially here on HN) is going to talk about how Go is Awful and Bad and made for stupid people or some shit like that. I’m tired of it. I’m gonna go hang out with the Java developers and the people doing work in Ruby on Rails or PHP.
> Infusion of traditional Business and Capital culture, which traditionally serves smoother-brains, the boring, and the unimaginative.
There’s an entire culture of people in tech who refuse, on some kind of principle, to understand or work with people in business / capital / management unless the people in business / capital / management somehow prove their street cred on the technical side. Like, the people who say that they can’t work for a manager unless the manager could do their job!
This is just a shitty echo of the “wow, startups are hard” cartoon panel. If you see somebody doing management or business poorly, and you think “wow, managers are stupid” then you’re falling into the same trap. If you think, “this is why you need a manager with deep technical expertise” then you’re falling into the same trap, but with extra steps.
If you want to work with people who have deep technical expertise, and you specifically DON’T value people with management or leadership skills (unless they also have technical expertise to justify their existence), then you have fallen into the trap and your attitudes are going to make the team more dysfunctional. You’re going to bring the team into conflict with other teams and with the goals of the business.
Anyway. This article doesn’t just promise flamebait, it seems to relish the flamebait, enjoy the flamebait. It seems to be steeped in the idea that pissing people off is a sign that you’re speaking the truth. I think some people have observed that people who speak the truth often piss people off, and then optimized for it. Goodhart’s Law and all that.
I've worked in IT for over 25 years. Other than a CTO or senior tech executive reporting to CEO, I have seen problems with technical people reporting to non-technical people that I never see with technical people reporting to, if not technical people, at least formerly technical people. A technical manager can have problems of their own, but why enter a new class of problems that don't exist otherwise.
Why would I work somewhere where my boss is effectively a PM?
People are also really bad at understanding if management is doing a good or bad job. Most people try to figure out if they like their manager on some kind of personal level.
This author needs to understand with web/api programming, even using JVM, Go, etc still require Celery/Sidekiq/WakaQ for siloing. You don't want some developer using Go to hog 100% of all webserver CPU doing something concurrently but which should have been done on a background server.
This makes a difference, and means you do not require queues for properly silo'd background tasks.
I'm sure there is a term for this phenomenon, but usually you see it within corporate bureaucracies - the skills that take you to the top are not necessarily the skills that make you good at your job. You get promoted by getting noticed. And creating value is one way of getting noticed. But you don't need to get noticed to create value. Same goes for any builder culture.
So take the opinions of the bloggers with a grain of salt. Eschew the RSS feed for the GitHub commit log. Read the source code, not the blogs. There you'll see that hacker culture is alive and well. Indeed, it's thriving.
My take of this situation is that people are overworked, and community has become overly regulated, unrewarded, and suppressed. (Language/tone policing, spam, aggressive individuals encouraged in groups, bad group membership policies [CoCs used as bullying devices more than simple rules to follow], dev advocates stepping on everything)
To a newspeak school to unlearn precise terminology.
So to translate OP, "soil, surface, and atmosphere" apparently refer to semantics, syntax, and runtime.
("Pedantic" is a favored word these days. In my days, objections to those who actually knew something about CS was that they are "academic", and "theoretical".)
But yea, maybe we can't have a PL conversation without also having a conversation about our own language? Ugh
They may not hold up to morepablo's bizarre demands of hacker purity (like the off-kilter conversation reported in the linked article. If I talked like that to someone who approached me, I'd be so embarrassed. Definitely wouldn't plaster it all over the Internet on my blog where I "look for ways to... empower [people]"), but it sure looks like the hacker spirit to me.
The difference between soil and foundation is almost as vast as the difference between soil and atmosphere. For people who think about programming in foundations they're more interested in how solving recurrence relations can lead to better optimizations; more generally speaking, how formal calculation of programs is influenced by or limited by language.
Complaining about python being slow, or java being verbose and golang being tricky etc. who cares. The stuff people have done in them in highly networked global environments is where a large focus of innovation is. This is the author missing the forest for the trees.
https://www.thatsmags.com/shenzhen/post/8620/touring-the-har...
However, software hacking also requires access to the low-level components and as abstractions get more and more complex, unpacking them becomes too much work and people become architects, not hackers, expecting all their tools to work only as documented and building with only the pre-approved, security-tested Legos (note that many of the software hackers seem to have gone to work for the NSA and other state-sponsored hacking groups, and their exploits have escaped into the wild, leading to the heavy focus on security consciousness, which also discourages the use of hacks to solve problems).
Note here 'hacking' means using features of systems that aren't described in the manuals and documentation to achieve some goal, rather like custom modifications of automobiles - and with modern cars, that just gets harder and harder to do.
A better title might have been, where have all the experimental risk-takers gone? (A: most of them were eaten by the Borg).
Ruby is not great, not terrible. I enjoyed learning the language. I didn't find much in its runtime or its constructs to recommend it over Python. But I haven't used it in years because the first medium-scale project I wrote in it I put down for two years, came back and found that Ruby on Rails had changed so much that my project wouldn't build; every dependency had gone through a major revision and Rails' preferred package manager had changed. The prospect of doing a lot of work to re-tool a build environment that had worked perfectly fine soured me on further activity in the space. This was nothing wrong with the language and everything to do with the ecosystem being so young that "the adults were not (yet) in charge."
Contrast C++. One of the most supported languages on the planet; adequate performance for my needs. I can't stand the constructs in the language itself. The templating system couples badly with other language features and they "fixed" it by cutting firebreaks in the parse process via newly-required keywords and template parse rules (all taxonomies are broken, and there's a touch of atmosphere here too; I got to ignore all those changes for a decade because MSVC basically told the standards committee to pound sand until 2017). It's a Turing-complete language, you can do everything with it any other language can do... But doing it by having a template resolution hinge on the implicit typecasting of an integer constant `0` makes my skin absolutely crawl.
Oh, and the thing about Authoritative Calm Professional Voice is spot-on.
The opening, I'll concede, is fluff that could have been edited out, but there it is.
There is also, for some reason, this subculture inhabiting HN which, if some project is not aiming to become the next multibillion unicorn, scale out hugely, dares not be a product, or someone open-sources his work without a particular desire to bring in a "team" or a "community", starts deriding and piling on the author, because in its opinion, such things (and maybe such people) simply should not exist. This subculture is a huge deterrent for anything tinkering-related that is not aiming at, you know, Changing the World or whatever it is these days.
Ive seen like hundreds of discussions like that
Java vs c# vs rust vs go vs kotlin
It is always heavy of emotions, unverified claims (performance especially)
and dependent on what stuff do you value.
This kind of discussion requires wide knowledge, hands on experience, curiosity and open mindness.
All of those 4 are really desirable itself, so together even more and are really rare!
>I prefer to work with an excellent software engineer, who doesn't tie their identity to a specific language or technology (e.g. would prefer a great hacker than someone who identifies as a "Ruby developer" or "JS developer.")
Why it matters to you how somebody calls himself?
Is this "single lang programmer" insult variation?
Especially when you are aware that concepts are above languages
>For all my advocacy in this post, it may surprise you to hear that I believe it takes years to be excellent at a language. It's not just syntax, it's soil and atmosphere: common bug flows and how to spot them, footguns, tooling,
Agree!
Many people do not get it, they are always like "you can learn langs after your first within a month" or so
>Functional programmers insisted without evidence that their programs were More Correct.
Hah
In my experience: half a year minimum, and only after your 10th. The amount of uninteresting trivia that you need to wade through on your way to concepts you already know is vast, much greater than you'd remember from 10 years back when you learned your previous language. More then 10 languages I already know do help, in that I can easily pick up any language in a matter of days, but... that's only if we're talking about the language[1]. Developing a skill in using that language, including absorbing the specific culture (books read, talks given, whose blogs to read, which Discord/Slack/#freenode to visit, and so on) and learning the details of the ecosystem (from stdlib to common libraries to frameworks, to the details of implementation, the FFI, and so on) and it's a lot of things to learn.
Well, at least I know that my next language will be a lot easier to learn, thanks to a revolution in the rubber duck industry, which gave us a duck that can - sometimes convincingly - pretend to understand what we're saying. And sometimes even gives you a hint that turns out to be real! Oh, the progress...
[1] As long as there's no genuinely innovative features in that language. Which, sadly, seems to be the case 95% of the time.
but you should hold in the back of your head a realization that your understanding of said ecosystem and the compiler is limited. Likely always will be, as there are multiple not stupid people working on it, and there's one of you.
It happened to me that I knew how to do X (and then did it) which had been boldly declared as impossible to do by the resident senior expert. I knew it not because I liked those minutiae, just was willing to dig to the bottom when solving some problem earlier. I dunno, but it's likely that both geeks who just absorb niche and arcane knowledge to feel superior and bone-minded resident experts are equally bad (and sometimes, rarely, but still, they are the same guy).
Might be true for Elm, but how is that the case for Clojure? Clojure, like any other Lisp, has a very powerful macro system. If Rich didn't think you should have that thing you wanted, build it yourself.
“Soil” = Implementation “Surface” = Language/Syntax “Atmosphere” = Community
Often when people talk about a programming language they mean a combination of these, but it takes very little to clarify which specific part you like or not.
The few meetups I go to, I've also noticed that 90% of conversations stay at surface level, the folks who prefer to go deeper were always rare, its likely that in the past, meetups tended to attract that small percentage in the first place, so there's some selection bias.
In terms of language-level specifics, I will say that in 12 years of experience I have rarely ran into a problem where "soil"-level properties of a language actually made a difference. I'm not building systems-level stuff or libraries, I'm building apps and services for businesses, where IMO the surface or atmosphere-level issues are more important. It doesn't matter that Python is 1000x "slower" than some other language, up to a certain scale. It matters more that I have access to Python's ecosystem, or there are specifics in how a python app is structured that I just happen to prefer because I'm comfortable with it. This is just an example.
The other issue is that most applications we write are going to fall into a handful of categories. The needs of a locally-run stateful application are going to be different from the needs of a stateless web application. For web apps, your bottleneck is rarely in the language runtime, and more in your application design, database, infrastructure, etc.
Language-level enthusiasts (which is how I would describe the author) are incredibly valuable members of the community, but its not the only game in town. There are so many other dimensions to measure technology, and so many other fields to be a "hacker" in. So why do "innovation tokens" need to be spent on the language runtime?
It is (or at least was) the period of being the Uber-but-for-X, the Twitter-but-for-Y. A period of page-long lists of uninspiring logos and machine generated startup names. A period where VC ecosystems became cookie-cutter themselves. Silicon Prairie, Silicon Swamp, etc.
The disappearance of hackers is also congruent with the locked and supervised platformization of "big tech". You can't really hack devices. The motto is: "Here is the browser, here is the API, now go play, consume your cloud budget and give us some ideas how to make money". In this context its all about optimizing the execution of more or less the same ideas. And boy did it optimize. Within a few months every silly chatGPTification concept has been paraded here on HN.
Of course today we have more latent hackers than ever. The interesting question is what would be the preconditions for them to start creating wonderful and weird things. Here is a tentative list:
* the massive expansion of self-hosting and shift to having serious compute and intelligence "at home". This is the broader fediverse or small tech movement
* the liberation of mobile devices and next-gen apps that might finally redeem the "supercomputer in our pockets". A related domain is non-smartphone mobile devices.
* the re-incarnation of the workstation concept in business context. Monstrous linux desktops that finally put the moribund "Productivity Suite" to rest and offer various completely new businesses launchpads to the next phase of the digital economy
Hackers currently have been either co-opted or starved to death by the lack of opportunity. Yet the cycle never finishes.
Yeah exactly. You're barking up the wrong tree. If you want to see optimism, go to a startup. The hackers aren't going to work for you at one of the big tech companies no matter how great you think that place still is.
Power and privilege would be important keywords here.
package main
import (
"fmt"
"runtime"
)
func infiniteLoop() {
for {}
fmt.Println("world")
}
func main() {
runtime.GOMAXPROCS(1)
go infiniteLoop()
fmt.Println("hello")
}
Kids these days want to build games and discord bots. They don’t want to build little text-based adventure games. And if you want to do those things you’re going to use a language that’s mature and has libraries built for that purpose.
I do like the breakdown the author gave. But the “atmosphere” component should not be underestimated: I haven’t given up on any languages but I’ve given up on dependencies because I’ve run into errors that I couldn’t find a solution to online.
Raylib supports over 50 languages.
Elixir has been great for our Authorization server. I really believe in the BEAM for high-uptime cases, and love a lot about Ecto's design as an ORM. That said, I only felt comfortable bringing Elixir to Ramp because I'd already built ~3 Pheonix projects before joining, and had a decade on other Erlang projects. I make a light reference to it in a few places in the article, but I think introducing Weird Tech is very, very easy to mess up and most people would be better off not doing it.
I lead with that in my other article that made it to HN, on strategies for learning exotic tech https://morepablo.com/2022/09/so-you-re-using-a-weird-langua...
More on BEAM at Ramp and why I like it https://engineering.ramp.com/elixir-at-ramp
Me comparing/opining Ecto and SQLAlchemy, the two ORMs at Ramp https://www.youtube.com/watch?v=5Ep9CDXUHNU
It's been running Authorizations for 4 years and had remarkable good mileage.
There are lots of hackers out there, but we're not all obsessed with creating new languages needlessly. I mean sure, I have my own pet language I hack on, but the author would probably call me a "non-hacker" because I prioritized readability over fancy language features like a novel garbage collectors. Gosh.
Or, alternatively, you went all "This guy likes Go. I must explain to him why he's wrong, so that he stops thinking wrong".
This whole article just makes me think "yeah, I wouldn't want to talk to you about that, either". And it's not because I don't know what he means, or necessarily even disagree with his conclusion on Go.
Okay so, according to the author, then it's not fine...
How do we fix this? Is it every employee's fault that they don't know the nuts and bolts of the things they work with, or is it the company's fault for not providing the right training?
There isn't much to get people started on the hacker-path - it's presented to them as atmosphere.
> Is it hard to learn a language?…
Amazingly, no. My language ( https://www.adama-platform.com/ ) recently had a 19 year old build a game with it. Does my language have expert documentation? Not really, but it has just enough.
Hackers still exist, but finding them at bigger companies is rarer.
Hacker means to use tricks to "hack", to "break", or to "reverse engineer" a system. It's very specific, very concrete job to do.
A hacker mindset means creative, innvative for the goal of automation instead.
I'll add some anecdata, to give more context on why "atmosphere at all costs" might be en vogue.
- Most software engineering is CRUD
- Almost all 3rd generation, higher level languages can achieve CRUD (e.g. Javascript, C#, Java, Python, Ruby, PHP, Python, Perl -- even Bash)
- Most engineers will not have to dig around in the internals of a language to be able to do their jobs (e.g. that you can fine-tune and pick your own garbage collector (or even disable it completely), depending on the domain in Java (such as low-latency environments); whereas in .NET, you cannot really tune, swap out, or turn off the GC completely)
- Without needing to know the internals of a language, all the aforementioned languages are largely interchangeable (again, for CRUD -- and based on taste)
This is why you may commonly see people recommending that even if you don't know a language, you should be able to pick up whatever language a potential engagement requires (see: "a senior should be able to pick up frameworks and languages within a week or two"). I've always disliked this way of seeing the world. It rubs me in a certain grating way: that most work is CRUD, so you should optimize your career for being an interchangeable COG.
In my experience, if you take the time to learn a single language or ecosystem thoroughly, your chances of finding work for that specific ecosystem greatly increase -- versus the "generalist." Likewise, you'll be able to tell when it's the tool that's messing up, or yourself. Further, you'll be able to find more interesting, "deeper" work to handle -- rather than just building another CRUD web app. And lastly, life is too short to work with stuff you don't like.
For example, I love the .NET ecosystem. If I want to build something that isn't in the HPC space, I'll reach for it first. I know Java, but I don't like Java -- and I do not ever want to work with it. My ability to land .NET work is much easier, because I know the ecosystem -- not just how to program in an OOP language.
Or how about databases? I love Postgres. If I want a great OLTP DB, without any fuss, I'll reach for it first. I know MySQL/Mongo/SQL Server (to be fair, this one is also really good)/etc., but I don't like most of them. My ability to land work that utilizes Postgres is much easier, because I've taken the time to thoroughly understand it.
Or in other words, most people in the game are optimizing for commerce: how much money they make.
The hackers? They're in lower-level, systems programming languages; they're in compiler and language design; they're in low-latency or kernel programming; they're in stuff that isn't directly related to making money. Part of the reason I'm learning C++ is because the work there is more interesting (database engineering is very fun, but you need C++ or C in some cases) -- and the people more passionate. But also, because the gravy train is starting to dry up in CRUD -- anyone who can program can do it.
I love .NET ecosystem but it sucks that it lacks of fancy jobs that you mentioned. If you want to do compilers with C# then it feels like you have to work for C# Compiler / Roslyn Team(s)
For cool jobs there is shitton of CPP which I do think is huge mess and I hope that Rust will steal CPPs market share because my experiences with it were way way more pleasant
(i) late stage capitalism: who cares about going through a 400 pages spec sheet to try and reverse engineer the ludicrous Chinglish [1] in which all non-mainstream manuals are written today (wanted to declare war on China by myself when parsing through a Xinje PLC manual recently) when you could be fired at any time, a health emergency can bankrupt you, you generally feel more and more powerless, from your daily life to the once-in-a-lifetime-but-happening-every-week events such as economic crises, pandemics, wars, automated labor, x-flation, climate change, and so on and so forth.
(ii) product refinement: we no longer are interested in a few lines of assembly which barely show two lines and a dot moving on the screen [2], we want that feeling, silky smooth user experience which some companies spend billions to provide, but very few individuals can offer by themselves, examples would be something in the tier of Bartosz Ciechanowski [3], scottbez1 [4], or Chris from Clickspring [5], for a more hardware bent.
[1] https://en.wikipedia.org/wiki/Chinglish
[2] https://en.wikipedia.org/wiki/Pong
Where the business is boring, try new things.
Where things are untested and critical, use reliable components.
The workforce tends to be employed at much larger organizations. This creates very narrowly focused teams, isolated to very different areas of product & platform: people are pdigeonholed in very specific tasks. Cranking out React widgets as the decades go by is all too probable (there are interesting challenges & arch questions here aplenty).
The irony is a ton of the money funding the large-scale industrialized computing came from the first internet booms. Where hackers did get rich, making small companies, & selling them to their more profitable peers & established businesses. Now the scale & industrialization inhibits the conditions of creativity that begat such a rise.
The industrial workforce isnt even the worst part of this sad saga, this march away from intelligible sharp systems knowledge. The system itself has ossified greatly.
The cost of technical diversity is being felt. We had such an explosion of open source means & ways, became so powerful. And that has diluted the intelligibility of systems, has a huge isolating effect. Rather than most folks using C/C++, there errupted php and perl and Java, which each had their own burgeoning ecosystems. The frontier kept expanding, with countless niches developing. While you might be great in your domain, might be totally on top of Django & just a genius productive whiz, your skills might not port. The fundamentals became diluted, and people specialized higher. Technical ecosystem diversification was a wonder & has let us explore & find so many great ways of doing things, but: Babel fell. A fairly unified culture became many. Tru polylingualism & polysystemism, being an Ur programmer, is much wiser a journey today, and that isolation has hurt & encumbered the view of most developers, has kept them from seeing a wider scene. Chained to the wall, being very industrially productive at marionette play.
And then the worst hit. The great ossification & stalen-ing of computing as a thing in the world. The dematerialization of computing the massification. Most computing floated up to a place where no one can see or learn or experience what is happening, has left the box, effervesced into the cloud. No one can touch computing today, there's no mortal computing, no personal computing left. Intelligent sharp computing offerings like Yahoo Pipes and IFTTT disappear & shrink. The output of the industry has gotten more and more uninteresting, less and less expert, less and less exposing of computing; endless appification, consumerizatio. How is anyone going to fall in love with & properly obsess-like they ought-over a world of black boxes?
Eventually we'll reawaken to cool human computing. Stop using computing only as a means to an end & start caring about the medium itself. And beget new cultures of truly epic hackers. It won't even look too too different from today I'd guess, it'll be built on the Titanous skeleton of open source. But it'll also have access & packages in to the beast, not merely be riding atop it's shoulders.
* Simple use of concurrency is simple to use, easy to get right and very useful. Like WaitGroups.
* Go was written partly to solve the issues that Google had with C++. Dependency trees that grew too large too quickly was one of these issues. It may be annoying tha Go disallows unused imports, but it helps to keep the dependencies under control.
* Go is a simple language with fewer keywords than C. It is easy to parse and the build times are excellent, even for larger projects. Short build times is not only nice to have, but it changes how developers iterate and work with code, in a good way.
* Arena allocators can be used, and the (unusually efficient and fast) garbage collector can be paused. Unwanted garbage collection can be avoided.
* The tooling is excellent: cross compilation, profiling, tracing, testing, code formatti g, benchmarking, dependency managment and even fuzzing are all built in and available by default.
* The Go, GCCGO and TinyGo compilers are available. GCCGO can produce smaller executables and TinyGo targets embedded systems.
* You can (mostly) read source code just by looking at a single source file at a time. Errors are handled at the spot or returned, not catched elsewhere. Interfaces are used sparingly. There are structs instead of classes and they are not inherited.
* The main question in Java is "what IS it really?" while in Go it is "what does it really DO?". This is often a worse question for simulators, but a better question for getting things done.
* Rust is correct and nice, but may provide friction while programming, because it is strict. Go provides more friction than Python, but less than Rust, because it is less strict. For better and for worse. For anyone that think Rust is too strict compared to the benefits that Rust gives, Go may be a better choice.
* Go is a goos fit for servers. Look at the most starred Go projects on GitHub.
* Go has minimalistic origins.
I really like Go. I just wish it had an "in" keyword like Python does, and the ability to mark regions of code to have Rust-like strictness.