Where have all the hackers gone?

Have other people observed the sentiment the author observes, around hackers being less common?<p>The author has a list of reasons (VC money, business culture, managers, fear of the unknown).<p>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.<p>I think the reason, plain and simple, is that most developers aren&#x27;t really in it for the passion anymore, but rather the money.<p>When I first started coding, I didn&#x27;t get paid. I didn&#x27;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.<p>However, as the idea of &quot;programming makes money&quot; 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 &quot;huh, how does the bootloader actually work&quot; or &quot;Why did chrome just crash, let me open up gdb...&quot;.<p>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 &quot;I want a paycheck&quot;) are getting older. They&#x27;re getting older, having kids, and now also have a reason to treat their job as a 9-5. &quot;Chrome crashed, I could open gdb and figure it out... but I&#x27;d rather watch my kid&#x27;s soccer game&quot;.<p>I think new hackers still form, but they&#x27;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.

I think the author of this article grossly misunderstood the purpose of his interaction which lead to this article.<p>You aren&#x27;t architecting a new programming language, man, you&#x27;re talking to a guy about computers because you&#x27;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.

My take is simply that programming has gotten way bigger. People seem to think that in the “old days”, programmers ate raw potatoes and programmed in assembly because it put hairs on their chest. The reality is, computers were way simpler objects back then. Assembler on the Intel 4004 has like, 30 opcodes or something. The list fits on your phone screen without scrolling. Modern javascript bundlers pull in more code than entire operating systems back then. C only has about 20 keywords. If you know assembler, you can probably learn K&amp;R C in a weekend if you go hard. Modern C++? Forget it. Apparently the spec just for c++ initialisers is 300 pages long.<p>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 <i>only</i> know web programming. That knowledge doesn’t really translate to operating systems work, mobile development, databases, AI, embedded, etc.<p>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 &#x2F; 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?<p>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.

Alright. Lets say in any group of people you have a normal distribution of people caring about the thing you care about. On the left, people dont care at all. On the right people think its the most important thing on the planet.<p>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”.

Sorry if this is off-topic but I often see in HN (either in articles posted here, or in the comments) lack of empathy.<p>He talks about a &quot;friend&quot; and then proceeds to say things like &quot;To be honest, I suspect he didn&#x27;t know or think much about them&quot; or &quot;This was not a fruitful conversation&quot;.<p>How is that supposed friend, who might very well be aware of this person&#x27;s blog, going to feel after reading this? Is it a cultural thing and this is not offensive everywhere?<p>The irony is that the main page says &quot;I ♥ people; look for ways to make them happy, and empower them.&quot;

Just to set the context: I like Golang as a language, but I think writing a program that&#x27;s more than ~10k lines of code in Golang is a mistake (honestly, the limit is probably a lot lower), and I also don&#x27;t think they should&#x27;ve added generics, just leave the language as useful as it is.<p>Anyway, I think the author missed the point a bit with his friends argument about &quot;Go developers knew that all you need is a for loop&quot;. It&#x27;s not just an &quot;atmosphere &quot; argument. The programming language literally restricts you to using for loops. That&#x27;s a surface property of Golang (or maybe it used to be, haven&#x27;t used it in a couple years).<p>Golang has been designed to have a minimal and thus very <i>smooth</i> surface. Those issues the author mentioned about Python, that&#x27;s rough surface.<p>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.<p>Not sure if it&#x27;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&#x27;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).

Maybe I’ve just fallen out of love with the nitty gritty of programming but this blogger sounds insufferable. If I’m wearing a duck duck go shirt and someone comes up and wants to talk about how DDG uses&#x2F;used bing I’m not going to engage in this conversation. Who the fuck wants to talk about the Golang GC just because you have a Golang shirt on? Also, how condescending to assume the person doesn’t think about it at all. This sort of monologue is gross and the writer is an asshole.

This is the specific spot my suspension of disbelief broke:<p>&gt; innovation tokens are completely made up, it&#x27;s like talking about the finite number of &quot;love tokens&quot; you can give your spouse in a given year.<p>You can&#x27;t complain that &quot;&#x27;atmosphere&#x27; questions are extremely based in feelings&quot; and then just get high on feelings like this.<p>The amount of &quot;love tokens&quot; 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.<p>Hackers didn&#x27;t go anywhere. The solution to the puzzle is that hacking is an ethos not generally suited to creating profitable businesses. However, we&#x27;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&#x27;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.<p>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&#x27;s &quot;play&quot;, I say: hooray! Play at home. Play in disposable playpens. Production is for shit that works.

