10 years-ish of Elixir • Hacker News Board

Re: 10 years-ish of Elixir

#71

Post by sodapopcan » Thu, Jan 14, 2021, 6:58 PM UTC

jrochkind1 wrote: post #62

sodapopcan wrote: post #52

Earlier quoted context omitted.

As in the whole project was rewritten in Django or some kind of transpiration going on there? I haven't gotten to the point where I'm adding a lot of libs yet and certainly can't speak to using it in a big team. In terms of syntax flexibility, Ruby has a similar issue where a lot of popular libs implement their own DSLs. I've never fully bought that that is a problem—a library is going to have an API that will requir…

> In terms of syntax flexibility, Ruby has a similar issue where a lot of popular libs implement their own DSLs. Of course in ruby, nobody is actually adding new syntax , although that's a common misconception. Ruby DSL's are still just ordinary syntax for method calls and block parameters, there's no new syntax at all. Sometimes it can look like it, maybe because ruby method calls don't require parentheses? But no l…

> Of course in ruby, nobody is actually adding new syntax, although that's a common misconception.

This is the argument I usually use for anyone who has a problem with it yet if they've already decided they don't like it, it doesn't do much to pursued them. On the other hand, being able to rewrite operators in Ruby does take it a bit in that direction—While not strictly new syntax, changing the meaning of an operator can really throw people off. As an example in the standard library, there is `Dir[]`. `Dir[]` is a shortcut to `Dir.glob`. Sure, it's technically doing some kind of access, but everyone knows it as hash access and certainly aren't accustom to passing a pattern to it. Elixir libs do stuff like this.

And I'm sorry, I don't know if can actually add new syntax in Elixir, but you can certainly change the meaning of existing syntax (as in Ruby).

Re: 10 years-ish of Elixir

#72

Post by AlchemistCamp » Thu, Jan 14, 2021, 7:03 PM UTC

s3cur3 wrote: post #8

Happy Elixir user here. At work we have a use case that isn't covered by José's high-level overview of the domains Elixir's used in: we run a massive multiplayer game server on it. This is actually a really good fit. (It kind of rhymes with the original use of Erlang, being telecoms infrastructure.) We get outstanding concurrency support, high reliability, and really efficient development times. I can't imagine shipp…

I'd love to learn more about this! Have you been involved in the project from the start?

Re: 10 years-ish of Elixir

#73

Post by jswny » Thu, Jan 14, 2021, 7:11 PM UTC

likortera wrote: post #43

Meanwhile te company I work for is moving away from it. We cannot find enough people with enough knowledge to be already productive in it. Not many want to learn it because it is considered pretty niche, and the ones willing to learn will need many months or years to be productive and build with some level of quality, and once they learn they move away to bigger companies which pay more. We end up paying to people to…

> and the ones willing to learn will need many months or years to be productive

That’s interesting. I’ve been doing Elixir for a while and found it almost overwhelmingly simple. As in, I’d do something in a very simple way which would usually take me a lot longer and have to think whether it was actually right because I’m not used to that.

I recently learned Go and I think it was only slightly more difficult to learn than elixir. I could see having trouble if you have never done functional before, but that’s kind of a separate issue. The language itself is tiny.

OTP is one thing that can take a bit of getting used to. But again, I think that’s only for people who are only used to traditional threading methods of concurrency, which is again a separate issue. OTP and the actor model themselves are dead simple in terms of how to use them.

> The editor plugins are terrible, slow, and blow away your CPU doing god knows what kind of indexing

Without even looking I already know what this is. You are using ElixirLS and you are hitting the Dialyzer PLT generation which is needed for type assistance. Elixir LS gives you a pop-up (at least in VSCode) telling you that it's building the PLT and it might take a while. You can disable this if you really want. Most importantly it ONLY RUNS ONE TIME. So, if you've already generated the PLT for a project, it will NEVER run again until you upgrade Elixir or something major. Other than that, I rarely ever see Elixir LS taking up any noticeable CPU.

> Compilation is slow and takes a lot of time Yes it does. However, you can just cache the _build/ directory in CI. Then it will act like it does locally, only recompiling what has changed and doing it very quickly. Usually, dependencies will not need to be recompiled if they haven't changed.

Also, testing in Elixir is crazy fast and everything runs nicely async by default, even database tests with Ecto.

Re: 10 years-ish of Elixir

#74

Post by dwoot » Thu, Jan 14, 2021, 7:15 PM UTC

Areading314 wrote: post #36

sodapopcan wrote: post #29

I'm building my first non-toy app in LiveView. I'm blown away by how quickly I can move with it and love how Phoenix encourages DDD practices. I'm a bit saddened that Elixir isn't bigger than it is. It's such a great entry into the world of BEAM and functional programming yet I've read more than once that people aren't interested because "it looks like Ruby and I don't like Ruby". There are some more legit reasons as…

