Hacker News new | past | comments | ask | show | jobs | submit login
We at $Famous_company switched to $Hyped_technology (saagarjha.com)
1224 points by gok on May 11, 2020 | hide | past | favorite | 200 comments

Nice, I laughed out loud when I read these two paragraphs:

> Initially, we tried messing with some garbage collector parameters we didn’t really understand, but to our surprise that didn’t magically solve our problems so instead we disabled garbage collection altogether. This increased our memory usage, but our automatic on-demand scaler handled this for us, as the graph below shows

> Today we are making some of the code that we can afford to open source available on our GitHub page. It is useless by itself and is heavily tied to our infrastructure, but you can star it to make us seem more relevant.

Actually, I think this was meant as a reference to Twitch's experiences with the Go garbage collector:


The Discord Go to Rust seems quite sensible engineering.

Sensible? I guess when you dig yourself into a hole, wanting to move to a shallower hole seems sensible. It showed that they understood neither their requirements nor their chosen tools, not surprising given that their stack is Elixir, Go and Rust, languages that there aren't too many experts for, and such consistent choices are a clear display of inexperience. There's just no way that technical sensibility is a chief concern of a company that goes from Elixir to Go to Rust within a few years.

If they had started with a runtime with better GCs or chosen, say, C/C++ from the beginning, none of this would have been necessary. They clearly choose hype first and everything else second. If that's their technical evaluation process, they are likely to choose wrong the first time, the second time, the third time, and however many times they need to rethink their choices, and every time their rationale would seem sensible when it becomes clear that their previous, ill-advised, choice is wrong, and before their new, untested choice shows its own problems. Making a bad choice and then wishing to fix it by making another using the same process that's led to the first doesn't inspire confidence.

Yes, if they used C/C++ from the beginning, they wouldn't have run into GC issues, but they would run into another whole set of issues exclusive to C/C++ (free-after-use, buffer overflows, annoying threading bugs, etc.)

Just like they've run into issues with Elixir and are going to run into plenty of serious issues with Rust. The belief that your chosen language/runtime does not have some very serious issues is the mark of inexperience. The only thing you can do is know what they are and what you can live with. Choosing a hyped language makes the first part very hard; their history shows that they consistently fail on the second part, too. It looks like it's a very inexperienced team, which tech has plenty of, but turning their blunders into success stories is precisely the kind of amateurism dressed in bluster that this post is rightly ridiculing.

There's an argument that it's good to avoid premature optimization - build your thing with something easy like rails or elixir and then if you run into performance issues rewrite those bits in something faster.

It's not about premature optimization. They clearly didn't know enough about Go when they decided to use it -- partly because few people do, but they did know that -- and they clearly don't know enough about Rust, either. They're stumbling from one hype to another based on sales brochures and bragging about it.

Again, Tech is full of such low-experience teams writing this kind of unimportant software and rewriting it every couple of years, and I guess it's good that someone volunteers as a lab rat for new languages (even if they do it over and over). But they're so inexperienced that they can't even see they're being snooty about their ignorance of their own requirements and tech.

> free-after-use

I wish ;)

Oops, meant to say "use-after-free"

Elixir could be argued as almost-sensible if they made the typical chat product backend decision to bolt some features onto ejabberd and pretend like they're hot shit at designing distributed servers. Though I would still stick with vanilla erlang because if you use elixir without also knowing erlang, you'll find yourself up shit creek without a paddle eventually. But a halfhearted google doesn't even confirm that they built on ejabberd.

I work for twitch and I've seen that article before and it doesn't seem to fit the pattern of we messed with GC and it didn't fix out problem. The solution in the article uses weird features and behaviors of the golang GC and how VMs allocate memory but it did work very well for them.

Can you please remove the channel points button for me? Thanks

See also Hotmail when they started migrating it to Microsoft tech.

The servers were stable for a day or two, so they cooked up a reaper process that would sequentially reboot every machine in the cluster, wait for it to start routing traffic, then reboot the next one. Every machine got at least one reboot a day from this.

