[HN Gopher] Erlang/OTP 25.0 Release
___________________________________________________________________
Erlang/OTP 25.0 Release
Author : nifoc
Score : 152 points
Date : 2022-05-18 12:33 UTC (10 hours ago)
(HTM) web link (www.erlang.org)
(TXT) w3m dump (www.erlang.org)
| nifoc wrote:
| Highlights: https://www.erlang.org/blog/my-otp-25-highlights/
| tonyg wrote:
| The new `maybe ... end` looks nice.
| sph wrote:
| At first sight it looks like Elixir's `with` expression.
| rkangel wrote:
| It is very much that. The Erlang team have not been too
| proud to steal good ideas from Elixir. Elixir has been a
| good source of fresh thinking for the BEAM ecosystem which
| has helped both the Erlang and Elixir side.
| mononcqc wrote:
| The Erlang 'maybe' expression expands on what 'with'
| allows in Elixir, mostly because the 'with' construct
| allows a list of conditional patterns and then a general
| 'do' block, whereas the Erlang 'maybe' allows mixed types
| of expressions that can either be conditional patterns or
| any normal expression weaved in together at the top
| level.
|
| It is therefore a bit more general than Elixir's 'with',
| and it would be interesting to see if the improvement
| could feed back into Elixir as well!
|
| The initial inspiration for the 'maybe' expression was
| the monadic approach (Ok(T) | Error(T)) return types seen
| in Haskell and Rust, and the first EEP was closer to
| these by trying to mandate the usage of 'ok | {ok, T}'
| matches with implicit unwrapping.
|
| For pragmatic reasons, we then changed the design to be
| closer to a general pattern matching, which forced the
| usage of 'else' clauses for safety reasons (which the EEP
| describes), and led us closer to Elixir's design, which I
| felt was inherently more risky in the first drafts (and
| therefore I now feel the Erlang design is riskier as
| well, albeit while being more idiomatic).
|
| So while I did get inspiration from Elixir, and
| particularly its usage of the 'else' clause for safety
| reasons, it would possibly be reductionist to say that
| "the good ideas were stolen from Elixir." The good ideas
| were stolen from Elixir, but also from Rust, Haskell,
| OCaml, and various custom libraries, which have done a
| lot of interesting work in value-based error handling
| that shouldn't be papered over.
|
| I still think these type-based approaches represent a
| significantly positive inspiration that we could ideally
| move closer to, if it were possible to magically
| transform existing code to match the stricter, cleaner,
| more composable patterns that they offer.
|
| In the end I'm hoping the 'maybe' expression still
| provides significantly nicer experiences in setting up
| business logic conditions in everyday code for Erlang
| user, and it is of course impossible to deny that I got
| some of the form and design caveats from the work done in
| the Elixir language already :)
|
| Also as a last caveat: I am not a member of the
| Erlang/OTP team. The design however was completed and
| refined with their participation (and they drove the
| final implementation whereas I did the proof of concept
| with Peer Stritzinger and wrote the initial EEP), but the
| stance expressed in my post here is mine and not the one
| of folks at Ericsson.
| OkayPhysicist wrote:
| The with statement in Elixir already allows for abitrary
| expressions between the with and the do. I'm not sure
| what I'm missing here.
| mononcqc wrote:
| You're right. After all these years (and even writing a
| book that had Elixir snippets in it) I had never seen a
| single example showing it was possible and did not know
| it could do it.
|
| Well there you go, I guess the pattern is equivalent but
| incidental.
| _randyr wrote:
| > the 'with' construct allows a list of conditional
| patterns and then a general 'do' block, whereas the
| Erlang 'maybe' allows mixed types of expressions that can
| either be conditional patterns or any normal expression
| weaved in together at the top level.
|
| This seems slightly incorrect to me. You can write
| expressions in Elixir's with macro too, by simply
| swapping the arrow for an equals sign. For example, this
| is perfectly valid Elixir code: with
| {:ok, x} <- {:ok, "Example"}, IO.puts(x),
| len = String.length(x) do IO.puts(len)
| end
|
| Did you mean something else?
| mononcqc wrote:
| See https://news.ycombinator.com/item?id=31425298 for a
| response, since this is a duplicate. TL:DR; I had never
| seen it and had no idea it was possible because I don't
| recall seeing any documentation or post ever mentioning
| it! Ignorance on my part.
| throwawayboise wrote:
| That's good. I didn't come to the BEAM ecosystem from
| Ruby, so I prefer Erlang's syntax to Elixir's.
| rkangel wrote:
| I was the same initially, but now having onboarded
| multiple people on to Elixir projects, the more familiar
| type of syntax does ease the first week or so of getting
| your head round things.
| macintux wrote:
| You're not alone. I value the conciseness of Erlang.
| waynesonfire wrote:
| I hope to think that it's just that the bar to make
| significant changes to Erlang is very high. Stability and
| backward compatibility over time is something worth
| valuing. For me, this is a property that makes Erlang a
| great ecosystem.
| rkangel wrote:
| I think this shows the inverse. DESPITE being a language
| with a long history, and a proven track record of
| dependability, they are continuing to add novel
| improvements. This release includes a new core bit of
| language syntax, and the expansion of the JIT which is a
| massive performance boost now on the two most important
| platforms.
|
| Turns out you can have stability _and_ innovation!
| [deleted]
| di4na wrote:
| Thanks to the EEF for funding my work on the float to string
| algorithm!
|
| And also, if you wonder if you could do it for your current
| platform of choice, please do not engage. Inside float to string
| conversion lies madness...
| terom wrote:
| https://youtu.be/rRbY3TMUcgQ 2013 and still totally relevant
|
| Outlaw Techno Psychobitch FTW
| [deleted]
| transfire wrote:
| "Go home and take my nine nines with me." Hilarious! Thank you.
| scns wrote:
| Damn thats funny! Thanks for sharing.
| lenkite wrote:
| > The JIT now works for 64-bit ARM processors.
|
| Does this mean mobile apps in Erlang is not far off ?
| R0b0t1 wrote:
| There are some really high integration ARM servers, like Cavium
| Thunderheads. And others. They're all unobtanium.
|
| Could be repurposed for Android development. I don't see it
| happening soon. Binding to Erlang is pretty difficult, see
| https://github.com/joshnuss/elixir-ffi.
|
| If it did happen it would be useful, just... take some time.
|
| ** Warning: Turns out this is a really bad idea, do not use!
| When the BEAM calls native functions it needs to know how many
| reductions should be used. Otherwise calling a long running
| function can break the scheduling completly, because with this
| approach a long running function is considered 1 reduction **
| Wuzado wrote:
| Probably mostly focused towards running on Graviton et al.
| mikedelago wrote:
| I haven't used it, but in a recent Thinking Elixir episode,
| they talked about Elixir-Desktop, which supports Android and
| iOS, as well as the standard Windows/Mac/Linux
|
| https://github.com/elixir-desktop/desktop
| lvass wrote:
| 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?
| toast0 wrote:
| 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.
| the_duke wrote:
| Not really, because UI components inherently need tight
| integration for event propagation, layouting, drawing...
| Sure, you could render individual components in their own
| processes and have one process accumulate a render tree , but
| I don't see much sense in that.
|
| The lack of GC also is a problem, so you might have to do
| each redraw in a fresh process or something like that to
| avoid accumulating too much memory.
|
| Processes would be good for all sideline functionality like
| API/db requests and expensive computations.
| outlog wrote:
| I'm in elixir land - but have a look at
| https://github.com/elixir-desktop - they even have an ios app
| in the app store..
|
| basically wxwidgets comes with a webview, and that one is
| loaded up - and everything is packaged as an app - so you can
| use phoenix (liveview), or even react or anything to your
| liking..
|
| believe certain improvements were made to OTP 25, so multiple
| things will land soon - even livebook
| https://github.com/livebook-dev/livebook are aiming at
| shipping a native app..
| jolux wrote:
| Erlang comes with a binding to wxWidgets that is used to
| implement the graphical debugger and observer it comes with,
| but they are fairly utilitarian in their styling and I don't
| know of any other Erlang/Elixir GUI apps. Which is to say: it
| probably could be done, but doesn't seem to be popular even
| among Erlang programmers.
| jacquesm wrote:
| Have there been benchmarks of the JIT vs say JS or the JVM?
| igouy wrote:
| _fwiw_ https://benchmarksgame-
| team.pages.debian.net/benchmarksgame/...
|
| _fyi_ "1.4 What sort of problems is Erlang not particularly
| suitable for?"
|
| https://www.erlang.org/faq/introduction.html#idp32114576
| rz2k wrote:
| With Nx[1], there might be fewer limitations than there used
| to be.
|
| https://news.ycombinator.com/item?id=26168304
| out_of_protocol wrote:
| Erlang JIT is still very simple, unlike highly optimized super
| complex V8 jit. It's faster than non-jit erlang, sometimes
| twice as fast, but nowhere near nodejs-fast. Erlang team don't
| have resources to make and maintain such complex beast.
| (everything said here is about raw performance)
| andy_ppp wrote:
| The JVM is nearly as fast as hand optimised C, this is not
| intended to be that fast, rather a simple bedrock to build
| further optimisations into. Immutable everything also will
| limit performance as will the focus on latency at the cost of
| everything else. Not sure of actual performance compared to JVM
| though, I wonder if it's as far away as I expect...
| jlouis wrote:
| If you are allowed to write e.g., a Java program and run it on
| the JVM, the speedup will typically be on the orders of
| magnitude in favor of the JVM. Static type systems and
| extensive optimization matter.
|
| However, chances are you have an Erlang program, and it's quite
| large. In this case, the speedup compared to the older bytecode
| interpreter is good for many programs. It is performance you
| get "for free" by upgrading.
|
| The underlying reason for picking something like Erlang is
| robustness. Java isn't really built for this kind of
| programming, and the JVM doesn't directly facilitate it either.
| rkangel wrote:
| I think the focus has been more on comparing the JIT'd code vs
| the unJIT'd previous VM approach and looking at the speedups.
| brightball wrote:
| 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 speed for those benefits.
| jacquesm wrote:
| I'm aware of all of that but _none_ of that answers the
| question.
| toast0 wrote:
| I don't think the two JITs really do the same work, so it's
| hard to benchmark them against each other.
|
| Erlang JIT takes BEAM bytecode and turns it into native code
| once at load time in order to avoid the overhead of the
| threaded code interpreter; if Erlang JIT is enabled, the
| interpreter is not used at all. Java's HotSpot JIT takes JVM
| bytecode and turns it into native code at runtime in order to
| improve performance of code that is run frequently (thus the
| name), guided by runtime information; lightly used code will be
| interpreted, heavily used code will hopefully be JITed to
| native. When HotSpot JITs, it may apply assumptions based on
| runtime use to produce faster code and if the assumptions don't
| hold for a call, the interpreter can be used instead (and if
| that happens often enough, the native code can be discarded and
| perhaps rebuilt), so the interpreter needs to be present
| always.
|
| Erlang JIT has been focused more on always applying and speed
| of application (because it delays code loading), whereas
| HotSpot focuses more on getting performance gains when it
| applies, and speed of application is less important because it
| happens asynchronously. So if you benchmarked speed of applying
| the JIT, Erlang would probably win, and if you benchmarked
| optimization of the code, HotSpot would probably win, but
| either way you're comparing apples and oranges.
| tiffanyh wrote:
| With the JIT foundation now set in Erlang/OTP 24 & 25, I can only
| hope that we'll begin to see massive perf improvement in
| Erlang/OTP 26.
|
| (Thanks you to Lukas and all others who work on this)
| di4na wrote:
| I mean we already got a stable 25% or more improvement, to the
| point that Jason is faster than NIF based json library... we
| already saw massive perf improvement with the JIT
| clone1018 wrote:
| Highlights blog post here: https://www.erlang.org/blog/my-
| otp-25-highlights/
| rcarmo wrote:
| ...with JIT support for ARM processors, which is quite
| interesting.
| benwilson-512 wrote:
| ARM support for the JIT is a great addition for any of us on an
| M1! I believe on Intel the JIT was improving compile times by
| 30-50%.
| mattbaker wrote:
| Good news for anyone deploying to Graviton too
| out_of_protocol wrote:
| * The JIT now works for 64-bit ARM processors, including M1
|
| * The JIT now does type-based optimizations based on type
| information in the BEAM files.
| igouy wrote:
| Previously (Erlang/OTP 24 highlight)
|
| "The BeamAsm JIT-compiler has been added to Erlang/OTP and will
| give a significant performance boost for many applications. The
| JIT-compiler is enabled by default on most x86 64-bit platforms
| that have a C++ compiler that can compile C++17."
| mikl wrote:
| Easily the best feature in this release if you do your dev work
| on an Apple Silicon Mac (or Raspberry Pi, I guess?).
|
| Also great if you have the option of deploying on AWS Graviton
| or similar.
| Jeff_Brown wrote:
| I taught myself Erlang last year and loved it until I tried to
| write an application. The OTP documentation, while voluminous,
| was confusing and seemed to have important omissions, and I found
| little if any community.
| davydog187 wrote:
| There is a huge community, not just in Erlang, but in the
| larger BEAM ecosystem. Have you tried the Erlanger or Elixir
| slack? We also have https://erlangforums.com/ and
| https://elixirforum.com/. For smaller BEAM languages like
| Gleam, we have Discord available
| https://discord.com/invite/Fm8Pwmy
|
| There's a lot of great stuff in the BEAM ecosystem, I would
| caution on writing it off too fast
| Jeff_Brown wrote:
| I know there's a lot of power there. Whatsapp was written in
| OTP and had something like half the world using it with a
| development team of maybe 12.
|
| I'm glad to hear the community is bigger than what I found. I
| don't actually remember that search process. What I remember
| clearest was running into the brick wall of the OTP
| documentation.
| dfinninger wrote:
| If you'd want to try again, I can recommend "Elixir in
| Action" [1]. It has a great introduction to the basics of
| OTP later on in the book. I understood it much better after
| reading that book that any other materials.
|
| While the book is about Elixir (which is a BEAM language)
| the underlying OTP principles are the same. The book covers
| "basic" OTP before moving on to some abstractions that
| Elixir provides.
|
| [1] https://www.manning.com/books/elixir-in-action-second-
| editio...
| lawn wrote:
| I second this recommendation, it's an excellent book.
| davydog187 wrote:
| I'm not sure on your exact timeline, but the documentation
| has also seen several upgrades.
|
| For example, see the "telemetry" library, written in Erlang
| and published to the Hex repository. Its documentation is
| built using the Elixir-based ex_doc
| https://hexdocs.pm/telemetry/readme.html
| haolez wrote:
| 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.
| dragonwriter wrote:
| > 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".
|
| There's, as I see it, three different kinds of legacy: (1) code
| that has an inordinately costs to maintain and especially
| update to changing requirements because it lacks tests,
| documentation of existing business intent and/or design, or
| otherwise has lost institutional knowledge needed for
| nontrivial work, relying on the foggy memories of a high
| priesthood increasingly, over time, working through ritual
| without understanding, (2) software with deep and fundamental
| dependencies on platforms or external components that are no
| longer supported or no longer available, and (3) software which
| doesn't meet the current arbitrary tech platform decisions of
| the organization using it, but which has no fundamental problem
| preventing maintenance or use.
|
| In lots of places, software that isn't adapted to a particular
| serverless architecture that the org has adopted is now the
| third type of legacy.
|
| > And that cloud providers have solved all the pains that
| Erlang was supposed to address.
|
| They haven't, though _for some use cases_ , the parts of the
| stack Erlang would be most useful for implementing are the
| parts you are likely to just get from a cloud vendor (that's
| not true of all use cases, though.)
|
| > 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.
|
| Elixir is probably not the best bet if your concern is to
| direct the most focussed possible effort learning the things
| that are most likely to dominate the largest share ofnthr
| general software dev marketplace in the near future.
| isaacimagine wrote:
| To that end, cloud platforms like fly.io[0] provide first-
| class support for Erlang/Elixir and related frameworks. If
| the industry is converging on Erlang-like solutions, it makes
| sense that Erlang is a natural fit.
|
| [0]: https://fly.io/phoenix-files
| melony wrote:
| Problem is that outside of Fly, somebody still has to do
| the system admin. Erlang (used in an web application
| context) won't manage itself no matter how well designed it
| is. Stuff like serverless is meant to completely outsource
| DevOps.
| ricketycricket wrote:
| I mean, `mix phx.gen.release --docker` generates a nice
| dockerfile for packaging up a release (which is all Fly
| does). At that point it's essentially no different than
| any other containerized application. I've shipped Elixir
| apps to Heroku, Fly, Render, and Azure with basically no
| devops on my part.
| rozap wrote:
| I will bet real money Erlang and elixir will be around and
| doing just fine in a decade. I would not make that same bet
| about any cloud services provider.
| msbarnett wrote:
| > What's your feeling on this?
|
| That anybody claiming serverless has "solved all the pain" is
| definitely trying to sell me something.
| numbsafari wrote:
| Anybody claiming that anything has "solved all the pain" is
| definitely selling you something after having bought a load
| of it themselves.
|
| State is suffering, and life is stateful, even after you're
| long dead and garbage collected.
| mattbaker wrote:
| I laughed and cried at that last sentence. 10/10
| tomjakubowski wrote:
| It helps to set up a supervision tree so one thing crashing
| and burning won't bring it all down.
| jimbob45 wrote:
| Serverless works super well for getting off the ground but the
| goal is to grow big enough that it's no longer the best option,
| no?
|
| Just because the industry is willing to waste money on tech
| they've outgrown doesn't mean you need to.
| _huayra_ wrote:
| One current advantage: FaaS is sold below cost by every cloud
| provider at the moment, so if you can design your app to take
| advantage of it, you'll save $$$.
|
| Don't know how that'll hold up into the very long term
| though...
| etaioinshrdlu wrote:
| I highly doubt they are sold below cost - when I've checked,
| the costs are actually higher than a regular VM instance for
| the equivalent amount of compute.
| kristjansson wrote:
| One good business cycle in the XaaS spaces might disabuse those
| people of that notion. Even on more stable providers, the
| whateveraaS products are a good solution for some cases, but
| far from panacea.
| kemiller wrote:
| 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.
| jlouis wrote:
| While Serverless does address some of the points which were the
| design goals of Erlang, it doesn't address them all. In no
| particular order:
|
| Hardware interaction is more or less non-existent in the world
| of Serverless.
|
| Timing/Latency is not really controllable. It's at the whim of
| your provider.
|
| FaaS doesn't support very large systems well. It's far more
| about scaling down than up.
|
| Erlang is functional for a reason: it minimizes faults. Quality
| follows.
|
| Complex feature interaction is limited in the stateless
| serverless world.
|
| Cloud providers tend to solve for a different set of problems,
| which is fine. But I'm going to claim that many of the things
| Erlang was designed to solve runs dual to the problems in the
| cloud space.
| yumaikas wrote:
| If you're wanting to use Elixir, it's not going to be nearly as
| mainstream as, say, Node, but fly.io has support for Elixir
| apps (to speak of cloud), and I think there's some cool stuff
| going on in Elixir myself.
|
| Of other note is that Erlang seems to enable folks that use it
| to punch above their weight class when it comes to running
| services internally and such.
|
| Serverless is far from the only valid way to run things these
| days.
| brightball wrote:
| IMO people represent what they know.
|
| People also overestimate what "the new" is, constantly.
| Otherwise, PHP would be dead by now rather than flourishing.
|
| Serverless is essentially PHP in CGI mode, with a lot of
| marketing behind it. There are certainly places where it's
| beneficial.
|
| Servers and databases are not going away anytime soon. They are
| simply too effective for what they do.
|
| The "everything is legacy crowd" hasn't been correct about
| almost anything in my lifetime. Mainframes are still going
| strong. SQL databases are better than ever and the NoSQL crowd
| has largely died out.
|
| 90% of the cloud ecosystems of today are just doing what Java
| app servers were doing in the late 90s.
|
| Erlang and the BEAM offer a set of trade offs that happen to be
| ideal for a lot of server based use cases to make hard things
| really simple. Probably not going to take over the world but if
| it fits what you do you probably won't want to go back.
| preciz wrote:
| I'm not sure where the industry is going but the innovations
| around LiveView are really convincing (I'm using LiveView in my
| work).
|
| Some great innovating Elixir projects:
|
| Oban: https://getoban.pro/
|
| Oban Demo: https://getoban.pro/oban
|
| Livebook: https://livebook.dev/
| nickjj wrote:
| A lot of popular web frameworks have their take on how to
| arrive at the same goal which is to be able to create
| responsive feeling sites without writing a lot of JS and
| creating API backends.
|
| Rails has Hotwire Turbo (which is technically back-end
| agnostic), Laravel has LiveWire, there's also HTMX which is a
| bit lower level and back-end agnostic. There's also Django
| Unicorn and Rails Stimulus Reflex.
|
| All of these solutions let you return HTML back from your
| server and partially update areas of a page while writing no-
| to-little JS. They're all implemented differently but for a
| huge classification of web apps the implementation doesn't
| matter.
|
| After jumping between Phoenix and Rails for quite some time
| (years), personally I find Hotwire Turbo's implementation and
| overall using it extremely intuitive, it "just works". It's
| been legit one of the best development experiences I've
| encountered. The best part about it is that it works with any
| back-end too, so you're not even limited to Rails. DHH and
| the Rails team never cease to amaze me in what they release
| to the world.
| preciz wrote:
| I also worked with Rails before and I'm happy to see their
| progress, I however wouldn't go back to work with it if I
| can choose, for me Phoenix and LiveView doesn't feel like
| magic or too much convention unlike Rails does
| unfortunately.
| mrdoops wrote:
| Serverless systems in almost every implementation are still
| stateless or limited stateful-serverless (the best examples are
| probably Microsoft's Durable Functions or Flink's Stateful
| Functions - there's also solid attempts by the Akka folks).
|
| These are largely built on top of either a stream processing
| (in case of Flink) or some flavor of Actor model based on event
| sourcing for peristence.
|
| What I'm getting at is that you'd build a serverless system on
| top of Elixir/Erlang/OTP and be served well by its mature actor
| model implementation and excellent distribution options. See
| https://eigr.io/ .
|
| The cloud provided options are interesting for some
| experimental / tactical use cases but I don't yet trust their
| abstractions to not be leaky and they typically come with
| vendor lock-in trade offs.
| Kototama wrote:
| This is one of the best answer.
|
| Also:
|
| - the supervisor system in Erlang/Elixir is relatively
| complex. It goes much beyond the "restart my service" when it
| crashes but allow to restart some processes, without
| restarting the service, and in a specific order to keep the
| system coherent.
|
| - local and remote calls behave the same in Erlang/Elixir,
| allowing to start with a monorepo having different Erlang
| "apps" than run on the same node, but then running the
| different apps on different nodes in the future, once the
| application, scales. This can be done very little changes to
| the application.
| haolez wrote:
| > - local and remote calls behave the same in
| Erlang/Elixir, allowing to start with a monorepo having
| different Erlang "apps" than run on the same node, but then
| running the different apps on different nodes in the
| future, once the application, scales. This can be done very
| little changes to the application.
|
| This sounds very appealing to my context.
| toast0 wrote:
| > - local and remote calls behave the same in
| Erlang/Elixir, allowing to start with a monorepo having
| different Erlang "apps" than run on the same node, but then
| running the different apps on different nodes in the
| future, once the application, scales. This can be done very
| little changes to the application.
|
| I wouldn't really say they behave the same. They have the
| same interface, so it doesn't take much to send to a remote
| node vs the local node, but there are a lot of details in
| the behavior that are clearly different, as is the nature
| of the beast. With a local process, if you monitor it, and
| receive a kill signal, you know it's dead; with a remote
| process, you may get a process died signal or a connection
| died signal; if the connection died you can't know if the
| remote process is dead or alive. That's new behavior and
| can be tricky sometimes.
| Kototama wrote:
| Ok good point. When using GenServers thought, which is
| most of the cases, it is mostly transparent.
| mattbaker wrote:
| My thinking is Erlang's been powering massive systems since the
| early 90s, I'm feeling pretty good about its longevity.
|
| Many of Elixir's strengths are Erlang's strengths.
|
| I wouldn't hesitate to learn some Elixir if it's interesting to
| you. It's not as pervasive as other languages but it's not
| niche either.
|
| Full disclosure, it's been such a wild success for my team at
| New Relic the last 5 years that I'm very biased :)
| dmix wrote:
| New Relic is using Elixir?
| mattbaker wrote:
| 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).
| Errrrrt wrote:
| Hmmm I looked for this position and couldn't find it.
| Could you link it? I would like to see if I can apply
| mattbaker wrote:
| Yep: https://jobs.jobvite.com/newrelic/job/oTbyjfwF
| haolez wrote:
| Wow! I've just subscribed to New Relic for my company (I'm
| the CTO) and couldn't be happier. What a coincidence :)
| mattbaker wrote:
| Well if you try out the GraphQL API its API gateway is
| Elixir! The fields themselves provide data from a multitude
| of services downstream, but the gateway unifies it and sits
| in front.
|
| I hope you like product :)
| sergiomattei wrote:
| Is Elixir running on OTP 25?
| Kototama wrote:
| Not yet, you can use OTP23 or OTP24 at the moment with latest
| Elixir 1.13. Check
| https://hexdocs.pm/elixir/1.13/compatibility-and-deprecation...
| conradfr wrote:
| Although changelog says:
|
| > v1.13.4 (2022-04-07) > This release has been verified to
| work with Erlang/OTP 25 RC2.
| Kototama wrote:
| Ah nice, I missed that!
| ricketycricket wrote:
| 1.13.4 is verified on OTP 25 RC2, so I'd assume it supports
| the release OTP 25.
|
| See: https://github.com/elixir-
| lang/elixir/releases/tag/v1.13.4
| haolez wrote:
| 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.
| davydog187 wrote:
| Serverless? You mean vendor lock-in, distribution issues and
| reproducibility issues, etc?
| haolez wrote:
| Yeah. There are obvious downsides, but what if your
| competitor.manages to outperform you with such tools? That's
| my concern
| conradfr wrote:
| Outperform in which aspect?
| haolez wrote:
| Deliver more features, faster.
| davydog187 wrote:
| Your competitor beat you while you were rewriting your
| product to be serverless
| bo0tzz wrote:
| > cloud providers have solved all the pains that Erlang was
| supposed to address.
|
| Assuming this is talking about tools like Kubernetes, they
| operate on a different level. The OTP's failure tolerance model
| operates on a (relatively) very small scale inside your
| application, whereas Kube operates on a whole-application
| level. Rather than obsoleting OTP, Kubernetes actually
| complements it.
| nix23 wrote:
| >engineer saying that software solutions outside of the
| Serverless ecosystem (FaaS, DB, etc) is "the new legacy"
|
| It's complete blindness to the reality. Trusting one single
| provider for your whole service (often not even completely
| opensource) is the same trap as Windows or Oracle in the
| 90's...just worse (because not on prem)...but hey history
| repeats itself ;)
| distortedsignal wrote:
| 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)
| barkerja wrote:
| This is great. I hope this finds its way to Elixir land.
| linkdd wrote:
| This already exist with the `with` expression, no?
| kemiller wrote:
| Yeah, `with` is pretty much this.
| dugmartin wrote:
| 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."
| [deleted]
___________________________________________________________________
(page generated 2022-05-18 23:01 UTC)