It is hard to fathom such a pretentious blog post. What response the author was hoping for when he created it? Good grief.

So the article seems to imply that &quot;hackers&quot; are the sort of people that look at a partially working system and say: &quot;hmm let&#x27;s re-write that in a new and untested language&quot; or worse still &quot;lets write this in language x because I&#x27;ve always wanted to try it&quot;<p>if thats the case, then I formally suggest that such people can get in the sea.<p>I might be somewhat unfair, but that was my reading.<p>&gt; innovation tokens are completely made up<p>So are programming languages.<p>Innovation tokens are there to make sure that a business can complete a project vaguely on time and vaguely on budget.<p>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.<p>I mean sure, writing your own database for your SaaS company might be a thing, but its almost certainly expensive and pointless. You&#x27;re on the hook for scaling it, recovering it when it fails, and finding and fixing all the bugs.<p>In short, this article, I feel, encourages a damaging, selfish side of CS that I think should be phased out.

Another reason is that being a fan of less popular tech is heavily punishing to career and job hunting. Hell, it&#x27;s quite a challenge to find a job even in React&#x2F;JavaScript (took me a good month or even a bit more last time, and I&#x27;m a senior dev), and it would be a nightmare for languages&#x2F;ecosystems like Haskell or Rust. I wouldn&#x27;t even want to find another JS job because I don&#x27;t want to go through a month of such struggle again, and if I were a Haskell dev I would be afraid to lose that job like I will die if I do. Nowadays, I don&#x27;t even want to touch stuff like that simply because it would be unhealthy for me to become interested in tech that makes my life so much harder and stressful. I would probably think about it only if companies started sending me positions with better-than-senior-React rates themselves proposing to pay me for learning their required stack on the go.

<i>&gt; Today, we&#x27;re afraid to do anything that&#x27;s not JavaScript, Java, Python, or Ruby. I have a feeling 10 years from now it&#x27;ll just be JS. We all read that excellent McKinley article about &quot;innovation tokens&quot; and we decided to be floor-avoiders instead of ceiling-breakers. Engineering leaders lead from a place of fear and risk-aversion instead of optimism and believing in their team. Where have all the c̶o̶w̶b̶o̶y̶s̶ hackers gone?</i><p>I think this reflects a larger cultural trend of fear, pessimism, and scarcity.<p>When we have spare capacity and a belief that we&#x27;ll have spare capacity in the future, it&#x27;s psychologically much easier to take risks, be whimsical, try things, explore, and give the benefit of the doubt.<p>When times are lean, the natural human response is to hunker down, hoard what we have, hustle, and do our best to survive.<p>It&#x27;s just not a great time in the world right now.

This is like every possible language war trope stitched together into a narrative.

I like the spirit of the soil&#x2F;surface&#x2F;atmosphere split but I think it’s a bit misleading to frame it as a way to talk about ‘languages’.<p>It feels like those things can be better framed as ‘runtime&#x2F;tooling’, ‘language&#x2F;libraries’ and ‘ecosystem’.<p>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.<p>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 <i>working in javascript</i> as a result. But I still consider myself an admirer of the core good ideas at the heart of the JavaScript language.<p>The surface matters a lot. You have to live there.

To be honest, it feels like engaging in a cultural war. I don’t want to liken this to any kind of mainstream cultural war, but instead liken it to the old tech cultural wars, like Emacs versus Vim or some shit like that.<p>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.<p>&gt; Infusion of traditional Business and Capital culture, which traditionally serves smoother-brains, the boring, and the unimaginative.<p>There’s an entire culture of people in tech who refuse, on some kind of principle, to understand or work with people in business &#x2F; capital &#x2F; management unless the people in business &#x2F; capital &#x2F; 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!<p>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.<p>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.<p>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 <i>observed</i> that people who speak the truth often piss people off, and then optimized for it. Goodhart’s Law and all that.

