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

81–88 of 88 posts

Re: The BEAM Has Spoiled Me

#81

Post by AlchemistCamp »

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.

Anything written after 1.3 is almost completely applicable today.

The auth generator is just a new feature. Learning how the pieces work from the book is still worthwhile.

My advice if you want to avoid confusion as you're learning is to just use the same version of Phoenix the book does! (1.4 in this case)

After you go through it, you can follow the official upgrade guides in just a few minutes.

Re: The BEAM Has Spoiled Me

#82

Post by QuadrupleA »

ggv wrote: post #75
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…

Thanks - appreciate the reply (and the other helpful replies here too). I've done a fair bit of threaded / async stuff in Python / C / JS - sounds like BEAM processes are more baked into the language & runtime and encouraged as an architectural style, rather than an added complexity you bargain with when you hit a single-threaded performance wall. Interested to do a deeper dive on it sometime.

Re: The BEAM Has Spoiled Me

#83

Post by busterarm »

tluyben2 wrote: post #48
busterarm wrote: post #24

Earlier quoted context omitted.

The problem there is that your coworkers working in those languages who don't have Erlang/Elixir experience have not internalized those lessons yet and they're not going to understand why you're doing what you're doing when they review your code. Edit: I remember an interview that I had once with a team that was trying to bring on a senior to improve their PHP code and they were really unused to the code style I used…

This is a problem with 'theoretical' (books/uni 'experience') and 'IBM thinking' (people are more expensive than adding more machines, so always optimize for using less people time; just add machines... says the hardware (and per core software license) vendor. Amazon AWS agrees!) people is that they lack the real life experience where things do not fit in 'best practices' (as in design patterns) or green field archit…

I also think that while these engineers all went to schools where they got both high level and low level programming under their belts, not enough of them really made the connection to understand what their code actually makes the computer do, aside from in the theoretical sense (Big O).

We're not really training enough truly full-stack engineers.

Re: The BEAM Has Spoiled Me

#84

Post by busterarm »

dnautics wrote: post #39
m12k wrote: post #37

Earlier quoted context omitted.

Off the top of my head, Go and goroutines are built around message-passing as well. And Scala/Java with Akka seems pretty well-established at this point too - although it'll likely never have as broad support as something built into the language like Elixir and Go has.

None of those other systems have solid failure-domain oriented programming baked in. Let's say there's a netsplit and you want your connection to bring down two other processes that depend on it, self-heal when the netsplit is resolved, and not have any other resources associated with the process leak (memory, file descriptors, resource pools, database connections, etc). This is like maybe two lines of elixir/erlang.

Also, error handling seems to be the worst part of working with Go by miles. I can't even imagine building such a system in the language.

Re: The BEAM Has Spoiled Me

#85

Post by dodobirdlord »

sho wrote: post #58
dodobirdlord wrote: post #18

Earlier quoted context omitted.

Release independence? If one team has a regression and needs to roll back their week's release, everyone gets rolled back too.

From my experience with microservices, this is kind of a utopia that never happens. What actually would happen is that everyone else's service is dependent on the new feature that the problematic service delivered, so they're all going to be rolled back anyway. Maybe in very large, mature companies this happy land of backwards compatible, fully independent microservices, deployed totally independently, is possible. B…

It's certainly true that microservices can be set up in such a way that they're really a distributed monolith. But you don't have to be a large, mature company to apply microservice best practices. A foundational best practice of microservice development is that each service has a staging environment that uses the prod endpoint for every service it depends on, and this is where you run acceptance tests prior to release. This way the staging behavior before release aligns with the prod behavior after release.

The week N release for microservice A won't have a dependency on a new feature in the week N release for microservice B, because the staging environment for microservice A (at release N) calls into the prod environment of microservice B (at release N-1), so the release-blocking tests wouldn't have passed.

It is a common and critical antipattern to have a single staging environment across multiple services, where each service calls the staging environment of each other service. This is a disaster waiting to happen for just the reason you describe.

Re: The BEAM Has Spoiled Me

#86

Post by mercer »

AlchemistCamp wrote: post #81
bigbassroller wrote: post #45

Earlier quoted context omitted.

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.

Anything written after 1.3 is almost completely applicable today. The auth generator is just a new feature. Learning how the pieces work from the book is still worthwhile. My advice if you want to avoid confusion as you're learning is to just use the same version of Phoenix the book does! (1.4 in this case) After you go through it, you can follow the official upgrade guides in just a few minutes.

I'll add that learning how to roll your own auth with the book and /then/ using the auth generator is a great learning experience.

Re: The BEAM Has Spoiled Me

#87

Post by hvis »

oli_b wrote: post #80
hvis wrote: post #63

Earlier quoted context omitted.

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

> is ActiveRecord much maligned?

Well, take the numerous articles extolling the virtues of Sequel, or DataMapper, or, related to the current discussion, Ecto itself. Like how expressive this stuff is. And how ActiveRecord creates a too huge API surface on models, and that that leads to bad design, etcetera. Now to mention the callbacks, which are admittedly problematic.

But then I try those aforementioned libs and see sharp corners like terrible argument validations (in case of Sequel) which lead to silently failing code, or actual hard limitations on what I can ask Ecto to do without resorting to meta-programming.

> I also haven't ever found a good replacement for AR migrations

IME, both Sequel and Ecto migrations are fairly serviceable. But neither provides the schema dumping feature that AR has. Which is pretty handy.

Re: The BEAM Has Spoiled Me

#88

Post by hinkley »

busterarm wrote: post #83
tluyben2 wrote: post #48

Earlier quoted context omitted.

This is a problem with 'theoretical' (books/uni 'experience') and 'IBM thinking' (people are more expensive than adding more machines, so always optimize for using less people time; just add machines... says the hardware (and per core software license) vendor. Amazon AWS agrees!) people is that they lack the real life experience where things do not fit in 'best practices' (as in design patterns) or green field archit…

I also think that while these engineers all went to schools where they got both high level and low level programming under their belts, not enough of them really made the connection to understand what their code actually makes the computer do, aside from in the theoretical sense (Big O). We're not really training enough truly full-stack engineers.

I walked out of college having made a game of one-upmanship with a friend (easy CS homework days, we’d compete against each other over runtime or algorithms), onto a project whose UI was so slow you could watch the screen paint itself. It was so bad I was ashamed to be associated with the project, but I moved a long way so I stuck it out for a bit, until it was respectable. I think I learned as much about performance tuning in the next six months as most people do in their entire careers. A couple jobs later and I could write a few chapters of an advanced book on performance analysis (in particular perf logs tend to hide critical info in plain sight).

We mostly just don’t care, and too many of us have honed or at least mislearned excuses for our behavior that business folks have no way to talk us out of. Most vexing for me is when customers threaten to leave over performance and the senior staff pull up some graphs that say we have done all we can. It’s fairly straightforward to climb the ranks on such a project by proving them wrong. These sorts often leave 2-3x (that I know how to find, who knows what he real number is) on the table, which is often enough to satisfy the customer. It’s often hard work but there’s nothing magic about it.

Post reply on HN