The moral authority with which I used to share that anecdote has eroded quite a bit in the years of Continuous Deployment. Most of my endpoints reboot at least once a week, except for holidays where we occasionally discover longevity bugs. With autoscaling some instances will be up for hours at a time (and if we are not very careful we'll completely pollute our server statistics).

One advantage of CGI is that the worker process terminates, and all the resources get freed.

Not that I recommend CGI for anything but very low usage sites, typically internal ones with a fixed user base.

Not to worry. We'll cloud-enable fastcgi and call it Serverless.

eBay did the scheduled reboot thing around 2000, but on a massive scale.

Their front-end servers were Windows ISAPI, and leaked memory like a sieve. So there was a documented process for rebooting groups of servers with a diagram dividing the front-end servers into rebootable clusters and the time between reboot intervals.

And yes, docker/k8s sure reminds me of those days when reviewing logs today and seeing some pods with unexplained non-zero restart counts.

Source: worked there, read the documentation.

Yes, but the Python garbage collector is only needed to handle cyclic references. Objects whose reference count drops to zero are still freed even with GC turned off. So AWS didn't make a mint from the experiment.

I would also expect Instagram to be on Facebook's infrastructure these days ;)

I'm sure the cost of getting all of the devs to write Python that safely runs without GC is far les than 10% of your AWS bill for Python services... Maybe at Instagram it is, but it won't be at 99% of companies.

It isn't like most Python devs you interview are going to have any kind of a reasonable answer for "How would you write XYZ - with the GC disabled?" I'd bet the ones with a good answer cost >10% more on average.

Right. The article describes them saving resources in the end from it, but I guess that was too reasonable for satire.

So swift using reference counting instead of a GC was BS marketing where the python approach (using both where it make sense) is a precedent and a superior solution?

FWIW, there's actually a CPython patch from Instagram [0] that proposes "Immortal Instances" (and I understand that YouTube had their own set of patches for "Eternal Refcounts") which aims to alleviate some of those issues and reduce Copy-on-Writes.

[0] https://bugs.python.org/issue40255

> Fun fact: As our spreadsheet met strong statistical guarantees of randomness, we were able to reuse it to replace our application’s CSPRNG.

Made my day.

My favorite

> Tomorrow we will try to understand our $43,398,207.34 bill for April's AWS usage.

And after understanding it, nobody will be dumb enough to volunteer to delete a third of the billed resources.

They will just have a program do the deletion randomly and call it chaos engineering.

There has to be at least 6-7 good blog posts to come out of that, too.

That's an interesting idea!

Would work for EC2, not so well for resources you don't alert on like S3 buckets, etc.

Sigh, it looks like the title got a bit mangled…oh well. As most of the commenters have gathered, this was mostly tongue-in-cheek; I kept a window with a few of these kinds of posts open as I wrote so I could refer back to them so if you might be able to make out some familiar companies or technologies in there. That being said, I love hearing about your employer's technical decision making process, so I don't want to discourage anyone from writing blog posts like these. Just try to keep in mind that your decisions not be the right ones for everyone else. On the flip side, if you're looking to make technical decisions yourself, sometimes what $FAMOUS_COMPANY did is not the right choice for you :)

Nice one. I'll cast my vote for $AN_ENGINEER_TOOK_A_MYTHOLOGY_CLASS as "funniest bit."

Obviously at some point you're gonna have to do the companion/followup piece, "Why $FAMOUS_COMPANY Ditched $HYPED_TECHNOLOGY for $BORING_DEPENDABLE_TECHNOLOGY and What We Learned"

A fellow individual of taste, I see.

But honestly, I would really enjoy seeing more of the latter type of think-piece in all seriousness. I genuinely do believe that the field as a whole would benefit from a bias towards $BORING_DEPENDABLE_TECHNOLOGY and customer centricity.

Yeah I like those. Obviously it would be great if there were more of them during the early part of the hype cycle, when contrary viewpoints are hard to come by!

> Obviously at some point you're gonna have to do the companion/followup piece, "Why $FAMOUS_COMPANY Ditched $HYPED_TECHNOLOGY for $BORING_DEPENDABLE_TECHNOLOGY and What We Learned"


Saagar - I haven't laughed this hard in months. Thank you for writing this - the bit about "Medium article we found that had something to do with multi-armed bandits" got me on the floor. Laughing during this time feels so so good, and I didn't realize how much I needed that!

Stay safe!

You too! And wrt to $HYPED_TECHNOLOGY - we at $GIANT_CO originally created it to solve some challenges, as one of the primary authors I'm starting $PERCY_JACKSON_CHARACTER_CO that provides commercial support and some extra features (honestly - just RBAC with LDAP and some light UI).

We added SSO, please pay us $30k extra. Also, pay us another $30k to be hosted on our Enterprise SLA guarantees, which actually just runs on the same hardware as the rest of our customers, but hey, whatever, you've got money.

now do one for covid


This is genius-level satire. So much of it rings so true, from $FAMOUS_COMPANY to $NOT_SO_FAMOUS_COMPANY.

Some great writing here. Thank you so much.

beautifully written. and your first illustration sets a new high standard in visual design, i absolutely loved it.

> first illustration

This seems to be the original (or as close to it as I could find with a really quick search): https://www.reddit.com/r/pcmasterrace/comments/92er50/next_g...

I thought this was the original, but I can't find a real reference. https://i.imgur.com/HvPGd

Yeah the TF2 hats one feels like the original to me, I can't remember an older occurrence of this meme than this

Yes! That's definitely older. Thanks for finding it :)

It was surprisingly difficult! I thought for sure knowyourmeme would have a page on it, but if they do I sure couldn't find it.

Yeah, it's that one except with "MAKE MORE CORES", probably back from when Intel was doing better.

I can't believe anyone is still considering $HYPED_TECHNOLOGY in $CURRENT_YEAR. We at $NO_PROFIT_STARTUP gave it our best shot, but the bugs they mention aren't as small as they seem -- they completely sank the project. At this point it's clear that $HYPED_TECHNOLOGY is falling behind on both adoption and ergonomics to $TRENDY_TECHNOLOGY, which handles these issues in a much cleaner and more scalable way. We'd strongly suggest anyone considering $HYPED_TECHNOLOGY to take a closer look before following the advice in this post.

Right, and those cowboys at SFAMOUS_COMPANY obviously haven't read the latest blog posts that clearly show $HYPED_TECHNOLOGY doesn't support $HIPSTER_PARADIGM in an async I/O functional stackless copy on write environment, meaning $FLASHY_LANGUAGE can't be used with dependent types unless you don't mind your static analyser giving false positives every time you try to multiplex coroutines in your template meta-programming frameworks; what were they thinking?

You all have it so wrong! We should go back to $REALLY_BASIC_TECH that we already had in $HAPPIER_TIMES and clearly solves your $OBVIOUSLY_SIMPLE_USECASE.

Here's the place in Englebart's 1969 Mother of All Demos where $SUPPOSEDLY_NEW_TECH was first shown. You kids have done nothing for a generation.

I don't know why we are all still talking about $FANCY_FEATURE. [Lisp|Erlang|Smalltalk] have been doing this for years.

Look man, it's relevant because $ESOTERIC_LANGUAGE is much harder to hire for than $MUNDANE_LANGUAGE that is taught in most CS programs now. It's not like anyone with 4 years of post-High School education can learn anything. And we certainly wouldn't invest any time in teaching them anything. All of our graduates jump ship to $TRENDY_STARTUP after less than 2 years with us so they have no loyalty anyway.

If you've been following this industry long enough, you'd know that $REALLY_BASIC_TECH was introduced in $HAPPIER_TIMES to replace a solution that is conceptually very similar to $HYPED_TECHNOLOGY. If you wait long enough there will be a new spin on $REALLY_BASIC_TECH once the next cycle of computer hardware becomes ubiquitous.

Exactly! Everyone knows that $HYPED_TECH is just reinventing the wheel that $OLD_TECH already invented, and back in those days we were handling hundreds of $MULTIPLES of users a $TIME_UNIT on a single machine with only 64 ${SI_PREFIX}bytes of RAM over a dial-up connection.

I'm excited to see what will go on this page for this thread: http://n-gate.com/

are we seeing the start of true meta-forums ? Place where we don't talk about one subject, but just have generic conversation about ranges of topic in one conversation ?


Line 1 Position 28: "SFAMOUS_COMPANY" identified not known. Perhaps you meant $FAMOUS_COMPANY instead ?

I'm still waiting for an anime that adopts programmer-lingo for its mecha-fight scenes technobabble.

We hear you. We at $SOON_TO_BE_FAMOUS_COMPANY spent $N_YEARS developing our own version of $HYPED_TECHNOLOGY, because $HYPED_TECHNOLOGY didn't quite fit our use case in that we couldn't understand how to operate it well on our environment.

Look for our 25 part blog series at http://$SOON_TO_BE_FAMOUS_COMPANY.com/blog/#WEAREFUCKINGNINJ... on how to operate our version of $HYPED_TECHNOLOGY well on your environment.

Did you consider $EVEN_WORSE_HYPED_TECHNOLOGY? Based on a keyword match with some academic paper I didn't understand and my poor understanding of virtualization, containers, and latency, it could solve all your problems.

I cover this in my article titled "$HYPED_TECHNOLOGY considered harmful".

We burned through $HUGE_AMOUNT_OF_VC_MONEY before we realized this.

> Every metric that matters to us has increased substantially from the rewrite, and we even identified some that were no longer relevant to us, such as number of bugs, user frustration, and maintenance cost.

That has happened more than I'd like to admit: massive overhaul effort, $new_thing is an improvement in many ways but has all of the reliability and maturity problems of a new system that hasn't gotten years of patches. But the team feels like they have to show ROI on reinventing the wheel, so they massage the metrics to look like an unambiguous success, when everyone involved at the ground level knows it wasn't.

Put simply: There's more money and prestige to be had by lying.

I thought we weren't supposed to talk politics on HN these days!

It's ok if it's not about anything actually important.

No one wins awards and medals for battles that don't happen.

> We hope that you internalize our company’s anecdote as some sort of ground truth and show it to your company’s CTO so they too can consider redesigning their architecture like we have done.

The sad part is how often this is the case. Not just about technology choices, but everything else as well, HR, marketing, and so forth.

Someone reads something, usually very short - that's semi correct, but lacks a ton of context, and then it gets accepted as some sort of unquestionable truth.

Just as often I see an engineer or two that already wanted to redesign their architecture but needs an article like this to "inspire" managers.

Actually I have been payed a couple of times to produce such reports for higher management.

You know, pay a couple of work days at external consultant rates for getting the higher ups to sign a project.

Brutal. Should we just shut down the front page of HN now that it's been so perfectly parodied?

I think those "We are HN" 4chan posts were cream of the crop.

Example: https://rbt.asia/g/thread/41920845 / https://news.ycombinator.com/item?id=7745561

> I started 6 companies and they failed, here's what I learned. Obviously you should take my advice because they were "learning experiences" and it has nothing to do with the fact that I'm a retard

I'd forgotten about the whole polyphastic sleep fad. Everything else there has stuck around in some form, but polyphastic sleep totally vanished.

Oh, that one's just on a longer cycle. It's not just a HN thing; the entire Internet collectively rediscovers polyphasic sleep every five or ten years.

There was a Seinfeld episode where Kramer tries it, so... very roughly pre-internet

i wonder if this thread inspired today's post


Oof. Satire's not what it used to be.

The first 5 or 10 posts are 0/10 but eventually they get better

imageboard culture's progression summed up in two links. good god.

I love how many mentions to JS there are in that post from 2014.

I wonder which languages / frameworks folks would pick on if we were do to a new rendition

Still JS I guess.

There's something almost a bit unique about the combination of how problematic and how popular JS is.

Last time we had this combination (extremely popular, inferior design) was on the peak of PHPs popularity.

(And now I'm referring only to JS,the language, TS for example is actually nice.)

Rust :)

> Anonymous Wed 14 May 2014 19:58:13 No.41921096

> how Rust and Hack are changing the face of programming

It's in there.

I wasnt hn user then, I lol'd hard

Hey, there's some articles on the front page that don't fit this pattern...

"Page title" (wikipedia.com) 1 hour ago

And in the comments on those, you'll find people asking "why is this on HN?".

Sure, but the migratory patterns of Canada geese are just a little off-topic, don't you think?

looking it right now: where some >90 %?

Or maybe a black banner? $FAMOUS_COMPANY was just murdered.

You will like n-gate.com

This page really should just support get params in the url! Do you know how many people I could trick into believing this with ?FLASHY_LANGUAGE=rust&HYPED_TECHNOLOGY=kubernetes ??


I didn't make it very pretty, but it should work.

This is brilliant. It's shocking how well this works.

The blog post is CC BY-SA 4.0, so I wouldn't mind if someone made something that did that ;)


I have no idea how CC BY-SA 4.0 works exactly, is the line in the footer sufficient?

Anyway, you should be able to add any of the $variables in the text as GET parameters and it will spit them back out.

We at $CONTENT_FARM fell in love with this envsubst-as-a-service paradigm, and built our own with A/B testing. We then discovered we can apply it not only to our content but also to our bash codebase!

Now looking for funding to add evolutionary algorithms, combined with the best ideas from TRAC and m4, to make this a joy to maintain.

Nice! Technically, I think CC BY-SA requires mentioning the license but I'm not going to go after you personally for it ;)

I've added "licensed under CC BY-SA 4.0". If you want me to add anything else, I'd be happy to.

This, but as an SEO strategy.

I'm gonna bet that there are proxy-like services replacing words in web pages on the fly.

Sums up the last 2 companies I've worked for and they weren't even large companies reallly.

Re-writing our entire platform in Go from .Net (at both places) solved zero of the problems we had as there is nothing in language syntax that could fundamentally fix: priority churn, lack of dev skills, no testing on the most critical platform components(!).

IMO it made it worse because 2 weeks of PluralSight doesn't turn a .NET (or any other) dev into a high performing Golang dev. They just write .NET apps using Golang syntax - a common Golang refrain I hear. So if you thought they weren't great in uncool-language-xyz then just wait until they 'learn' Go.

That excerpt about your experience almost felt like a post mortem of my last job. The only differences are that we went from Typescript > Go, and had absolutely no time to stop and learn the language.

This made my day. Instantly reminded me of the MongoDB webscale video https://www.youtube.com/watch?v=b2F-DItXtZs

“Does /dev/null support sharding?”


“but as we seek to grow further it’s clear that a complete rewrite of our application is something which will somehow prevent us from losing two billion dollars a year on customer acquisition”


Used to work at a PaaS, which had a 17 year old codebase. It did something that none of our competitors could do, which was really important to our client base.

We were a second-tier player in the space, where the 1st-tier player would be exponentially more expensive to implement and of little benefit to any but the largest clients (think, SAP vs Mysql, for analogy's sake).

When courting new customers, we often encountered the question, "When are you going to re-write your product and get off [language platform]?"

We wrote a white paper to explain where we were, where we were going, and how [language platform] wasn't impeding our 1) security, 2) performance, 3) extensibility.

But we got that question every time. CEO asked tech team how long it would take to re-write the entire 17 year old code base, without losing any client facing features, in [any_new_platform].

They ended up selling to a big financial concern (for analogy's sake, think CA -- Computer Associates).

Was probably the right move.

You know, I guess these kinds of articles are formulaic, but I enjoy seeing the rationale for switching. There definitely are reasons to sometimes migrate to another infrastructure or language (be it cost, ease of hiring, performance, etc), and I like hearing the rationale behind it, even if I don't agree with it.

Going onto the other end of the spectrum, I had a job in 2012 doing ColdFusion, ActionScript, and DOS FoxPro. ActionScript was still semi-relevant, but ColdFusion was barely supported anywhere anymore, and FoxPro (in any version AFAIK) hadn't been updated in at least six years.

Whenever I got annoyed by this, they had this strong attitude of "if it ain't broke, don't fix it", and told me that there's no reason to rewrite anything.

Coldfusion isn't the worst language I've used, but ColdFusion code can be extremely difficult to debug, especially before they introduced CFComponents, and after about six months, I quit. I haven't talked to anyone there in a number of years now, but my understanding is that they really haven't been able to replace anyone who left, since the number of people willing to do ActionScript and Coldfusion and FoxPro is shrinking every day.

Changing to $Hyped_technology has one really good side effect: it attracts talent. Is your site getting 2000 visitors a day really going to benefit from Kubernetes? Is your Android app really going to see an appreciable difference if you rewrite the server in Rust? Is your code really going to have less bugs if your new server it in Haskell? The answer to all these questions is "maybe", but all of those technologies have the advantage of being sexy to people who absolutely love compsci, and being able to attract that kind of talent has value.

I don't know how much of a success story this really is, but I took a job at Jet.com, when that was still relevant, because it was using F#, and that seemed pretty neat. I met some of the most incredibly smart and talented engineers that I've ever worked with there, and I think that's in no small part because a lot of people who are interested in F# do programming for more than "just the money".

> Today we are making some of the code that we can afford to open source available on our GitHub page. It is useless by itself and is heavily tied to our infrastructure, but you can star it to make us seem more relevant.

Good, less satirical related article: https://logicmag.io/failure/freedom-isnt-free/

Our internal studies showed that gaslighting users by showing them a completely new interface once in a while and then switching back to the old one the next time they loaded a page increases user engagement, so we made sure to implement such a system based on a Medium article we found that had something to do with multi-armed bandits.

Some darkness here.

Just letting out some pent-up frustration about $MESSAGING_APP that was running this kind of A/B tests in their TestFlight builds where I'd get a different UI at each launch (I know I opted in to the bleeding edge, but could you at least make it consistent?) $SEARCH_ENGINE keeps changing fonts and spacing on me too, which is less jarring but somehow more annoying because it instantly feels "off" to me.

Holy shit, that just hit home hard... I just pitched doing multi-armed bandits for ad placement.

I’m shocked you leaked our proprietary internal architecture details and have forwarded this memo to management.

"Every metric that matters to us has increased substantially from the rewrite, and we even identified some that were no longer relevant to us, such as number of bugs, user frustration, and maintenance cost. Today we are making some of the code that we can afford to open source available on our GitHub page. It is useless by itself and is heavily tied to our infrastructure, but you can star it to make us seem more relevant."

This is gold.

On the plus side, makes pen-testing easier.

HN cracks me up.

Most people here seem to agree that $Hyped_technology is a bad choice vs. $Old_and_tested_tech ... but those same people piss on tech like PHP and/or MySQL and instead recommend $Hyped_technology

company i am consulting switched from php stack to client side react. killing search traffic and botching evey other metric they had. inlcuding revenue.

there is a german word for this fallacy: “Technologieglaeubigkeit”: the belief that with modern technology you automatically make a the right decision.

That was some really wonderful satirical writing! Thanks for writing it. The next one should be on microservices and devops :)

Yes please. You should write a book on such things!

I'm waiting for that $startup_name to try (ab)using this $Hyped_technology everywhere and subsequently writing a blogpost titled: '$startup_name: Our incredible journey'.

$Famous_company to $other_startups: We can't wait to see what you'll come up with!

Anxiously awaiting the “Why we are moving away from $Hyped_Technology” post replete with details on how $startup_name reinvented and reimplemented an older, more efficient wheel.

> We know you’ll ignore the fact that you’re not us and we have enough engineers and resources to do whatever we like, but the decision will ruin your startup so it’s not like we’ll see your blog posts about your experience with $HYPED_TECHNOLOGY anytime soon.


Great article, even better as a template.

Can you either (a) let users specify some of this values to generate these blog posts about (company, technology) pairs they want to, or, (b) randomly fill in those values on each refresh?

Would allow us to see random, fun blog posts.

It's like this guy was reading my mind... he's likely using $THE_NEXT_BIG_TECH !!! I need to buy all the $TECH_PUBLISHER books, attend the $hot_location conferences and buy some $ONLINE_LEARNING courses. I also can't use my $old_free_ide , I need to buy a license for $new_ide (just a skin of the old one, actually, in the $old_tech, but that's not important).

$old_tech has a lot of free courses, blog posts, books, etc but all those ppl had it wrong - and it can't be that everyone selling $new_tech online courses, conferences, books, ides, tooling, etc is just trying to make money off my FOMTW[0], right?

[0] FOMTW = Fear Of Missing a Tech Wave

Within the past two to three decades at least, I saw much of the tech world grow (for better or worse), benefiting from NIH inclined innovation + OSS bazaar model; some random evolution examples coming to mind include minix vs linux, java vs golang, memcached vs redis, apache vs nginx vs traefik, lxc and docker ... not that the development of the latter was motivated by lacking capabilities of the former, boring tech more or less has been always available but it takes guts and perseverance to embark on a green implementation. We probably have to admit that most of us do have NIH, to some degree.

Guess the keywords { orchestration, AI/ML, distributed, streaming } are left out for future enhancement of this beautiful prose.

And when one does an RCA on why that's happening across our industry - the cause could be just one of

- severe craving for resume pimping - severe craving for ego-stroking - severe incompetence and inability to recognize and control complexity.

With https://news.ycombinator.com/item?id=22796017 being last month, I guess the people are now ready call this out in a more bolder way, and that's good!

What no mention of the fact that $FLASHY_LANGUAGE doesn't have generics?

$HYPED_LANGUAGE is simultaneously every language and no language, possessing generics while somehow still lacking it. It is shapeless and formless, yet intimately familiar in a curious sort of way. The legends say that some used it for something useful back when it was nascent, but all that's left is a desiccated husk, beaten daily by hecklers on forums across the Internet. A vessel for aspiring language theorists, it is but a placeholder now, a place where interesting languages go to die.

What are some examples of $HYPED_TECHNOLOGY and $FLASHY_LANGUAGE these days? All I can remember is Ruby on Rails.

Just sprinkle some magic Kubernetes on your problems and they'll all go away! Oh, and make sure you add a Service Mesh too... just in case.

Kubernetes makes way more problems than what it solves in my company. We even migrated to another cloud provider, hoping for a better managed kubernetes. We ended up with different bugs and issues and a worse than useless support in a different timezone, in addition to a much more expensive cloud bill.

There's no good managed k8s anywhere. You can get bad managed k8s cheaply from Digital Ocean, or expensively from EKS or GKS, whose pricing and service levels are broadly similar. The major difference is that, if you do >$100M ARR and have EKS spend to match, you can expect to have several TAMs available, at least one of whom will usually understand what they're all taking turns apologizing for this time. Google, by contrast, will never give a shit about you no matter who you are, and charges slightly more for this service.


(which looks an awful lot like cgi-bin and shared hosting all over again)

React, Typescript, GraphQL, Rust and Go more recently. But there’s been plenty since and prior to Rails. I remember all the Java hotness.

Blockchain and Rust. You get five ironic moustaches if it compiles to web assembly.

At least web assembly brings us something completely new that we never had before. Rust is just an attempt to improve things, which is fine! But, it needs a decades long proven track record to come close to competing with Java/C++/PHP, which takes time obviously.

I think the cool kids are moving to DOS on Dope or Cobol on Cogs.

As someone leading the charge moving a company from Rails on Heroku to Go on Kubernetes with Prometheus/Jaeger/Fluentd/$CNCF I’ll be self aware enough to say “all of the latter.”

Elixir, Node, Scala, Go, React, SPAs in general

* Anything CSS-in-JS

* any new Nxxt.js framework that looks a lot like PHP 4, with HTML, SQL and JavaScript mixed all over the place.

Node.js itself was the new hotness for a while.

Java on Javascript is the cool thing these days

Are you referring to typescript? If so, that’s hilarious

Mostly Rust and yet another JS framework.

I wouldn't be shocked if some $other_famous_company filed a copyright claim saying that this was plagiarism.

I had a couple of these from my browser history open for inspiration ;)

