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

51–60 of 340 posts

Re: Ask HN: Who regrets choosing Elixir?

#51

Post by treis »

brenden2 wrote: post #23
treis wrote: post #21

Earlier quoted context omitted.

How close does it come to matching the Ruby/rails gem ecosystem?

Phoenix is the closest, and while it's not exactly a Rails clone, it provides most of what you need to get started. It's similar to Rails in that there's a CLI to generate code, and frameworks for unit testing, DB modeling, templating, etc. Where Phoenix really shines is its support for fancy stuff like Websockets and distributed messaging in your backend. Trying to do these things in Rails leaves much to be desired.

I mean more stuff like Devise for authentication, Apartment for multitenancy, ancestry for hierarchical data, etc. Seems like every common problem has a gem that solves it. Does Elixir/Phoenix have equivalents?

Re: Ask HN: Who regrets choosing Elixir?

#52

Post by james-mcelwain »

ianamartin wrote: post #32
james-mcelwain wrote: post #13

Earlier quoted context omitted.

When people refer to "typing", it is almost certainly reasonable to assume they are referring to static typing, as implemented by most languages. I don't think this should be confusing. Specs/contracts are cool but ultimately don't afford the same kind of descriptive and expressive power that a static type system does. > static types in most languages[2] don't reduce this burden much: there isn't an alternative to th…

>> When people refer to "typing", it is almost certainly reasonable to assume they are referring to static typing, as implemented by most languages. Really? You're going to go with "most languages implement static typing"? That seems like a bold statement.

I'm not making a claim about all languages, I'm talking about languages that support any kind of extensible type validation, whether statically or at runtime.

Re: Ask HN: Who regrets choosing Elixir?

#53

Post by freedomben »

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 the idea of recursion for everything. There are pre-written macros to help of course, but it's just training wheels. This will improve with time and experience. I also don't fully grok how to write my own macros. What I really need to do is spend a couple of days deep diving until I get it.

2. Phoenix is changing quickly (tho slowing down). I wrote some stuff if Phoenix 1.2, 1.3, and the upgrade path is a bit involved (no more so than a rails upgrade was tho). I suspect it's stabilizing, but when I first created one project it used brunch for assets, now it uses webpack (which is a good choice, but as a non-frontend person I'm not well equipped to make the change myself to upgrade my project). 1.3 (IIRC) also dropped models, so that required some refactor to work as a 1.3 project.

3. Deployment changes quite a bit. The old rules for Ruby go out the window. You can still treat your Phoenix app like a rails app if you want, but it's like buying a Ferrari to drive around the neighborhood at 25 mph. This takes some learning, and while much of the old rules about scalability, etc are still applicable, they do change a bit and it requires making new mistakes and learning from them.

4. I get irritated now when working with non-functional code in other languages. My tolerance for side-effects is down to nearly zero, and I get irritated when there's a dozen lines to do something that in Elixir is a couple of pipes.