Making things easy is the problem. It&#x27;s been long known in secret societies, that guarding entry through a solvable but hard entry barrier makes it more rewarding for those who do make it through and the ones already inside. In programming, we have tried to make everything easy: JavaScript everywhere. Electron everywhere. Slow code everywhere. No need to think about memory of cpu cycles at all. The result is piles of crap like Microsoft products and Slack and hackers are the minority.

&gt; Languages with proper concurrency like JVM, BEAM, or Go don&#x27;t require Sidekiq or Celery queues<p>This author needs to understand with web&#x2F;api programming, even using JVM, Go, etc still require Celery&#x2F;Sidekiq&#x2F;WakaQ for siloing. You don&#x27;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.

They&#x27;re busy building stuff without blogging about it. It&#x27;s tough to assess a change in culture when your heuristics are limited by selection bias favoring loud contributors over productive builders. That&#x27;s not to say there aren&#x27;t great hackers who blog; but there are certainly bloggers who are bad hackers, and by definition they&#x27;re more immediately visible than great hackers who don&#x27;t blog.<p>I&#x27;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&#x27;t need to get noticed to create value. Same goes for any builder culture.<p>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&#x27;ll see that hacker culture is alive and well. Indeed, it&#x27;s thriving.

&gt; Where have all the hackers gone?<p>To a newspeak school to unlearn precise terminology.<p>So to translate OP, &quot;soil, surface, and atmosphere&quot; apparently refer to <i>semantics</i>, <i>syntax</i>, and <i>runtime</i>.<p>(&quot;Pedantic&quot; is a favored word these days. In my days, objections to those who actually knew something about CS was that they are &quot;academic&quot;, and &quot;theoretical&quot;.)

Right now on the front page is a post about where to see Hokusai&#x27;s Great Wave today (<a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=35985221" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=35985221</a>) or Why is my dryer radioactive (<a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=35990858#35992719" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=35990858#35992719</a>).<p>They may not hold up to morepablo&#x27;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&#x27;d be <i>so</i> embarrassed. Definitely wouldn&#x27;t plaster it all over the Internet on my blog where I &quot;look for ways to... empower [people]&quot;), but it sure looks like the hacker spirit to me.

<i>Foundations</i> are often missing: <i>semantics</i>. This is the dividing line, I find, between <i>practitioners</i> and <i>researchers</i>. Like most dichotomies there is some bleed over between the two groups: I consider myself a practitioner but I tend to think in terms of semantics and try to keep up with the research. I know of many researchers who dabble in practice and build things with the fruits of their labours.<p>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&#x27;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.

Hackers hack on all levels of abstraction. Defining &quot;hacker&quot; around the level of programming languages seems silly. Hardware hackers could have said the same thing about the author.

It&#x27;s interesting reading stuff like this. I think the author is missing a perspective that all the programming languages that he&#x27;s listed are old and have stacks of features that were introduced because of feelpinions, fashion and sometimes function.<p>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.

Maybe they went to Shenzhen, after the US electronics manufacturing industry left the country in search of cheap labor and higher profits? Of course this is mostly hardware hacking:<p><a href="https:&#x2F;&#x2F;www.thatsmags.com&#x2F;shenzhen&#x2F;post&#x2F;8620&#x2F;touring-the-hardware-hacker-hangouts-of-shenzhen" rel="nofollow">https:&#x2F;&#x2F;www.thatsmags.com&#x2F;shenzhen&#x2F;post&#x2F;8620&#x2F;touring-the-har...</a><p>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).<p>Note here &#x27;hacking&#x27; means using features of systems that aren&#x27;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.<p>A better title might have been, where have all the experimental risk-takers gone? (A: most of them were eaten by the Borg).

I like the author&#x27;s division of the issues into soil, surface, and atmosphere. I&#x27;ve definitely made project choices on all three.<p>Ruby is not great, not terrible. I enjoyed learning the language. I didn&#x27;t find much in its runtime or its constructs to recommend it over Python. But I haven&#x27;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 <i>Ruby on Rails</i> had changed so much that my project wouldn&#x27;t build; every dependency had gone through a major revision and Rails&#x27; 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 &quot;the adults were not (yet) in charge.&quot;<p>Contrast C++. One of the most supported languages on the planet; adequate performance for my needs. I can&#x27;t stand the constructs in the language itself. The templating system couples <i>badly</i> with other language features and they &quot;fixed&quot; it by cutting firebreaks in the parse process via newly-required keywords and template parse rules (all taxonomies are broken, and there&#x27;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&#x27;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.

