[HN Gopher] A response to "Erlang - overhyped or underestimated"...
___________________________________________________________________
A response to "Erlang - overhyped or underestimated" (2010)
Author : Tomte
Score : 40 points
Date : 2024-02-20 18:14 UTC (4 hours ago)
(HTM) web link (jlouisramblings.blogspot.com)
(TXT) w3m dump (jlouisramblings.blogspot.com)
| throwawaymaths wrote:
| > In Erlang, the mantra is "abstraction is had by introducing
| another process".
|
| This is probably "not a good idea", as processes introduce
| bottlenecks. Really, if you want to abstract in erlang, you
| should, in 95% of cases really just write a behaviour.
|
| Of course if you need to abstract over something stateful, yes,
| please write a process. The benefit being that you can do some
| pretty painless dependency injection (or at a minor readability
| cost compile time pick between modules) and inject the state in
| your tests.
| zilti wrote:
| I really have to finally take a look at Erlang, it's been on my
| list for years
| fredrikholm wrote:
| For me, no language has been more fascinating as unlike most
| languages Erlang is very focused on distributed systems as a
| first class citizen and sells that, rather than the more
| common sales pitch of being exactly like other languages but
| with subjectively better syntax/semantics.
| freedomben wrote:
| (In Elixir) I've most recently found myself lamenting the
| indirection of processes as a ton of third party dependencies
| spin off processes to manage their state, and when something
| goes wrong (usually some argument I'm incorrectly passing in to
| a function call or something) the stack trace I get doesn't
| lead back to my code so I have to try and figure out the
| closest point to where I'm invoking it. Probably still a good
| tradeoff for immutability and the actor model, but an
| unfortunate downside that has pained me.
| throwawaymaths wrote:
| I haven't found most 3rd party dependencies doing that unless
| they're making, for example, a request pool.
|
| Should we be shaming those libraries?
| dqv wrote:
| What libraries? You might be able to do something with the
| process dict depending on how the libraries are set up.
| Basically you create a process id that you use to track
| what's going on: @type trace_id ::
| nonempty_binary() @spec put_trace_id(trace_id())
| :: term() | nil def put_trace_id(id), do:
| Process.put({:my_app_name, :trace_id}, id) @spec
| get_trace_id :: trace_id() | nil def get_trace_id,
| do: Process.get({:my_app_name, :trace_id}) @spec
| make_trace_id :: trace_id() def make_trace_id, do:
| Base.hex_encode32(:crypto.strong_rand_bytes(16), padding:
| false)
|
| It does require that, along the call path, you set that trace
| id whenever a new process is started. It gives you some
| visibility into what's going on, especially if you also do
| something like Logger.metadata(trace_id: get_trace_id())
| after you call put_trace_id/1
|
| That said, I think any library that does start processes like
| that should have some mechanism that lets us identify the
| provenance of the crash. "Crashed when trying to fribulate.
| Trace id xxxxxx"
| dang wrote:
| Related:
|
| _A response to "Erlang - overhyped or underestimated"_ -
| https://news.ycombinator.com/item?id=2039180 - Dec 2010 (33
| comments)
|
| _Erlang - overhyped or underestimated?_ -
| https://news.ycombinator.com/item?id=2038392 - Dec 2010 (38
| comments)
| quatrefoil wrote:
| I think the blog post is guilty of the same thing we're all
| sometimes guilty of when discussing something we like, but few
| other people seem to appreciate. It's this "no, it's great, you
| just don't understand it" mentality. We get it, they don't, and
| if we explain the genius of it one more time, the world is going
| to see the light.
|
| Erlang has been around for a looong time (it's about as old as
| C++). It never rose to any real prominence, nor has it dominated
| any well-defined niche. Sometimes, outcomes like that are just a
| matter of bad timing. But sometimes, people just try your thing,
| don't like it, and the best response isn't "actually, you just
| don't get it" - it's to learn and iterate.
| Bjartr wrote:
| I thought it dominated, or was at least popular within, the
| niche it was developed for, telecom hardware. It is the
| "Ericsson Language" after all
|
| Is that not the case?
| quatrefoil wrote:
| Not really - at least in my days in that industry, the bulk
| of telco equipment was running C/C++ or Java code. This
| included Ericsson gear. Ericsson and one or two other telco
| companies were definitely using it in production, but it
| wasn't dominant.
| AceJohnny2 wrote:
| No. In fact, Erlang was open-sourced _because Ericsson gave
| up on it_. From wikipedia:
|
| > In February 1998, Ericsson Radio Systems banned the in-
| house use of Erlang for new products, citing a preference for
| non-proprietary languages. The ban caused Armstrong and
| others to make plans to leave Ericsson. In March 1998
| Ericsson announced the AXD301 switch, containing over a
| million lines of Erlang and reported to achieve a high
| availability of nine "9"s. In December 1998, the
| implementation of Erlang was open-sourced and most of the
| Erlang team resigned to form a new company Bluetail AB.
| Ericsson eventually relaxed the ban and re-hired Armstrong in
| 2004.
|
| I know this seems like a black mark on Erlang. I think it
| just demonstrates the difficulty of carving a new niche.
| Training developers in a new language _and paradigm_ is hard.
| deathtrader666 wrote:
| Or someone could read it as the Ericsson management not
| really understanding the capabilities of their own internal
| tools, and must've read something up on Java or .NET in an
| HBR article.
| hosh wrote:
| I didn't like Erlang when I first tried it.
|
| Then later, I found myself doing things in other languages ...
| and I realized what I was trying was significantly less effort
| in Erlang and I was poorly reinventing ideas from OTP. That was
| when I pivoted my career to seek out teams that work with
| Elixir.
|
| Some years later, when I finally got around to learning and
| using Node.js, I realized just how poor the async/await/promise
| design Node.js was (error-prone by design). But I highly doubt
| I would convince anyone to really give Elixir or Erlang a go.
|
| In my case, it was certainly a case of "it's great but I just
| didn't understand it".
| jimbokun wrote:
| Whatsapp had 35 engineers and 450 million users when they sold
| to Facebook for $21.8 billion. Whatsapp, of course, was
| developed in Erlang.
|
| There are times when the masses are just wrong. The Whatsapp
| story probably isn't possible with some other technology stack.
|
| Of course, maybe it's just that very few applications need to
| scale in the way Erlang enables.
| mekoka wrote:
| > But sometimes, people just try your thing, don't like it, and
| the best response isn't "actually, you just don't get it" -
| it's to learn and iterate.
|
| Elixir is Erlang with more sugar coating. The language and many
| of its associated projects (e.g. Phoenix) are regularly touted
| as some of the most productive development tools. You still
| don't see people flock toward them.
|
| I used to think that large groups of people can't be wrong.
| Time and personal experience taught me otherwise. Now I know
| that sometimes it's possible that they actually just don't get
| it. But that's also fine.
| Supermancho wrote:
| Erlang devs _wish_ it was as popular as Javascript when it used
| XMLHttpRequest. It 's less popular than Lua today, which has no
| package manager. That means something is very wrong.
|
| > The main objection is familiarity: "It doesn't look like Java!"
| I think the point is somewhat moot.
|
| It doesn't matter what the zealots think. It's not moot, because
| there are people born every day that will think it. This will be
| a response to the language, every day, until we're both long-
| dead. It matters enough that it drove people to dedicate time to
| develop entirely new syntax (eg elixir), as mentioned. Given the
| myriad of languages that use a functional style, Erlang is just
| not special, excepting the unique syntax which makes it
| unfamiliar and elixir that just makes a bit more user friendly.
| Maybe, just maybe, it _is_ partly about the syntax.
|
| The Erlang tooling is primitive. I don't want to develop another
| toolchain and have to do with the gaps, thx. Yes it's a chicken-
| vs-egg thing, but without support for a new language, you wont
| see a lot of adoption.
|
| The semantics are less efficient. Now the context needs to be
| carried around or in another set of terms, or worse another event
| queue, or worse overloaded fns? When a for-loop has to be broken
| up into 2 fns, you've made things worse at the smallest scale. I
| then have to communicate the naming and choices to future
| developers? This makes debugging, design and code reviews
| harder/more divisive.
|
| I can read through a couple functions and understand what a
| c-like program does, even if it's in Python or PHP or Java or C
| (most of the time). Saying they are different in details, is
| missing the point. I don't have to know how data is split up
| because everything is either a structure or a scalar, serially
| processed and in static locations for reading...until you hit a
| DB. Hitting a single async store is complicated enough that it
| has caused developers headaches for decades. Introducing easy
| queues as a solution, is handing out footguns. The complexity
| introduced into event-driven applications, limits the practical
| complexity of application development in practice, by orders of
| magnitude (bottlenecks and race conditions).
|
| Sloppy programming is jr friendly. Raising the developer
| performance expectations higher, is worse for adoption. Perl died
| on this hill.
|
| Years after I last used Erlang to replace a Java chat client from
| 5000 lines to single page Erlang module, then got a job writing
| it (2009), I would not recommend it to anyone. I did try cracking
| open another person's project in 2012ish and that was not fun. At
| least we have Kafka.
| drekipus wrote:
| This is my take as well (adding erlang to my list of things
| along with python/kotlin/go/lua).
|
| Some things are just a little *too* different. There's no for-
| loop, it's just recursion. Pattern matching on the function
| signatures are nice, but then I have to dig around a lot more
| to find what I need.
|
| That being said, I do want to try it and learn about it more;
| the promises it makes about concurrency and event driven
| programming looks nice, i do really want to try it.
| stanmancan wrote:
| I haven't looked at Erlang much but I've been using Elixir
| for a couple of years now and it's been the most enjoyable
| language I've used to date.
|
| I don't miss having a for-loop, recursion works but the Enum
| module is great and easy to use. When done right, pattern
| matching on function signatures is nice and clean. If you
| find it's actually more difficult to find what you're looking
| for it's a sign somethings probably off.
| rootlocus wrote:
| > It's less popular than Lua today, which has no package
| manager.
|
| https://luarocks.org/
| stanmancan wrote:
| This is a pretty outdated take considering all of the
| experience you've referenced is 10+ years old now.
| superjared wrote:
| I drank the Erlang Kool-Aid around the same time this was
| published. In 2013 I worked for a company that had a few Erlang
| services (as well as some JVM services, a mix of Scala and to a
| lesser degree Java).
|
| One thing I was tasked with was replacing the ingress data
| collector. One of the limitations of Erlang at the time was that
| all SSL termination was funneled through a single core. Once the
| Java replacement was deployed, we saw a massive decrease in
| latency, the p95s and p99s especially, and all the weird
| operational overhead of trying to understand what the Erlang VM
| was doing at any given moment.
|
| Say what you will about Java and the JVM, but it's a fantastic
| platform for reasonably high performance servers. Erlang might
| have a lot of claims for high concurrency and scalability, but
| practically I've had considerably more success with the JVM.
|
| I haven't touched Erlang since 2013, so in the intervening 11
| years I can only hope that it has gotten better. Though I have
| zero interest in trying it again.
| CyberDildonics wrote:
| What is an _ingress data collector_ and how is it different
| from a server?
___________________________________________________________________
(page generated 2024-02-20 23:00 UTC)