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

311–320 of 340 posts

Re: Ask HN: Who regrets choosing Elixir?

#311

Post by uryga »

kerkeslager wrote: post #288
uryga wrote: post #85

Earlier quoted context omitted.

> Could you explain what descriptive and expressive power is missing here? tldr: i haven't seen a runtime typechecker that handles generics and function types in a satisfactory manner. i've used various Python libraries for runtime type-checking (based on `typing` annotations) like `typeguard`. and they work okay for simple types, but suck for anything involving generics and function types. checking if something is a…

> i've used various Python libraries for runtime type-checking (based on `typing` annotations) like `typeguard`. Let's just stop right there, since it's immediately clear you aren't answering the question I asked. You're talking about type checking, not descriptive and expressive power. The topic is whether dynamic types are suitable for domain modeling, not whether dynamic types provide static type checking. We all…

alright, just to clarify, from the comment that introduced expressive power into the discussion:

> Specs/contracts are cool but ultimately don't afford the same kind of descriptive and expressive power that a static type system does.

i understand that as "the ability to describe/enforce the domain's rules".

now, i guess i made a bit of leap, jumping to runtime typechecking. my thinking was that while modelling your domain, you might want to specify that e.g. `width` and `height` must at least be numeric (i know i would!); `typeguard` et al are a concise way of doing that in Python, but have their limitations. so static types can be more "expressive" if the tools i mentioned (generics and function types) are useful for describing your domain model, which i often find to be the case.

looks like i missed the mark there; but in that case, i'm not sure what point you're making with that Square class. it's hard to say what's missing (or not) because there's not a lot there.

Re: Ask HN: Who regrets choosing Elixir?

#312

Post by karmakaze »

shoo wrote: post #240
karmakaze wrote: post #234

Earlier quoted context omitted.

Caught me as an odd choice to scale an IoT backend.

at some point you end up with path dependence -- you're in the situation you're in, and it would be big-bang rewrite or incremental migration to port all the code to a new stack, not to mention the costs of retraining existing staff to be able to effectively develop in and support the new stack, or replacing the staff with different staff who know the new stack but don't understand the existing business and code. so…

Oh yeah, I know all too well about path dependence. That's how we end up with a Rails monolith that's written in a very standard/structured way so that many devs can contribute, add type annotations for safely/docs, etc. Using no types is like having no tests and thinking about adding them later. Usually better to have it in place as you go.

Re: Ask HN: Who regrets choosing Elixir?

#313

Post by bb010g »

tyurok wrote: post #205
freedomben wrote: post #53

I've done both, much more Rails than Phoenix, but I'm not doing any new development in Rails. I do regret choosing Elixir at times for the following reasons: 1. I am new to the language (I've been using it for "years" but only very part time (not part of my day job)). While the functional approach does lead to much more elegant code, it can also be super esoteric to me as I'm new to and somewhat uncomfortable with th…

The annoyance over non-functional code is real. I can't tolerate OOP stuff that `obj1.calls(obj2)` and changes `obj2` anymore. I didn't care before, now it makes me want to refactor everything or not write it at all. Using Elixir kind of made me not want to use anything else.

Haskell's nice. Got some mature web stacks if you ever want to give those a try. https://github.com/Gabriel439/post-rfc/blob/master/sotu.md#s...

Re: Ask HN: Who regrets choosing Elixir?

#314

Post by a-saleh »

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…

I think one approach when choosing more niche language might be, first look for a book like https://www.erlang-in-anger.com/, read through it and consider, if this is the sort of stuff my colleagues will want/be capable to deal with.

Then consider how hard it would be to get more people that have used such language/ecosystem in anger.

Re: Ask HN: Who regrets choosing Elixir?

#315

Post by zihotki »

ksec wrote: post #302
kazinator wrote: post #295

Earlier quoted context omitted.

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 ap…

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.

Re: Ask HN: Who regrets choosing Elixir?

#316

Post by kazinator »

zihotki wrote: post #315
ksec wrote: post #302

Earlier quoted context omitted.

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".

Re: Ask HN: Who regrets choosing Elixir?

#317

Post by roguas »

411111111111111 wrote: post #270
dnautics wrote: post #263

Earlier quoted context omitted.

You could containerize your python. That's like having a fat binary.

yes, you can do that. I've been doing that for around 8 years now. And no, it's not the same. Not even remotely. The only thing that helps with are quick and easy deployments. The thing which makes maven special is the ease of producing artefacts for deployments, not the final step of starting it up on the server.

Python doesn't require creating artifacts. It requires dependency resolvement which Docker is perfect for.

Re: Ask HN: Who regrets choosing Elixir?

#318

Post by joelbluminator »

AlchemistCamp wrote: post #43
dnautics wrote: post #41

Earlier quoted context omitted.

> Any codebase beyond fairly small will be harder and harder to work with to an unreasonable degree, in my experience, and any perceived "velocity" gained from the dynamic nature of it is paid for doubly so by the lack of safety you get beyond toy projects. How does pagerduty deal with it, I wonder.

Or Discord.

Or Gitlab

Re: Ask HN: Who regrets choosing Elixir?

#319

Post by dnautics »

mapcars wrote: post #305
dnautics wrote: post #112

Earlier quoted context omitted.

This is 100% correct, and a very huge pain point, and why you're supposed to use Mox, which solves that problem (arguably in a more conceptually "correct" fashion than ad-hoc Ruby Mocks). Admittedly there is a very steep learning curve, but it's worth it, because once do it you start to be able to do things you can't do in any other PL (not even erlang). It's a pity that the elixir community doesn't make this clearer…

>and why you're supposed to use Mox, which solves that problem I never used that Mox and never had a need to. I just use `Mock` which allows `passthrough` as I stated in another comment, what other clarity is needed I don't understand. Can you give any example of the problem you can not solve instead of pitiness?

You can't run concurrent tests doing direct mock injection in that fashion, because the mock is global. If you use Mox (or similar), your mocks are tied to your test.

Re: Ask HN: Who regrets choosing Elixir?

#320

Post by dnautics »

rorygreen wrote: post #289
dnautics wrote: post #120

Earlier quoted context omitted.

1. IEx.Pry, if you are used to ruby's pry. Pipe states are extremely easy to inspect: abc |> foo() |> bar() to abc |> IO.inspect(label: "a") |> foo() |> IO.inspect(label: "b") |> bar() |> IO.inspect(label: "c") If you use vscode, this user snippet will inject this (with line numbers as labels) when you type "ins ", which can be used to great effect with multiline cursors. Since line numbers are usually the same lengt…

Oh. Dropping IO.inspect into the pipeline is embarrassingly obvious! I can't believe I didn't think to do that. I always used IO.inspect as a pretty printer during development but I guess I didn't think it would return/pass through its input. Thanks for pointing that out. I clearly hadn't bothered to read the 'Getting Started - Debugging' page on the Elixir website at any point.

Oh man I'm so sorry. The difference between using io.inspect like this and not is a the difference between "huge pain, worst ever" and "best concurrent debugging feature ever". IO in erlang is atomic, so in concurrent systems IO output will never be interrupted by IO output from another thread, which is not generally true in other systems (c, c++, rust, go). It makes a HUGE difference.
Post reply on HN