> there was no one left who could support an Erlang system.
If you have $200k "python engineers" on the payroll who wouldn't jump at the opportunity to do some additional Erlang, maybe it's time to reconsider your hiring practices and that is the real cautionary tale.
Back in the day people would balk at hiring Python programmers saying, "there are so many more Java programmers", and I used to say, "Why would you hire a Java programmer who was unwilling or unable to learn Python?"
Same logic applies here: Why would you hire a Python programmer who was unwilling or unable to learn Erlang? (Especially if you're going to pay them to do it!)
If you can't switch languages you're a kind of technician not a programmer.
FWIW, having done it professionally for ~15 years I'll never write another large project in Python again. Erlang's runtime is so much better than Python's it's just ridiculous. I feel stupid for not realizing this sooner.
If I had a Python job (a language I enjoy) and I was forced to work in a language I don't (say, Perl), I'd start complaining about it and looking for something else to do. I personally wouldn't mind working with Erlang, but that isn't the point. Many developers "can" do these things but it doesn't mean they want to.
It's pretty much how we treat our Python projects. All of us hate it, but data science is done in Python so we still need some percentage of the engineering team fluent enough in it to sustain operations with it (on-call, maintenance, bugs, eventual decommissioning).
The moment we can get rid of it, you bet we will. But it's much easier tearing it down when you understand it enough to discern designs driven by the limitations of the tech vs requirements for the product. Black box ground up replacements are hard and expensive compared to ports. Also, thankfully it's Python and nothing something more difficult/complex.
At the end of the day, it's a job, and there's an expectation of professionalism to do what's necessary. A lot of people on HN like treating tech jobs like a paid hobby which I think is detrimental to career development.
Regrettably, also back in the day and probably around the same time, companies who wanted to hire "outside of the box" asked for Python. Not because they were python shops, but because they figured that people who had an interest in a new but not-quite-commercially viable language must have some sort of intrinsic interest in programming, and would likely make for better programmers.
This is because those shops read the PG essays, and think that the the shibboleth is Python, it is not. The marker is that that someone is at the fringe and not in the middle of the flock.
I have met lots of engineers who are smack dab in the middle of the flock when it comes to tech stacks, or even _behind_, but they were more than capable. Hire for what you need. But what you think you need and what you actually need is probably not know to you.
Depends on the reason for switching. If I'm asked to switch because the new stack is going to have measurable improvements plus the language is going to stay and grow (just as examples may be Go or Rust right now), then sure. On the other hand, if the reason is because the company fucked up by relying on one idiot with an elitist mindset about programming languages, then that request going to have to come wrapped with very good incentives. If I'm a great java developer with tons of jobs to choose from, you are going to have to give me a very good reason to narrow my opportunities down for you. Otherwise, I'd say no and move on and you can go hunting for devs for a niche language and pray to Gods that the hiring situation will improve for you.
Your example of Java to Python doesn't represent the gravity of switching from Java to say Erlang or Haskell. You assume someone says no because they are unwilling or unable. We are unwilling, sometimes, because of the opportunity cost we have to pay for your fuck up.
> If I'm a great java developer with tons of jobs to choose from, you are going to have to give me a very good reason to narrow my opportunities down for you.
Why would learning a new tool narrow rather than widen your opportunities?
Learning an obscure tool that eventually dies is a waste of time. Think learning a language only you and a few of your friends speak. This in itself is good enough reason to be cautious about what you invest your time in learning.
Languages and specially the tool chain and the way of doing things around them evolve. If you spend like 5 years doing something else and come back to it, you'll find things have changed a lot. You may argue that it's easy to relearn this. But from a job perspective, the guy who has been using the exact same tech stack in the recent years will often be a better bet than a guy who wrote Java in version 1. This is very true for C#. Syntax, design principles, tools, method of deployments all have changed rapidly. Professionally, you want to be as up to date as possible in the area you worked in or you get rusty. You can learn new things on your time for their own utility. Flushing down 40-60 hours a week on a useless piece of knowledge is bad all round to me.
> Flushing down 40-60 hours a week on a useless piece of knowledge
That is only if it's actually useless. I haven't programmed in haskell for many years, yet I am very glad I did. It was hard at first, but it made me think about code, data and transformation from a different perspective, expanding the repertoire of paradigms, regardless of which language I code in.
YMMV, but personally, I'd much rather hire or work with someone with 3y java + 1y erlang experience, than just 5y java experience. In general a polyglot rather than monoglot, especially if it's a different coding paradigm. Nevertheless, I may not actually want them coding random bits of work in erlang or whatever random language.
Seriously, why doesn't python have a maven equivalent yet?
And no fat-binaries. Nor self executing binaries. It's just as old and having em basically just boils down to enforcing conventions. But nope, nothing. There have been attempts by some such as shiv, but really... None are even remotely as usable as maven is.
I've been a happy Python programmer for over fifteen years, so this comes from a place of love and respect.
Beyond roughly 150k LoC you start to run into difficulties keeping everything straight over time, especially if you use a lot of indirection or other magic. The aspects of the language that help you go fast when you're prototyping (is "RAD" still a thing? Rapid Application Development) start to trip you up when the codebase matures. There are a lot of fancy footguns in Python that catch you if you stop dancing.
Tooling is getting a little better (MyPy, et. al.) but at the same time the overhead of adding explicit type information erodes the advantages Python has over, say, Java or Haskell.
This is true of all dynamic languages. Rails codebases become a nightmare beyond a certain LOC. It’s taken a long time but now that we have languages with strong static typing but good type inference like Kotlin, Swift, Typescript etc the old fully dynamic languages are obsolete technology and will eventually be replaced.
from personal experience with mypy, the great thing about gradual typing in a dynamic language is that, well, it's gradual! when I want to do something extremely dynamic, there's no horrible reflection API in my way. but most of the time I can live happily inside the walled garden mypy provides.
I have adopted this attitude for personal projects & small companies, and it was mostly great.
There was at least 1 really large error that slipped into production because we were mocking an untyped service incorrectly (a mistyped property name), and the test passed, but prod exploded. It was embarrassing, and I certainly would have caught it with more mypy discipline, but overall the pros outweighed the cons.
At big companies that use mypy, however, this is problematic. If teams only define types for the straightforward parts of the system, then the types become less useful, especially as the company scales. From what I’ve seen, individual teams use an all-or-nothing approach with MyPy, so it’s unusual for an individual dev to sparsely type anything.
agreed - I am thinking more in terms of the common distinction between infrastructure/libraries and application code - I can write dynamic, well-tested libraries that are used by heavily annotated, checked application code. The types are generally more meaningful at that layer, and it tends to evolve more quickly anyway.
Completely agree. I worked at a company on a Common Lisp project where the Python crew refused to learn Common Lisp because they thought it would look bad on their resumes. This should be a litmus test for programmer quality: If they don't want to learn something because it's not "fashionable", they're probably lousy programmers who lack confidence in their own abilities. Do you really want these people working for you?
> Completely agree. I worked at a company on a Common Lisp project where the Python crew refused to learn Common Lisp because they thought it would look bad on their resumes.
They can put only "Python" on their résumés, right?
The reasoning is simple: if someone thinks something would look bad on their resume, they probably don't want to spend time on it, either.
For example, I wouldn't want PHP or Fortran on my resume, and, consistently with that, I avoid them. I don't have an opportunity to actively avoid them, but that defense mechanism would leap into action, if called upon.
However, I know a thing or two about these; I'm not simply applying "meme-based reasoning".
This really is resume driven development into a whole new level. No wonder why some sane Programming languages Never made it. And it is the reason why I am worry about Ruby's future.
It's not a resume driven development but a proper allocation of personal time and skills planning for the future. What's the point of learning something you won't use in the future? If for the sake of learning then there are a lot of better choices.
Just don't base your choices on the spreading of ignorant memes.
Would you want to pass on Lisp because of the ramblings of a rookie web developer with no Lisp experience? That's what you might do if you believe the "Lisp Curse".
I'll be the first to admit... I'm a little conflicted by this..
I've almost exclusively worked on the usual procedural /OO languages professionally (java /c#)..I like to experiment and I've picked up a bunch of languages along the way (perl, python, coffeescript, f#, nim etc).. And its usually because I want to see what's different and spend enough time to do something useful (but not large) with it. Also, it helps you become a better programmer IMO. otoh, if I'm hired for my skills but then have to work on js( don't actually like the js eco system) or haskell (I gave up after trying and I doubt I'd become very good at it anytime soon if I were forced into it) I'd be not happy either (and IMO, with valid cause that doesn't reflect on me or my abilities)
> If you have $200k "python engineers" on the payroll who wouldn't jump at the opportunity to do some additional Erlang
Ah, sure they might be willing, but as a lead I'm not willing to invest in it.
1. I'm not sure I want someone who's got 4 weeks of experience in a language working on system critical infrastructure. Pick your time, does it take 6mo?
2. They have existing work, learning and working on an entire new language _AND_ new project is a huge task. Especially for non-trivial projects.
We could, but in our case it was a better engineering decision was to retire the old system and move on.
This kind of sentiment come up every so often on HN and I'm just sick of it. Sure, programmers should strive to improve their craft, just like professionals in every industry. But there are plenty of ways to improve yourself and learning a new language is hardly the most effective choice (and in fact could be counterproductive).
How does learning a new way to think about a problem become counterproductive? Each language you learn gives you a new angle from which you can approach a problem. Is it counter productive to learn a second spoken language? I haven’t come across an argument against that, even learning a dead language like Latin or Ancient Greek has benefits.
Perhaps counterproductive is too strong a word, but there could definitely be problems in the short term. Programmers love to apply things they learned in their work, and taking a concept or pattern from language A and applying them to language B is a natural reaction. The most common culprits are monads and actors. Ergonomics (readability, cognitive cost, debugging, IDE support, etc) became afterthoughts in the midst of excitement, and the long term health of the codebase (and teammates) suffers.
I have made mistakes like that (introducing monads/future and making the team learn guava) and I still regret it. Its not to say futures are useless - there were a lot of async logic in the codebase and futures solve a real problem, but its not clear if the benefits outweigh the cost.
If you have $200k "python engineers" on the payroll who wouldn't jump at the opportunity to do some additional Erlang, maybe it's time to reconsider your hiring practices and that is the real cautionary tale.