Pretentiousness and fluff of the post aside, there are some interesting points, like: businesses just want to be riskless rent collectors, so they do Whatever Other Businesses are Doing, which is a major contributor to the decline of this &quot;hacker culture&quot;; there&#x27;s also this &quot;neutering&quot; aspect of today&#x27;s conversations in your typical corporate environment, where you are only allowed to be &quot;polite&quot;, &quot;positive&quot;, and &quot;constructive&quot;, even if the subject is barely worth talking about at all.<p>Oh, and the thing about Authoritative Calm Professional Voice is spot-on.<p>The opening, I&#x27;ll concede, is fluff that could have been edited out, but there it is.<p>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 &quot;team&quot; or a &quot;community&quot;, 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.

Language discussions are unpleasent and waste of time<p>Ive seen like hundreds of discussions like that<p>Java vs c# vs rust vs go vs kotlin<p>It is always heavy of emotions, unverified claims (performance especially)<p>and dependent on what stuff do you value.<p>This kind of discussion requires wide knowledge, hands on experience, curiosity and open mindness.<p>All of those 4 are really desirable itself, so together even more and are really rare!<p>&gt;I prefer to work with an excellent software engineer, who doesn&#x27;t tie their identity to a specific language or technology (e.g. would prefer a great hacker than someone who identifies as a &quot;Ruby developer&quot; or &quot;JS developer.&quot;)<p>Why it matters to you how somebody calls himself?<p>Is this &quot;single lang programmer&quot; insult variation?<p>Especially when you are aware that concepts are above languages<p>&gt;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&#x27;s not just syntax, it&#x27;s soil and atmosphere: common bug flows and how to spot them, footguns, tooling,<p>Agree!<p>Many people do not get it, they are always like &quot;you can learn langs after your first within a month&quot; or so<p>&gt;Functional programmers insisted without evidence that their programs were More Correct.<p>Hah

This is an annoying, pretentious article. You don’t need to know all of the intricate internals of a language and its runtime to appreciate its features. Similarly, you don’t need to learn all of the frameworks in the TypeScript ecosystem to be productive in TypeScript. So clearly there’s a disconnect between what the author wishes programming would be and the reality of programming.

