Ten Years of Erlang
ferd.ca
ferd.ca
I have found that I like Lisp-Flavoured-Erlang (LFE) a bit more, since I still find the prolog-esque syntax a bit frustrating. I've been doing this stuff for like 6 years, and I still occasionally get tripped up on when to do a comma, semicolon, or period occasionally. While I'm not a huge fan of LISP-2 semantics, overall I find the syntax for LFE to be a lot more consistent than raw Erlang.
This isn't to crap all over regular Erlang though; Erlang was the first language I had seen that fully embraced pattern-matching, and I find that kind of pattern to be incredibly elegant.
If someone reading this hasn't tried out Erlang, do yourself a favor, download and install it, and build a simple TCP chat server. I can virtually guarantee you that it will be easier than anything you've built in C/C++, and it's incredibly satisfying to have something you built in a few hours have the ability to scale correctly.
From what I've read in blog posts, it feels like the coolness of Ruby comes from the feeling of "holy crap, something that would have taken me two days in Java/C/C++ took me an hour with Ruby" (hopefully I'm summarizing this more or less correctly).
Erlang has definitely given that feeling to me. Distributed programming can be really, really hard, and gluing things together with sockets and whatnot can lead to a lot of really difficult bugs. Since Erlang embraces distribution and concurrency as part of its paradigm, it sometimes kind of feels like outright magic. Sometimes things feel like they went a bit...too perfect, like you missed something, when you really haven't.
I'm not going to say that it fixes every issue with concurrency; you can still have race conditions and Mnesia and ets can be a bit finnickey if you're not careful, but I think I can honestly say that, for distributed apps, I can accomplish 20x as much as I could with most other platforms.
Speaking purely personally, mathematics has consistently been the discipline that’s delivered the most bang for my buck in that regard - learning a new branch can let you solve problems that are just impossible to solve, or take pages and pages of computation, in a few lines.
I agree with mathematics; I came to the same conclusion about five years ago; I realized understanding some basic type theory made a whole lot of programming easier for me.
It's kind of dry reading, but I've been trying to get into different process calculi lately; specifically the Pi Calculus and Join Calculus, since these things feel like a cool hybrid of computer-science and mathematics.
Also, Tony Hoare's book on CSP is actually a fairly interesting read; certainly interesting if you like Go. You can actually download it legally free here: [2]
In regards to type theory, I'd recommend starting by learning Haskell, just to make the terminology a little less scary, then picking up the book "Basic Simple Type Theory" by J Roger Hindley. Don't let the name fool you, it's still pretty heavy stuff; there's no way I would have been able to get through it if I hadn't learned Haskell beforehand. [3]
[1] https://www.amazon.com/Programming-Distributed-Computing-Sys...
[3] https://www.amazon.com/Simple-Cambridge-Theoretical-Computer...
They do have some major fundamental differences though and I think the similarity is often overstated.
Phoenix doesn’t have a magical asset pipeline, it doesn’t have a whole library of language extensions a la ActiveSupport, it doesn’t represent dB rows as objects. Those are just a few things off the top of my head.
Additionally all requests to an app running Phoenix/Cowboy/Plug are separate processes and can happen in parallel without having to stand up multiple app instances.
The creators of elixir were rubyists. As someone who used to Ruby and now Elixirs, a lot of the joy of the platform (relevant to gp's comment) has made it over. Elixir is legitimately as fun to program in as Ruby, if not more so. I think that the developers of elixir care about the user experience in a way that basically no other language seems to.
I could of course be biased because before Ruby I used to program in an actor-like C++ framework, so everything just feels like I'm coming home to a home I never knew existed to me.
Those are affectionately called "ant turd tokens", because they're kind of small and it's easy to miss which one is which, especially when moving code around.
I got to work with Erlang professionally a few years back, and miss it in a lot of ways.
It also shows that the first few rungs matter a lot; this is the territory of easy answers, where following a few simple rules leads to rapid productivity, and there will always be people for whom that level is good enough, either through carefully weighed decisions from limited information, or ignorance and deferment of future problems and their solutions. You can't solve everyone's problems for them, but you can try to evangelize, and you can try to build your system in a way that best practices can be incrementally adopted from existing fumblings. Anticipate that most of it will stay mediocre.
History is littered with systems that, in hindsight, seem to have offered sensible solutions to complex problems, yet didn't survive in the end. Much knowledge and wisdom is lost, and others independently discover it when trying to ascend an unrelated stack. Erlang/OTP is truly the sort of environment that masquerades as a programming language yet asks questions at a much higher conceptual level: what do we want systems as a whole to look like if we have to maintain them indefinitely? Its architectural innovations have been copied elsewhere, where they rarely form part of a coherent stack, but at least expose people to the advantages of its model. This may also be the most viable source of adopters of Erlang at higher levels: people who've sought out similar model for its benefits, and could thrive with an offering that pays attention to these concerns throughout.
I discovered BEAM while looking into a way to run concurrent, distributed Golang/gRPC services in a supervisor-worker set up. I've continued tinkering with OTP ever since.
Edit: added quoted portion.
Rails is a killer-app for Ruby because it’s a framework; a developer who uses Rails in their project is inherently a Ruby developer. People learned Ruby to use Rails.
But you don’t need to write a single line of Erlang to use CouchDB or Riak or Ejabberd. They’re self-contained. (And, in fact, scriptable in not-Erlang languages; CouchDB for example spawns and manages a JavaScript engine to run its “design documents” on.)
Thus, these infra components becoming popular doesn’t cause there to be any more Erlang programmers than there were before.
In that sense, I would say that Erlang has never had a true “killer app” yet. (Outside of a few specialized domains, like telecom and fintech, where the OTP platform itself is Erlang’s killer app.)
And even in the places where Erlang itself is a “killer app”, it’s also not so much a viral thing that the whole industry gets excited about; rather, Erlang is more of a “secret sauce.” Nobody’s learning Erlang in their basement because their friend told them it’d be the next big thing in their industry.
How does anyone learn Erlang, then? Well, usually, engineers are forced to learn Erlang at one job (where the system architect there decided on it); they get to liking it; and then, when they later become a system architect themselves in another job, and choose a stack, they choose Erlang, thus forcing a new wave of engineers to learn it.
Also, IMHO, if you want to have a solid foundation when learning Elixir, it’s simpler to learn Erlang/OTP as a cohesive whole (from e.g. ferd’s Learn You Some Erlang book) and then “chase it” with an Elixir book; rather than trying to understand OTP through the lens of how it’s exposed in Elixir. Everyone in the elixir-lang Slack that asks how to get started learning Elixir, I tell them to learn Erlang first. So “being a simpler jumping-off point to Elixir knowledge” is also kind of a killer app.
I would guess that this is only true in cases where there are killer apps for a secondary language on a runtime, but no killer apps for the primary language. Like, I wouldn’t say that Clojure is a killer app for Java. But then, is that because Java is already popular? Or is that because Clojure developers don’t necessarily end up knowing Java as well as Elixir developers end up knowing Erlang?
I'm not sure if Elixir developers plan on providing complete wrappers for Erlang's stdlib in the future. This is in fact one criticism I have of the language, because even for simple things like serialization you have to drop to Erlang and call :erlang.term_to_binary(), which feels a bit second-class.
I really like the language otherwise though.
Well, to be honest, :erlang module has many functions, many of which have literally nothing in common with each other. That's because that module is imported by default in Erlang - it's like `__builtins__` in Python. Exposing it as `Erlang.term_to_binary/1` module/wrapper wouldn't really fit well with the rest of the Elixir stdlib, which is (commendably) very neatly organized, with each module doing just what its name suggests.
On the other hand, wrapping just `erlang:term_to_binary/1` and `erlang:binary_to_term/1` in a `Serializer` module would be probably ok, but then there are tens of such modules you'd be pressed to implement for `:erlang` alone, and it gets worse with a rather extensive Erlang stdlib and OTP apps.
One of the Elixir selling points was (and probably is) the simplest possible FFI to (and back from) other BEAM languages (like Erlang or LFE). Calling an Erlang function is exactly the same operation as calling Elixir one - literally, the only difference is that, syntactically, most Elixir functions live in CapitalizedModules. That's it - there's no runtime overhead, no difference in handling arities, arguments, guards, exceptions or return values. The feeling of second-classiness is definitely there - the argument order and naming conventions (for args and functions both) differ, and the Erlang/OTP docs (used to - not sure it's still the case) look less than appealing in comparison with Elixir. But, realistically, Erlang's stdlib is a result of 30 years of accretion of tools and it's not small by any means. Wrapping entirety of it would take many years at least and it would consume a lot of developers' time, possibly hindering the development of the language itself. Elixir is still a young language, without a very large following and secure position in the industry - it's dangerous to divide your forces and pursue to many goals at once in a situation like that.
To summarize: in my opinion, the feeling of second-classiness is not a serious enough problem to invest resources in making it go away, at least at this point. While they may look less than pretty, Erlang/OTP docs are very well written and the functionalities tend to be rock solid. The stdlib is... not the prettiest in terms of organization, owing to decades of evolution, but with the FFI as trivial as it is, it's more than usable from Elixir. I think that was the original plan: the stdlib of Elixir was intentionally kept small and very clean, which was supposed to be Elixir's appeal, but it's only possible if reaching for the functionality missing from stdlib is simple. Just a hunch of mine, we'd need to ask Jose to know for sure :)
At one point I suggested in the forums that, inspired by how Elixir understands [foo: bar] as equivalent to [{:foo, bar}], maybe it could allow foo:bar() as equivalent to :foo.bar(). That would make the syntax exactly like Erlang's, which would be pretty nice to signal "I'm calling an Erlang function here".
I still think it's a good idea, but it wasn't met with a lot of enthusiasm :)
Hm, it definitely looks like it. What arguments against it were raised?
I guess you can always do `alias :foo, as: Foo`.
Nerves, which is already being heavily used for embedded systems and only getting stronger thanks to the likes of Scenic.
And Phoenix LiveView (not released yet), which I personally think pulls the strengths of Phoenix together in a way that can truly disrupt web development. It’s very difficult to do what LiveView is doing on other tech stacks.
The combination of those two will likely fuel things long term.
https://docs.microsoft.com/en-us/aspnet/core/blazor/?view=as...
While it sounds expensive at first, the template engine has been extended to support delta tracking and the process model that Elixir inherits fits well for a heavily interactive system with thousands or millions of users. The end result is that it's a very lightweight client setup and outside of using the template system properly, there are no gotchas with learning which code runs where.
I didn't use Blazor yet, but that's what I understand from the documentation.
LiveView still needs more work to be really ergonomic, wouldn't work for all use cases, but I'm personally holding my breath here in excitement to adopt it in my Elixir projects.
Still, I find it ironic that the next server side web technology leap, after the famous Rails demo referenced in the article, comes from another Ruby-inspired language.
The issue I have with the statement is that it pulls all of the negative connotations that some people have with Ruby onto Elixir...and Elixir is not at all like Ruby.
It’s not at all the same thing as Ruby on Beam though - it’s a very different language, but it does borrow a lot of good ideas from the Ruby ecosystem while improving on them in many ways.
LiveView cannot avoid latency. When I've experimented it's great for something running on my local network; less good when it's in a datacentre in another country. It's laggy.
And unless you replicate to many locations, or can deploy it to edge compute nodes (no idea) then this will always be a problem compared to 'true' client-side development.
I want it to work but I don't see how it can beat the laws of physics.
It’s not going to fail to ‘work’ because of this. It just has a niche and isn’t a general purpose web framework.
I’m looking forward to building some admin tools with it, reducing the complexity required when having to deal with server and client separately.
All our tools are now hosted in the cloud - we don't run any servers on the local network. With a 20-30ms RTT perhaps it will feel smooth - or the micro-delays will be noticeable.
If you built a traditional SPA, aren't you still making loads of calls to your server?
I don't see how LiveView would be more laggy than that. In both cases you're making network calls from the user's machine, to your server, getting a response from the server and then rendering output on the client when it's received.
Of course you can cheat and do optimistic rendering on the client (like outputting what you wrote instantly in some DOM element instead of waiting for a response and validating it after the fact) but I believe that enhancement could be done with both techs.
The only place where LiveView falls short is a true offline / fully client side app, but those are such a rare breed and way out of the norm for a typical web app. In 20 years of web dev as a freelancer, I've been asked 0 times to build an offline / client side JS app.
For data loading, yes. But here's a few random thoughts:
* I can pre-emptively load data in a SPA (think: 3 screens-worth of a datagrid) and keep fetching in advance, so the user rarely feels the lag.
* Much of my investigation has been around adaptive forms, wizards, validation and keeping logic in a single place. Having to define models and logic once, rather than client-side and server-side would save so much time.
My testing suggested that client-side validation still gave better results, because it was instant. Moving forward & back through a wizard was better if client-side rather than each screen rendered server-side.
I experimented early May so am a little hazy on details (and can't find which PIM I put my notes in, sigh) and look forward to seeing other people's experiments. Particularly when not run on their local machine.
In some cases yes, but I don't think you can get away with client side validation for a lot of things because they depend on the state of your database to return the correct result.
For example, how would you validate an email or username on the client when the availability of the name depends on you making a database call to see if a user exists already? You have to make a network call, get the result and then update your validation errors on the client based on that server side result.
But for validating something like a phone number or twitter handle, sure, client side works all the way but I don't think having even 200ms of delay for that validation is going to make for a bad user experience. 200ms is a lot too. That's about what it takes to ping a server in Tokyo from New York.
Your other points are valid tho. I guess we'll see where LiveView ends up going.
.optional {
display: none;
}
input:checked ~ .optional {
display: inherit;
}1. unpoly to handle common JS behaviours (such as show this div when this checkbox is selected)
2. Web components to handle more complex pieces of UI while maintaining compatibility with LiveView: rendering a functional jQuery carousel via LiveView/Websockets is much harder than just pushing a <carousel> element through the socket. Admittedly I haven't tested if the DOM diffing library LiveView uses plays nice with web components.
I’ve interviewed plenty of people who cut their teeth on Rails and fall apart as soon as you present them, say, Sinatra. Or a gem that provides an API client. Once it comes to writing non-Rails code (with all the helpers and the magic), it’s as good as learning a new language that happens to look exactly the same.
The BEAM ecosystem is all about fault-tolerance, distribution, and concurrency. These BEAM concepts could be described as "upper ladder" ideas: they require more prerequisite understanding of systems engineering to appreciate. Despite being a fallacy of composition, to compare a given Erlang vs Ruby/Rails developer may be useful to consider.
A person who invests in learning Ruby/Rails might be motivated to do so because of that bootstrapping mindset of MVP's and failing fast. Our average Rails developer might be rolling the dice for that "killer app" opportunity more often than our Erlang developer prioritizing concurrency and reliability. This may be because those BEAM features are more useful at a later stage of product development. So while the BEAM features are uniquely powerful if they require an upper-ladder understanding our MVP-developer doesn't yet have - they're unlikely to pick Erlang as tool-set to invest in.
If we accept that the BEAM is good at infrastructure and that doesn't result in as many opportunities for these hype-cycle-causing-killer-apps, than what could be changed in the ecosystem to support this goal? Can we get both the later stage benefits of reliability and concurrency in addition to the early-stage productivity benefits? Maybe this early-stage development focus is where Elixir will break out of the infrastructure-niche Erlang seems to be in. Can Elixir's tooling reach a short enough new-product feedback loop more potential killer-apps get deployed into production? I think as Elixir brings in some different personalities to the ecosystem we could see more killer apps but that idea -> production feedback loop seems to be the key component.
1. Change the syntax. Elixir wasn't far enough. Not at all and BEAM doesn't need to know, so we have a chicken-egg problem of people entrenched don't want to spend time that will help the language and underlying strategies become more widely adopted. Perhaps this was the production feedback loop you were referencing. We still don't have a good methodology for measuring all sorts of things in software dev. 10 years, 20 years, the language may just never do more than incremental changes (like elixir).
2. Handling text is still awful in these languages.
In contrast to what? Honestly just curious.
Oh dear.
This ladder is a great blueprint, great article:
functional programming
isolated processes and concurrency
reliable concurrency (links, monitors, timeouts)
OTP behaviours and other system abstractions
How to structure OTP systems
How to build releases and handle their life cycle
How to never take the system down, and how to operate itHave you seen ex11? [1], it's Erlang native, and at least 0.1 of a GUI library. X11 and Erlang actually go together really well, although a lot of important functionality for a real application is missing; I used this to display images generated by an Erlang application, and it felt a lot nicer to me than using wxWidgets; I added a few bits of functionality to the library while I was in there, and it wasn't that hard to turn the X11 protocol docs into Erlang code for the things I needed.
I imagine if someone had a real need here, it wouldn't be that hard to get it into shape. Caveat: X11 is dying, etc.
[1] The most active fork appears to be here https://github.com/skvamme/ex11 -- it's been somewhat retargeted to mobile, but the examples for desktop should still work as well as they did.
I mean, that's a completely incorrect characterization of Erlang, regardless of how you feel about the comparison to C#.
Erlang is just as much a general purpose language as C#, it is just a different paradigm, i.e. functional programming rather than (mostly) object-oriented.
> There is 0 Erlang-native GUI libraries
This isn't true at all. There is a tight integration with the wxWidgets framework (in fact, one of Erlang's handiest tools is built with it, Observer). Scenic, as mentioned elsewhere in the comments, is for Elixir (perhaps there is an Erlang-native API for it, not sure), but provides a native framework for OpenGL, and a UI paradigm that meshes nicely with processes and supervision.
Of course, Erlang is not perfectly suited for all environments (e.g. iOS apps), but that is true of essentially all general purpose languages - there are some places where they aren't well suited or have flaky support. I wouldn't build an iOS app in C# either, it makes little sense to use anything other than Swift/Obj-C in that environment. Likewise if I'm primarily building Windows-based apps, I would use C# before I would reach for Erlang. But for backend services, infrastructure, networking, etc., it is extremely well suited, and I think the domains that it can provide a compelling solution for will continue to grow (e.g. embedded).
Because in my opinion C# is miles ahead of Erlang. If I want to create an application, back-end, front-end, running on a wide variety of platforms, Mac, Linux, PC, IOS, etc, I would use C# 1000 times over versus Erlang.
The tools available, documentation, huge amount of libraries and support mean that developer efficiency in C# land is light-years ahead of Erlang. I could make a website + backend + IOS/Android app with all shared code while using tons of pre-existing OSS frameworks / packages and get it all up and running and prod/enterprise ready in no time at all and have it ready for enterprise load and scalability. Try that with Erlang!
You might not believe it, but that is a fairly niche desire. There a tons of use cases for server software running only on server OSes (which these days, is some flavor unix 90+% of use cases)
And gee, Erlang is/was made to excel at server based software. Not desktop frontends.
My point C# can do 10 things. Erlang can do 1. If all you care about is the 1, then the other 9 C# can do are moot. If Erlang does that 1 better, then it is best (for that use case). C# is best for others.
Edit: yes of course, he mentioned it in the text post in your link but as a joke: https://news.ycombinator.com/item?id=512145
'Getting' OTP, and especially how to structure an application the right way is definitely tough, because there's not a lot out there like it if you come from the world of C or scripting languages. It's not just code organization, but thinking about how to structure all the processes so that things fail in a 'good' way, and you have everything talking in the right way.
A big thanks to Fred for his book, and the many hours he has spent helping people on the mailing list, IRC and elsewhere.
I miss my time working with Erlang. I think it's still an indicator of an environment willing to try new things, but like he writes, you have to be wary of the places that are 'serial early adopters' too; I've encountered a few of those in my Erlang career.
My personal take is that the next major milestone for Erlang/Elixir will be a significantly more performance BEAM. Be it JIT or reworked Hipe.
Elixir (& Phoenix) brought a ton of interest from the Ruby community. The only remaining aspect that would keep a Ruby developer using Ruby is the perf vs Erlang. Today, for many raw perf task there isn’t a meaningful difference in speed (note I’m not taking scalability). As soon as the speed difference becomes meaningful, Erlang will get another wave of people.
The issue becomes hard to fix because all of these small costs add up but none will show as up a single bottleneck in practice, making profiling a blunt tool for this kind of performance problem. Elixir isn't immune to this either but the functional aspects of design do help keep some of these choices local to the code that chooses to trade some time or memory away for other conveniences.
An example I saw recently of this sort of adoption is map access, which is entirely okay if the trade-off is understood. I put in some time to show that much of the understanding of performance profile of the Access behavior gets colored by these expectations that the small things don't matter: https://lobste.rs/s/bctcke/performance_elixir_s_access_behav...
https://www.bignerdranch.com/blog/elixir-and-io-lists-part-1...
What is your definition of slow or fast?
For example with Elixir it was possible to generate 5,000x random 19 character codes in 3ms on a 5 year old i5 3.2ghz desktop workstation. I don't know how long it would take with Ruby but for such a text / CPU intensive task, I'm quite happy with the performance.
Also parsing templates with EEx is ridiculously fast, because it's not treated as a string.
spec-builder git:(master) ruby -e "require 'benchmark'; puts Benchmark.measure { 5_000.times { rand(36**19).to_s(36) } }"
0.005459 0.000009 0.005468 ( 0.005464)
It would be interesting if you wanted to come up with a Ruby version that adheres to the random code spec which should be able to be determined from looking at the first 2 versions. It's basically only a subset of characters that can be used and the code should be output as XXXX-XXXX-XXXX-XXXX.
I personally use the 25ms version because I find it to be the best one if you factor in both speed and readability. I'm sure there's better ways but I'm only an Elixir beginner.
Also for the record I didn't write the 2nd or 3rd versions of that gist. I asked around in the community and that's what others have put together.
I wish the industry was much more Erlang friendly.
It is basically erlang with better tooling and still an easy use of erlang.
I am not entirely sure about tooling myself. I would love to see a serious IDE for Erlang, I wonder what the tooling looks like. I've mostly just used the Erlang terminal to learn.
- Early Erlang tools had a lot of issues when Elixir showed up but rebar3 made quick progress and is a very good set of tools integrated into one command-line interface
- rebar3 has supported creating releases for a very long time which Elixir's mix tool is just catching up to (sure distillery supported things but so did relx and half a dozen other Erlang tools)
- rebar3 has built-in support for things like dialyzer which still require extra work to use from mix
- rebar3's _checkouts feature is very nice and has no good mix equivalent
- rebar3 offers a declarative configuration setup which makes it easier for other tools to integrate their data and read other data w/o requiring plugins to be loaded everywhere (and this is to say it still supports scripting where needed, which will still result in a declarative output)
- rebar3's version resolution system is more practical and puts the final control of version selection in the developer's hands rather than strictly package manager metadata which can lag or suffer unfortunate problems from version operators and unfortunate problems that come up from blind-semver adoption (this is a longer topic so I apologize for the poor summary here but I do think there is a good argument for rebar3's approach)
- rebar3 works and upgrades independently from Erlang/OTP releases allowing more fluid iteration whereas mix is very much locked to Elixir
I participate in the Elixir community and every time I hear the tooling story I think about all of the things I miss from Erlang tools when using Elixir. It'd be more accurate to say that Elixir has revitalized Erlang with a bit of competition and some diversity in background.
Either way, there is room for improvements in both camps. I hope Elixir's mix catches up with rebar3 in some of these areas and I hope Erlang doesn't ignore some of the caveats that are still around as given facts of life (perhaps getting better support for the wider set of BEAM languages would be a start so each doesn't need its own tool).
One quick correction: the equivalent to _checkouts in Mix is to use path dependencies. I often use environment variables to control when to use one or the other and I like the fine grained control more. Here is an example: https://github.com/elixir-ecto/ecto_sql/blob/master/mix.exs#...
But in general yes, we are glad to borrow ideas from each other and we should continue doing it!
My only problem with this solution is that it changes the mix configuration itself (which is version controlled) which is fine if others are in need of similar overrides when working on the project. For one-off/local things, it can be a bit heavy for temporary overrides.
Still, it's a fair trade-off since it's a lot easier to code up logic like this with mix compared to rebar3.
https://news.ycombinator.com/item?id=20357055
Elixir is just a slightly changed Erlang syntax?
...see where that leads us? Please actually voice reasons how it's not cleaner, as it's most definitely less verbose, And having less clutter is generally seen as cleaner
Calling functions with and without parens makes for a less clean syntax. Less consistency (plus mandates the dot notation for calling anonymous functions).
and we're finally finding out how both opinions are correct
when people say that elixir code is cleaner, they're normally talking about the significantly reduced amount of code they have to write because of the macros. its not specifically about how they're defining a function or calling them anonymously
while i cant say that i agree with atom reference, (its 1 char in elixir, two in erlang), you're definitely correct about that annoying idea they've had about dropping parenthesis on functions without parameters... that was just misguided i think.
I definitely wish Erlang had the same macro capability. I just find the overall syntax sufficiently unpleasant that I can’t get into Elixir.
Please, don't use such an excuse for not trying out a language. :(
The unpleasantness you speak about is akin to motion/sea sickness - the signals your brain receives disagree with the brain's predictions of what they should be. The discrepancy manifests as a feeling of unease at the very least, or you may throw up non-stop for 3 days on the deep end, but, eventually, the sea sickness disappears completely.
I believe I experienced something very similar to this many times while learning many strange, exotic languages as a hobby. When the syntax or semantics were completely outside of what I already learned, I was irritated that "I don't even know how to ...something...". When the new language was close to what I already learned, I was irritated that "it doesn't work as it should" due to the differences. Basically, I experienced some kind of rejection reaction from my brain every time. But then, after a few days to a few weeks, that feeling faded and disappeared.
There's a technique I thought up and used a few times which helped me with especially hard, complex, or simply exotic syntaxes. I'm not sure if it will work for everyone, but it helped me with Lisp and Prolog when I first learned them. What I did was to print several tens of pages of (syntax-highlighted and preferably heavily commented) example code and scatter them around the house at spots I was likely to look at. Next to the mirror in the bathroom, on the fridge doors, on my desk, and so on. I wasn't trying to actively read that code very much, just glanced at it from time to time, and sometimes tried to read a bit more when I was bored. When I returned to actually learning the language the next weekend (I think), it went much easier than before. I still wasn't able to write in the language, obviously, but reading - even if I didn't really understand more of it than before - stopped being a hassle, the feelings of rejection disappeared, and I was able to learn quickly from that point on.
Well, that's just my theory based on personal experience, so it may be utterly stupid or just my imagination, so take it with a grain of salt. Still, I believe the feeling of unpleasantness from the syntax should be very easy to neutralize and as such it's not, IMHO, a good reason for "not getting into" a language which is otherwise interesting (whether Elixir is such for you is another matter).
I like Erlang’s syntax. I like the concision. I like the clear differentiation between variables and atoms that capitalization offers. Erlang’s syntax and underlying model are firmly entwined in my head.
I think both languages have issues with Syntax but in the cleaner department, I am baffled at the insistence that Erlang is hard. Inconvenient, maybe but most of the features in Erlang are so primitive that there is little to no ambiguity of what something can mean.
Verbosity strikes both (records and binaries in Erlang vs the sigil and keyword heavy Elixir code) and certainly some folks prefer rebinding variables and colon syntax on atoms but it's certainly not without real trade-offs in common idioms (tagged tuples, special casing required for atoms like true, false, nil, interop with Erlang becomes uglier, etc).
I think Elixir making different token choices for these distinct ideas is the main reason for readability improvements. Especially since Erlang has less different tokens overall which you'd think would help reduce the noise.
https://blog.codinghorror.com/the-magpie-developer/
though that's less for a competitive advantage and more because new tech is shiny
Riak is not great. It performs well, but doesn't scale well. It has tons of operational overhead, a lot of bugs (and it didn't help that a slowly disintegrating company left less time to fix those bugs "until next release"), and any changes to the cluster while it's being used heavily leads to instability/unavailability. And many of its features were not implemented great; the SOLR functionality is a pig, for example, and "enterprise" replication is flaky.
On our team, we had a few engineers who could write Erlang, but they slowly moved to other teams, so troubleshooting production issues became a black box of pain. I'm so glad the product we had using it was sunset.
All that being said, I do not blame Erlang for Riak. I blame Basho. Their support was clueless, and their platform simply didn't perform as advertised.
A question for rubyists out there: what does the "ladder of ideas" for ruby look like?
It was elegant and clear!
Does someone know if this is an inherent Erlang problem or just due to some weird project setup in this case?
All these bigger projects tend to have a bit weirder idiomatic build setups because they had to haphazardly reimplement bits of (at the time) yet non-existing build systems by hand.
It’s become near-official for OSS Erlang work and the OTP team has moved the repo under their GitHub organisation (https://github.com/erlang/rebar3)
Erlang.mk tends to be the other option otherwise.
To me it looks like Erlang itself isn't all that interesting, and OTP is where all the fun and magic is.
* Erlang and OTP in Action;
* Designing for Scalability with Erlang/OTP: Implement Robust, Fault-Tolerant Systems;
* Designing Elixir Systems with OTP (in beta).
This problem existed since Lisp was invented. The benefits would have to be large to overcome the downsides of this learning curve, and so far they are not, except in certain niches.
I hate the rain the functional parade, but it's been tried and retried for many decades, but will just not fly in the majority of the real world. I'm just the messenger. The jet-powered chainsaw works wonderful in the lab, but actual lumberjacks either can't figure out how to start it or blow their arms off.
If you disagree, please reply instead of negativate me. I would greatly appreciate that.
I sometimes try to help normals relate to me by asking, "You know Sheldon Cooper from Big Bang Theory? I'm like a stupid, slighty-less-social-idiot Sheldon Cooper."
I identify with Dr. Cooper. (BTW it sucks being like that. Don't ever think we do it because we like it. There are a few perks but it mostly sucks. Also, it's like living in "Idiocracy". I can't watch that movie because it's too painful. That's my life. From my point of view y'all are running around pouring Gatorade on the plants talkin bout "It's got lectrolites!" It's getting seriously scary now IRL too: where the fuck are all the fucking insects!? We should all be fucking terrified right now.)
Anyhow, from my POV the "average" programmers should GTFO and stop peeing in the pool. I would fire 90% of working programmers. They're not needed and actively counter-productive.
Also, FP is coming on stronger today than ever before. You are in actual fact just wrong.
This is the theory that the elite are so productive that they can replace say 10 non-elites. The main problem with this is that most problems to be automated (or upgraded) are not well-defined. It takes iterative interaction with analysts, users, testers etc., and this is where probably 2/3 of the effort takes place. Communication and teamwork is more of a bottleneck than raw coding, and the Sheldon Cooper types rarely do well on that.
If the requirements were clearly defined, the 10x-Elite Theory would possibly work in practice. But it's a rare day in May one gets a clearly-defined specification that doesn't shift around a lot.
If you could find a domain having clearly-defined specs, then you could implement that 10x Elite Theory and crush the competition by cranking out software for a fraction of the traditional competitions' price. For example, make an office suite fully compatible with MS-Office, and charge 1/2 of what Microsoft does. You'd be a billionaire. (Past attempts were not sufficiently compatible, which may be a tall order because one has to mirror bugs in MS's software to be so.)
> This is the theory that the elite are so productive that they can replace say 10 non-elites.
No no no, I'm saying that the non-elites are counter-productive, that they contribute negative productivity.
(FWIW, I've met at least one "10x" in real life. He made his mark out of Uni by co-founding a company that made their own self-configuring ("Autonomous OS") box that really worked. Sold to IBM.)
> If you could find a domain having clearly-defined specs, then you could implement that 10x Elite Theory and crush the competition by cranking out software for a fraction of the traditional competitions' price.
People do that. Have you heard of Kdb? https://en.wikipedia.org/wiki/Kdb%2B
Now check out arcfide's "AMA: Explaining my 750 line compiler+runtime designed to GPU self-host APL" https://news.ycombinator.com/item?id=13797797
Reflect that that was two years ago.
Try to imagine what the world would be like if all core software was written by ~100 people like Arthur Whitney or arcfide.
The whole "Trusted Compute Base" could fit in ~100 pages of code or less. Crystalline mathematical purity...
The rest of us would be writing macros. Sad? Maybe. But the machines would work.
You may have concrete examples of that, but I couldn't agree based on my own perspective/experience. I've worked on a team with an elite programmer (in terms of actual 10x productivity) for nearly 3 years now. I know they're not all the same, but this guy isn't particularly sophisticated or cerebral in his approach; in fact, he wouldn't want to take on architectural concerns, refactoring, or really complex problems - I and another dev take care of that. He's just incredibly productive, by any measure you'd like to use -- LOC contributed, modules written, features implemented, issues closed. I've sometimes wondered if he's a front for an entire team behind him.
That doesn't mean the rest of us aren't worth having on the team. We are definitely contributing positively. In fact, he couldn't work anywhere close to the rate he does if he had to take care of the stuff the rest of us do.
The kind of people I'm talking about are not necessarily fast and they tend to leverage other people's abilities rather than shut them out.
Like Fabrice Bellard: https://en.wikipedia.org/wiki/Fabrice_Bellard
Ridiculously sharp guy, and his work has enabled so much other stuff and so many other people, eh?
- - - -
No team of ten people could do what arcfide does, eh? It would all get bogged down in intercommunication, etc. We pay a price for programming with sub-elite programmers. Metaphorically, I'm trying to say that teams dragging stone blocks are hindering the adoption of the wheel. (I'm not trying to make stone-block-draggers feel bad, FWIW.)
That’s why I downvoted you. It’s not because of your opinion, it’s because it’s probably not in the right thread.
My post relates to measuring "worth" here, and to the reasons why it probably didn't catch on.
I'm not really disappointed Erlang didn't catch on more. As I said in the post, I wanted to take a bit of time to reflect over most of that decade, the ladder of ideas, and things that changed.
Gulp!
I suppose I was looking for a few key ideas/themes as a summary the way we are taught to create and seek out in college writing courses, typically "essay style" you could say. Habit. Instead, it's more of a collection of relatively indendent notes.
I have no CS degree, never went to university but have been doing freelance web dev work for ~20 years.
Been through a lot over the years but never took a shot with a functional language until I met Elixir recently.
It really didn't take that long to get to the point with Elixir where things somewhat started to click. I'm still very much a beginner and am learning multiple new things for every few hours I'm coding but I am able to make progress without feeling like I'm in way over my head. Of course I still have so much to learn about Elixir / Phoenix, Erlang and OTP but it'll come in due time. You don't need to take in all of the complexity at once.
I'm multiple thousands of lines of code into developing my first Elixir / Phoenix web app and there has been stumbling along the way but also great strides of progress.
An average programmer is a few years out of college and is lazy.
It's such an obvious thing, but so true and so easy to get wrong. I'm really looking forward to your Phoenix app!
There are lots of things that were tried and retried for decades before they caught on, which are now standard. For example look at the 90s when Java and Python came around - GC and memory safety were radical ideas for the industry where C/C++ were standard, even though they had been around in various languages for decades.