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

Joy of Elixir

joyofelixir.com

Post reply on HN
Print view View original

71–80 of 92 posts

Re: Joy of Elixir

#71

Post by 59nadir »

ams6110 wrote: post #67
59nadir wrote: post #65

Earlier quoted context omitted.

Learning how the BEAM works and the architectural decisions that make sense for running your system on it is the realistic growth path for any serious BEAM developer. This has nothing to do with any of the languages on the BEAM, but with what makes sense on the VM. Your assertion that abstraction is somehow not needed in "large complex systems" (this being completely undefinable, by the way) seems silly and I can ref…

50% less code? Can you provide some more specifics? That seems like a bold claim.

We use REST for both internal and external calls to services (a mistake, in my opinion) and while Erlang actually has frameworks for this, none of them are good and cowboy_rest requires lots of boilerplate. Doing it with Phoenix would cut out lots of entire modules and replace them with functions without paying any real cost.

I like Erlang, but there's no upside to using it instead of something else that runs on the BEAM, apart from making a basic library that you want to use both from Erlang and Elixir (I don't know what the situation for compiling Elixir with rebar3 is).

Effectively, Erlang is to Elixir what Java is to Kotlin, except there are even less performance differences and no compatibility issues. It makes perfect sense to learn Erlang syntax and learning the semantics of it will mean you've learned BEAM semantics, but you might as well do that in Elixir and actually have a better road to it.

Edit: I'd like to add that I find a general lack of tools for dealing with boilerplate in Erlang. It also has a generally outdated functional programming skew in that it doesn't at all facilitate pipelining and this makes it less attractive to make nice abstractions like Plug(0), for example. This is exacerbated by the fact that collections aren't abstracted over, so whenever you end up dealing with them there's lots of sighing and docs checking to see what the argument order was the week they designed that particular module and that particular function in that particular collection module.

0 - https://github.com/elixir-plug/plug

Re: Joy of Elixir

#72

Post by skrebbel »

ryanbigg wrote: post #53
adamkittelson wrote: post #2

I've certainly enjoyed Elixir as an nth programming language and the idea of Elixir as a 1st programming language is really interesting. I know I've seen at least one educator in the community speculate that Elixir (or FP languages in general) could potentially make great 1st programming languages because they're often conceptually easier than OOP languages and in many ways the difficulties people associate with lear…

Hi! Thanks for the kind comment :) I find it an interesting idea too. I mentor people at Culture Amp in Ruby and Elixir and I'm definitely finding Elixir easier to teach for a couple of main reasons: * It's Just Functions And Data™ * Inheritance isn't a thing * Functions either come from within the same module if they don't have a module prefix * Functions from other modules _must_ have a module prefix. * Immutabilit…

I beg to differ with most of your points:

* Inheritance isn't a thing, but behaviors and protocols are.

* Functions from other modules _must_ have a module prefix, except if the current module has `import` statements at the top or, worse, `use` statements which happen to run macros that in turn `import` stuff again. Phoenix does this with controllers, and it's a mess. A million unprefixed functions available and no clue where they come from. Also, you forgot about `Kernel`.

* Immutability, except when you inherit code that uses Agents all over (which is really just a Java Bean, a mutable object, or whatever you want to call it) and you lose it all again. Process state is mutable, and the smaller your processes are, the more your code starts to smell imperative.

In all honesty, if you add import, use, macros, behaviors and protocols to your list, then all in all there really is pretty much to learn. It's no C++, but I have a hard time calling Elixir simpler than Ruby.

Now, I think these are all good features (except Agents). They just make Elixir less simple, that's all.

Re: Joy of Elixir

#73

Post by jondubois »

bhauer wrote: post #33
jondubois wrote: post #31

Why is there so much Elixir hype on HN at the moment? HN shouldn't be used as a propaganda hype machine. I've seen all the language hype cycles, Year 1: PHP sucks! Node.js is awesome! Everyone must use Node.js! Year 2: Node.js sucks! Go is awesome! Everyone must use Go! Year 3: Go sucks! Rust is awesome! Everyone must use Rust! Year 4: Rust sucks! Elixir is awesome! Everyone must use Elixir! ... And of course you get…