Not the purpose of the article but as I am a bit negative on Ruby, and I am neutral to positive on Java...<p>&quot;Ruby is so much better than Java! Look at how you open a file in Java (shows you 30 lines) vs. Ruby! (2 lines)&quot;<p>Ruby Example.<p>================<p><pre><code> begin File.open(&quot;&#x2F;path&#x2F;to&#x2F;your&#x2F;file.txt&quot;, &quot;r&quot;) do |file| file.each_line do |line| puts line end end rescue Errno::ENOENT puts &quot;File not found&quot; rescue Exception =&gt; e puts &quot;An error occurred: #{e.message}&quot; end </code></pre> Java Example, one line less than Ruby ( no imports shown but could also be required for external Gems )<p>================<p><pre><code> public class Main { public static void main(String[] args) { String filePath = &quot;&#x2F;path&#x2F;to&#x2F;your&#x2F;file.txt&quot;; try (Stream&lt;String&gt; lines = Files.lines(Paths.get(filePath))) { lines.forEach(System.out::println); } catch (IOException e) { e.printStackTrace(); } } }</code></pre>

&gt; Elm and Clojure both have something like &quot;if Evan&#x2F;Rich didn&#x27;t think you should have that thing you wanted, have you considered that maybe you&#x27;re wrong? &quot;<p>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&#x27;t think you should have that thing you wanted, build it yourself.

While I think his terms “Soil” “surface” and “atmosphere” are kinda cute, I don’t understand the need. Each of these already has a very clear established term.<p>“Soil” = Implementation “Surface” = Language&#x2F;Syntax “Atmosphere” = Community<p>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.

It seems the author is lamenting that most people are no longer interested in their preferred level of abstraction, and have instead focused on higher abstraction levels that are less interesting to them. Which is fine, it just means they haven&#x27;t found &quot;their people&quot; yet.<p>The few meetups I go to, I&#x27;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&#x27;s some selection bias.<p>In terms of language-level specifics, I will say that in 12 years of experience I have rarely ran into a problem where &quot;soil&quot;-level properties of a language actually made a difference. I&#x27;m not building systems-level stuff or libraries, I&#x27;m building apps and services for businesses, where IMO the surface or atmosphere-level issues are more important. It doesn&#x27;t matter that Python is 1000x &quot;slower&quot; than some other language, up to a certain scale. It matters more that I have access to Python&#x27;s ecosystem, or there are specifics in how a python app is structured that I just happen to prefer because I&#x27;m comfortable with it. This is just an example.<p>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.<p>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 &quot;hacker&quot; in. So why do &quot;innovation tokens&quot; need to be spent on the language runtime?

This is not a period of invention. Its a period of cookie-cutter, step-by-step colonization by imitation of more and more domains (both consumer and enterprise) using well-established (even if mostly questionable) patterns.<p>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.<p>The disappearance of hackers is also congruent with the locked and supervised platformization of &quot;big tech&quot;. You can&#x27;t really hack devices. The motto is: &quot;Here is the browser, here is the API, now go play, consume your cloud budget and give us some ideas how to make money&quot;. 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.<p>Of course today we have more <i>latent</i> 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:<p>* the massive expansion of <i>self-hosting</i> and shift to having serious compute and intelligence &quot;at home&quot;. This is the broader fediverse or small tech movement<p>* the liberation of <i>mobile devices</i> and next-gen apps that might finally redeem the &quot;supercomputer in our pockets&quot;. A related domain is non-smartphone mobile devices.<p>* the re-incarnation of the <i>workstation</i> concept in business context. Monstrous linux desktops that finally put the moribund &quot;Productivity Suite&quot; to rest and offer various completely new businesses launchpads to the next phase of the digital economy<p>Hackers currently have been either co-opted or starved to death by the lack of opportunity. Yet the cycle never finishes.

&gt; Engineering leaders lead from a place of fear and risk-aversion instead of optimism and believing in their team.<p>Yeah exactly. You&#x27;re barking up the wrong tree. If you want to see optimism, go to a startup. The hackers aren&#x27;t going to work for you at one of the big tech companies no matter how great you think that place still is.

I&#x27;d qualify as one (not one of the &quot;break into places types&quot;) but I hack around software and hardware. I&#x27;d engage with the world more if I knew where my next meal was coming from - and if having that meal would still allow some freedom to &quot;hack&quot;. I think one of the reasons a lot of the &quot;hackers&quot; existed mostly in the past is these people never had to worry about where their next meal was coming from, even if they had other fears and worries (<i>cough</i> cold war <i>cough</i>).<p>Power and privilege would be important keywords here.

His comment regarding preemptive vs cooperative scheduling, so which is it? Does Go have preemptive scheduling or not? I was under the impression that it did get that somewhat recently? Could anyone point me in the right direction?

&gt; Today, we&#x27;re afraid to do anything that&#x27;s not JavaScript, Java, Python, or Ruby…Where have all the c̶o̶w̶b̶o̶y̶s̶ hackers gone?<p>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.<p>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.

Pablo, turning the question towards you, what would you have liked to know about Elixir up-front before using it to build an authorization server at Ramp? Let&#x27;s get an honest take.

Better title for this would be &quot;Where have all the language nerds gone from my personal circle of friends?&quot;<p>There are lots of hackers out there, but we&#x27;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 &quot;non-hacker&quot; because I prioritized readability over fancy language features like a novel garbage collectors. Gosh.

&gt; he didn&#x27;t want to talk about any of that. To be honest, I suspect he didn&#x27;t know or think much about them<p>Or, alternatively, you went all &quot;This guy likes Go. I must explain to him why he&#x27;s wrong, so that he stops thinking wrong&quot;.<p>This whole article just makes me think &quot;yeah, I wouldn&#x27;t want to talk to <i>you</i> about that, either&quot;. And it&#x27;s not because I don&#x27;t know what he means, or necessarily even disagree with his conclusion on Go.

Suggested edit: &quot;The song for this post is YAKETY SAX&quot;

&gt; Most developers have major gaps in their understandings of the tools they use. This is fine. [...] Many people across the 7 companies I&#x27;ve worked for are best described as &quot;adequate.&quot;<p>Okay so, according to the author, then it&#x27;s not fine...<p>How do we fix this? Is it every employee&#x27;s fault that they don&#x27;t know the nuts and bolts of the things they work with, or is it the company&#x27;s fault for not providing the right training?

The tools that people learn on (mac books, IDE and so on) are far more polished today than they used to be, and they don&#x27;t require or invite learners to &quot;look beneath&quot;. Frameworks are even marketed to developers a bit like fashion items with web sites that look like magazine covers.<p>There isn&#x27;t much to get people started on the hacker-path - it&#x27;s presented to them as atmosphere.

The risk aversion is a fact of life (and sad).<p>&gt; Is it hard to learn a language?…<p>Amazingly, no. My language ( <a href="https:&#x2F;&#x2F;www.adama-platform.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.adama-platform.com&#x2F;</a> ) recently had a 19 year old build a game with it. Does my language have expert documentation? Not really, but it has just enough.<p>Hackers still exist, but finding them at bigger companies is rarer.

A lot of my colleagues are software engineers just because it pays. They are barely enthusiastic and have surface level knowledge.

The pioneers and the people who start doing something later, when it’s safe, are not the same people.

A developer with a hacker mindset is different from a hacker.<p>Hacker means to use tricks to &quot;hack&quot;, to &quot;break&quot;, or to &quot;reverse engineer&quot; a system. It&#x27;s very specific, very concrete job to do.<p>A hacker mindset means creative, innvative for the goal of automation instead.

Lovely article -- very original.<p>I&#x27;ll add some anecdata, to give more context on why &quot;atmosphere at all costs&quot; might be en vogue.<p>- Most software engineering is CRUD<p>- Almost all 3rd generation, higher level languages can achieve CRUD (e.g. Javascript, C#, Java, Python, Ruby, PHP, Python, Perl -- even Bash)<p>- 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)<p>- Without needing to know the internals of a language, all the aforementioned languages are largely interchangeable (again, for CRUD -- and based on taste)<p>This is why you may commonly see people recommending that even if you don&#x27;t know a language, you should be able to pick up whatever language a potential engagement requires (see: &quot;a senior should be able to pick up frameworks and languages within a week or two&quot;). I&#x27;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.<p>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 &quot;generalist.&quot; Likewise, you&#x27;ll be able to tell when it&#x27;s the tool that&#x27;s messing up, or yourself. Further, you&#x27;ll be able to find more interesting, &quot;deeper&quot; work to handle -- rather than just building another CRUD web app. And lastly, life is too short to work with stuff you don&#x27;t like.<p>For example, I love the .NET ecosystem. If I want to build something that isn&#x27;t in the HPC space, I&#x27;ll reach for it first. I know Java, but I don&#x27;t <i>like</i> Java -- and I do not ever want to work with it. My ability to land .NET work is much easier, because I <i>know</i> the ecosystem -- not just how to program in an OOP language.<p>Or how about databases? I love Postgres. If I want a great OLTP DB, without any fuss, I&#x27;ll reach for it first. I know MySQL&#x2F;Mongo&#x2F;SQL Server (to be fair, this one is also really good)&#x2F;etc., but I don&#x27;t <i>like</i> most of them. My ability to land work that utilizes Postgres is much easier, because I&#x27;ve taken the time to thoroughly understand it.<p>Or in other words, most people in the game are optimizing for commerce: how much money they make.<p>The hackers? They&#x27;re in lower-level, systems programming languages; they&#x27;re in compiler and language design; they&#x27;re in low-latency or kernel programming; they&#x27;re in stuff that isn&#x27;t directly related to making money. Part of the reason I&#x27;m learning C++ is because the work there is more interesting (database engineering is <i>very</i> 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.

Two answers:<p>(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.<p>(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 <i>that</i> 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.<p>[1] <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Chinglish" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Chinglish</a><p>[2] <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Pong" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Pong</a><p>[3] <a href="https:&#x2F;&#x2F;ciechanow.ski&#x2F;" rel="nofollow">https:&#x2F;&#x2F;ciechanow.ski&#x2F;</a><p>[4] <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=ip641WmY4pA">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=ip641WmY4pA</a><p>[5] <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=3PwAQZNLy0I">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=3PwAQZNLy0I</a>

I blame the software methodologies for this. And the dogmatic LoC per reported hour. Imagine a hacker saying: i need 5 story points to figure out for the REST API how the bootloader works.

maybe its because the article yesterday, 80% of jobs are gotten through networking, and if the rest are from leetcode interviews.. you kind of have decided to select against diversity.

Where startups and tech intersect, there should be a tech risk budget:<p>Where the business is boring, try new things.<p>Where things are untested and critical, use reliable components.

I would argue that the hackers haven&#x27;t gone away as much as they&#x27;ve completely been outnumbered by the non hackers.

C is making a big comeback. More and more people are waking up to what utter garbage the modern frameworks and languages are.

All the hackers I know right now are dabbling heavily with AI since that&#x27;s the new hot thing

What upset me is that tooling seem to be more important then solving the problem.

Not here for sure. here is more like technews than hackernews.

You&#x27;re just laying bricks, how you lay bricks was decided long ago.

Technology became easier to be a consumer, so creation skills were lost.

Of those I have been in contact with lately most have gone away from public spaces in general because we are sick of being distracted from hacking by screaming holy warriors, bad-faith assholes shitting on everyone to make themselves feel better, and the gradually worsening infiltration of commercially-sponsored misinformation.

People who were inspired by the movie are all in their 40s now.

I am here! -waves-hand-

Patent trolls?

The challenge of becoming a well-traveled technically-adept Renaissance man is much harder than it used to be. People say this is an incursion of more people just looking for a solid job, that we have less-engaged less-hackerly people, but ideally that wider funnel would also grant a much wider amount of people access to this incredibly compelling interesting field; I&#x27;d hope we&#x27;d still see a flourishing of hackerness. Alas.<p>The workforce tends to be employed at much larger organizations. This creates very narrowly focused teams, isolated to very different areas of product &amp; 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 &amp; arch questions here aplenty).<p>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, &amp; selling them to their more profitable peers &amp; established businesses. Now the scale &amp; industrialization inhibits the conditions of creativity that begat such a rise.<p>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.<p>The cost of technical diversity is being felt. We had such an explosion of open source means &amp; ways, became so powerful. And that has diluted the intelligibility of systems, has a huge isolating effect. Rather than most folks using C&#x2F;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 &amp; just a genius productive whiz, <i>your skills might not port</i>. The fundamentals became diluted, and people specialized higher. Technical ecosystem diversification was a wonder &amp; has let us explore &amp; find so many great ways of doing things, but: Babel fell. A fairly unified culture became many. Tru polylingualism &amp; polysystemism, being an Ur programmer, is much wiser a journey today, and that isolation has hurt &amp; 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.<p>And then the worst hit. The great ossification &amp; 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&#x27;s no mortal computing, no personal computing left. Intelligent sharp computing offerings like Yahoo Pipes and IFTTT disappear &amp; 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 &amp; properly obsess-like they ought-over a world of black boxes?<p>Eventually we&#x27;ll reawaken to cool human computing. Stop using computing only as a means to an end &amp; start caring about the medium itself. And beget new cultures of truly epic hackers. It won&#x27;t even look too too different from today I&#x27;d guess, it&#x27;ll be built on the Titanous skeleton of open source. But it&#x27;ll also have access &amp; packages in to the beast, not merely be riding atop it&#x27;s shoulders.

Russia?

I feel like many developers completely misses the point(s) of Go. It is not perfect, but it has a few nice properties:<p>* Simple use of concurrency is simple to use, easy to get right and very useful. Like WaitGroups.<p>* 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.<p>* 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.<p>* Arena allocators can be used, and the (unusually efficient and fast) garbage collector can be paused. Unwanted garbage collection can be avoided.<p>* 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.<p>* The Go, GCCGO and TinyGo compilers are available. GCCGO can produce smaller executables and TinyGo targets embedded systems.<p>* 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.<p>* The main question in Java is &quot;what IS it really?&quot; while in Go it is &quot;what does it really DO?&quot;. This is often a worse question for simulators, but a better question for getting things done.<p>* 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.<p>* Go is a goos fit for servers. Look at the most starred Go projects on GitHub.<p>* Go has minimalistic origins.<p>I really like Go. I just wish it had an &quot;in&quot; keyword like Python does, and the ability to mark regions of code to have Rust-like strictness.