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

Erlang/OTP by Example

erlangbyexample.org

Post reply on HN
Print view View original

81–90 of 108 posts

Re: Erlang/OTP by Example

#81

Post by lenkite »

ilovecaching wrote: post #19
plainOldText wrote: post #17

Earlier quoted context omitted.

Rust has too big of a learning curve, and it's quite complex for writing service oriented systems. Granted, having a static compiler eliminates many types of bugs found in other systems. In my opinion a more sensible approach is Elixir + Rust (via rustler). Your get the elegance and productivity of Elixir, the concurrency and fault tolerance of Erlang/OTP, while still being able to writing super fast, low level code…

I don't buy this argument. Erlang does have a steep learning curve, but it isn't the semantics of the language, it's understanding how to build and deploy OTP applications. Understanding apps, releases, clustering, mnesia, process registries, circuit breaking etc. all take time. It also will cost you hours, and hours, and hours down the road when you have a large sprawling app with very little abstraction and no -spe…

I have been following this thread with interest. Wouldn't Golang (over Erlang/Rust) be the ideal language here for scalable microservices ? Comes with in-built concurrency, all your afore-mentioned container orchestrators are written in Go-Lang and it comes with first class support for gRPC. Very stable, very easy to learn, a terrific concurrency model, great libraries for network programming, productive right off the bat and compiles to container-friendly binaries.

Re: Erlang/OTP by Example

#82

Post by richjdsmith »

innocentoldguy wrote: post #76
the_clarence wrote: post #49

I'm kind of sad that Elixir is getting all the love and the cool resources since I much prefer Erlang's syntax. Thanks for this page!

I love Erlang too, but I don't think Elixir's popularity is stealing love away from Erlang. If anything, I think Elixir compliments Erlang and provides a path for people to enter the world of Erlang, BEAM, and OTP that they didn't have before. Elixir helped to lower the bar of entry. My understanding is that the Elixir team has also helped drive some improvements in Erlang, which is nice. Personally, I love both Erla…

I agree wholeheartedly. Elixir gave me an opportunity to start to play around with Erlang and OTP. While I prefer using Elixir, its ability to mix and match with Erlang has made it a great gateway.

Re: Erlang/OTP by Example

#83

Post by michaelcampbell »

throwaway487548 wrote: post #57
sumnulu wrote: post #37

Earlier quoted context omitted.

Very happy with Akka. It is fast (thanks to JVM), has lots of build-in building blocks / modules and documentation covers everything, also community is very helpful. https://akka.io/docs/

JVM can't be really fast, since it does lots of context switching when doing I/O, with locking and busy waiting, JNI string conversions, useless buffer copying, etc, etc.

https://martinfowler.com/articles/lmax.html

Yes, yes it can.

Re: Erlang/OTP by Example

#84

Post by jeremyjh »

ilovecaching wrote: post #5

As someone who has worked two jobs now writing, deploying, and operating Erlang clusters, I recommend switching to Rust. Erlang requires a lot of TLC to get right, it's super slow, and it's hard to burst. Like, super hard to burst. Erlang nodes are meant to cluster as a k graph and never go down. Modern ops, especially container ops, does availability through ephemerality of services. The BEAM just doesn't like to be…