I too feel there is a generational hype cycle at HN. However, I don't see much in the way of "language N sucks" as a precursor to "everyone should use language N1!" Maybe I am just blind to the negativity, but in general, what I see with each hype generation is only the positive side: "everyone should use language N1!" I suspect with any given hype generation—with each trending language—we're going to see a lot of po…

Adding more programming languages just fragments the job market further. That might mean fewer jobs available for other languages and allow software developers less movement between companies.

How many times have you seen a job advert and you think oh wow that looks interesting, I'd like to work there... Oh wait, they use X on the backend, I don't have any previous commercial experience with X so damn, I can't join the company. The more programming languages there are, the more often this will happen. The time for creating and promoting new programming languages is over, we have to move forward and work with the languages whose ecosystems have had 20 years to evolve - This is where the real value is.

I'm certain that using Elixir over Haskell, Go or even JavaScript/Node.js adds no extra value to any given project... It only restricts the pool of potential job candidates.

If you use any programming language for long enough, eventually, you will be very productive with it - The language itself doesn't really matter.

Its just a waste because there are already so many languages optimized for the server-side use cases which Elixir aims for and which are already doing a great job.

Re: Joy of Elixir

#74

Post by robert_tweed »

RodericDay wrote: post #46
zensavona wrote: post #43

Earlier quoted context omitted.

I have first hand experience with this actually... Over the last 6 months or so a good friend of mine has learned to code from scratch. After much deliberation I took a gamble and set him up with Elixir as his first language (largely because he wanted to code so he can work with me on some projects, which use Elixir). I am really happy with this choice and so is he. Elixir is a language with very consistent ideas thr…

Python has the same via help(thing)

As does Clojure with doc. However, neither of these include examples as standard. Idiomatic docstrings tend to be a short string; one sentence or paragraph.

Re: Joy of Elixir

#75

Post by s_kilk »

zensavona wrote: post #43
adamkittelson wrote: post #2

I've certainly enjoyed Elixir as an nth programming language and the idea of Elixir as a 1st programming language is really interesting. I know I've seen at least one educator in the community speculate that Elixir (or FP languages in general) could potentially make great 1st programming languages because they're often conceptually easier than OOP languages and in many ways the difficulties people associate with lear…

I have first hand experience with this actually... Over the last 6 months or so a good friend of mine has learned to code from scratch. After much deliberation I took a gamble and set him up with Elixir as his first language (largely because he wanted to code so he can work with me on some projects, which use Elixir). I am really happy with this choice and so is he. Elixir is a language with very consistent ideas thr…

How does your friend deal with Processes, OTP, Supervision trees and so on?

I'm a huge Elixir fan, but always thought it would be a hard first language because of OTP, the benefits of which are kinda hard to appreciate without some experience making production software. Happy to be wrong on that though.

Re: Joy of Elixir

#76

Post by jaylynch »

yorwba wrote: post #68
jaylynch wrote: post #59

Earlier quoted context omitted.

When I went to university for CS, Haskell was used in the introductory programming courses and this was one of the main reasons we were told about. Another goal was to take the people who had been learning to code in their spare time and put them on more even footing with those who were totally new, force them to think about things from first principles rather than lean on acquired habits, etc. I had already been cod…

> Another goal was to take the people who had been learning to code in their spare time and put them on more even footing with those who were totally new The thinking behind that is usually a bit fallacious, though. Say the department has been teaching Java in the introductory programming course, and noticed that some people already know most concepts. Then they decide to use a different language to "level the playin…

It was a long while ago now, if you had learnt anything before you got there it was pretty much guaranteed that you'd seen either BASIC or C. :)

The internet wasn't what it is now either so most people who had done some coding before were indeed lacking in understanding of the fundamental principles of what they were doing – I know I certainly was. There may have been outliers yet beyond the "I've been playing with code" crew but I didn't meet any.

I'm not at all suggesting it would be good reasoning today, but I think it helps to show that the underlying idea that FP is a good way to introduce people to code whilst ensuring they develop a strong theoretical understanding was true then and should still be today.

