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

How I fell in love with Erlang

boragonul.com

Post reply on HN
Print view View original

181–190 of 263 posts

Re: How I fell in love with Erlang

#181

Post by toast0 »

jacquesm wrote: post #174
toast0 wrote: post #171

Earlier quoted context omitted.

I've got a hobby OS you may want to check out. Crazierl is a just enough kernel that can run the FreeBSD build of BEAM as a single OS process. Features include: x86-32 only, bios boot only, SMP capable, drivers in Erlang (there's nifs for managing memory with devices or i/o; and the kernel manages the interrupt controller(s) and has console output before userspace takes over), a kind of working IPv4 stack, dist! It d…

Very neat! I have my own OS to work with that I know like my back pocket, so if I ever go this route I'll probably just carve that up.

Did you get your serial ports working? :)

If it doesn't take much time, it's worth trying to get it to run in v86; it's so much easier to send people a link to a web page to poke at your OS than to send them an image and tell them to run qemu against it.

Edit: I misinterpretted --- you'll carve your OS up, not mine, that makes more sense!

Old comment: Feel free to carve away, just be aware that just because it's committed doesn't mean it works... I wouldn't take my memory management code, for example. There's some fiddly issues I haven't tracked down because it doesn't break consistently.

Re: How I fell in love with Erlang

#182

Post by bostik »

toast0 wrote: post #144
zwnow wrote: post #54

Earlier quoted context omitted.

For me it took a tremendous amount of work to somewhat understand the OTP stuff though. Its one of those languages where I can never be confident about my implementations, and thankfully it has features to check whether you have stale processes or whatever. A language I am humbled by whenever I use it.

Here's a trick to confidence in a BEAM system. If you get good at hot loading, you significantly reduce the cost of deployment, and you don't need as much pre-push confidence. You can do things like "I think this works, and if it crashes, I'll revert or fix forward right away" that just aren't a good fit for a more common deployment pattern where you build the software, then build a container, then start new instance…

Erlang's hot reload is a two-edged blade. (Yes yes, everything is a tradeoff but this is on another level.)

Because it's possible to do hot code reloading, and since you can attach a REPL session into a running BEAM process, running 24/7 production Erlang systems - rather counterintuitively - can encourage somewhat questionable practices. It's too easy to hot-patch a live system during firefighting and then forget to retrofit the fix to the source repo. I _know_ that one of the outages in the previous job was caused by missing retrofit patch, post deployment.

The running joke is that there have been some Ericsson switches that could not be power cycled because their only correct state was the one running the network, after dozens of live hot patches over time had accumulated that had not been correctly committed to the repository.

Re: How I fell in love with Erlang

#183

Post by simoncion »

nakamoto_damacy wrote: post #50

Will it ever run in WASM? EDIT: there is Lumen, but not sure if it's stalled or still going.

> Will it ever run in WASM?

A ten-second search reveals [0]. (Have Kids These Days forgotten all about Emscripten?) However, given that web browser pages are often short-lived, I don't see what benefit bringing in all of Erlang and its VM gets you, other than the fact that you've pulled off the stunt.

[0] https://www.antvaset.com/erlang-otp-wasm>

Re: How I fell in love with Erlang

#184

Post by marcus_cemes »

stevenjgarner wrote: post #159
quaunaut wrote: post #142

Earlier quoted context omitted.

This reads as if it isn't trivial to have an HTTP API for your public API in Erlang/Elixir, which is weird. Sure there isn't an included HTTP API for Erlang processes, but why exactly would you want one? They're not for the public internet, as their an implementation detail of your system. The majority of what they're capable of just isn't relevant to the public internet.

Unfortunately very little is trivial for me. Personally I have found the real value of Erlang to be internally between trusted nodes of my own physical infrastructure as a high-level distributed "brain" or control plane for health monitoring, config distribution (env vars, static config files, etc), smart failover decisions etc. Keep the “outside view” (HTTP, SMTP, DNS) all standards-based OSI, internally mapped to d…

This stands to reason. If you need to bridge different languages together like in your case, they need to speak a common tongue. REST/GrahQL/gRPC solve this problem in different ways. There is no technical limitation keeping you from serving HTTP traffic from Erlang/Elixir, but from my own experience it isn't a pleasant experience. JavaScript or Python are dead simple, until you realise that 64-bit integers are not a thing in JS, and need to be handled as strings. Similarly, tuples will give you hell in Python.

On the other hand, if you don't need to cross that boundary, the BEAM will very happily talk to itself and let you send messages between processes without having to even think about serialisation or whether you're even on the same machine. After all, everything is just data with no pointers or cyclic references. That's more that can be said for most other languages, and while Python's pickle is pretty close, you can probably even share Erlang's equivalent of file descriptors across servers (haven't tried, correct me if I'm wrong), which is pretty insane when you think about it.

> I have found the real value of Erlang to be internally between trusted nodes of my own physical infrastructure as a high-level distributed "brain" or control plane

I think this is pretty high praise, considering it's about as old as C and was originally designed for real-time telephone switches.

Re: How I fell in love with Erlang

#185

Post by simoncion »

igouy wrote: post #145
adamddev1 wrote: post #137