What turned me off about elixir was not the syntax, it was the flexibility in designing new syntax. It felt like each library had its own idioms and syntax rules, which just adds a huge amount of variety and difficulty in a codebase. It was hard to have consistent architectural patterns across a team. I've seen an elixir/phoenix backend rewritten completely in python/django and it was a big improvement in developer p…

> Designing new syntax As in a DSL?

> It felt like each library had its own idioms and syntax rules This sounds like the way software should be. No? Domain-driven design? Or are you saying that they don't follow industry nomenclature?

> It was hard to have consistent architectural patterns across a team Is this a symptom of everyone being new the language on the team or the language itself? Elixir is a very simple language compared to Python and Ruby in my experience. There are certainly way more people that have done the latter two. What's comfortable isn't always better.

I'm wondering how aware of the trade-offs you are in using an imperative language as compared to one that's functional. If the nitpick/gripe you're having is around readability and syntax, I'm sure there are enough counters in other languages that you've worked with where the code was just spaghetti and hardly testable

Have you considered that productivity comes more with time? I get the sense that you've worked in a team with very few experienced developers that have either worked with Elixir/Erlang or functional languages. My experience has been that those with extensive experience in OO or imperative languages w/o ever treading into FP have had a much harder time adopting Elixir and it has resulted in slower development early on, but those willing to learn, march much faster after ramp-up.

But if you value correctness, less bugs, and easily testable code, it's hard to beat functional languages in this area, and I'm not even talking about just Elixir

> I've seen an elixir/phoenix backend rewritten completely in python/django and it was a big improvement in developer productivity. Is this really a better idea? If you're mentioning "consistency enforcement", why not use Golang? Elixir also has a formatter built into its toolchain.

Take my responses with a grain of salt -- because if you're just doing a CRUD app and not buying into what the BEAM gives you from an operational perspective, it's probably not that worthwhile?

Re: 10 years-ish of Elixir

#75

Post by s3cur3 » Thu, Jan 14, 2021, 7:16 PM UTC

AlchemistCamp wrote: post #72

s3cur3 wrote: post #8

Happy Elixir user here. At work we have a use case that isn't covered by José's high-level overview of the domains Elixir's used in: we run a massive multiplayer game server on it. This is actually a really good fit. (It kind of rhymes with the original use of Erlang, being telecoms infrastructure.) We get outstanding concurrency support, high reliability, and really efficient development times. I can't imagine shipp…

I'd love to learn more about this! Have you been involved in the project from the start?

Yep! I was actually the sole dev working on it, both server- and client-side. I'm working on a post for our public dev blog talking about why I chose Elixir and what my experience has been. It'll eventually be available here:

https://developer.x-plane.com/blog/

Re: 10 years-ish of Elixir

#76

Post by 40four » Thu, Jan 14, 2021, 7:17 PM UTC

ch4s3 wrote: post #25

40four wrote: post #15

Learning Elixir and starting to use is in projects is at the top of my TODO list for 2021. I tried to get into a while back, but being unfamiliar with functional programming concepts at the time really got me. Learning a new language and trying to grep FP at the same time was too much for me :) Now, I'm more well versed in FP in general, and I'm excited to give it another go! Everyone I've talked to who uses Elixir o…

Come by and check out https://elixirforum.com/ and slack https://elixir-slackin.herokuapp.com/ everyone is super friendly and helpful. * edit: fixed link

Cool I’ll check it out thanks

Re: 10 years-ish of Elixir

#77

Post by josevalim » Thu, Jan 14, 2021, 7:27 PM UTC

jrochkind1 wrote: post #62

sodapopcan wrote: post #52

Earlier quoted context omitted.

As in the whole project was rewritten in Django or some kind of transpiration going on there? I haven't gotten to the point where I'm adding a lot of libs yet and certainly can't speak to using it in a big team. In terms of syntax flexibility, Ruby has a similar issue where a lot of popular libs implement their own DSLs. I've never fully bought that that is a problem—a library is going to have an API that will requir…

> In terms of syntax flexibility, Ruby has a similar issue where a lot of popular libs implement their own DSLs. Of course in ruby, nobody is actually adding new syntax , although that's a common misconception. Ruby DSL's are still just ordinary syntax for method calls and block parameters, there's no new syntax at all. Sometimes it can look like it, maybe because ruby method calls don't require parentheses? But no l…

Correct. You can't add new syntax to Elixir either.

FWIW, the meta-programming models are very distinct. Elixir's is based on AST and it works at compile-time (like Lisp but without reader macros). For example, imagine you want to do your html markup in Elixir, you could do this (but don't!):

    html do
      title "hello world"

      body do
        ...
      end
    end