Re: Joy of Elixir

#77

Post by Hates_ »

bitwalker wrote: post #66
cordite wrote: post #29

While I applaud creating documentation, books, and guides for those new to the language, there's still a significant accessibility gap in resources. I already know the language, I've already done some basic stuff in phoenix, I've even made my own HTTP API wrapper as its own library. But when it comes to architecting backend systems that aren't tied to phoenix or playing around with IEx, I really feel like I am on my…

I'm actually working on a book which I think covers a lot of what you're looking for (and was what I wanted back when I got started with Elixir a few years ago). I'm covering architectural patterns for the items you mentioned as well as flow control and digging in deep on how to really leverage the fault isolation mechanisms of OTP. I'm the maintainer of Distillery, the release tooling in Elixir, so I'm also covering…

Do you have a mailing list I can sign up to to stay notified?

Re: Joy of Elixir

#78

Post by bsaul »

jondubois wrote: post #31

Why is there so much Elixir hype on HN at the moment? HN shouldn't be used as a propaganda hype machine. I've seen all the language hype cycles, Year 1: PHP sucks! Node.js is awesome! Everyone must use Node.js! Year 2: Node.js sucks! Go is awesome! Everyone must use Go! Year 3: Go sucks! Rust is awesome! Everyone must use Rust! Year 4: Rust sucks! Elixir is awesome! Everyone must use Elixir! ... And of course you get…

don't understand why you got downvoted, it's a pretty legitimate concern.

You may however see the whole thing a bit differently :

- node popularized single loop event on the server side, which is great for fast low cpu request processing

- go evangelized simple design, coroutines , unique code formating, and has arguably one of the best stdlib. That's still true today and it's great

- Rust made people realize writing concurrent truelt safe code was possible. Huge advance.

- Elixir helped the community focus again on actor + message passing concurrency. It's fantastic.

All of those concepts are beneficial to learn, for you as a programmer, no matter which language you use.

If for example look at swift evolution, you'll see the current threading model (based on event loops, like node, because of iOS) discussed and compared to the actor model ( like erlang / elixir), but also that some web framework reimplemented go-style concurrency. You'll also see that they're talking about adding semantic for detecting memory sharing patterns (much like rust).

If you've followed all the discussions on those languages for the last two years you know exactly why those conversations are taking places. So all in all it's a good thing communities are advocating the strenghts of their language. It helps everyone improve.

Re: Joy of Elixir

#79

Post by passer-by-123 »

skrebbel wrote: post #72
ryanbigg wrote: post #53

Earlier quoted context omitted.

Hi! Thanks for the kind comment :) I find it an interesting idea too. I mentor people at Culture Amp in Ruby and Elixir and I'm definitely finding Elixir easier to teach for a couple of main reasons: * It's Just Functions And Data™ * Inheritance isn't a thing * Functions either come from within the same module if they don't have a module prefix * Functions from other modules _must_ have a module prefix. * Immutabilit…

I beg to differ with most of your points: * Inheritance isn't a thing, but behaviors and protocols are. * Functions from other modules _must_ have a module prefix, except if the current module has `import` statements at the top or, worse, `use` statements which happen to run macros that in turn `import` stuff again. Phoenix does this with controllers, and it's a mess. A million unprefixed functions available and no c…

I would say the difference is that you can start small. You can start thinking about functions and data and you can build a large amount of software with the simpler abstractions. I would say this is not specific to Elixir but to functional languages. A good amount of my code is just functions and data. Processes, macros, protocols, etc come only when strictly necessary.

Re: Joy of Elixir

#80

Post by notamy »

ryanbigg wrote: post #64
notamy wrote: post #8

There seems to be an unfortunate number of "TODO: Add image here"-type blocks in this. Other than that, a quick glance seems good to me.

Yup, sorry about that! I am a _horrible_ artist and so I'm hoping to rope a good friend of mine in to help with that. He's recently started a new job and so he's been busy. One day there'll be some great images in the book.

Can't wait to see them! I really like the book so far :)
Post reply on HN