What are the alternatives to Elixir? I'm a proponent of functional/LISPy languages and when it comes to developing web applications, Elixir with Phoenix and Ecto just works extremely well. Maybe the next best would be Clojure since the JVM brings a huge ecosystem with it, but I did a cursory look into it a while ago and the frameworks just didn't seem to be on the same level as Phoenix/Ecto. The main complaints are v…
Ask HN: Who regrets choosing Elixir?
221–230 of 340 posts
Re: Ask HN: Who regrets choosing Elixir?
#222TL;DNR, use a language your company can support. It doesn't matter how suited to the job a language is, if it's single Engineer or small team, what happens when they move on? How do you support it? Who's on call? Not Elixir, but a cautionary tale from our Erlang project. ~8 years ago a our IoT backend was written in Erlang, this was the early days of IoT, so sure it made sense as a technology, could scale well, handl…
Yes that. But also only use paradigms which the company can support. For example good static typing is not just about adding type declarations but about taking advantage of the type system to the right degree . (Like don't ever overdo it, it's killing productivity most times). But what degree falls into the productivity boosting spot and from which point on it will hinder productivity depends a lot on the team. The p…
Our adoption of TypeScript led to a significant reduction in defects, and it definitely isn't killing productivity. Most of the time we take advantage of existing types so if anything it speeds things up in the long run.
Re: Ask HN: Who regrets choosing Elixir?
#223Earlier quoted context omitted.
Well, that’s not how programmers are recruited in the real world though. Java shops will hire Java programmers, C# shops will hire C# hands, etc etc. Marketing yourself as a generalist problem-solver will get you, at best, in one of those nightmare scenarios where you’re the only programmer in a non-tech company.
That's why you don't market yourself as a generalist problem-solver. You market yourself as an expert in C# AND Python AND Swift AND... whatever else you know how to use. With appropriate signalling to communicate your experience levels with each. There are lots of senior roles that require oversight of multiple projects that are working with different tech stacks. Some companies specialise in a single language. But…
>You market yourself as an expert in C# AND Python AND Swift AND... whatever else you know how to use
So that everyone knows you're full of shit? It takes years in a technology to become an expert at it. There's no replacement for the experience of taking multiple projects from inception to production to scale. That's how you learn about the inscrutable errors, fiddly configuration issues, and pitfalls that make you an expert at something.
Re: Ask HN: Who regrets choosing Elixir?
#224I wrote an Elixir GraphQL-to-multiple-REST-backends proxy two years ago. It used OAuth and ran redundant in a Docker Swarm. Also wrote an Expo+Apollo PoC for the mobile Dev group to start from.
The backends were swagger which allowed me to autogenerate the Elixir source code for the GraphQL resolvers from the swagger.json file. It was a project for a telecom company which also employed Erlang programmers.
My experience: stability was outstanding, performance reasonable. Got a lot of praise for it. Only got one big report in two years.
Would I recommend it? Only to experienced software engineers.
Would I recommend it to companies? Only if you understand that every new tool or stack is a strategic decision.
Re: Ask HN: Who regrets choosing Elixir?
#225Earlier quoted context omitted.
You're not wrong! I actually tried doing a bunch of research to figure out how the original Ericsson phone switches worked with Erlang, but couldn't find a whole lot of info.
At least we have this "Erlang: The Movie" demo to reverse engineer some bits: https://m.youtube.com/watch?v=BXmOlCy0oBM
That's awesome! Thanks!
Re: Ask HN: Who regrets choosing Elixir?
#226Earlier quoted context omitted.
Erlang's hotswap and Python's hotswap are of comparable power, ie, both are crappy. Being able to do something isn't the same as doing it well. You can hot swap all languages.
If you're claiming that Erlang is no better at hot-swapping code than "all languages", you haven't seen Erlang's hot-swapping abilities. "All languages" provide you the ability to run arbitrary code, and thus theoretically support hot-swapping, but if you try to put it into practice you'll soon run into real obstacles you hadn't considered that either bite you or at the least make your job a lot harder. Erlang provid…
I have seen it, it is no better than Python's, exactly as I said.
Hot swapping Erlang in production is rarely done, and if it is done, it mostly done during debugging, not serving production traffic.
I invite you to do a straw-poll on the erlang mailing list.
Re: Ask HN: Who regrets choosing Elixir?
#227Earlier quoted context omitted.
> 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.
This, twice. 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…
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.
Re: Ask HN: Who regrets choosing Elixir?
#228Earlier quoted context omitted.
This, twice. 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…
Can you expand what you mean re: large projects in Python?
Yeah, thanks for asking.
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.
Re: Ask HN: Who regrets choosing Elixir?
#229TL;DNR, use a language your company can support. It doesn't matter how suited to the job a language is, if it's single Engineer or small team, what happens when they move on? How do you support it? Who's on call? Not Elixir, but a cautionary tale from our Erlang project. ~8 years ago a our IoT backend was written in Erlang, this was the early days of IoT, so sure it made sense as a technology, could scale well, handl…
[deleted]
Re: Ask HN: Who regrets choosing Elixir?
#230Earlier quoted context omitted.
> 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.
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 y…
[deleted]