We at $Famous_company switched to $Hyped_technology
saagarjha.com
saagarjha.com
> 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.
https://blog.twitch.tv/en/2019/04/10/go-memory-ballast-how-i...
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.
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.
I wish ;)
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).
Not that I recommend CGI for anything but very low usage sites, typically internal ones with a fixed user base.
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.
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.
Made my day.
Would work for EC2, not so well for resources you don't alert on like S3 buckets, etc.
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"
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.
The posts I see tend to have $MORE_RECENTLY_HYPED_TECHNOLOGY in place of $BORING_DEPENDABLE_TECHNOLOGY.
Some great writing here. Thank you so much.
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...
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.
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.
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.
You know, pay a couple of work days at external consultant rates for getting the higher ups to sign a project.
Example: https://rbt.asia/g/thread/41920845 / https://news.ycombinator.com/item?id=7745561
I wonder which languages / frameworks folks would pick on if we were do to a new rendition
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.)
> how Rust and Hack are changing the face of programming
It's in there.
I didn't make it very pretty, but it should work.
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.
Now looking for funding to add evolutionary algorithms, combined with the best ideas from TRAC and m4, to make this a joy to maintain.
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.
Lmao
Bwahahahahaha
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.
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".
Good, less satirical related article: https://logicmag.io/failure/freedom-isnt-free/
Some darkness here.
This is gold.
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
there is a german word for this fallacy: “Technologieglaeubigkeit”: the belief that with modern technology you automatically make a the right decision.
$Famous_company to $other_startups: We can't wait to see what you'll come up with!
Brilliant.
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.
$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
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!
(which looks an awful lot like cgi-bin and shared hosting all over again)
* any new Nxxt.js framework that looks a lot like PHP 4, with HTML, SQL and JavaScript mixed all over the place.
We heard it's good. We found that [a complete rewrite of our software] resulted in a better quality product
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!
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))))Can we, from now on, reply with this post to every entry that fits the title after substituting variables?
Possibly not a coincidence in this well written piece.
Holy crap, this is pure gold.
Shit, I wish.
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...
* 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.
For example:
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?
Network devices are labeled FatherJack (fastest), FatherTed (baseline), FatherDoogle (slowest). Storage is on CraggyIsland.
Edit: I obviously meant Ovid’s Metamorphoses, but autocorrect got me. I’m leaving it, because that’s hilarious.
real name, no gimmicks
Ovid's Metamorphoses?