In the above, `html` would be a macro that looks at the structure of the code and transforms it into something at compilation time. The macro must exist before being invoked and it has to literally surround the code it changes. Once the code compiles, you can't change it.

Ruby's meta-programming is runtime-based. So the same example above would likely be implemented by calling methods on an object, either pre-defined ones or using method_missing, as you execute the code. In Ruby you can also define (or redefine) methods at any time and it affects the whole runtime.

Both languages also have a similar ability to meta-program a class (in Ruby) or a module (in Elixir). Think Rails' resource macro in a router. But Elixir modules are closed, in contrast to Ruby classes. Many times this is what people refer to as DSLs, even though the term DSL in itself is more general. Python has similar abilities too.

PS: you are certainly aware of the Ruby bits but I went for completeness to be a reference for others. :)

Re: 10 years-ish of Elixir

#78

Post by sodapopcan » Thu, Jan 14, 2021, 7:31 PM UTC

desmondmonster wrote: post #59

likortera wrote: post #55

Earlier quoted context omitted.

The folks you're talking about are a lot more expensive (in Europe at least) than the equivalent folks for more traditional platforms. Again, and without centering ourselves in pure technical and our own careers and CVs. How does that help the business?. Regarding to libraries, there's not much to discuss. Just look at the number of available packages as right now: rubygems: 164,235 (source: https://rubygems.org/stat…

Ironically, Europe has a higher concentration of Elixirists given Erlang was invented there. My hiring attitude is that paying for senior developers is cheaper in the long run given their ability to make better decisions. > I wonder if what your team of 3 people is building couldn't have been built with just one engineer and ruby on rails at the expense of paying for two more servers. Emphatically no. Having more ser…

> While other package ecosystems certainly have _more_ packages, the question is: how many of those will you actually use?

Exactly. Saying NPM has millions of packages is completely misleading. There will be 20, 30, 40 packages that all do the same thing.

Elixir is also a very stable language with no current plans for a 2.0 release. This means that while a lot of Hex packages may not have been updated in a while, they are still rock solid. I agree that this is a very hard thing to get used to since the first thing I always do is looked at the last commit date and then the number of stars. While this is still useful, it doesn't hold the same weight it does in other ecosystems. Personally, I think this is how it should be.

I won't say that the Elixir ecosystem is perfect, though. There has been trouble with maintainers leaving projects, but to knowledge someone always steps up.

Re: 10 years-ish of Elixir

#79

Post by sodapopcan » Thu, Jan 14, 2021, 7:39 PM UTC

desmondmonster wrote: post #59

likortera wrote: post #55

Earlier quoted context omitted.

The folks you're talking about are a lot more expensive (in Europe at least) than the equivalent folks for more traditional platforms. Again, and without centering ourselves in pure technical and our own careers and CVs. How does that help the business?. Regarding to libraries, there's not much to discuss. Just look at the number of available packages as right now: rubygems: 164,235 (source: https://rubygems.org/stat…

Ironically, Europe has a higher concentration of Elixirists given Erlang was invented there. My hiring attitude is that paying for senior developers is cheaper in the long run given their ability to make better decisions. > I wonder if what your team of 3 people is building couldn't have been built with just one engineer and ruby on rails at the expense of paying for two more servers. Emphatically no. Having more ser…

Ooo, I'd also mention that there often isn't a need for a lib. For example, as outlined in The Little Ecto Cookbook, it's trivial to build a small fixtures framework—the API is two one-liner functions! Sure, it's missing a few things, but I've been using it on my own project and have not missed anything provided by dedicated fixtures lib.

Re: 10 years-ish of Elixir

#80

Post by conradfr » Thu, Jan 14, 2021, 7:41 PM UTC

likortera wrote: post #48

cpursley wrote: post #45

Earlier quoted context omitted.

> once they learn they move away to bigger companies which pay more Maybe consider paying your people more or moving to a better company?

> Maybe consider paying your people more Salaries are actually pretty good. Not facebook salaries, but good enough and certainly above average. The company can already get very proefficient, experienced developers in Ruby and JavaScript. > moving to a better company? I certainly could. But how does this solve the business problem I'm talking about? The reason I'm not moving to another place and instead helping transi…

So, totally disinterested question, can you name those companies paying well for Elixir in Europe? :)

Otherwise I agree with a good part of your post. For CRUD work I feel way more productive with PHP/Symfony than with Elixir/Phoenix, especially for outputting HTML. Part of it is the DX with the templating and type hinting but also the unbeatable amount of libraries and manpower behind the language and framework.

Otherwise the plugin for Jetbrain's IDEs works OK for me (but again it can't beat the Symfony plugin with PHPStorm features).