11–20 of 105 posts
CouchDB. It's rare that a piece of software is bad enough to give its language and runtime a bad name, but it's actually that bad.
That is why I love elixir, the power of erlang with a better syntax. Of course elixir is not perfect, but it is really good at making erlang better.
I would amplify this by pointing out that Elixir was not even a gleam in anybody's eye when Damien wrote this criticism. That said, I would say most everything that Damien says here and is not already labeled as fixed remains an issue as written. Erlang is an exceeding conservative language community, from its telecommunications heritage, and its syntax has hardly budged from when it was first written.
Erlang's statement separators seem to me more like English. I don't hear a lot of complaints about commas, semicolons, and periods in English and I don't find it an issue in Erlang.
"," means AND.
";" means OR.
"." ends the rules.
In Algol based languages ";" ends each statement. To apply OR or AND conditions between statements, you then need to use if/then/switch conditions.
I think it's no wonder that Elixir is having the success it is. It fixes literally every single issue on this page (many of which still exist in erlang), plus you get all the good stuff.
That is why I love elixir, the power of erlang with a better syntax. Of course elixir is not perfect, but it is really good at making erlang better.
CouchDB. It's rare that a piece of software is bad enough to give its language and runtime a bad name, but it's actually that bad.
I've tried to use it. I hadn't realized it was erlang based, but now I respect erlang less
Isn’t it supposed to be mainly REST based and have a goal of being able to sync multiple nodes with expected connection loss in between?
I’ve never needed that on a project but it seems like it would work for some use cases. I hear good things about PouchDB.
I think it says something that erlang is still relatively successful and popular despite all that. In particular, it means it just nailed its semantic fundamentals: message-passing, functional, actor-based concurrency with supervision trees and all the OTP goodies. I think it's no wonder that Elixir is having the success it is. It fixes literally every single issue on this page (many of which still exist in erlang),…
I've worked for many years with many other languages and runtimes, but beam, OTP and Elixir (and the synergy between them) are better tools. As a foundation, message passing and isolation are the only realistic weapons I've seen against most common causes of technical debt (coupling). It isn't a silver bullet, but it tries hard to help you. And, importantly, it's approachable.
Another way to look at it is that it delivers many of the same benefits of SOA/microservices, without the significant infrastructure/deploy/devops overhead.
I think it says something that erlang is still relatively successful and popular despite all that. In particular, it means it just nailed its semantic fundamentals: message-passing, functional, actor-based concurrency with supervision trees and all the OTP goodies. I think it's no wonder that Elixir is having the success it is. It fixes literally every single issue on this page (many of which still exist in erlang),…
We've been using Elixir almost exclusively for a couple years, and I can't speak highly enough about it. There are clearly problems where beam is ill-suited, but otherwise, I almost feel religious about it. I've worked for many years with many other languages and runtimes, but beam, OTP and Elixir (and the synergy between them) are better tools. As a foundation, message passing and isolation are the only realistic we…
Earlier quoted context omitted.
I would amplify this by pointing out that Elixir was not even a gleam in anybody's eye when Damien wrote this criticism. That said, I would say most everything that Damien says here and is not already labeled as fixed remains an issue as written. Erlang is an exceeding conservative language community, from its telecommunications heritage, and its syntax has hardly budged from when it was first written.
I wonder if they're less likely to change now that Elixir is a thing. The community won't push on them to change as hard, as the community will move to Elixir. However, they still benefit greatly from the Elixir community as seen by OTP 20 and OTP 21 bringing great benefits from the Elixir community leaders.
I’m skeptical. It seems more likely a new, larger community will form (probably has formed) but I think anyone sufficiently dedicated to have used such an obscure, weird language prior will stick with it.
(I may be projecting a bit, but as someone passionate about Erlang I have minimal interest in Elixir.)
Erlang's statement separators seem to me more like English. I don't hear a lot of complaints about commas, semicolons, and periods in English and I don't find it an issue in Erlang.
I was going to rage on the author, but I'll just let it go. "," means AND. ";" means OR. "." ends the rules. In Algol based languages ";" ends each statement. To apply OR or AND conditions between statements, you then need to use if/then/switch conditions.
To be pedantic about it, in ALGOL, the original "Algol based language", the semicolon is a separator. There are lots of "missing" semicolons in ALGOL programs. See the examples here: https://en.wikipedia.org/wiki/ALGOL#Code_sample_comparisons
I think that is more confusing than what C does. E.g. look at the ALGOL 68 example. One 'od' ends with a semicolon, the other doesn't. I dunno if that example is correct or not, I haven't written an ALGOL program in about 45 years.