[HN Gopher] Ask HN: Is Erlang an albatross to Elixir adoption?
___________________________________________________________________
Ask HN: Is Erlang an albatross to Elixir adoption?
I pose this question in all seriousness. An observation: after
being an elixir developer for a few years now, and bringing new
talent into the mix (no pun intended), is that it's a friction
point for new devs learning Elixir when they invariably stumble
across the things in erlang -- libraries and the like. I'd hoped I
could avoid it myself, but it's too interdependent. The notion
that to learn a language you also need to learn a second one is not
great. Imagine people saying "cool, learn python, but oh, you also
should brush up on cobol while you are at it, you know." It's just
bizarre. And before the vocal defenders kick in I want to clarify
that the following response (which is what I usually hear) is NOT a
valid response to the question being posed: "Erlang is easy, it's
just semantics that are different" While this statement might be
true, it doesn't address my point. That something is easy to do for
one person is irrelevant to the fact it causes friction for new
devs and may hinder adoption. I think there are many amazing
points to Elixir, and thanks to Erlang it has a lot of amazing
roots. I know both communities are trying to make both co-exist
well. But every time I come across an Erlang library, invariably
the documentation is a nightmare (if it exists at all) and I have
to read the code just to figure something out. This is true also of
many system level things even in Erlang. The docs are horrific.
Reading the code is NOT an answer. I don't know what a solution
is, but perhaps a concerted effort to create a documentation and
library ecosystem that never links back to Erlang would help. And
where there are critical systems that use an Erlang library,
perhaps rebuilding it in Elixir is in order? Flame away :) I ask
the question because I'm curious how others feel about it, and I
want to help promote more adoption of Elixir. (And hearing from ALL
sides, not just defenders of the faith. What about people who've
tried elixir and moved on?)
Author : srevenant
Score : 83 points
Date : 2022-05-09 14:16 UTC (8 hours ago)
| omgmajk wrote:
| The analogy ~"learning python but also cobol" is not quite
| correct. It's more "learning kotlin but you also have to learn a
| bit of java".
| sa1 wrote:
| > "Erlang is easy, it's just semantics that are different"
|
| The opposite: syntax's different, similar semantics.
| udfalkso wrote:
| I've built quite a lot with Elixir at this point, and I love it,
| and I haven't written any erlang at all (other than maybe a
| couple of very simple function calls). I don't think this is a
| real problem, except for those building very complex
| applications.
| johnisgood wrote:
| I love Erlang. Elixir seems to go away from the philosophy of
| Erlang, and they are pushy about it, they try to make Erlang
| worse in that regard. Leave Erlang alone, and stick to Elixir,
| please.
| dimgl wrote:
| Yes, it absolutely is. The few times I did work with Elixir I
| came across a few instances where I had to use libraries that had
| not been ported over to Elixir yet so I had to deal with Erlang.
| It wasn't fun.
|
| That being said, I think it's only one of the issues affecting
| Elixir adoption. Elixir, while undoubtedly a great language, is
| not very easy to use. The docs have a huge focus on the language
| and its syntax, but don't really hold the hand of developers of
| imperative languages who want to understand the paradigm of
| functional programming.
|
| It took me an obscenely long amount of time for me to understand
| how a GenServer works, and how the entrypoints for an application
| work. This is a big pain point with learning Elixir and every
| time I come back to it I have to do this big mental overhead that
| IMO just isn't productive.
| alberth wrote:
| > I had to use libraries that had not been ported over to
| Elixir yet so I had to deal with Erlang
|
| Why do these libraries need to be ported to Elixir at all?
| dimgl wrote:
| IIRC they don't, but as someone who doesn't know Erlang, the
| Erlang documentation was really hard to read and the APIs
| differed from other Elixir libraries.
| srevenant wrote:
| +100 -- the heart of the problem
| freedomben wrote:
| This last part is really important. If you don't already know
| what GenServer or Application or Supervisor are/do, finding out
| from just the docs or internet posts is extremely hard.
| konfusinomicon wrote:
| did you have an aha moment that finally made it all (genservers
| and entry points) make sense? if so, what was it?
| eric4smith wrote:
| I think we are just more used to Elixir docs.
|
| The few times I've had to jump into Erlang docs, in truth, it has
| not been much of a problem. My main problems have always been the
| differences in string/binaries types between Erlang and Elixir.
| malkosta wrote:
| I work in a company along with dozens of Elixir engineers. It's
| pretty rare that anybody needs to read/write any Erlang code.
| It's a bit rare that anybody has to read Erlang documentation.
| And when that happens, it isn't a burden.
| elesbao wrote:
| Tackling a new language over BEAM and integrating with Erlang is
| as big as Clojure with JVM - The thing is that Elixir used to be
| more erlang-y than it is now and does a decent job hiding the
| hardcore functional/process comm/OTP plumbing. I don't see our
| team writing too much Erlang but we know that a full distributed
| Elixir production setup will incur the same operational load as
| in Erlang. W.r.t documentation, I found Francesco Cesare book
| (and the original Erlang programming book by Joe Armstrong)
| pretty good to help where the doc was too terse. Maybe you are
| looking for documentation on frameworks ? My main block was to be
| used to read http or database framework docs and jump straight
| into functional programming and pure language documentation...
| just an idea.
| dogleash wrote:
| > "cool, learn python, but oh, you also should brush up on cobol
| while you are at it, you know." It's just bizarre.
|
| It's more like learning python and also c. Depending on the
| library, python can smell a lot like the c underneath.
|
| Sometimes you'd never know a python library is written in c,
| sometimes it's a manageable leak like the socket module, and
| sometimes it's opencv. Write enough python and you'll find C
| library wrappers so atrocious and/or badly documented that you
| just whip out ctypes and hack out a replacement wrapper yourself.
|
| The reason you're hearing the answer you preemptively dismissed
| in the OP is that the distance between erlang and elixer is thin,
| much smaller than python and c. That's sorta the bed that elixir
| made itself.
|
| If people believe elixir is held back by erlang, and that elixir
| should do it's best to hide erlang, then the the albatross is
| probably elixir around erlang's neck. Mindshare and time spent
| contributing (e.g. to documentation) should be further split
| between two very similar ecosystems? For what? Because it doesn't
| look enough like Ruby?
| yumraj wrote:
| Perhaps.
|
| My parallel example would be the Play Framework. Play 1.x was
| written in Java, but supported both Java and Scala, and was
| fantastic, easy to use and one of the most productive and
| performant full-stack framework for web development.
|
| Then, they created Play 2.x, where the core was written in Scala
| and if I remember correctly even used Scala for its HTML
| template. Even though it supported Java, and obviously Scala,
| there was a definite drop in its usage and I believe it majorly
| impacted its adoption.
|
| Personally I think if they'd stayed with the Play 1.x model, it
| would have been extremely successful.
| atonse wrote:
| I've used Elixir in production since 2016 and I have only had to
| deeply introspect erlang code exactly once, when I had to
| implement OIDC using Ueberauth and it used the underlying oidcc
| erlang library (which was extremely cryptic and wasted days of my
| life with absolutely useless error messages).
|
| And then I remembered why erlang never picked up. It was a huge
| pain in the butt to try to read the erlang. Didn't like it at
| all.
|
| Apart from that, we've done tons and tons of work in elixir and
| never had to touch Erlang, and for that I'm eternally grateful.
| travisgriggs wrote:
| My N00b take on Elixir in general (were N00B = Have my first app,
| an MQTT/API bridge written and deployed running on Ubuntu
| employing Bandit, Finch, Tortoise, OpenAPISpex, and Jason).
|
| The immediate answer would be no. I would say 5%-15% of my
| questions asked on the Slack channel have ended up in Erlang
| land. The first time someone answered with "you want
| :binary.bin_to_list()", I was completely confused. "What is
| :binary?" It took me a minute for the lightbulbs to say
| "remember, you read Erlang syntax is upside down from Elixir and
| maybe that'a an Erlang thing?" The erlang docs are not _bad_ ,
| but they are structured and navigated very differently than the
| Elixir ones. And the notation differs. It can look almost like
| BNF some times.
|
| I find it inconvenient and annoying that this is so, but never
| felt like it was an albatross. It's a weird split, because many
| common things ARE in both systems. But then, some things don't
| make the cut. And experienced people just "know". Hopefully,
| you're around one of those people either directly or virtually.
| I've asked why not just transcode the entire erlang library over.
| If the languages are nearly associative, just make a process that
| (mostly) automates a conversion. I asked about this in the Slack
| channel, but the sentiment seemed to be "decent idea, but not
| worth the work."
|
| I wish I had opportunity to do more Elixir/Erlang. I have a goal
| to see if I can't learn some LiveView stuff. In my short journey
| I've worked up my list of "love this/wish this were better." This
| issue would be a cool thing to improve, but it wouldn't make my
| top 10.
|
| My loves?
|
| * I love the straightforward simplicity of the language, it
| reminds me of Smalltalk that way
|
| * I really like pattern matching, and recursion. I realized how
| much time I spend in other languages writing code that describes
| where the code goes next. Pattern matching and recursion I really
| like
|
| * The Slack community is great. Better than just about any other
| "open source" community I've gotten help from in the past few
| years.
|
| * The key players (Jose, Chris, etc) are accessible and really
| nice guys. Submitting a documentation clarification PR was super
| nice because of Jose.
|
| * I love piping. I'm told newbies overdo this. I'm still loving
| overdoing it. I wish the syntax were a little less difficult to
| type; I should figure out how to do some hotkey thing I guess.
|
| * Binary. Wow. Parsing binary data streams in Elixir just rocks.
|
| * I like OTP more and more; often the community seems at odds
| with it. It's not "purely functional". This may be the area the
| author was originally barking at.
|
| Things that disappoint me (so far, but I am open/hopeful to
| coming round in some cases):
|
| * VSCode is OK. But a language like this really wants a decent
| IDE. I want to work on functions, not files.
|
| * I love/hate the formatter. I love that there is one and I get
| consistency. But it's not associative. A formatter should format
| my code, not just kind of format it. If it made a 3 lines out of
| one of my long lines, but then I shorten the code, so that it can
| now fit on one line, it should do that. It can't because it
| doesn't know the difference between extra new lines I put in and
| one's it added. The reality is, I want it to format the whole
| file, not just the horizontal space. The fact that newlines are
| part of the syntax in some cases makes this even more of a
| problem. IMO syntax either own newlines completely (python) or
| leave it as a presentation character and design the syntax so the
| whole program could go on one line if it needed to.
|
| * To date, I have found the defstruct story unfulfilling. The
| syntax is a bit weighty to type %SomeStruct{foo: 1, bar: 13}
| requires me to do a lot of slow reaching shifts and it always
| feels like it slows me down. One defstruct per module hasn't
| scaled well for me. When I switch back to Python/Kotlin/Swift,
| the struct/dataclass just works better for "modelling" up data.
|
| * "Namespaces are a honking good idea - we should do more of
| them!" Elixir looks like it has namespaces with
| Dotted.Module.Names. But only barely. In fact, since there are
| edge cases where nesting modules creates issues, I took to never
| nesting them, even when using Similiar.Dotted.Prefixes to "group"
| them. Eventually, you realize you could just use _ or pretty much
| any separator. The dot's have very little value. I wish the
| namespace story was more like Python's (but not the shadow
| binding nonsense).
|
| * Macros are awesome. BUT, sometimes it can get really confusing
| what's going on. I don't love the quote/unquote thing. What I
| have sorely missed with some macro heavy libraries is the ability
| in the IDE to see what the code turns into. Kind of like running
| just the C Preprocessor on macro heavy C code to see what's
| really going on.
|
| * I do not love do/end. We have punctuating characters in
| romanized languages for a reason. They structure and organize the
| words and phrases we use inside of them. When we use alphabetic
| words to do this, the brain has to parse more to separate the
| structuring elements from the content.
|
| * I _think_ I 've come to appreciate the "batteries included"
| language approach more. There's a balance of course. Python has
| some stuff in it that just seems silly to be in the base library.
| But a lot of things is just there ready to be used. In Elixir,
| I'm left guessing what extra modules to use. It's hard to know
| what's being actively supported. And discovery is yuck. I wish
| for more ItDoesThis boring names rather than cute/clever plays on
| words for package names. For example, would the lay reader be
| able to guess what my Bandit, Tortoise, and Finch modules
| actually do?
| josevalim wrote:
| This is fantastic feedback. I always love reading posts like
| yours. Three quick notes to complement what you said:
|
| * The formatter is always a balancing act. The behaviour you
| see is because people get really upset when we don't respect
| their line breaks (and, as you correctly said, we can't later
| know which newlines were introduced by us). You can try
| formatting more frequently to get feedback sooner (that's what
| I do: I usually type code with no indentation whatsoever and
| "collaborate" with the formatter as I go).
|
| * I am thinking really hard about the struct problem and trying
| to find a balance between getting some of the guarantees of
| structs without having to hijack a whole module.
|
| * Re namespaces, agreed they are not as powerful as namespaces
| in other languages, because they are not actual entities.
| However, you shouldn't run into issues. If you do recall what
| it was, feel free to reach out or post something in the forum.
| The dot notation can be useful in aliases (which a different
| separator would not help).
|
| Have a good week!
| travisgriggs wrote:
| People like Jose are why I like the Elixir community. So many
| others would have taken offense and become defensive.
| pera wrote:
| > The notion that to learn a language you also need to learn a
| second one is not great
|
| It depends on how far you're trying to go maybe? You could argue
| that, for any given programming language, there is always a point
| where you will have to learn some intermediate representation
| language to achieve certain tasks; I personally don't think this
| is unique to Elixir.
| my69thaccount wrote:
| This is just a result of your own context and background. If you
| were an Erlang developer then Elixir would come naturally. If you
| started to learn Python as an Erlang developer and had to
| understand its C implementation details (via SciPy etc, which
| operations are implemented in Python or natively) you would make
| this same post in reverse. But you're taking that for granted
| because you are already coming from that position.
| throwaway81523 wrote:
| I've used Erlang and have been interested in Elixir but haven't
| used it. After a little getting used to, I've generally liked the
| Erlang docs. I have the impression that Elixir is just Erlang
| with different surface syntax so the main real differences are in
| the library culture (Elixir's are more Ruby-inspired, with
| Rails's inanities mostly cleaned up). From a Lisp background, all
| these languages are pretty much the same. Erlang/Elixir's
| concurrency story is far better than say Python's, but that's not
| really about the language per se.
|
| I'd actually like a statically typed BEAM language. A few of
| these have been attempted, but I don't think any have gotten
| traction.
| dpeck wrote:
| https://en.m.wikipedia.org/wiki/Betteridge's_law_of_headline...
| JohnHaugeland wrote:
| > What about people who've tried elixir and moved on?
|
| I've tried it three times and it offered me nothing Erlang
| didn't. Erlang, on the other hand, offers me much that Elixir
| does not.
|
| In truth, I've never met anyone who likes Elixir except people
| who were already Ruby programmers.
|
| What's particularly weird is your attempt to dig at the Erlang
| docs. They're extracted the exact same way the Elixir ones are;
| it's just a different CSS theme.
|
| C'mon, dude. This is very much a "coffeescript is held back by
| javascript" post. Yes, we know, Kotlin is really burnt by its
| Java roots, etc, etc.
|
| The base language always lives. The descended language rarely
| does.
| Skinney wrote:
| > Erlang, on the other hand, offers me much that Elixir does
| not.
|
| Genuinly curious. Like what?
| xzyyyz wrote:
| Nice to meet you. I am completely un-Ruby Pythonista, and I
| like Elixir a lot.
|
| I felt the same way as topic starter, and I invested couple
| months to make several tools Elixir-native -- the project was
| cancelled with the layoff.
|
| I think, this is a compromise. I strongly dislike Erlang
| abstraction leak, but I understand the desire to deliver the
| language, and iterate on cleaning up toolchain & libraries
| later.
| srevenant wrote:
| Although I also have issue w/the Elixir docs, they tend to have
| more explanations in them than the Erlang ones. Marginally :)
|
| I am one who came not from Ruby, btw. My roots come from a
| variety of things including Smalltalk, C, C++, Perl (dare I
| admit), Java, Javascript and Python, among those most
| influential on my life (and in that order).
|
| I'm really happy w/Elixir, finally getting back to a better
| true object oriented system (for those who know the roots of
| such).
| devoutsalsa wrote:
| Reminds me of this blog post:
|
| "The Most Object-Oriented Language" =>
| https://blog.noredink.com/post/142689001488/the-most-
| object-...
| srevenant wrote:
| Yep :) Anybody familiar with the roots of OO will
| understand how wildly Java/C++ and their ilk went off the
| rails. It wasn't intended as a code organizational system.
| It's about encapsulation of needs, actors, and sending
| messages back and forth.
| null0ranje wrote:
| Elixir was a gateway to Erlang for me. I hadn't heard of Erlang
| before I started writing in Elixir, but all the discussion of
| why Elixir was so great revolved around Erlang and the BEAM.
| This lead me to Joe's distributed systems thesis and really
| changed how I approach writing code.
|
| The syntax takes a bit of getting used to, but I generally
| prefer the language. I haven't found anything that's a nice to
| work with for web app development in Erlang, though; I do think
| the tooling around Phoenix is nicely polished.
| freedomben wrote:
| Is this the "Joe's distributed systems thesis" you refer to?
| https://erlang.org/download/armstrong_thesis_2003.pdf
|
| Edit: After reading the first bit of that I'm pretty
| confident that is was GP was referring to. It's a really good
| paper and worth reading to understand why Erlang/Elixir do
| many of the things they do.
| lawn wrote:
| Macros in Elixir are very nice, so you only have to implement a
| few functions to get a GenServer instead of the whole protocol.
|
| Also, I'm not a Ruby developer but still found Elixir to be
| nicer than Erlang in small but important ways. The
| documentation part does hold true IMO, as the official Elixir
| docs are fantastic, which goes beyond just a different CSS
| theme.
| pessimizer wrote:
| > In truth, I've never met anyone who likes Elixir except
| people who were already Ruby programmers.
|
| This was the purpose of the language (or if not an explicit
| purpose, the primary effect.) Elixir created an environment
| that attracted Rails people (and other people repulsed by
| languages that don't look like C/Algol), and behind the Rails
| people (Rails been long established as a safe choice but aging
| and scaling badly) comes management of safe companies and
| consultancies, and with that comes a sure way of making a
| living for people who love Erlang and are willing to play the
| Elixir game.
|
| Elixir is the same as Erlang, except with bad syntax and loaded
| with various ways to make your programs indecipherable, and
| with a cleaned up standard library and lots of nice little
| affordances/templates to help with processes and OTP. While
| Elixir (in my experience) takes a lot more debugging due to the
| weird javascripty syntax and pseudo-mutable variables, it's the
| same thing in my book (and the error messages are great.)
|
| Happy to do the one that provides the most work, and thankful
| that they created it.
| josevalim wrote:
| It was not the purpose of the language nor I believe it is
| its primary effect. It was the immediate effect though.
|
| At last ElixirConf, I remember asking for a show of hands on
| people's backgrounds, and I would say Ruby was 40-50%. It is
| impossible to know how it applies to the community as a
| whole, but I think the idea that Elixir is "Erlang for Ruby"
| is several years dated at this point.
| jacquesm wrote:
| This is why I've always just settled for the 'root' language and
| try to stay away from derivatives even if those offer a lot of
| goodies the 'root' does not offer. So no Typescript, Clojure or
| Elixir for me. I also think that the main attraction of an eco
| system is how long term stable it is and usually the second layer
| is less long term stable than the foundation.
|
| And usually such a 'derivative' language only serves to fragment
| the eco system (community, contributions) of the 'root', not to
| enhance it.
| dimgl wrote:
| One of those is not like the other. JavaScript and TypeScript
| are almost interoperable. You don't have to relearn the
| semantics of the language to use a JavaScript library in
| TypeScript. It's is an extremely light superset compared to
| Clojure, Scala, Elixir, Kotlin, etc.
| jacquesm wrote:
| Typescript requires an intermediate step though.
|
| We had the Typescript vs JS debate when starting out with
| pianojacq.com and I was pretty strongly committed to doing it
| in plain JS and not to have any tooling dependencies or build
| step. Which I think is the one thing that makes JS at least
| moderately interesting: that it is a language that in theory
| does not require any tooling beyond the browser. Of course,
| the day Typescript is supported natively by the browsers that
| argument will die. But for now that does not seem to be the
| case.
| dimgl wrote:
| I agree that just JavaScript is okay for simple
| applications. In fact I didn't use TypeScript for a really
| long time because getting the tooling going can be
| cumbersome at first.
|
| TypeScript shines with complex webapps. Having the typing
| prevents a whole class of issues and helps with refactoring
| quite a bit.
| jacquesm wrote:
| Yes, agreed. And small projects tend to grow to much
| larger projects over time so it may well make sense to
| choose Typescript even if your project is still small.
| mikepurvis wrote:
| True, though I think part of this is also recognizing that
| the more the semantics diverge, the more potential upside
| there is.
|
| Not that JavaScript-with-types isn't a compelling pitch for
| TypeScript-- it totally is. But that's a benefit that is
| primarily geared toward scale and safety, whereas Clojure is
| a completely different _kind_ of language from Java. Maybe I
| 'm just arguing essentially the same point here, that Clojure
| is always going to be a niche, but the core of it is that if
| your problem domain demands using a Lisp, and you have other
| reasons to want to be on the JVM, then it's likely that the
| cost of having to pick up some Java is going to be well worth
| it.
| adamors wrote:
| I feel like this is an issue with all superset languages or
| however you want to call them and should be taken into account by
| anyone learning one of these.
|
| You can't really learn Elixir without also learning _some_
| Erlang, you can't really learn TypeScript without learning some
| Javascript, you can't really learn Clojure without picking up
| some Java. The platform/base language is abstracted away to some
| extent but not completely.
|
| It's especially visible when trying to use libraries used in the
| platform language.
| cutler wrote:
| I've been happily using Clojure for about 9 years and hardly
| ever have I needed to dip into any Java code. That's not to say
| I can't grok Java if I need to. Compared with the monstrosity
| that is Gradle deps.edn is a breath of fresh air.
| ch4s3 wrote:
| > You can't really learn Elixir without also learning _some_
| Erlang
|
| I'd argue that you end up learning a good bit about OTP,
| Erlang's standard library, and some stuff about the VM but very
| little Erlang in practice. Although if you know about BEAM, and
| some of the standard library there isn't much "Erlang" to learn
| after that. It doesn't seem to leak into Elixir the way Java
| does in Clojure, and the surface area of Erlang is smaller than
| Java anyway.
| adamors wrote:
| If you use these superset languages day-to-day you will end
| up interfacing with the base/platform language at some point.
|
| Just recently I had to figure out why the Elixir Kafka
| library didn't support something and I ended up using the
| wrapped Erlang library at the end. Without some Erlang
| knowledge I would have been completely lost.
| ch4s3 wrote:
| I don't exactly disagree, but what I mean is that in
| learning Elixir you'll learn about the BEAM and by the time
| you need to peek under the hood, it's just syntax that's
| different mostly.
| ravi-delia wrote:
| Yeah Erlang idioms are what make Elixir so powerful, but you
| basically don't have to touch actual Erlang. I've messed
| around, just because I felt like I should have some
| appreciation for the work Erlang developers put in, but the
| Elixir wrappers are good enough it's almost never necessary.
| Even if you need an Erlang library, you're just calling the
| functions and the docs are usually pretty good.
| sergiotapia wrote:
| Been using Elixir since 2016 and I don't know anything about
| Erlang beyond "it uses BEAM". You don't need Erlang to use
| Elixir.
| Communitivity wrote:
| I learned Elixir early on, and then had other tasks and languages
| I needed to devote my time to. So I haven't kept up with it. I
| remember though that learning Erlang first well (including how
| BEAM worked) was a huge help to me in learning Elixir. It lets
| you understand what is going on under the hood. That said, I've
| used the analogy of Elixir is to Erlang the way Java is to JVM
| byte code. That means you can master Elixir without ever coding
| Erlang, but I think you'll have a harder time of it.
| freedomben wrote:
| I think it's important to differentiate between groups, because
| it is definitely possible (and normal) in some situations not to
| ever need to understand Erlang or know anything about it.
|
| If you are building a Phoenix web app, you can go many years and
| never run into non-trivial/non-obvious Erlang (excepting perhaps
| a small thing here or there, although many of those have Elixir
| wrappers now). I've also heard similar regarding Nerves apps.
|
| On the other hand if you're writing a non-trivial CLI or app that
| doesn't use any sort of "framework" and you have to dig into OTP
| more than just the standard well-documented-in-elixir functions,
| then you will most likely run into the problem described in the
| question.
|
| I don't think it's "an albatross" but it's certainly not ideal.
| Now that real apps/companies are using Elixir and it's not just
| the hobbiest/early adopters, it's an important question to ask
| and I'm glad to see it!
|
| I wonder how much we can solve this by improving the Elixir docs.
| If we better document the areas where people end up digging into
| Erlang, it seems like it would help. I'm hesitant to accept the
| "to be a Sr Elixir dev you might just need to learn a little
| Erlang" but that's also worth considering.
| jacquesm wrote:
| > I don't think it's "an albatross" but it's certainly not
| ideal.
|
| I find the whole framing problematic. To call the foundation
| that you are building on and that you seek to displace an
| albatross is missing the option that it could easily be seen as
| being the other way around.
| freedomben wrote:
| > _I find the whole framing problematic. To call the
| foundation that you are building on and that you seek to
| displace an albatross is missing the option that it could
| easily be seen as being the other way around._
|
| well of course, if you're coming from an Erlang perspective,
| Elixir is a language that solved/solves a problem that
| doesn't exist. This is a valid view, but OP's thread is
| specifically asking as an Elixir dev with the perspective
| that Elixir solves a problem, rather than introduces one.
|
| Recognizing that different perspectives exist isn't bad (and
| in many cases is very good), but it doesn't feel super
| constructive in a thread that precludes those perspectives.
| It seems a little like forum questions saying something like,
| "how do I do X on Windows?" and somebody replies, "Install OS
| X."
| pessimizer wrote:
| Except nobody is asking how to do anything, so every answer
| is equally unproductive.
| chrismccord wrote:
| As the creator of Phoenix, I've never written an Erlang program
| fwiw. That said, I frequent the Erlang docs and most seasoned
| Elixir developers will do the same because the standard library
| is a wealth of features, and the documentation while not 2022
| polished, remains a remarkable resource.
|
| > I don't know what a solution is, but perhaps a concerted effort
| to create a documentation and library ecosystem that never links
| back to Erlang would help. And where there are critical systems
| that use an Erlang library, perhaps rebuilding it in Elixir is in
| order?
|
| This would not be helpful. Erlang has over _three decades_ of
| features, heritage, and libraries. Elixir helped usher in first
| class documentation as a core language feature, but that doesn 't
| make rock solid Erlang libraries somehow things that should be
| avoided. Rewriting for rewriting sake is also not a good idea.
| One of the benefits of bootstrapping off an already amazing
| platform is exactly because you don't have to invent the
| universe. See Clojure and Java.
|
| In fact, Elixir has helped Erlang up its documentation game, and
| there is already work done to help the ecosystems share
| documentation tools. Both ecosystems work by rising together, not
| masking one or the other. We see this in tools like `telemetry`,
| documentation generators, and recently the Erlang Ecosystem
| Foundation: https://erlef.org
| johnisgood wrote:
| Phoenix seems quite bloated. Is there any way to make it work
| without JavaScript, or do I have to rely on it? I really wanted
| a web framework where I can have routers, templates, sessions,
| and the usual stuff and no JavaScript, only if I write it
| myself into the template. :(
| jolux wrote:
| There's no JavaScript unless you write it into the template.
| If you want to use LiveView that needs JavaScript but plain
| old templates do not.
|
| As for bloat I don't really agree but I can see how it might
| appear that way. Phoenix is actually not monolithic, it is
| sort of just a set of conventions and macros (batteries) that
| make using Plug and Ecto and some other libraries together
| more cohesive and more like programming in Rails. If you
| don't like that approach you can also just use Plug and
| Plug.Router directly, which is more of a microframework feel
| like Flask or Sinatra.
| [deleted]
| johnisgood wrote:
| Got any resources for simple usages of Phoenix? Most of
| them are all about LiveView and a lot of stuff that uses
| JavaScript.
|
| > There's no JavaScript unless you write it into the
| template.
|
| I want this. How do I achieve this? "mix phx.new" is not
| it, as there are JavaScript files in "assets/", for
| example.
| conor- wrote:
| You pass the `--no-assets` flag when using `mix
| phx.new`[1]
|
| Also ime, there's not many good blog posts or guides
| around Phoenix that I've seen. The sort of de facto
| resource would be the Programming Phoenix book. It's well
| worth the $25 considering the amount of effort Chris and
| co. seems to have put into it.
|
| [1]https://hexdocs.pm/phoenix/Mix.Tasks.Phx.New.html
| johnisgood wrote:
| Thank you! Will give it a go. :)
| ricketycricket wrote:
| `mix phx.new foo --no-live` does that. LiveView is completely
| optional. Node/npm has been completely replaced by esbuild
| and even that is optional if you want to rip it out and
| handle assets another way.
| johnisgood wrote:
| Yeah, I suppose that is why I thought it required
| JavaScript (the book instructed me to type --live). I was
| following the instructions of some books and there was
| JavaScript such as utils.js and whatnot.
|
| I typed what you told me, but it does have
| "foo/assets/vendor/topbar.js" and "foo/assets/js/app.js".
| Not sure what those are though or if they are a necessity.
| It ends up being
| "deps/phoenix_html/priv/static/phoenix_html.js" on
| localhost:4000. Any ideas as to how to COMPLETELY avoid
| JavaScript? Are there any sources for that perhaps?
| conradfr wrote:
| https://hexdocs.pm/phoenix/Mix.Tasks.Phx.New.html
|
| I think you want the --no-assets option.
| _acco wrote:
| Highlighting an important distinction Chris makes: there's a
| _huge_ difference between needing to learn to _read
| /understand_ the basic syntax of a language and needing to
| learn to _write_ it.
|
| When writing Elixir, yes, you'll be exposed to Erlang
| syntax/docs sooner or later. But you're not _writing_ Erlang,
| so you never need to learn how to: - Compile
| more than a couple lines of Erlang into a function -
| Create an Erlang module/file - Learn Erlang's build
| tooling - Cold recall its syntax
|
| Creating something functional from scratch in a language is
| 100x (1000x?) more challenging than learning how to roughly
| read it.
|
| I've been programming full-time in Elixir for a couple years.
| All told, I think I spent 3-5 hours one afternoon learning the
| basics of Erlang's syntax so I could better read the docs.
| Haven't had to think about it consciously since.
| linkdd wrote:
| This.
|
| I was able to read Erlang before knowing the name of the
| language. I discovered this language by looking at the source
| code of RabbitMQ, and I was surprised at how I could read it,
| knowing nothing about the language.
|
| At first I thought atoms were variables defined somewhere
| (and I did not care where it was defined, the names were
| explicit). When I learned that they are in fact values, it
| blew my mind.
|
| It's only 6 months later I started coding in Erlang. Then 3
| years ago I started writing Elixir. I did not have to learn
| Elixir in fact, it was just another syntax for what I already
| knew.
|
| I always recommend learning Erlang first with
| https://learnyousomeerlang.com/ and then learning Elixir.
| Simply because this book does a far better job at explaining
| OTP than the Elixir docs.
|
| Maybe there is some value in writing learnyousomeelixir.com?
| SOLAR_FIELDS wrote:
| I can read C++ pretty well, I know how to build, compile, and
| run C++, but I probably couldn't write very good C++. I think
| it's like reading a book about how a machine gun is used in
| action and constructing one vs. given a machine gun with no
| hands-on training and trying to use it myself.
| mgdev wrote:
| Devil's advocate:
|
| What would it take to programmatically port/transpile the core
| of Erlang's ecosystem to Elixir?
|
| Pick the killer app to serve as the root node (Phoenix?) and
| walk back to the leaves (OTP, popular libraries, etc). Do a
| 1-time cutover of literally everything. Fork/port ERTS (incl
| BEAM) to make Elixir-native and rebrand it. Etc.
|
| While I generally agree that "rewriting as bad" there is
| something to be said about the importance of _ease_ when
| bootstrapping and scaling an ecosystem. You're either stealing
| mindshare from an established ecosystem, or you're capturing
| new minds as they come in.
|
| IMO Elixir/OTP is too radically different from other very-large
| ecosystems to benefit from transfer learning for junior/mid-
| level people (great similarity w/other smaller fringe ones,
| like Ruby, Clojure, etc, but that won't get us there), and the
| most senior people fall into the "it's all the same at the end
| of the day" trap and don't put in the energy absent some strong
| business driver. So you really need to reduce even the
| shallowest cognitive bumps to get escape velocity.
| jolux wrote:
| I had this same thought because I think Elixir and Erlang are
| actually similar enough that translating between them
| directly may be feasible and have decent results. I don't
| really think forking is a good idea though. As I understand
| it most BEAM maintenance is actually done by Ericsson, and
| I'm not sure the Elixir community has the resources to
| sustain a project like that. It seems like it would also
| create bad blood with the Erlang community and risk breaking
| compatibility eventually, which would be a huge loss for
| users of libraries like Ranch and Hackney.
| j4pe wrote:
| Is it a bit of extra complexity? Yes.
|
| Does it cause friction for new devs? No - I can't think of any
| mainstream Elixir use cases that require Erlang libraries, with
| the exception of math operators like `:math.sqrt/1`. Chris'
| comment here is the golden example of this.
|
| And anyway, what does the user get in exchange for that extra
| layer of complexity? A unique high-concurrency VM with easy-to-
| use primitives that would require huge gobs of code and lots of
| added dependencies in other languages.
|
| It's a small tradeoff. My own experience is that the benefits
| far outweigh the complexity cost.
|
| It sounds like OP mostly objects to the oldschool textfile
| documentation aesthetic of a lot of Erlang core and libraries,
| which is fine, but the overwhelming majority of new Elixir devs
| doing web applications and data processing will never encounter
| this.
| alberth wrote:
| Raw performance is the actual albatross.
|
| IMHO, the low raw performance of Erlang is what's holding it back
| from mass adoption.
|
| (Even marquee Erlang/Elixir users like Discord, still have to use
| Rust NIFs to overcome the slow Erlang runtime)
|
| People have a hard time understanding how Erlang can have such:
| high concurrency, low latency & tight standard deviations ...
| when people are just accustom to looking at raw performance
| benchmarks (where Erlang does quite poorly).
|
| While BeamASM (JIT) is very exciting, the reality is that the
| Erlang runtime has only speed up by ~25% over the last decade,
| where other languages like JS, Go, PHP have seen >150% speed ups
| (and Erlang was already considerably slower than these languages
| prior to their speed ups).
| Communitivity wrote:
| I am dubious it's the performance of Erlang that's the
| albatross, considering the performance of RabbitMQ messaging
| system and Process One's XMPP server ejabberd. However, at the
| end of the day Erlang is a VM language, so I'd think it's not
| going to be as fast in many cases as Rust. Performance in a
| distributed system is good, because of the design, but that's
| still not the #1 priority of Erlang. I think Erlang's #1
| priority is robustness.
|
| Then what is the albatross?
|
| I think it is complexity. Erlang, and OTP, is not simple to
| understand. There are a lot of footguns. It is beautifully
| designed and fit for purpose, given it's history and heritage.
| However, the learning time for creating a real app in Erlang is
| high. To flip it around, I think the reason Ruby caught on so
| fast was that it was so easy to learn Rails and create a web
| app with it.
|
| You could perhaps convert Elixir to be based on top of Rust,
| but there are many concepts that don't map, or don't map well.
| derefr wrote:
| > While BeamASM (JIT) is very exciting, the reality is that the
| Erlang runtime has only speed up by ~25% over the last decade
|
| Yes... because perf hasn't really been a focus for Erlang until
| about 1.5 years ago. Various (usually academic) third parties
| have contributed big performance-enhancing patchsets (the
| earlier JIT; Dialyzer and then HiPE based on Dialyzer analysis;
| etc.) but these have then languished, with attempts to further
| development on them slowing to a crawl over time. The patchsets
| were just "too big to be digested properly"+ by a team of core
| maintainers who 1. didn't write the code, and don't fully
| understand it, and 2. who aren't CS academics themselves.
|
| Each of these indigestible patchsets was eventually dropped,
| throwing away any follow-on in-tree work done to it, and
| dropping perf back to where it was before said patchset was
| introduced.
|
| The new work is in-tree, done ground-up by the core maintainers
| themselves, and so is actually showing linear improvements in
| speed. This not only includes runtime speed, but also the
| batteries-included addition of long-ignored performance-
| oriented features, like atomic counters and fast global
| readonly modules (and the runtime itself being gradually
| rewritten in terms of these!)
|
| + This is exactly why, in the Linux kernel, big patchsets
| aren't accepted as-is, but rather are required to be broken
| down into small changes that 1. can add value on their own, and
| 2. can be molded to fit the design philosophy of the kernel on
| their own. This is why e.g. the "containers" patch from OpenVZ
| was never pulled in; but instead, each bit of it was gradually
| reworked into the cgroups + namespaces code that powers Linux
| containers today.
| MrWiffles wrote:
| As an Elixir noob, I'm reading these comments about
| performance and coming to some conclusions that I'd like to
| ask ya'll to idiot-check me on.
|
| First, let me establish that there are at least two ways of
| thinking about performance in the context of a server-side
| HTTP application:
|
| 1) Per-request speed ("from receiving the request to
| response, single-threaded, X ms") 2) _Throughput-based_
| metrics ( "We can serve X requests per second with Y cores
| spread across Z nodes")
|
| I think both ways of measurement have value, but in this
| context I'm operating under the assumption that we're focused
| on option 2. Correct me if I'm wrong.
|
| Now, with that understanding in place, it sounds to me like
| Elixir/Erlang performs "pretty good" in terms of that overall
| throughput if you leverage the multithreading capabilities in
| building your apps and thread scheduling isn't terribly
| contentious (hopefully not a lot of other processes/threads
| competing for execution time on the same machine as your
| Elixir app), but measured on a raw per-operation speed metric
| it doesn't quite stack up to other non-compiled languages
| like PHP or maybe even Ruby (which would shock me but let's
| just poke that bear anyway, see what kinda growl we get...).
|
| So if indeed my understanding is right, my next question is:
| "how much of a performance reduction would we realistically
| see with an Elixir app that's otherwise well built and doing
| the same thing?" Issues of misconfiguration, bad deployment
| architecture, etc. withstanding.
|
| And if that question is indeed valid/not-batshit-crazy, my
| next would be: "does that degredation matter or scale in a
| multi-node/clustered deployment context?" In other words, if
| you have a say 50-node (be they VMs or containers) Elixir
| app, built well, properly configured and deployed, load
| balanced etc., is it going to have significantly/noticeably
| slower throughput than an equivalent PHP/Java/Ruby/$OTHERLANG
| app when compared as close to apples-to-apples as you can get
| that sort of thing?
|
| (Maybe take Ruby out of the equation here with issues of
| GIL/threading being what they are over there. Haven't had the
| chance to work with recent Ruby though so if threading is a
| valid comparison nowadays, by all means keep it in mind!)
|
| I'm just trying to get a sense for whether or not I'm barkin'
| up the wrong tree with my recent interest in Elixir. Am I
| wasting my time _right now_ and maybe should wait a few years
| before really tearing into it, or is it _effectively_ in a
| real-world, non-academic scenario, going to perform "close
| enough" in the real world in a multi-core, multi-node load
| balanced context?
| alberth wrote:
| > perf hasn't really been a focus for Erlang until about 1.5
| years ago.
|
| The core maintainers _have_ been working on JIT /perf for
| 10-years.
|
| You can see Lukas own described 10-year journey documented
| below.
|
| https://drive.google.com/file/d/1hHCs90kDX_wJ9AbLzGNu5bZKdIV.
| ..
| derefr wrote:
| I've had this conversation on HN three times now, and I'm
| misunderstood each time I say it. It's getting a bit
| frustrating.
|
| I'm not saying that the Erlang maintainers haven't been
| _trying_ to work on perf. I 'm saying that their _approach_
| to working on perf has, until recently, been to focus on
| building on top of large blobs of relatively-opaque third-
| party code -- either in-tree code, like HiPE; or library
| code, like LLVM. These approaches haven 't been
| maintainable, and have eventually been dropped.
|
| The difference in the last 1.5 years is that the perf
| enhancement this time is purely due to optimizations to the
| emulator and runtime -- and improvements to the way the
| compiler works enabling better runtime insight into the
| code -- with no big blobs of opaque code being relied upon.
| There's nothing extra to maintain; no big experimental
| perf-hack to enable with a feature flag. It's just the
| runtime itself being improved.
|
| With previous attempts, the perf improvement was a sigmoid
| sawtooth: perf increased, levelled off, and then dropped
| back down. This time, the perf improvement is a linear
| ratchet function.
|
| ---
|
| My other point, is that until fairly recently, most of
| Erlang's biggest users were "enterprise" customers with
| embedded use-cases, whose #1 concern was stability -- they
| didn't care about perf-enhancing _new language features_ ,
| because they weren't about to rewrite their
| working+tested+certified code just to get better perf. They
| were only interested in "transparent" perf enhancements.
|
| More recently, though, large non-"enterprise" corporate
| users of the Erlang runtime, like WhatsApp and Discord,
| have been migrating their work developing third-party perf-
| enhancing feature modules upstream as language features,
| because they _are_ interested in rewriting code to increase
| perf -- as long as that rewritten code is also just as
| maintainable (if not moreso.)
| alberth wrote:
| > I'm saying that their approach to working on perf has,
| until recently, been to focus on building on top of large
| blobs
|
| Totally agree.
|
| Off topic: I really love Erlang/Elixir - but I'm
| beginning to losing hope in being able to see a path
| where it can 3x improve performance. There has be a lot
| of people for a _very_ long time been hoping this major
| improvement will come "soon". I'm unfortunately just not
| seeing it happening or a path to it ever happening. I
| hope I'm wrong.
| conradfr wrote:
| FWIW I have ported Json APIs from JS & PHP to Elixir and the
| Elixir ones were the fastest (on the same server). And it was
| before even leveraging ETS to cache DB data (which is faster
| than Redis by design).
| jacquesm wrote:
| Erlang excels at the 'hard' parts of the problem space having
| to do with complex distributed ultra reliable systems, the
| 'number crunching' bits are offloaded to specialist languages
| because the underlying language model that Erlang uses does not
| lend itself for the kind of optimization that JS, Go, PHP etc
| have available to them simply because their runtime model is so
| completely different.
|
| The biggest issue from what I know about how Erlang works
| internally is not so much the fact that Erlang could not in
| principle be made fast (and indeed, BeamASM will if it makes it
| to mainstream become a good step in the right direction), but
| that the whole way in which Erlang schedules its threads is
| super ineffecient in terms of cache use and besides the byte
| code interpreter relies on its ability to keep track of the
| number of reductions that it has done to determine when a
| thread has had enough cycles and we need to move on.
|
| This means there will always be a fairly hard upper limit as to
| how far you can optimize Erlang byte code, it is at its core a
| cooperative multi tasking operating system inside a user
| process.
|
| One of the more elegant ways to do such interop is to isolate
| your number crunching code to a separate process group working
| their way through a queue one unit of work at the time that way
| you can use all of the Erlang goodies and still get very good
| performance.
| the_only_law wrote:
| > the 'number crunching' bits are offloaded to specialist
| languages because the underlying language model that Erlang
| uses does not lend itself for the kind of optimization that
| JS, Go, PHP etc have available to them simply because their
| runtime model is so completely different.
|
| Yeah I love Erlang, but often reach for something else when I
| need to be able to express and optimize compute bound
| problems.
| jacquesm wrote:
| In a way it makes perfect sense. When I look into my
| toolbox I see a whole pile of different saws, each of which
| has a specific usecase, metal, wood, living wood, trees,
| joinery, figure work, glass+ etc. The one-tool-to-fit-all-
| usecases programming language hasn't been invented yet as
| far as I can see.
|
| + technically, probably more of a grinder because the blade
| is covered with diamond dust, but you use it like a saw.
| MrWiffles wrote:
| > The one-tool-to-fit-all-usecases programming language
| hasn't been invented yet as far as I can see.
|
| Well, just like you can use a screwdriver to pound a nail
| into the wall (flip it handle-first), you _could_ use C
| or Rust or Go or Java or...nearly anything to
| build...nearly anything if you really _forced_ it hard
| enough, had infinite time, expert labor and budget,
| but...
|
| ...there are better tools for the job of pounding a nail
| into the wall than a screwdriver! ;-)
|
| In other words, I totally agree with you. Sure, you
| _could_ build, oh I dunno, say a compute-intensive
| application entirely in, say, Ruby, but you 'd need to
| throw some ungodly expensive hardware at it. Makes a lot
| more sense to use the right tool for the job!
| derefr wrote:
| > One of the more elegant ways to do such interop is to
| isolate your number crunching code to a separate process
| group
|
| Or, if you want to maximize perf inside some hot section of
| code (say, a game-engine renderer) while also retaining
| Erlang semantics for how it interacts with the rest of the
| system, you can write your code as a "threaded NIF" -- a
| native thread (in C or Rust or whatever) that sends messages
| back over to the arbitrary Erlang processes in its address-
| space (not just its owner process!) as it works.
| alberth wrote:
| What concerns me is I see people talk about using NIFs like
| no big deal.
|
| BUT, they come at the cost of potentially bringing down the
| entire Erlang runtime. People use Erlang, more times than
| not, because they want a fail-safe runtime ... so
| recommending NIFs shouldn't be taken lightly.
|
| Just my 2 cents.
| derefr wrote:
| > People use Erlang, more times than not, because they
| want a fail-safe runtime
|
| I disagree; 99% of people running Erlang runtimes are
| running them in use-cases where it'd be _fine_ if any
| individual node crashed and got restarted.
|
| (E.g. running a Phoenix web-app as a K8s replicated
| Deployment, with no durable internal state, only the
| mesh-replicated Phoenix.Presence data that can be
| recovered from peers after node restart; where, for
| users, even having a long-running websocket is just an
| optimization over long-polling, and so it's no skin off
| the clients' backs if said connection gets dropped once
| in a blue moon, requiring them to reconnect to another
| node in the cluster.)
|
| I agree that you should only be using NIFs after you've
| exhausted the other options -- "C nodes" being my
| favorite of those, personally.
|
| But downplaying NIFs ignores a whole other segment of
| use-cases, where you're not _adding native code to
| Erlang_ , but rather you're _starting_ with a "core" of
| native code (e.g. an HFT trading engine), and then
| building an app by _wrapping_ that native code in Erlang,
| where the code presents itself to Erlang as a NIF.
|
| If efficient shared-address-space high-throughput
| interaction between your native "core" and your higher-
| level "glue" is the whole _point_ , then Erlang+NIFs is a
| pretty great way to get a bunch of advantages without
| losing much. It's a lot better than what you get from the
| alternatives -- where those alternatives are "loading the
| native core as an FFI module in some other dynamic
| language runtime."
| aeturnum wrote:
| The phenomenon you're talking about, imo, doesn't have anything
| to do with Erlang or Elixir.
|
| All languages have limits to what you can do natively. There will
| always be some tasks where you will cross a language barrier from
| "your" language to another. To me, the question is: "Is the area
| that Elixir covers big enough to recommend?" and I think the
| answer is yes.
|
| I do not think most programmers _need_ to learn Erlang to use
| Elixir - but I think programmers will often encounter Erlang and
| can decide to learn it (or look for a different library that 's
| pure Elixir). I am sure that there are individual programmers who
| would learn pure Elixir, but get 'scared away' by Erlang...but I
| doubt they are hurting the language ecosystem in a meaningful
| way. Focusing on this would both be optimizing something that
| does not, in general, matter - and would be trying to achieve an
| impossible goal.
| scottmessinger wrote:
| FWIW, I've been using Elixir in production since 2016 and haven't
| found I've needed to learn any erlang. For context, we use Elixir
| for our backend and serve around ~100/rps over websockets. We've
| integrated Elixir into Stripe, Segment, Google, and Xero and
| haven't found we've needed Erlang libraries for any of those
| integrations or any of the other parts of our code base.
|
| > Elixir when they invariably stumble across the things in erlang
| -- libraries and the like. I'd hoped I could avoid it myself, but
| it's too interdependent.
|
| This hasn't been true in my experience. I'd be curious to hear
| which Erlang libraries the OP has been using.
| ch4s3 wrote:
| If nothing else you're likely to run into ETS, it's really nice
| and easy to use. But even still, the calls are pretty easy to
| make, and the docs are good. You don't really even need to
| understand any Erlang syntax, it's just built into OTP.
| rkallos wrote:
| Chiming in with 6 years of professional Erlang experience. I'm
| somewhat familiar with Elixir, having worked on some Elixir
| codebases for a few months.
|
| > The notion that to learn a language you also need to learn a
| second one is not great. [...] It's just bizarre.
|
| I disagree. I don't think it's bizarre. I expect to sometimes
| have to poke around in C code when writing Erlang or Python. It's
| also fairly common for C/C++ developers to look at the assembly
| output of some piece of code using https://godbolt.org/.
|
| > Reading the code is NOT an answer.
|
| Again, I disagree, and I think this perspective is harmful to
| career development. Knowing how things work on a deep(er) level
| is a superpower. When you're writing Elixir, do you never open up
| a .ex file in the standard library to see how something is
| implemented? Are you not at all interested in what powers things
| like Phoenix.PubSub?
|
| > I don't know what a solution is, but perhaps a concerted effort
| to create a documentation and library ecosystem that never links
| back to Erlang would help.
|
| I suspect that a library ecosystem that doesn't require Erlang
| would be a huge effort to implement and test, and would wind up
| pulling in all of the ideas from Erlang that you haven't
| learned/mastered yet. A better alternative would be to accept the
| fact that Elixir builds on top of Erlang, and understand that a
| deeper knowledge of Erlang is going to help you improve as an
| Elixir developer.
|
| > And where there are critical systems that use an Erlang
| library, perhaps rebuilding it in Elixir is in order?
|
| I'm definitely biased, but I would be much less trusting of an
| Elixir copy of a 'critical' Erlang library. Many of the selling
| points of Elixir that lead to very concise code (read: macros,
| 'using', and others) are things that make it difficult for me to
| develop a deep understanding of a library. It's cool to use DSLs
| like Ecto and Plug, but I have a much harder time understanding
| those libraries as a result. Erlang's unambiguous syntax and its
| basic text-substitution-based macro system are much easier for me
| to understand, and while it takes more effort to write APIs and
| code that are as concise as what's available in Elixir, I know
| that I can open up an Erlang file and trust that much less is
| hidden from me.
| myth_drannon wrote:
| It's the same way that the Java/JVM prevents Clojure being picked
| up more. To figure out Clojure's errors you need to be familiar
| with Java/JVM (most of time).
|
| Elm is a great example of a language that doesn't suffer from
| being written in Haskell, you basically completely unaware of it
| and not required to dip your toes into Haskell's ecosystem.
| handsaway wrote:
| Well to be fair Elm runs on a completely different platform,
| it's just the compiler is written in Haskell. "Leveraging the
| Haskell ecosystem" isn't part of Elm's value prop.
| Plugawy wrote:
| In my experience (7+ years of using Clojure) this is caused by
| the misunderstanding of what Clojure actually is: it's a LISP
| designed for the JVM, you cannot escape the host and pretend
| it's not there. In return you get access to one of the biggest
| software ecosystems and pull any library from Maven Central
| etc.
|
| Coming from Ruby/Go/JS to Clojure was definitely harder than I
| expected but rather than fighting "this stupid JVM" it made
| more sense to buy into the idea of how Clojure is built and
| used.
| ModernMech wrote:
| > It's a LISP designed for the JVM
|
| Honestly, this should be the Clojure tagline. Would solve a
| lot of the confusion. To be truthful, I never pictured it
| that way, but to be fair I think Clojure sells itself as more
| than that.
| lispm wrote:
| But it's more than that. It has different data structures,
| operators and semantics from Lisp - stuff which goes beyond
| just a simple retargeting to the JVM. It also provides an
| integration into/on top of the JVM, but also stuff like
| persistent functional data structures, avoids OOP, ... It's
| opinionated.
|
| Lisp and Scheme on the JVM exist, too.
| melony wrote:
| I wish it would focus more on using technology provided
| by the underlying platform instead of its own half-baked
| and slow implementations. Clojure's concurrency story is
| horrendous. There are multiple versions of shared memory
| concurrency on its JS and JVM runtimes but none of them
| scales to match the performance of the local APIs
| (Promises and Project Loom for Java). They are always
| playing catch-up five years after the original features
| have been shipped. Even today, trying to find an up to
| date library for features like WebWorkers or WebRTC that
| has seen a commit in the past _year_ is a waste of time.
| fyzix wrote:
| I must say that having to learn Erlang killed my desire to learn
| gleam. I just wanted to explore a functional language and having
| to do 2 at once wasn't worth it. I chose f# in the end.
| ithrow wrote:
| F# has the same problem, you have to learn C#.
___________________________________________________________________
(page generated 2022-05-09 23:02 UTC)