$Hyped_technology is a great hiring mechanism for less well known or not popular companies. I'd take a job at $boring_company at a low rate if I could do interesting Rust projects.

Well said company better hope $Hyped_technology will become mainstream, otherwise they're screwed with a hard to maintain codebase. So it's kind of a gamble.

Why we switched to [hyped technology]

We heard it's good. We found that [a complete rewrite of our software] resulted in a better quality product

> aggressively

On point satire. I’m always a little bit wary of people who talk about aggressive caching and other aggressive things.

It’s as if you didn’t really get the solution you wanted, so you just hit it harder until you got a few more percent out of it and called it a day instead of figuring out an order-of-magnitude better solution.

Fair enough, but don’t try to trick me!

I could build $Famous_company in a weekend with $Outdated_technology.

I was expecting URL parameters "Famous_company" and"Hyped_technology" to substitute in the text.

Sadly it's a static site, so the best I can do is stick a contenteditable on it :( On the plus side, I'm immune from comments here on Hacker News about why my website isn't a static site.

Could use Javascript to search-replace the text. Progressive enhancement and all :D

I stubbornly refuse to serve JavaScript on my website, but perhaps I can whip up a snippet that you can self-XSS yourself with.

How's this?

  document.body.innerHTML=document.body.innerHTML.replace(/\$[\w_]*/g,'<span contenteditable role="$&" style="border:dashed 1px gray">$&</span>');document.querySelectorAll('span[role]').forEach(s=>s.addEventListener('input',e=>document.querySelectorAll('span[role="'+e.target.getAttribute('role')+'"]').forEach(t=>t!=e.target&&(t.textContent=e.target.textContent))))

