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

101–108 of 108 posts

Re: Erlang/OTP by Example

#101

Post by _asummers »

elcritch wrote: post #99
_asummers wrote: post #95

Earlier quoted context omitted.

> Elixir is overall a syntax that works well for me, at least as well as Rust’s. The Elixir team have made great strides in providing good compiler error messages, and are actively improving the distribution/ packaging story. Hex and mix are fantastic, and on par with what I’ve use in cargo. I'm working on making the dialyzer error messages better, too, in Dialyxir[0] and Erlex[1] =). [0] https://github.com/jeremyjh/…

Wow, thanks! I’ve kept up with your project and greatful for the work. Out of curiosity, have you seen anything in Dialyzer for dealing with typing GenServer messages and handlers? I haven’t figured out a way to spec message handlers as dialyzer seems to only check that you have any `handle_cast` implemented and adding a behavior doesn’t compose. Given the key role GenServer plays in OTP, it’s a big lack IMHO. I’ve w…

Nah because as soon as you deviate from the GenServer behaviour you'll get errors from not matching the @callback. The trick there is to provide a narrower API that calls into the GenServer functions with the proper @spec and treat the handle_cast and friends as private functions that you don't call directly. So like a pop/0 might call cast(:pop) and you'd have the associated handle_cast for :pop.

Re: Erlang/OTP by Example

#102

Post by elcritch »

_asummers wrote: post #101
elcritch wrote: post #99

Earlier quoted context omitted.

Wow, thanks! I’ve kept up with your project and greatful for the work. Out of curiosity, have you seen anything in Dialyzer for dealing with typing GenServer messages and handlers? I haven’t figured out a way to spec message handlers as dialyzer seems to only check that you have any `handle_cast` implemented and adding a behavior doesn’t compose. Given the key role GenServer plays in OTP, it’s a big lack IMHO. I’ve w…

Nah because as soon as you deviate from the GenServer behaviour you'll get errors from not matching the @callback. The trick there is to provide a narrower API that calls into the GenServer functions with the proper @spec and treat the handle_cast and friends as private functions that you don't call directly. So like a pop/0 might call cast(:pop) and you'd have the associated handle_cast for :pop.

Yah, that's the error I ran into. Creating function wrappers to send messages works well for client api's. However, it doesn't help verify that you've implemented the `handle_cast` properly or dealing with messages from other places. Normally it's not to big of an issue.

Re: Erlang/OTP by Example

#103

Post by erszcz »

elcritch wrote: post #93
ilovecaching wrote: post #63

Earlier quoted context omitted.

> One thing that's pretty frustrating about your comments, is how you both have an answer for everything but don't actually give any specifics, which makes it nearly impossible to actually address or consider your advice. What is it you want to know? I'm giving you my personal experience, not an essay. It's hard to find people who have professional experience with Erlang, so I thought it would be useful to other peop…

> What is it you want to know? I'm giving you my personal experience, not an essay. It's hard to find people who have professional experience with Erlang, so I thought it would be useful to other people who are evaluating it to hear from someone who has been there. I'm more than happy to dig into things more if there's a pointed question. While this whole comment thread has turned into a bit of flame war, I appreciat…

> I’d love to have a Rust "OTP" and actor system for IoT devices where Beam doesn’t fit.

You might want to check out Grisp - https://www.grisp.org/ - Erlang VM ported to RTEMS. They also offer devboards with ample resources designed to run this thingy.

Re: Erlang/OTP by Example

#104

Post by _asummers »

elcritch wrote: post #102
_asummers wrote: post #101

Earlier quoted context omitted.

Nah because as soon as you deviate from the GenServer behaviour you'll get errors from not matching the @callback. The trick there is to provide a narrower API that calls into the GenServer functions with the proper @spec and treat the handle_cast and friends as private functions that you don't call directly. So like a pop/0 might call cast(:pop) and you'd have the associated handle_cast for :pop.

Yah, that's the error I ran into. Creating function wrappers to send messages works well for client api's. However, it doesn't help verify that you've implemented the `handle_cast` properly or dealing with messages from other places. Normally it's not to big of an issue.

