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

Erlang/OTP 25.0 Release

erlang.org

Post reply on HN
Print view View original

101–110 of 125 posts

Re: Erlang/OTP 25.0 Release

#101

Post by dugmartin »

barkerja wrote: post #87
distortedsignal wrote: post #85

Having worked with erlang for some time now, https://www.erlang.org/eeps/eep-0049 is _very exciting_ to me. One of the issues that I have with the codebase that I'm in is deep nesting, which could be solved with this feature. Very compelling. (HN mods: feel free to delete this comment or my comment at https://news.ycombinator.com/item?id=31426002 , since they're the same content)

This is great. I hope this finds its way to Elixir land.

It is already there with the "with" macro.

The EEP doc calls it out:

https://www.erlang.org/eeps/eep-0049#elixir

"This is the most general control flow in this document, being fully flexible with regards to which values it can handle. This was done in part because there is not a strong norm regarding error or valid values in either the Erlang nor Elixir APIs, at least compared to other languages here.

This high level of flexibility has been criticized in some instances as being a bit confusing: it is possible for users to make error-only flows, success-only flows, mixed flows, and consequently the ˋelseˋ clause can become convoluted."

Re: Erlang/OTP 25.0 Release

#102

Post by Errrrrt »

mattbaker wrote: post #92
dmix wrote: post #65

Earlier quoted context omitted.

New Relic is using Elixir?

Yep, it’s by no means the most common stack but it does power a few critical services. We’re actually hiring for an elixir role right now (non-senior/mid-career, prior elixir not required).

Hmmm I looked for this position and couldn't find it. Could you link it? I would like to see if I can apply

Re: Erlang/OTP 25.0 Release

#103

Post by kemiller »

haolez wrote: post #26

I've seen more than once recently an engineer saying that software solutions outside of the Serverless ecosystem (FaaS, DB, etc) is "the new legacy". And that cloud providers have solved all the pains that Erlang was supposed to address. What's your feeling on this? Elixir sounds very compelling to me, but I worry that I might be going in a direction that's not where the industry is going.

I'd actually characterize it the other way around: Elixir and Beam give you most of the benefits of serverless with better portability and lower costs.

Also, meta: don't worry too much about where people tell you the industry is heading. 1) They don't actually know, 2) it's much more conservative out there than you might think. Even when new paradigms do gain traction, they pretty much always augment rather than replace, for a good long while at least.

Re: Erlang/OTP 25.0 Release

#104

Post by toast0 »

lvass wrote: post #47
lenkite wrote: post #43

> The JIT now works for 64-bit ARM processors. Does this mean mobile apps in Erlang is not far off ?

I don't see any serious attempt at UIs with erlang. I think erlang processes would provide a great foundation for UI components, but has it even been tried?

IMHO, you want to do it from scratch if you want it to really work with Erlang, but that means a ton of work. ex11 exists, but I don't know that it was ever very complete, and it was built in the old era of X11 where clients didn't render fonts, etc, so there'd be a lot of work to complete it. The most active fork has moved towards using it for embedded systems.

Personally, I used ex11 because the wxWidgets interfaces are hard for me to grasp and then accept; it was easier for me to understand X11 as a distributed communication protocol that has a side effect of occasionally outputting graphics; but my application only outputs a bitmap once in a while, so really I could have made anything work. ex11 doesn't help you with mobile though, because Android and iOS don't run X11.

There's also gtkNode, but I don't know how well that works, because it didn't seem any less confusing than wxWidgets. gtk has some ability to run on mobile, I think.

Re: Erlang/OTP 25.0 Release

#105

Post by [deleted] »

dugmartin wrote: post #101
barkerja wrote: post #87

Earlier quoted context omitted.

This is great. I hope this finds its way to Elixir land.

It is already there with the "with" macro. The EEP doc calls it out: https://www.erlang.org/eeps/eep-0049#elixir "This is the most general control flow in this document, being fully flexible with regards to which values it can handle. This was done in part because there is not a strong norm regarding error or valid values in either the Erlang nor Elixir APIs, at least compared to other languages here. This high level…

[deleted]

Re: Erlang/OTP 25.0 Release

#106

Post by jacquesm »

brightball wrote: post #21
jacquesm wrote: post #7

Have there been benchmarks of the JIT vs say JS or the JVM?

BEAM is never going to win for straight line speed. This is going to be an improvement for a language optimized for resilience, concurrency and consistency. Running millions of concurrent processes, with their own heap, with consistent response times that individually tolerate failure without negatively affecting the entire system is just a different animal with a different set of trade offs. You’re trading some spee…

I'm aware of all of that but none of that answers the question.

Re: Erlang/OTP 25.0 Release

#107

Post by mattbaker »

Errrrrt wrote: post #102
mattbaker wrote: post #92

Earlier quoted context omitted.

Yep, it’s by no means the most common stack but it does power a few critical services. We’re actually hiring for an elixir role right now (non-senior/mid-career, prior elixir not required).

Hmmm I looked for this position and couldn't find it. Could you link it? I would like to see if I can apply

Yep: https://jobs.jobvite.com/newrelic/job/oTbyjfwF

Re: Erlang/OTP 25.0 Release

#108

Post by brightball »

jacquesm wrote: post #106
brightball wrote: post #21

Earlier quoted context omitted.

BEAM is never going to win for straight line speed. This is going to be an improvement for a language optimized for resilience, concurrency and consistency. Running millions of concurrent processes, with their own heap, with consistent response times that individually tolerate failure without negatively affecting the entire system is just a different animal with a different set of trade offs. You’re trading some spee…

I'm aware of all of that but none of that answers the question.

It’s suggesting that there’s probably not much of a point to it.
Post reply on HN