That's a bug of $HYPED_TECHNOLOGY. It's been known for years, but they're too busy evangelizing at conferences to fix it.

This is brilliant, precisely because it's not actually special at all...

Can we, from now on, reply with this post to every entry that fits the title after substituting variables?

I suspect that would not go over all that well after the first couple posts.

This is absolutely brilliant, I can't find words to express the genius of this article. I often would have similar feelings to this author, as I am an (chemical) engineering student and I have learned to appreciate traditional stable designs that are meant to last for decades and are there to just work, not to look good on reddit and Medium. But I never knew how to express myself. This post did it better than I ever could.

From a game theoretic/psychology perspective, doing this kind of thing makes sense. It punts the ball on so many issues, and gets people into the mindset that all of our problems will go away when the rewrite is "done." I wonder what analogs out of software engineering exist for this - probably a lot.

This made me laugh out loud more than anything in Silicon Valley's final season.

Hehe, DAU -> 'Dumbest Assumable User'/'Dumb-Ass User'.

Possibly not a coincidence in this well written piece.

Yeah I had to google this one - in German IT circles, DAU always means Duemmster Anzunehmender User (Dumbest Assumable User), never Daily Active Users

Can we play game? Replace the variables with your favourite (humourous or real case's) values?

My god, this is brilliant. We can shut it down now, this is every engineering blog post ever.

This reminds me of a Lowtax post on Something Awful years ago...it gave me a good chuckle.

Are they still using php-based $Var_names in their blogs? Switch to Javascript let.

Don’t forget the promotion!


Holy crap, this is pure gold.

the saddest thing, once you work in software is: at the majority of places people are not as smart and pragmatic, as they say they're or seem. so the software world keeps going in depressing circles e.g current state of docker, k8s, SPA's etc. maybe one day, someone will documented the amount of human hours wasted on these useless rewrites and reinventing the wheel etc.

as long as they contribute, im cool with it

Brilliant !!!

Can't wait to see the meta-commentary on this meta-article on n-gate.com


Shit, I wish.

One of my last teams used gods from Greek mythology (e.g. Apollo [1], Ares [2]), and another nearby team used Pokemon names. Lots of folks started using similar naming conventions and eventually a clear naming manifesto was sent to all engineers to discourage this practice for new services.

It's much easier to discuss and reason about complex systems when the names are self-explanatory, especially when you get to 100s or 1000s of names.

[1] https://www.memsql.com/blog/case-study-scalable-sql-database...

[2] https://eng.uber.com/aresdb/

I work at a very large tech company and my experience with names there leads me to disagree.

* It is often most critical to differentiate between things that have similar functions. The relevant distinctions will not be clear by the time of naming (i.e., this is the part that used to manage the whole X but now just responds to callers, this is the part that was separated out from the old X for scaling, this is the old X backend, this is the older backend that runs for the old platform Xes only...).

* The same name may seem to make sense to people for very, very different things. (Viz. how many technical meanings "migration" has) If you have to namespace your names to get over this, Org Product Name starts getting clunky enough it will be called something different in practice anyway.

In sum, I would say that it's much easier to discuss and reason about complex systems made up of parts with clear divisions of responsibility, and I'm sure that everything tends to be easier when those divisions have been static enough over time such that the names can still correspond to responsibilities. However, I will take every single Pokemon name in existence over the confusion caused by names that try to describe what services do and are inaccurate.

> It's much easier to discuss and reason about complex systems when the names are self-explanatory

For example:


This is gold :-)