That said, overall I much prefer Phoenix/Elixir. None of the downsides are the fault of Elixir, so I believe with time It'll be a no-brainer. I am already at the point where I don't start any green field projects in Rails (tho I do use Ruby extensively for scripting as it's by far the best scripting language IMHO).

Re: Ask HN: Who regrets choosing Elixir?

#54

Post by kerkeslager »

neilwilson wrote: post #15
kerkeslager wrote: post #4

Earlier quoted context omitted.

I'm a bit confused by this comment. Having used both Ruby and Elixir (more Ruby) both languages have type systems which are quite capable of modeling domains[1]. They lack static type checking , but I find that a thorough test suite catches most type errors anyway. And while creating a thorough test suite is costly, static types in most languages [2] don't reduce this burden much: there isn't an alternative to thorou…

Type systems are really a set of comprehensive tests you don't have to write yourself that cover a subset of the things you need to test for. Static languages fell out of favour last time round the dynamic/static merry-go-round because the typing started to get in the way. You ended up writing more type boilerplate than actual code - and not breaking your methods/functions down into smaller functions to avoid having…

> Type systems are really a set of comprehensive tests you don't have to write yourself that cover a subset of the things you need to test for.

Maybe in a very strongly-typed language, but having used a pretty wide variety of statically-typed languages, I can confidently say none of them had strong enough type systems that the assertions made by the type system could be considered "comprehensive". You still need a test suite.

Re: Ask HN: Who regrets choosing Elixir?

#55

Post by bryanrasmussen »

_t0du wrote: post #31
james-mcelwain wrote: post #13

Earlier quoted context omitted.

When people refer to "typing", it is almost certainly reasonable to assume they are referring to static typing, as implemented by most languages. I don't think this should be confusing. Specs/contracts are cool but ultimately don't afford the same kind of descriptive and expressive power that a static type system does. > static types in most languages[2] don't reduce this burden much: there isn't an alternative to th…

I see that language parroted all the time - "With thorough enough testing a dynamic language shouldn't be a problem", and I have never understood it. Arguing to build what is essentially a build-time type checker in the form of automated tests seems twice as cumbersome for half the benefit. Instead of building tests that check each branch of a program's types, why not use a language that forbids dynamic typing? You s…

type errors are generally the lowest common denominator error, thus tests that catch higher level errors will also catch whatever typing error is related to the actual error you are testing for.

Not to say I haven't had benefits from catching type errors but generally not as great as those I have from having an automated GUI test running.

Re: Ask HN: Who regrets choosing Elixir?

#57

Post by kerkeslager »

ed25519FUUU wrote: post #10
kerkeslager wrote: post #4

Earlier quoted context omitted.

I'm a bit confused by this comment. Having used both Ruby and Elixir (more Ruby) both languages have type systems which are quite capable of modeling domains[1]. They lack static type checking , but I find that a thorough test suite catches most type errors anyway. And while creating a thorough test suite is costly, static types in most languages [2] don't reduce this burden much: there isn't an alternative to thorou…

> They lack static type checking, but I find that a thorough test suite catches most type errors anyway. Maybe ruby is different than python in this regard, but with python I see a lot of “assert isinstance(arg, dict)” in functions which would not be necessary with type checking. Feeding an unexpected type into a function, and having it carry on as normal, is really scary.

I've seen this too, but I tend to think of it as an antipattern.

The fact is, in most cases a Python function won't carry on as normal if you feed it an unexpected type, because while Python's type system isn't static, it is fairly strong. In general I am a fan of strong types and I would like it if Python's type system were a lot stronger.

But ultimately this isn't what my post was about: I'm talking about modeling your domain with types, not type checking.

Re: Ask HN: Who regrets choosing Elixir?

#58

Post by neya »

I'm one of those raving fans you talk about. I always love sharing the success stories of Elixir with everyone because it deserves so much more love than it currently receives.

I came from a Rails background too and Elixir is so much better than even Ruby (which I'm a huge fan of already) simply because it forces you to think in terms of functions rather than OOP based. Most people who try and give up early on Elixir - including myself (I gave up initially after a few weeks actually, before going back to it again) was simply because I was trying to code things like I would normally do in an OOP setting.

For example, you don't use FOR loops in Elixir, you don't nest switch cases. If you try to be in an OOP mindset with this language, you WILL fail. And that's a good thing. The language constantly challenges you to rethink a lot about your code. And it always results in better code when you do it functionally. Eg. using pattern matching instead of multiple if else clauses.

The downside of Elixir is the ecosystem isn't as mature as Ruby, so, for some of the things you're trying to accomplish, you won't find ready made libraries, or they won't be maintained anymore. Sometimes, you will be forced to write something from scratch and that can cost valuable developer time. Integration of stuff like GraphQL can be too verbose compared to other programming environments as well. But, the language itself? It's hard to complain. My entire consulting career has been built around Elixir since I made the switch ~3+ years ago. That's how good it is.

Re: Ask HN: Who regrets choosing Elixir?

#59

Post by freedomben »

regulation_d wrote: post #45
flaque wrote: post #3

One counter point to elixir is that there's a significant learning wall to onboard new developers, more so than simpler a language like Go or Python.

To me learning Elixir felt like a two stage process: learning the language and learning the OTP. The language itself is pretty small and I felt like the first stage was pretty easy. Learning the OTP is a much bigger challenge. At the same time, I think you can gain a lot of the benefits of Elixir and the BEAM without needing to be an OTP expert, because frameworks like Phoenix leverage it for you. In my experience, t…

Very much agree. With the exception of macros, part 1 learning the language was a joy. It was fairly easy and I loved it.

Part 2 learning Phoenix and OTP has been a long, ongoing thing. If I did it full time it would be done, but doing it off and on part time it is a long slog.

Re: Ask HN: Who regrets choosing Elixir?

#60

Post by james-mcelwain »

kerkeslager wrote: post #44
james-mcelwain wrote: post #13

Earlier quoted context omitted.

When people refer to "typing", it is almost certainly reasonable to assume they are referring to static typing, as implemented by most languages. I don't think this should be confusing. Specs/contracts are cool but ultimately don't afford the same kind of descriptive and expressive power that a static type system does. > static types in most languages[2] don't reduce this burden much: there isn't an alternative to th…

> When people refer to "typing", it is almost certainly reasonable to assume they are referring to static typing, as implemented by most languages. I don't think that's a reasonable assumption at all. Even if, as you assert, the average person doesn't understand that types exist in dynamically-typed languages, I don't think that means I have to conform to common misconceptions. > Specs/contracts are cool but ultimate…

> the average person doesn't understand that types exist in dynamically-typed languages

Again, this is needlessly uncharitable as to what people mean when they talk about type systems, which is obviously about the capabilities of defining new types for program analysis, not that the runtime has an internal conception of types.

> Could you explain what descriptive and expressive power is missing here?

Sure! Looking at this, I have no idea what the size of side_length is, whether it's possible for it to be negative, or whether it's possible it to be null.

Of course, unless you're writing purely square based software, most domains are more complex than this. But I still think it's pretty helpful to know the properties of the parameters being passed to build your square are!

Post reply on HN