Yeah ideally those APIs are well scoped enough to be able to unit test them, but I agree there's some piece missing there.

Re: Erlang/OTP by Example

#105

Post by adamnemecek »

throwaway487548 wrote: post #56
ilovecaching wrote: post #19

Earlier quoted context omitted.

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…

Seems like you don't get it. In the comment above there is a suggestion that Erlang being well-researched and based on the right principles of FP is good-enough to build almost half of 4G platforms having crappy syntax, crappy VM, crappy everything but OTP itself. This is the point and the big deal. Rust is a mess of amateurish overcomplicated poorly understood hype-driven crap. Tokyo is utter bullshit (look how Erla…

> Rust is a mess of amateurish overcomplicated poorly understood hype-driven crap.

Please be more specific about the amateurism.

> Tokyo is utter bullshit (look how Erlang or Go solve the same problems with order of magnitude less lines of code),

No, they work in fundamentally different spaces.

Re: Erlang/OTP by Example

#106

Post by throwaway487548 »

adamnemecek wrote: post #105
throwaway487548 wrote: post #56

Earlier quoted context omitted.

Seems like you don't get it. In the comment above there is a suggestion that Erlang being well-researched and based on the right principles of FP is good-enough to build almost half of 4G platforms having crappy syntax, crappy VM, crappy everything but OTP itself. This is the point and the big deal. Rust is a mess of amateurish overcomplicated poorly understood hype-driven crap. Tokyo is utter bullshit (look how Erla…

> Rust is a mess of amateurish overcomplicated poorly understood hype-driven crap. Please be more specific about the amateurism. > Tokyo is utter bullshit (look how Erlang or Go solve the same problems with order of magnitude less lines of code), No, they work in fundamentally different spaces.

Piling up features instead of reduction and unification is the clear sign of amateurism.

For example, ML's (and Erlang's) unification of bindings via unified pattern-matching everywhere is a major achievement and canonical example. Haskell's unified approach to typing, is another. Everything is an expression of Scheme and even Lisp's unification of representation of code and data is the great discovery of old times.

PL design is hard, design of good runtimes (OTP, Go) is even harder. Ignoring almost everything which was good and true in PL field is definitely amateurism.

I don't want even start about what kind of nonsense Tokyo is. Universal event-driven frameworks is the same madness as J2EE. On the other hand, ports, typed channels or futures or pattern-marching on receive - support of fundamental concepts in a language itself is the right way.

Re: Erlang/OTP by Example

#107

Post by adamnemecek »

throwaway487548 wrote: post #106
adamnemecek wrote: post #105

Earlier quoted context omitted.

> Rust is a mess of amateurish overcomplicated poorly understood hype-driven crap. Please be more specific about the amateurism. > Tokyo is utter bullshit (look how Erlang or Go solve the same problems with order of magnitude less lines of code), No, they work in fundamentally different spaces.

Piling up features instead of reduction and unification is the clear sign of amateurism. For example, ML's (and Erlang's) unification of bindings via unified pattern-matching everywhere is a major achievement and canonical example. Haskell's unified approach to typing, is another. Everything is an expression of Scheme and even Lisp's unification of representation of code and data is the great discovery of old times.…

Rust is a simpler language than Haskell. You can’t write an os in Haskell. Rust is a replacement of c and cpp and it’s well suited for that. Rust embraces zero cost abstractions which none of the languages you mention do.

You need to wait a bit. Tokyo is a low level abstraction. People will build on top of this. Let’s be real, it’s the most promising language of late.

How long did it take for erlang to mature. Rust has come insanely far in the little time it had. Give it five more, you’ll be surprised.

Re: Erlang/OTP by Example

#108

Post by vesak »

sargun wrote: post #55
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…

I'm going to disagree with you on Rust. It's a very different, very verbose language. It doesn't have any of the stories around immutability that Erlang does. You say you had to rewrite Mnesia, but Rust doesn't even have transactional memory to start with. Suggesting that event-driven programming is anything like language-level threading like Erlang and Go is crazypants. A common error in event-driven languages is th…

>You say you had to rewrite Mnesia, but Rust doesn't even have transactional memory to start with.

He said ditch Mnesia, not rewrite.

Post reply on HN