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

Ask HN: Who regrets choosing Elixir?

news.ycombinator.com

Post reply on HN
Print view View original

271–280 of 340 posts

Re: Ask HN: Who regrets choosing Elixir?

#271

Post by phtrivier »

theonething wrote: post #254
JohnBooty wrote: post #89

Earlier quoted context omitted.

Thank you for the thoughtful reply! So you're going to type the wrong one (not necessarily on purpose), and you'll get a runtime error. Not that bad, sure, but you'll get it. I agree with your facts but not your conclusion here. This certainly happens, but this is trivially caught by your integration tests. Now, it's certainly true that in a static language, your compiler would catch this for you. In a decent IDE it…

> I wind up having 10 different files open at a time in my text editor so I can see what various methods are expecting. Huh, I thought this was normal. Not everyone does this?

No. Something like "intellisense" has existed for decades. It relies on the static type system to "guess" what functions make sense in a given context. You Ctrl-Space your way to writing the code , ans get Brain cycles back to actually think about stuff.

Re: Ask HN: Who regrets choosing Elixir?

#272

Post by samtechie »

I have been using Elixir for about a year and the only problems I have found is the much smaller ecosystem. It's still a niche language. This means you may be the first one to encounter some problems although I have found the community quite helpful. Even if the number of libraries cannot really stack up to Rails the few libraries tend to be high quality. Overall, I find things more explicit and understandable. There's a lot less magic and I find functional code easier to reason about. At the end of the day, every popular language was niche at one time but some people took a chance on it. Maybe Elixir hasn't yet gone mainstream but its a fairly healthy ecosystem with many brilliant, passionate people.

Re: Ask HN: Who regrets choosing Elixir?

#273

Post by seanhandley »

asfarley wrote: post #106

I tried implementing an algorithm for tracking multiple objects based on graph-cuts using Elixir. I was disappointed in the lack of strict typing in the language, since this is one of the things that made me want to try functional programming. In order to tell the type of various method signatures, it seems like you have to go looking at other areas of your program. I’m aware that it’s possible to annotate method sig…

To be fair, dynamic typing is a well-promoted feature of the language. The first sentence on the Elixir homepage starts "Elixir is a dynamic, functional language"...

Re: Ask HN: Who regrets choosing Elixir?

#274

Post by michaelcampbell »

brenden2 wrote: post #11
michaelcampbell wrote: post #8

Earlier quoted context omitted.

I feel there are dimensions to "ease" and Go and Elixir went different directions on them. Go is very "simple" in that you can look at it and generally easily understand what it's doing . Elixir and its ilk tends to make it easy to do what you want to do . In Go you have to re-write things over and over because the abstractions are low, but they're easy to do. In Elixir you can use the built in libs/abstractions, but…

Go is a language that always felt painfully obtuse to me. It always seemed hard to do basic things. To be fair I've only used it begrudgingly and never on my own work. The only thing I ever enjoyed about Go was the fast compilation.

I agree and dislike the language immensely. Some colleagues of mine like it for the runtime and compile time, which I guess is fine, but my beef with them is that they mistake motion for action.

They consider themselves "productive" because in go "...the code just flies from my fingers...", when what they're doing is reimplementing the same things over and over because the language doesn't support it.

HAVING to type a lot of stuff, even if it's easy to type, isn't productive. It's just a lot of typing.

Re: Ask HN: Who regrets choosing Elixir?

#275

Post by dathinab »

kiliancs wrote: post #222
dathinab wrote: post #153

Earlier quoted context omitted.

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.

You are misunderstanding what I mean. Through I haven't be to clear I think.

What I mean is code which not only uses types and takes advantage of the type system but overdoes it. In many languages with a powerful type system you can encode much more then just basic types and this is useful to reduce possible error cases. But if you overdo it the type system part becomes too complex, type error messages too unreadable and it hinders productivity and on-boarding.

I'm a big fan of static typing and believe that more encoding more constraints in the type system is _generally_ good. But if the resulting types become to complex it often not worth it.

Re: Ask HN: Who regrets choosing Elixir?

#276

Post by strzibny »

You are asking the right questions.

In our particular case,

1, we did not have good libraries for file uploads to Azure and to handle the signing for securely displaying them.

This was solved by 2 very simple modules. In the end, both things are fairy simple unless you want them complicated (ActiveStorage can sure do "more" out-of-the box).

This also means the code it's super straight-forward and understandable.

2, we did not have a good library for SOAP.

We started to build a simple SOAP library. This I would consider a pain, but there is always option to avoid it (see no. 3).

3, we did not have good PDF libraries.

I happened to package my Ruby library (using Prawn) as a Docker container and simply call its API. This could also simply solve no. 2.

On the other hand hand,

1, we got one of the best GraphQL libraries out there (Absinthe)

2, we got a really fast test suite (once everything compiles, that is)

3, we are getting great tooling like Phoenix LiveDashboard for free

Also I want to note that deployment is now quite easy with "mix releases" (as compare to what it was). You even get a remote console that connects to your running cluster. No problem.

[0] https://nts.strzibny.name/phoenix-livedashboard-request-logg...

Re: Ask HN: Who regrets choosing Elixir?

#277

Post by sbalea »

sitkack wrote: post #226
pritambaral wrote: post #219

Earlier quoted context omitted.

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.

Hot swapping support in Erlang is first class, but even with that, it is not an easy feat to accomplish in large systems. Which is why, in my experience, people tend to avoid it if they can do without it. Systems i have worked with either had scheduled downtime periods or one could easily take down a node for upgrades without impacting the general availability of the system. In such cases, there is no real incentive to invest time and energy in managing hot swapping. But if you absolutely need all parts of your system be up 24/7, Erlang has the best story I've heard so far.

Re: Ask HN: Who regrets choosing Elixir?

#278

Post by sbalea »

nell wrote: post #146
rlander wrote: post #125

Earlier quoted context omitted.

To be fair, if you’re rewriting an Erlang system in Python/JS and you don’t feel like you’re losing much, Erlang was the wrong choice from the beginning. The cases were Erlang shines are very hard to replicate in these languages.

> The cases were Erlang shines are very hard to replicate in these languages. I'm just beginning to get interested in the Erlang ecosystem. Could you please add more color to this and give some examples where Erlang shines? IIRC, Whatsapp backend used to be on Erlang.

If the problem you're solving can be easily split into many independent, low volume, maybe long running, communication oriented tasks, you owe it to yourself to look into the Erlang ecosystem. Think handling signaling for calls, chat connections, inputs from millions of IoT endpoints.

Re: Ask HN: Who regrets choosing Elixir?

#279

Post by dreamcompiler »

enz wrote: post #261
dreamcompiler wrote: post #190

Earlier quoted context omitted.

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…

> 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?

One would think they could just avoid mentioning Lisp. I still don't understand their reasoning.

Re: Ask HN: Who regrets choosing Elixir?

#280

Post by _8ljf »

as-j wrote: post #92

TL;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…

“after a few years”

Key phrase right there. Because it doesn’t matter what language a system is written in: if management doesn’t bother to hire replacements until after everyone who understands that system and why it works the way it does has already left, of course it’s going to crater shortly thereafter.

That’s not a language problem, that’s a business continuity problem. And it’s lamentably common as dirt.

Any monkey can learn to churn code. Learning the business domain, what its problems are, and how to solve them; that’s the bit that actually matters.

PEBKAC, at every level.

Post reply on HN