Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How And Why We Switched from Erlang to Python (2011)

engineering.mixpanel.com

Post reply on HN
Print view View original

141–150 of 150 posts

Re: How And Why We Switched from Erlang to Python (2011)

#141

Post by theamk »

cellularmitosis wrote: post #121
andy_ppp wrote: post #109

Earlier quoted context omitted.

The problem here is not understanding your database not about making a system in an unsupported and probably undeployable thing to prove how clever you are...

> "to prove how clever you are" I see this a lot and I just don't get it. Is a mechanic who uses air tools trying to "prove how clever he is"? Knowing more than one tool allows you to choose the right tool for the job. Assuming arrogance and a motive of "proving cleverness" sounds like a great way to pick a fight.

Air tools are fine -- after the car left mechanic's garage, I cannot tell if air, electric or manual tools are used.

But if I give my car to mechanic for carb cleaning and tune-up, and get it back with fuel injection system and explanation "it is better anyway", I would be very unhappy.

Re: How And Why We Switched from Erlang to Python (2011)

#142

Post by cellularmitosis »

theamk wrote: post #136
cellularmitosis wrote: post #124

Earlier quoted context omitted.

> just ban the Clojure code in the production A dev ran up against the limitations of one platform and solved the problem by choosing a platform which didn't have those limitations. And management responded by banning the new platform. How long do you think that dev is going to stick around in an environment like that? Ultimately this comes down to what sort of environment you want to foster. One approach leads to an…

I am not sure why you think it is "management responded" -- it is all about other people on the team. Right now, I am responsible for maintaining one of our internal services. If someone tries to rewrite part of it in Clojure without extensive internal discussion first, I'll do all I can to stop it (and I am not "management" at all). And most people on the team will agree with me. If the original dev would not want t…

“If someone tries to rewrite part of it in Clojure without extensive internal discussion first”

“single-handedly moving to a new technology and then forcing everyone else on the team to support it is impolite and annoying”

The dev you’re describing has indeed made some bad choices and I wouldn’t want to work with that guy either.

What I had in mind was more along the lines of “check out this thing I made, what do you think?”

Totally ok responses would include: “let’s just bypass the ORM here instead”, “let’s divert 5% of traffic to it and see what happens”, “this stays a prototype until you reach a bus factor of 2”, etc.

Re: How And Why We Switched from Erlang to Python (2011)

#143

Post by teilo »

bcbrown wrote: post #140
teilo wrote: post #139

Earlier quoted context omitted.

My company is an example of this, and in a way that is quite different from that laid out in the article. We actually began with a Python implementation for our integration / API server. But this was well before asyncio and eventlet and kestral. It didn't scale well, and we quickly outgrew it. We implemented its replacement in Elixir, a solution we are still running. It is written by a developer we still have, is wel…

> We have looked for more Elixir developers. They are rare beasts. But we have a lot of Python developers. Was there any consideration of training up the Python developers on Elixir?

That's the 0.5 Elixir developer. Let's face it: It's easy to become a poor Elixir developer, but those capable of becoming a good Elixir developer such that it's worth the cost of effort to train them, are uncommon.

As the CIO, where the buck stops, I learned Elixir well enough to write my own Genserver-like implementation from scratch, and thoroughly enjoyed it. I wanted to be able to understand the code base. But I am still a far better Python developer than I will ever be an Elixir developer. It's all a question of time utilization.

Due to the modular nature of our integration, it's relatively easy to move from one platform to the other, one module-at-a-time. And in the end, the cost of getting a new Python-based platform up-and-running far outweighed the cost of trying to retrain Python devs.

Re: How And Why We Switched from Erlang to Python (2011)

#144

Post by e12e »

cellularmitosis wrote: post #105
bradleyjg wrote: post #54

Earlier quoted context omitted.

In general language diversity at a company is a big negative. Obviously sometimes there are even bigger negatives that mandate overriding that rule--you aren't going to use Java on the front end or javascript on the backend, that would be madness--but you never want two languages in the same niche. That's a cost with no benefit. If you have some developer that wants to write something in a new (for your company) lang…

Some dev: "Hey, I noticed one of our more complex API endpoints had some pretty bad response latency, so I dug into it a bit. It turns out our PHP/Symfony/Doctrine stack was generating over a hundred SQL queries, all of which were being performed sequentially because we don't have a good per-request concurrency story in this tech stack. So I wrote an alternate implementation in Clojure which has a great concurrency s…

Maybe not. But if the alternative was spend one tenth of the time to cut the redundant sql queries down a bit and cut latency 50% - leaving a codebase that anyone on the team could further develop and debug... Then "that guy" might stil be in the wrong...

Re: How And Why We Switched from Erlang to Python (2011)

#146

Post by bradleyjg »

Silhouette wrote: post #111
bradleyjg wrote: post #54

Earlier quoted context omitted.

In general language diversity at a company is a big negative. Obviously sometimes there are even bigger negatives that mandate overriding that rule--you aren't going to use Java on the front end or javascript on the backend, that would be madness--but you never want two languages in the same niche. That's a cost with no benefit. If you have some developer that wants to write something in a new (for your company) lang…