The only thing holding me back from Erlang is the lack of type checking. Convince me?

https://www.erlang.org/doc/system/typespec.html

Yep. You feed files annotated with those to Dialyzer or similar for not-runtime typechecking. That plus the basic runtime checking provided by guard expressions [0] gives you a bunch of coverage... and I think some of the folks who like Elixir are working on their own typechecker thing? I don't really know, because I don't use Elixir.

[0] https://www.erlang.org/doc/system/expressions.html#guard-exp...>

Re: How I fell in love with Erlang

#186

Post by FredPret »

jimbokun wrote: post #123
tommica wrote: post #18

Earlier quoted context omitted.

> Suddenly Erlang made it fun and programming became addictive. I'm saying this with complete sincerity: WHAT IS IT THAT YOU PEOPLE SEE!? What is the fun? What are you addicted to? Typing and seeing the output? Solving a problem? I feel like I am missing out on some amazing life altering experience when I see people state that. The same thing I have with the article - what does it mean to love a programming language?

It's kind of like this: https://xkcd.com/224/ Also this: https://www.infoq.com/presentations/Simple-Made-Easy/ For me, there's a dopamine hit in taking a complex problem, and breaking it into simple interacting parts that solve the problem in an elegant way. Overly complex programming languages add lots of incidental complexity that slow down this process. A clear, simple, consistent semantics accelerate this process…

> https://xkcd.com/224/

> “My God, it’s full of ‘cars’”

Classic

Re: How I fell in love with Erlang

#187

Post by toast0 »

bostik wrote: post #182
toast0 wrote: post #144

Earlier quoted context omitted.

Here's a trick to confidence in a BEAM system. If you get good at hot loading, you significantly reduce the cost of deployment, and you don't need as much pre-push confidence. You can do things like "I think this works, and if it crashes, I'll revert or fix forward right away" that just aren't a good fit for a more common deployment pattern where you build the software, then build a container, then start new instance…

Erlang's hot reload is a two-edged blade. (Yes yes, everything is a tradeoff but this is on another level.) Because it's possible to do hot code reloading, and since you can attach a REPL session into a running BEAM process, running 24/7 production Erlang systems - rather counterintuitively - can encourage somewhat questionable practices. It's too easy to hot-patch a live system during firefighting and then forget to…

You certainly can forget to push fixes to the source repo. But if you do that enough times, it's not hard to build tools to help you detect it. You can get enough information out of loaded modules to figure out if they match what's supposed to be there.

I had thought there was a way to get the currently loaded object code for a module, but code:get_object_code/1 looks like it pulls from the filesystem. I would think in the situation where you a) don't know what's running, and b) have the OTP team on staff, you could most likely write a new module to at least dump the object code (or something similar), and then spend some time turning that back into source code. But it makes a nice story.

[1] https://www.erlang.org/doc/apps/kernel/code.html#get_object_...

Re: How I fell in love with Erlang

#188

Post by zachrip »

marcus_cemes wrote: post #184
stevenjgarner wrote: post #159

Earlier quoted context omitted.

Unfortunately very little is trivial for me. Personally I have found the real value of Erlang to be internally between trusted nodes of my own physical infrastructure as a high-level distributed "brain" or control plane for health monitoring, config distribution (env vars, static config files, etc), smart failover decisions etc. Keep the “outside view” (HTTP, SMTP, DNS) all standards-based OSI, internally mapped to d…

This stands to reason. If you need to bridge different languages together like in your case, they need to speak a common tongue. REST/GrahQL/gRPC solve this problem in different ways. There is no technical limitation keeping you from serving HTTP traffic from Erlang/Elixir, but from my own experience it isn't a pleasant experience. JavaScript or Python are dead simple, until you realise that 64-bit integers are not a…

64 bit ints are a thing in JS for a while now

Re: How I fell in love with Erlang

#189

Post by sodapopcan »

simoncion wrote: post #177
sodapopcan wrote: post #121

Earlier quoted context omitted.

It depends on how technical you want to get. It's certainly not a loop in the classic sense, like a for loop etc. Like there are no `continue` or `break` semantics and you can't return out of it (and yes yes of course you can still do all that stuff, just not with dedicated keywords). I call it a loop, though. Whenever I make a lil' server in Elixir (mostly always for teaching) I always call the function `loop`: defm…

To put it another way: anything you can express with iteration, you can express with recursion (just as long as you don't run out of call stack). Once you get it, it's obvious, but if you're not already familiar with the notion, the understanding can be pretty amazing.

> just as long as you don't run out of call stack

And with tail-call you don't even need to worry about that :)

Re: How I fell in love with Erlang

#190

Post by SoftTalker »

davidw wrote: post #156
SoftTalker wrote: post #128

Earlier quoted context omitted.

That's the downside. If you look at the monthly "who is hiring" posts here on HN, you rarely see Erlang jobs. Elixir shows up a bit more often but it's still uncommon.

Yeah, I've really enjoyed the jobs where I got to use Erlang, but there haven't been enough of them. Even Elixir is kind of scarce.

Only had one, a contract where I got to choose the implementation. Job was to simulate a bunch of sensors on a network and Erlang was perfect for that.
Post reply on HN