> It also enables event driven programming through tokio, which is a better fit for web servers than green threads (you're mostly waiting on the network)

This is a really strange thing to say. Erlang is still an event-driven I/O runtime, it just doesn't inflict the user with the burden of continuation passing like tokio does. What is the benefit of doing that yourself? Even with futures its far more verbose and awkward than it needs to be. And since the entire ecosystem is not built on this io system, you will always be finding libraries - even very popular ones, such as diesel - that are incompatible with it and forcing you into threadpools. Every library in use with BEAM uses async I/O in exactly the same way.

Re: Erlang/OTP by Example

#85

Post by pmontra »

ilovecaching wrote: post #69
pmontra wrote: post #67

Earlier quoted context omitted.

> The BEAM just doesn't like to be treated like cattle. So don't. Deploy using edeliver and give up docker for the Erlang / Elixir parts of the project. If you really can't, you might want to switch to a language with a runtime that plays more nicely with the container idea of the world, but I know companies that deploy Erlang with docker and they are happy with that. Purists frown at the idea but it works.

It's a major pain to run it in containers, and that extends beyond Docker. That's why I do advocate switching away from Erlang. Giving up on containerization isn't an option unless we want to manage two completely separate infrastructures, which we definitely do not want to do.

I think that those people I wrote about are running BEAM in containers as if it were PHP. No connections between nodes and a load balancer in front of the containers. That should leave them with the niceties of the language, most but not all of OTP, and almost none of the deployment woes people have when unfamiliar with BEAM.

Re: Erlang/OTP by Example

#86

Post by toast0 »

ilovecaching wrote: post #75
toast0 wrote: post #70

Earlier quoted context omitted.

Bursting is an interesting thought. I think, if you planned it out, it could be done -- subject to some constraints. It would be hard to burst stateful (mnesia) nodes --- schema operations require a lock across all the nodes in the schema, and that lock requires that the nodes not be in the middle of the 'log dumping' process (where the global transaction log gets divided into per table logs and such), which means lo…

Our nodes are stateful. We also wrote our own dist (I didn't write it, it could be a lot better). We also have good metrics on our spikes, we just have black friday where we need to burst like crazy.

Oh yeah, black Friday is crazy. For us, we've always been seeing that our annual big spike load ends up being our sustained daily peak in a few months, so we will need those nodes anyway.

Re: Erlang/OTP by Example

#87

Post by stplsd »

ilovecaching wrote: post #5

As someone who has worked two jobs now writing, deploying, and operating Erlang clusters, I recommend switching to Rust. Erlang requires a lot of TLC to get right, it's super slow, and it's hard to burst. Like, super hard to burst. Erlang nodes are meant to cluster as a k graph and never go down. Modern ops, especially container ops, does availability through ephemerality of services. The BEAM just doesn't like to be…

>and it's hard to burst. Like, super hard to burst

What exactly does 'burst' mean in this context?

Re: Erlang/OTP by Example

#88

Post by ilovecaching »

stplsd wrote: post #87
ilovecaching wrote: post #5

As someone who has worked two jobs now writing, deploying, and operating Erlang clusters, I recommend switching to Rust. Erlang requires a lot of TLC to get right, it's super slow, and it's hard to burst. Like, super hard to burst. Erlang nodes are meant to cluster as a k graph and never go down. Modern ops, especially container ops, does availability through ephemerality of services. The BEAM just doesn't like to be…

>and it's hard to burst. Like, super hard to burst What exactly does 'burst' mean in this context?

Bursting is when you need to add additional capacity to handle expected but higher than normal load for a brief period of time.

Re: Erlang/OTP by Example

#89

Post by ilovecaching »

jeremyjh wrote: post #84
ilovecaching wrote: post #5

As someone who has worked two jobs now writing, deploying, and operating Erlang clusters, I recommend switching to Rust. Erlang requires a lot of TLC to get right, it's super slow, and it's hard to burst. Like, super hard to burst. Erlang nodes are meant to cluster as a k graph and never go down. Modern ops, especially container ops, does availability through ephemerality of services. The BEAM just doesn't like to be…

> It also enables event driven programming through tokio, which is a better fit for web servers than green threads (you're mostly waiting on the network) This is a really strange thing to say. Erlang is still an event-driven I/O runtime, it just doesn't inflict the user with the burden of continuation passing like tokio does. What is the benefit of doing that yourself? Even with futures its far more verbose and awkwa…

This is an implementation detail that you have no control over. From the point of a view of a process, io is synchronous. This is very limiting. It's better to keep decisions of concurrency in libraries rather than bake it into the language.

Re: Erlang/OTP by Example

#90

Post by jeremyjh »

ilovecaching wrote: post #89
jeremyjh wrote: post #84

Earlier quoted context omitted.

> It also enables event driven programming through tokio, which is a better fit for web servers than green threads (you're mostly waiting on the network) This is a really strange thing to say. Erlang is still an event-driven I/O runtime, it just doesn't inflict the user with the burden of continuation passing like tokio does. What is the benefit of doing that yourself? Even with futures its far more verbose and awkwa…

This is an implementation detail that you have no control over. From the point of a view of a process, io is synchronous. This is very limiting. It's better to keep decisions of concurrency in libraries rather than bake it into the language.

Can you elaborate on the limits this imposes? What is it that you can do with direct access to an event loop that you cannot do in Erlang?
Post reply on HN