If you have some developer that wants to write something in a new (for your company) language, or even worse goes off and does so without asking, because he wants to try it out, you probably want to fire that guy. Either he doesn't understand the downsides or he does, but doesn't care. What if it has the potential to be a much better tool for the job than the mainstream options, and your developer thinks it's worth t…

I guess my answer would be that this is the kind of decision that requires being able to see the big picture. Is an individual developer in a position to weigh future recruitment challenges?

My remark about firing a person merely wanting to write something in a different language was off base and end up derailing the discussion. But the point I should have made, and stick by, is that this decision is properly made at either the company wide level, or for large companies at the level several rungs up the ladder. It isn't at all, like someone suggested above, equivalent to picking a personal IDE.

Re: How And Why We Switched from Erlang to Python (2011)

#147

Post by Silhouette »

bradleyjg wrote: post #146
Silhouette wrote: post #111

Earlier quoted context omitted.

If you have some developer that wants to write something in a new (for your company) language, or even worse goes off and does so without asking, because he wants to try it out, you probably want to fire that guy. Either he doesn't understand the downsides or he does, but doesn't care. What if it has the potential to be a much better tool for the job than the mainstream options, and your developer thinks it's worth t…

I guess my answer would be that this is the kind of decision that requires being able to see the big picture. Is an individual developer in a position to weigh future recruitment challenges? My remark about firing a person merely wanting to write something in a different language was off base and end up derailing the discussion. But the point I should have made, and stick by, is that this decision is properly made at…

Is an individual developer in a position to weigh future recruitment challenges?

Maybe, particularly if it's a smaller organisation.

In any case, it's obviously a management decision at some point, as all things are. However, it seems quite reasonable for me for a developer to advocate using a more suitable tool even if it's not an existing choice/standard within the organisation, and if they make a good case, it seems quite reasonable to me that management might then back them despite the downsides if the upsides appear greater.

Re: How And Why We Switched from Erlang to Python (2011)

#148

Post by vidarh »

pdimitar wrote: post #48
vidarh wrote: post #17

Earlier quoted context omitted.

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…

> Long time, Dimi.. 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 t…

> Well yeah, because you avoid me like I am an obsessive ex-girlfriend. :D

Hah. I'm equally slow to reply to most e-mails :-P

> and they don't want any newer technologies.

I don't think it's necessarily that often that it is that they don't want any newer technologies per se, but that it's easy to avoid technologies you don't personally see the benefits of, even if that is because you don't know them.

But I also see the reverse relatively regularly: People who push the new hotness because they want to play with them rather than for any real business reason, but who try to pretend otherwise. It's fine, if you want to try to rewrite something in a new language because you want to see if it brings benefits, cool, justify it as research.

Re: How And Why We Switched from Erlang to Python (2011)

#149

Post by vidarh »

robertAngst wrote: post #23
vidarh wrote: post #17

Earlier quoted context omitted.

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…

> they'd written a monolith instead of building a system where the message delivery was designed to be sharded; n Do some languages handle this differently? Isnt this based on how the code was written rather than a language natively sharding?

Yes, that was largely my point. While Rails at the time probably did sort-of encourage a monolith, there was nothing requiring it to be that way; it was their design choices, not Ruby or Rails that caused their scaling problems at the time they moved away from Rails.

When they were rewriting anyways, it's very much possibly that moving off Rails was the right choice anyway, but that was incidental to the far bigger problem of their broken architecture.

Re: How And Why We Switched from Erlang to Python (2011)

#150

Post by pdimitar »

vidarh wrote: post #148
pdimitar wrote: post #48

Earlier quoted context omitted.

> Long time, Dimi.. 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 t…

> Well yeah, because you avoid me like I am an obsessive ex-girlfriend. :D Hah. I'm equally slow to reply to most e-mails :-P > and they don't want any newer technologies. I don't think it's necessarily that often that it is that they don't want any newer technologies per se, but that it's easy to avoid technologies you don't personally see the benefits of, even if that is because you don't know them. But I also see…

Both can be true, depending on the responsibility of the programmer. It would be an endless discussion so not gonna tackle that.

I'd focus on the endless pretence of many people in HN and Reddit; they really love to downplay the clearly documented and unique advantages various pieces of tech have: Erlang's OTP and BEAM's preemptive scheduling and soft-real-time guarantees, Go's goroutines and channel primitives (which I dislike but I admit they are often useful), OCaml's amazing typing system that can and does prevent a ton of bugs by the mere virtue of your program compiling, Racket's ability to make a fully functioning DSL for practically every business need you might have, etc. ad infinitum.

What often rubs me the wrong way is the really strong maintenance of the illusion that "we can do what Erlang OTP does in C++" (yes you can, but do you have 20 years to reinvent that particular wheel?), or "Go can have as strong a typing as OCaml and Haskell" (not when most Go devs reach for the interface{} escape hatch every day, and not when you don't have algebraic data types with variants and maybes), or "C can be an extremely safe language if you know what you're doing" (lol don't even get me started on that one!).

People in the tech communities should know better -- that's my argument. People cannot just pretend Python is God's gospel while we all know they just don't want to learn anything else but Python.

This is a serious problem in most technical discussions which very quickly get hijacked away from the objective technical merits and into the murky territory of beliefs and prejudice.

Pretty sad. We the techies should be better than that.

Post reply on HN