Using Simpsons as an inspiration to server roles naming scheme; they had lisa-[xxyy], bart-[xxyy] etc. ICQ , circa AOL times.

We used WWII-era warships. Keep in mind this was at a Navy contractor.

Total PITA by the way. App-Prod-DB-001, App-QA-007 or DB-Bak-003 tells me what the server does, and what sort of tier (Prod, Test/QA, Dev, misc.) and a couple of other details about just looking at it. Folks reading this post could probably make some guesses just by the names.

Meanwhile, what the hell do servers Leonidas and Hephaestus do? Both of em crashed -- how much should I be panicking about that?

I currently maintain a product that is Father Ted-based.

Network devices are labeled FatherJack (fastest), FatherTed (baseline), FatherDoogle (slowest). Storage is on CraggyIsland.

This is cool until you work somewhere that has over 100 MetadataService services.

I giggled at that, because I felt seen. I took an overview of western literature class in college which included Obie’s Metamorphosis, and it’s had a severe negative impact on my ability to name services.

Edit: I obviously meant Ovid’s Metamorphoses, but autocorrect got me. I’m leaving it, because that’s hilarious.

> Obie's Metamorphosis

real name, no gimmicks

Yay, autocorrect!

As naming schemes go, though, my preference ordering is still mythology > Middle Earth > Harry Potter > dropping the last vowel.

> Obie's Metamorphosis

Ovid's Metamorphoses?

Autocorrect comes for us all in the end.

Also my favorite part.

LOL OVER 9000!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact