41–50 of 150 posts
We have a monorepo and I imported our entire commit history into Mixpanel - https://twitter.com/i0exception/status/1010663994435067904
As you can see, over the last 3 years, we've rewritten large parts of our infrastructure in golang. While we still use python for a lot of things, we felt that the type safety and concurrency primitives in go were a much better fit for writing some of our core services.
I was an intern at Mixpanel at the time (but not the author of this article or involved in the discussed rewrite). For context, the company was then My recollection of events (of 8 years ago): The Erlang endpoint was written a year or two earlier as someone's first Erlang project, in a tiny org with no Erlang experience. The endpoint worked well enough and people moved onto other projects in the mostly Python codebas…
I was an intern at Mixpanel at the time (but not the author of this article or involved in the discussed rewrite). For context, the company was then My recollection of events (of 8 years ago): The Erlang endpoint was written a year or two earlier as someone's first Erlang project, in a tiny org with no Erlang experience. The endpoint worked well enough and people moved onto other projects in the mostly Python codebas…
To me, the fact that a novice was able to deploy production code that went on unmaintained for months, running a crucial part of the operation, speaks positively about Erlang.
I was an intern at Mixpanel at the time (but not the author of this article or involved in the discussed rewrite). For context, the company was then My recollection of events (of 8 years ago): The Erlang endpoint was written a year or two earlier as someone's first Erlang project, in a tiny org with no Erlang experience. The endpoint worked well enough and people moved onto other projects in the mostly Python codebas…
Seems like an oversight that nobody thought to get proficient with erlang. As someone who has started learning it, this seems like the obvious choice.
You're also presupposing Python is inferior to Erlang, which I'm not really going to argue about here, but I think we can all agree that Python isn't so bad that the decision to continue to use Python substantially and negatively impacted the org's ability to succeed.
I was an intern at Mixpanel at the time (but not the author of this article or involved in the discussed rewrite). For context, the company was then My recollection of events (of 8 years ago): The Erlang endpoint was written a year or two earlier as someone's first Erlang project, in a tiny org with no Erlang experience. The endpoint worked well enough and people moved onto other projects in the mostly Python codebas…
I think Facebook chat had a very similar experience. The first version was written by someone who liked Erlang. Later on, when some performance issues came up (probably related to GC), no one knew Erlang, and all the high performance backend code in the company was in C++. So it made sense to rewrite the thing.
Earlier quoted context omitted.
Or, part of the job that the tool has to be right for is the team, which can be as much a part of the job definition as the output. OTOH, if there is strong reason to think the tool is otherwise correct, finding resources to. enable the team to gain and/or borrow the knowledge they are currently lacking should be practical.
> OTOH, if there is strong reason to think the tool is otherwise correct, finding resources to. enable the team to gain and/or borrow the knowledge they are currently lacking should be practical. It's incredible companies don't invest in training enough, and this goes both for the companies who provide training (causing companies to avoid wasting money on it to begin with) and the ones who need training for their tea…
Them not being able to utilize Erlang well seems to be the gist of the article. The rest seems like a post-hoc rationalization. It's fair to switch away from a technology your team doesn't know well and doesn't want to learn. Maybe that should have been the title.
Long time, Dimi.. It's a favorite pet peeve of mine too that people often try to rationalize either their lack of experience with a platform or a broken architecture as a problem with the language in question. Though sometimes it's done because it helps paper over internal politics (e.g. lack of clout to be perceived to criticize past decisions) by blaming something external like a language or framework to justify ar…
Well yeah, because you avoid me like I am an obsessive ex-girlfriend. :D
You're the last person I expected to reply! Very pleasant surprise.
> It's a favorite pet peeve of mine too that people often try to rationalize either their lack of experience with a platform or a broken architecture as a problem with the language in question.
I am the same. I get it, I understand the mechanisms leading to that but I still get irritated sometimes that people pretend their motivation is something more. I am quite OK with admitting: "No I don't want to learn Rust right now; I use Go and OCaml when I need fast(ish) native code and I am quite OK with Elixir doing everything else". I don't pretend that Rust is bad; I know it's very good but I am openly admitting that currently I am working on deepening my skills and not widening them.
> Though sometimes it's done because it helps paper over internal politics
Yep, doesn't help when the CEO and the CTO are old friends back from their Perl and bash and Slackware days and they don't want any newer technologies. I also get that motivation and maybe I'll become that conservative one day myself but in the meantime it's really weird to pretend that we had everything we ever needed in the older languages / OSes / frameworks. We definitely didn't. And things definitely improved hugely in the last several years. (We might need a new OS though, Linux feels kind of stuck.)
As for monoliths, it's a 50/50, we know it. There are many projects (I'd say most) that are served quite well as a monolith. And most projects never grow that big that they need the horizontal scaling anyway. But yeah, let's all pretend we're Google, it's kind of how it goes these days.
I was an intern at Mixpanel at the time (but not the author of this article or involved in the discussed rewrite). For context, the company was then My recollection of events (of 8 years ago): The Erlang endpoint was written a year or two earlier as someone's first Erlang project, in a tiny org with no Erlang experience. The endpoint worked well enough and people moved onto other projects in the mostly Python codebas…
Is it common for an intern to get such an impactful project?