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

The BEAM Has Spoiled Me

gvaughn.github.io

Post reply on HN
Print view View original

71–80 of 88 posts

Re: The BEAM Has Spoiled Me

#71

Post by categorybooks »

bigbassroller wrote: post #45
AlchemistCamp wrote: post #12

Earlier quoted context omitted.

For me personally, Programming Elixir and Programming Phoenix , from the Pragmatic Bookshelf, were both very useful. Quite a few of my students have said great things about Phoenix in Action , from Manning, and it looks to me like a fantastic resource for beginners. Elixir in Action is also top-notch and will show you what's special about the BEAM.

To those out there learning from “Programming Phoenix”, although is the best resource for lay of the land of Phoenix, the content is getting out dated with the rise of auth generator and the context model has also changed a lil bit. It takes diligence in following along and referencing the documentation to not get stuck. Great book though.

What would you suggest as a more up-to-date alternative?

Re: The BEAM Has Spoiled Me

#72

Post by GordonS »

OkayPhysicist wrote: post #54
dynamite-ready wrote: post #44

I've written a decent amount of Elixir for a personal project, and have come to a few conclusions. For a start, it's very different. That will become self evident if you try to learn either Erlang or Elixir, when coming from a language like Python/C++/etc (and though Elixir looks a lot like Ruby, it's still more like Erlang, tbh). So that can be classed as a negative. Secondly, fault tolerance in Erlang/Elixir/OTP is…

Great overview, but I'd have to disagree about being different being a negative. If you try to emulate what came before, then you miss out on the opportunity to build something better. The whole Ford and his better horse thing.

I might have misunderstood, but I took the comment to mean looking more like Erlang was a negative? Erlang's syntax is really divisive - just looking at Erlang code makes my head want to burst!

Re: The BEAM Has Spoiled Me

#73

Post by atulatul »

jefflombardjr wrote: post #3
grantjpowell wrote: post #2

The BEAM is great, but the Elixir language itself is really what spoiled me. After having written ruby for years, I really enjoy what the Elixir language has to offer. Pattern matching[0] and the pipe operator[1] eliminate a ton of intermediate variables. Functional programming took a while to get used to, but I'm really starting to like thinking immutably. Now that I'm more advanced in the language, I'm starting to…

Can you recommend any learning materials that were particularly useful to you?

Disclaimer: This is primarily about language... not BEAM as such. Also, links are inline.

I liked the book Programming Elixir 1.6 By (Pragmatic) Dave Thomas. Solved the exercises. Did not quite find use for macros. And I have not done any production projects.

The pragmatic studio has some courses for the space: elixir, OTP, LiveView, etc. and free tutorials. The quality is good. Simon Thomson's course on futurelearn was also good. https://pragmaticstudio.com/ and https://www.futurelearn.com/

A recurrent problem for me though has been to write an application. I used to write java's petclinic/petstore application when learning a framework, library, etc. Have not been able to do so with some other ecosystems... perhaps laziness, perhaps have not been able to answer why. And languages in isolation have not clicked for me much apart from maybe making me think in different ways.

Why does this Erlang/Elixir/BEAM interest me then? A colleague who talked highly of it... Then there's Joe, his talks, and Alan Kay's recommendation has Joe's thesis on recommended reading list: https://news.ycombinator.com/item?id=20653453

There is also Erlang Masterclass series 1,2,3 starting here: https://www.youtube.com/playlist?list=PLR812eVbehlwEArT3Bv3U...

Re: The BEAM Has Spoiled Me

#74

Post by princevegeta89 »

malinens wrote: post #69
princevegeta89 wrote: post #46

I still write Elixir only, and don't really leverage BEAM (not yet) but the sheer performance of the system amazes me. Phoenix is very largely scalable, and makes some really clever decisions in terms of architecture unlike Rails/Django. The learning curve has been a little steep and there is a paradigm shift but I've encountered situations where it really ended up helping me navigate through code with precision and…

all languages I know have async tests

But, are they truly async?

Re: The BEAM Has Spoiled Me

#75

Post by ggv »

QuadrupleA wrote: post #8

Article piqued my interest, but also left me scratching my head a bit - everything mentioned is kinda vague / abstract. Elixir/BEAM are "better" but better than what? Curious the author's prior language experience. What's he developing with it exactly? Native apps? Web stuff? Or just learning / experimenting? Didn't really understand how the Elixir / BEAM approach is different from typical threads, OS processes, or a…

Hello, OP here. Yes, I was intentionally abstract because I thought I was writing to a smaller audience of people who had spent some time with Elixir/BEAM. I never expected the attention this has received!

In my 25 year career, I've been paid to work in Lotus Notes, Java, C#, Javascript, Ruby, Clojure, and now Elixir. My employer's system is basically an integration platform. We perform background tasks on behalf of our customers that access 3rd party APIs, our database, and then decide to push some data to other systems. We do have a web interface that is mostly the status of this background processing, plus a UI for when the users need a manual action.

There's other great replies touching on your technical questions, but here's my brief angle on it. BEAM processes are as isolated as OS processes, but they are very quick to spawn and need very little memory. A typical developer-caliber laptop computer can probably support on the order of a quarter million processes. Their isolated nature is supported at all levels of the design of the BEAM.

Re: The BEAM Has Spoiled Me

#76

Post by ggv »

cuddlecake wrote: post #66
OkayPhysicist wrote: post #56

Earlier quoted context omitted.

What's the practical difference between a "real" microservice and an independent process tree potentially running on a different machine? Erlang/Elixir really doesn't have any trouble being distributed across multiple nodes, you just get a lot more latency on your messages.

You're correct, there's barely any difference, from a structural point of view. I was mainly taking issue with the author's comparison of processes with microservices: > You can consider each process a logical microservice But as you said, the process trees can be considered (micro)services, but I wouldn't say that each process represents a microservice. It's just not accurate in my opinion.

OP here. You make a valid point. I was speaking in generalities in a short high-level blog post. I liked microservices better the first time when it was called SOA (service oriented architecture) in which there was an emphasis on the logical encapsulation of services. How they were to be deployed was a separate concern.

I was really trying to emphasize the logical separation vs. deployment separation and not the "micro" nature. Thanks for picking up on that.

Re: The BEAM Has Spoiled Me

#77

Post by bostonvaulter2 »

princevegeta89 wrote: post #46

I still write Elixir only, and don't really leverage BEAM (not yet) but the sheer performance of the system amazes me. Phoenix is very largely scalable, and makes some really clever decisions in terms of architecture unlike Rails/Django. The learning curve has been a little steep and there is a paradigm shift but I've encountered situations where it really ended up helping me navigate through code with precision and…

> I still write Elixir only, and don't really leverage BEAM (not yet)

Since you're using Phoenix you are already reaping the benefits of the BEAM because Phoenix helps you use good patterns with regard to process isolation. In many web apps you won't really need to deal directly with OTP for quite a while (unless you're doing something rather specialized).

Re: The BEAM Has Spoiled Me

#78

Post by princevegeta89 »

bostonvaulter2 wrote: post #77
princevegeta89 wrote: post #46

I still write Elixir only, and don't really leverage BEAM (not yet) but the sheer performance of the system amazes me. Phoenix is very largely scalable, and makes some really clever decisions in terms of architecture unlike Rails/Django. The learning curve has been a little steep and there is a paradigm shift but I've encountered situations where it really ended up helping me navigate through code with precision and…

> I still write Elixir only, and don't really leverage BEAM (not yet) Since you're using Phoenix you are already reaping the benefits of the BEAM because Phoenix helps you use good patterns with regard to process isolation. In many web apps you won't really need to deal directly with OTP for quite a while (unless you're doing something rather specialized).

Well, yeah, I'm aware of the fact that I'm leveraging BEAM. What I rather meant was I haven't gotten creative with using the OTP ecosystem for my project just yet.

Sorry I should have framed it better.

Re: The BEAM Has Spoiled Me

#79

Post by ridiculous_fish »

cuddlecake wrote: post #35
ridiculous_fish wrote: post #19

How does BEAM handle system calls? If I have a million BEAM processes and each one calls stat(), what happens?

What do you expect to happen in other languages, when your program makes a million calls to `stat()`? Is that something that happens often? What kind of application needs that? Is there a language that solves this neatly? (I'm genuinely curious, independent of my newbie elixir evangelism)

This problem doesn't arise in a 1-1 language like C, because the thread spawning will either fail or have obviously terrible performance. These languages push you into using work queues, etc. immediately.

But in languages with green threads (like Go), you CAN spawn a million threads and performance will be fine, until you make a syscall.

An example of how this can happen: I once wrote a Go tool that walks the filesystem. I spawned a new thread for every directory, thinking that Go only has ~N kernel threads so performance will be fine. I was shocked to see that, in this scenario, it spawns a kernel thread for every green thread!

Re: The BEAM Has Spoiled Me

#80

Post by oli_b »

hvis wrote: post #63
dnautics wrote: post #38

Earlier quoted context omitted.

It's definitely not an orm, as it was stolen from c# linq. Imo this is actually much better than an orm because it really hits home that the data in memory are stale as soon as you receive them because database transactions are explicit, and not hidden behind getters and setters. ORMs can get you into trouble because they try really hard to hide the problem of distributed state and sources of truth.

Coming from (the much-maligned) ActiveRecord, I wasn't really impressed. It has this cute macro-based syntax, and that seems to inform even the "functional" API as well. Yet when you I wanted to do something just a bit more advanced like joining on an association whose name I don't know in advance (or, say, want to parameterize the function with), I had to resort to writing a macro myself and then eval-ing it an runt…

I had the same experience, but now I'm wondering - is ActiveRecord much maligned? It is news to me. It handles simple stuff really well, takes a lot of the pain out of relationships, and doesn't prevent you reaching for SQL when required. I also haven't ever found a good replacement for AR migrations, which makes schema changes + keeping a record of those changes absolutely seamless. Are there some alternatives I should be investigating?
Post reply on HN