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

51–60 of 88 posts

Re: The BEAM Has Spoiled Me

#51

Post by rcxdude »

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)

git, for example, can do this on a large repository when checking for updated files (because it needs to check the modification timestamp of every file in the repo), and for a lot of common operations it's actually the bottleneck (and one reason why it is often faster on linux: the VFS layer in linux puts a lot of effort into making such operations as fast as possible, somewhat appropriately Linus was the one who did a lot of that work originally). In C it works pretty much as expected, and most of the overhead is in the kernel.

Re: The BEAM Has Spoiled Me

#52

Post by dmitriid »

tluyben2 wrote: post #50
dmitriid wrote: post #42

Earlier quoted context omitted.

> I'd say 19 out of 20 engineers I've spoken to don't really leverage BEAM. That's because most tasks we as engineers write rarely have the need for distribution or parallelism. It's mostly "get data A, get data from B, mix, save resulting data C". nd when you need to do that in parallel, you through it in Kubernetes, or Apache Beam. It's even more pronounced in web/microservices situations because the web server tak…

Apache Beam I see, but what has Kubernetes to do with getting and mixing data in parallel?

You an automatically scale instances up until there are enough to process incoming requests.

Re: The BEAM Has Spoiled Me

#53

Post by OkayPhysicist »

hazz99 wrote: post #32
OkayPhysicist wrote: post #31

Earlier quoted context omitted.

Phoenix takes a little bit of reading to figure out (though the documentation is brilliant, and really easy to read). Once you understand how it works, though, creating an API is extremely straightforward. It's amazing.

I just couldn’t get past ecto! It never seemed to “click” for me. Maybe I need to go back and learn it more in-depth, it sounds like it’ll be fantastic once I get the hang of it.

The trick to Ecto is that it serves as a separation between your data storage, and your data representation in your code. Basically, there're 3 parts.

The first part is your schema. It defines an Elixir struct that is your domain model of your data.

The second idea/part is the concept of a changeset. It represents a change you'd like to make to the data store, but haven't yet. These are composable, so you can bundle a bunch of changes into a single, atomic unit, which you then send to your repo. If any part fails, then the whole thing fails, no changes are made to the persisted data.

The last thing is migrations, which strictly speaking are optional, but a huge convience. They define how you'd like your database to be structured. The cool thing about them is that they define rollback operations automatically.

Once Ecto "clicks", it really becomes a strong selling point to the language as a whole. It makes working with persisted data super easy.

Re: The BEAM Has Spoiled Me

#54

Post by OkayPhysicist »

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.

Re: The BEAM Has Spoiled Me

#55

Post by perfect_kiss »

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…

> The tools for introspection are amazing. I recently debugged a production issue by opening a console connected to a running system, and calling the functions I suspected to be failing to see what they were returning directly. Not sure if any other language has that facility.

twisted/python has had manhole facility since early 2000s, I still sometimes use it to day

http://www.lothar.com/tech/twisted/manhole.xhtml

Re: The BEAM Has Spoiled Me

#56

Post by OkayPhysicist »

cuddlecake wrote: post #33
amgreg wrote: post #15

> Some teams are happy to use Elixir to write web applications, to fit it into their pre-existing microservice deployment model. I urge developers to reach for those bigger thoughts that fault tolerant lighweight processes enable. You can consider each process a logical microservice, but you don’t need the friction of deploying it separately, and serializing to/from json, and containers, and orchestration, and distri…

I think the author's use of the microservices is unfortunate and confusing. With the BEAM, it is easy to create fully independent process trees. The architecture enables it. In fact, you can pull in dependencies and add them as "OTP applications" (which is in essence a fully independent process tree, doing its thing.) The BEAM lends itself very well to structuring parts of your application as independently supervised…

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.

Re: The BEAM Has Spoiled Me

#57

Post by OkayPhysicist »

m463 wrote: post #27

I'm reading all this and wondering what BEAM is.

The BEAM is the virtual machine that runs Erlang, Elixir, and a handful of other languages. It's basically a system for managing a massive number of small, independent processes that communicate through message passing.

Re: The BEAM Has Spoiled Me

#58

Post by sho »

dodobirdlord wrote: post #18
amgreg wrote: post #15

> Some teams are happy to use Elixir to write web applications, to fit it into their pre-existing microservice deployment model. I urge developers to reach for those bigger thoughts that fault tolerant lighweight processes enable. You can consider each process a logical microservice, but you don’t need the friction of deploying it separately, and serializing to/from json, and containers, and orchestration, and distri…

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. But in startups tearing forward at full speed with limited crew it's a pipe dream. The better solution is for proper source control management, so problematic changes that are actually independent can be reverted effectively, leaving everything else alone.

Re: The BEAM Has Spoiled Me

#59

Post by s3cur3 »

SmooL wrote: post #7
jefflombardjr wrote: post #3

Earlier quoted context omitted.

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

Honestly the docs themselves are excellent https://elixir-lang.org/getting-started/introduction.html

It’s the only language I’ve used where just going step by step through the official docs was enough to pick up the language. Took me maybe a day and a half.

Re: The BEAM Has Spoiled Me

#60

Post by cultofmetatron »

hazz99 wrote: post #32
OkayPhysicist wrote: post #31

Earlier quoted context omitted.

Phoenix takes a little bit of reading to figure out (though the documentation is brilliant, and really easy to read). Once you understand how it works, though, creating an API is extremely straightforward. It's amazing.

I just couldn’t get past ecto! It never seemed to “click” for me. Maybe I need to go back and learn it more in-depth, it sounds like it’ll be fantastic once I get the hang of it.

For me ecto was a breath of fresh air. When I look at an ecto query, I'm never guessing about the output sql. It doesn't try to make relational queries look like objects. Often times I think, "how would I do this in sql" and there's usually a matching Ecto.Query operator that handles that.
Post reply on HN