13 ms·

What Sucks About Erlang (2008)

145 points by jxub 8y ago

HumanDrivenDev 8y ago
Programming discussions would be much better if everyone could be this critical of their favourite programming languages. There are languages everyone is happy for you to criticize online. Then there are a small few that cause people to lose their shit when you offer a critique. It's really sad - you really shouldn't be so personally invested in a tool you didn't write.
- saagarjha 8y ago
  Every language has its flaws, and experts know their language's ones and work around them. Unfortunately sometimes in doing so they forget that their methods of skirting around problems are workarounds and instead call people out for trying to do something "the wrong way".
- 6nf 8y ago
  'You can divide programming languages into two groups - those that people complain about, and those that nobody uses'
  - HumanDrivenDev 8y ago
    C# is widely used, but it's a bit of a sacred cow.
    - brianberns 8y ago
      I was a C# programmer for years, and got tired of it. But instead of complaining, I just switched to F#. That's one of the nice things about the .NET platform.
    - moomin 8y ago
      C#’s a weird one: it’s widely used, but still unpopular. It’s got genuinely large problems (like the anemic OS ecosystem) but when considered as a language on its own, it’s been ahead of the game in its class.
      - GordonS 8y ago
        It may be unpopular with the HN crowd, but that's more by proxy, in so far as a Microsoft stack in general is unpopular here. C# is however very popular in the enterprise world. I've been using it for work and side projects alike for many years, and personally I love it.
        Gibbon1 8y ago
        Offhand thought just now. Java programmers seem to argue a lot back and forth about build/deployment systems. I don't see C# people do that much.
        Const-me 8y ago
        Not just enterprise. Mainstream uses for .NET are windows desktop software (WPF & XAML are the best GUI toolkits for the platform), videogames (Unity3D is quite popular), cross platform mobile development (Xamarin). Now when .NET Core supports ARM Linux, it also works well for some embedded applications, but I don’t know whether somewhere except me does that.
kuon 8y ago
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.
- jerf 8y ago
  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.
  - sb8244 8y ago
    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.
    - macintux 8y ago
      > as the community will move to Elixir 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.)
- segmondy 8y ago
  Elixir doesn't have a better syntax than Erlang, it has a syntax that you can relate to and a syntax that makes sense to you. The first time I encountered Erlang I said Meh! After doing serious development in Prolog for a year, Erlang clicked! The first version of Erlang was implemented in Prolog and retained Prolog's syntax. There's reason behind the madness. As I mentioned in my other comment, "," and ";" signify OR and AND. One of the great thing about OR and AND is that they can be greatly parallelized. We haven't seen the last of Prolog & Erlang. With multicores being a thing, the language of the future is going to look more like them. The last serious research I saw done on these where in the 90's. So that annoying syntax is going to allow programs to gain performance advantage with more cores without being rewritten. The only thing that needs to change will be the run time. BEAM for Erlang and WAM for prolog.
ams6110 8y ago
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.
- staticassertion 8y ago
  People fuck up commas and semicolons basically constantly in English.
- segmondy 8y ago
  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.
  - PhantomGremlin 8y ago
    In Algol based languages ";" ends each statement. 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 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.
  - tom_mellior 8y ago
    This could still be simpler without losing anything: It's kind of redundant to use ";" at the end of rules that are followed by another rule for the same function. Erlang could just use "." here as well. The parser could still tell that another rule for the same function follows by seeing if another rule for the same function follows ;-) (Prolog, which influenced this part of Erlang syntax an many others, does it this simpler way. It still sucks if you want to comment out the last line of a clause, or switch the last line of a clause with some other line.)
facetube 8y ago
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.
- lallysingh 8y ago
  I've tried to use it. I hadn't realized it was erlang based, but now I respect erlang less
  - brightball 8y ago
    I haven’t used it personally, but I looked at it enough to know that its goals are different from most DBs. 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.
    - HumanDrivenDev 8y ago
      I don't quite get pouchdb. Do you need to store multiple revisions of the same document in a browser database? Locks/transactions seem like a better approach here for writing to data client side.
      - brightball 8y ago
        The main point is to sync server side data to a client side database, smoothly, so that the application can continue to function offline and then resync once the connection is re-established. Couch has always been good at this use case where systems on both ends may have changed in the disconnect time.
        HumanDrivenDev 8y ago
        but you could store Ids and revisions on any key/value store on the client. Why does the client need pouchdbs multiple revisions?
losvedir 8y ago
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), plus you get all the good stuff.
- latch 8y ago
  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 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.
  - shadowycoder 8y ago
    Can you share a bit about the deployment story. I haven't really been able to get a good view of the automation behind that. Granted, I have yet to develop anything actually deployable, but would love to hear some opinions about that.
    - latch 8y ago
      My point is that you can achieve many of the same benefits of microservices within a single app (or "vm" in erlang terms). So you get isolation (beam processes), decoupling (message passing) and resilience (supervisors) without having to deploy and maintain N different apps and the pain points that come with that (monitoring, discovery, integration testing, debugging, ...) Our company has other systems, in other languages, and a pretty involved deployment process (docker+nomad) so our deploys are pretty specific to that. But, I can tell you that as a developer, having only a few "apps" that internally have hundreds of services, has more or less freed us up of having to worry about any of that cognitive (and performance) overhead.
plainOldText 8y ago
I turned to Erlang a few years ago as I wanted to experiment with more exotic languages. Then I discovered Elixir and never looked back. It’s a truly enjoyable, expressive and productive language. I highly recommend it.
rdtsc 8y ago
It's a 10 year old blog post from the creator of CouchDB who then later declared the project dead despite it already having a vibrant open source community with multiple users and contributors. Then went on to create another project that had a similar name but was a merge of a bunch of other technologies which lead to endless confusion years on after the fact. http://damienkatz.net/2012/01/the_future_of_couchdb.html http://damienkatz.net/2012/01/the_future_of_couchdb.html Yes, of course the argument should stand on its own despite the author's other claims or blog posts, so let's review some claims: > Because Prolog sucks ass for building entire applications. There have been entire applications written in Prolog. Attacking syntax is is just silly. Had Prolog used statements and not expressions or ; instead of . I doubt we'd would have a seen a lot more or less applications in Prolog. > But that hasn't deterred Erlang from stealing it's dynamite syntax. The syntax is consistent. That's the point. It has relatively few syntax and semantic rules. It has strong types and behaves consistently, comparing say, with "this" in Javascript. js has semicolons but it behave inconsistently sometimes. You'd have to explain why {} + [] = 0 for example. Picking on js here since the author used js as an example of a "good" language. > editing code is much harder than conventional languages. Have not found this to be true. It is a bit harder. But not much harder and not a show stopper. You can't randomly copy and paste code and reorder statements because compiler will not like it. That's probably a good thing. Variables being immutable is helping when inserting a new function call in the middle, you have to think well if that modified value is suitable for the operations that follow below. > If Expressions There are 6 paragraphs talking about the "if" expression. "if" is not even used that often and focusing on it just because it has the same name as the "if" statement from Algol (C) type languages is a waste of time. Use "case" instead or even better multiple function clause heads. Yes, you can't do an early return so you have to explicitly handle every case. I see it as a good thing. You can cheat and say "_ -> ...DefaultValue" but it will stand and be obvious what's happening to the reader. > You Say String of Characters, I Say List of Integers Or list of unicode code points... You have a choice to use binaries instead of lists of integers. They are closer to the traditional strings in other languages. This is a better explanation of how they work: https://medium.com/@jlouis666/erlang-string-handling-7588daad8f05 https://medium.com/@jlouis666/erlang-string-handling-7588daa... > but it's surprisingly limited and verbose, requiring you to state the type of the record for each reference in the code. Since the blog was written Erlang got maps other languages call them dicts or hash tables for example. All in all I'd say syntax is often what people talk about but it is closer to bike shedding. It is easy to argue about because it's right there and everyone can see a . instead of a ;. It would better to talk about the semantics of the language, sending messages, concurrency, modeling applications as a set of communicating processes, supervision trees etc.
hoodoof 8y ago
I seem to recall the author of the old post ditched Erlang at some later point.
odammit 8y ago
I disagreed up until the docs section. I like all the other things he critiqued!!1! Rearranging: the punctuation helps you think about how you’re rearranging. You can’t copy/paste around in any function and expect it it work! The records comparison to a struct is unfair. He could have patterned matched on the record instead of destructuring and accessed the attributes of the record. Immutability! Fuck yeah! I tend to name subsequent variables with the mutation that was applied to them. It’s wordy. Name = “wayne” NameCapitalized = ... Now get off my lawn!
phoe-krk 8y ago
f(X) -> X1 = foo(X), X2 = bar(X1), baz(X2). If I use the pointless variable names like that, sure, I run into trouble, but this means I'm a shitty programmer who cares little about program readability. f(X) -> fooedX = foo(X), baredX = bar(fooedX), baz(baredX). f(X) -> fooedX = foo(X), fabedX = fab(fooedX), baredX = bar(fabedX), baz(baredX). Or just f(X) -> baz(bar(fab(foo(x)))).
- didibus 8y ago
  Ya, actually, I often use this style in other languages to be clear about the intermediate steps. My understanding though is that the problem is mixed with Erlangs pattern matching it can cause issues, because it won't necessarily fail to repeat the variable name, it'll just behave wrong. At least that's what I heard.
- cygned 8y ago
  I am not an Erlang programmer, but that style of programming bothered me, too. This variable per function application is a code smell in my point of view and should be handled with function composition or partial application (not sure how Erlang handles these, though).
  - jxub 8y ago
    Elixir has pipes for this, effectively solving this painpoint.
pulsarpietro 8y ago
Is it right to say that Erlang and Prolog are actually that close as stated at the beginning of the article ? As far as I am aware Erlang does not run the unification algorithm and it is very different, you can, for instance, assign variables. I don't think it is right to compare the two as close languages as it is claimed but I would be interested in your opinion
- Tomte 8y ago
  It's true that Erlang is not a logic-based language like Prolog, but the first implementation of Erlang was written in Prolog.
  - pulsarpietro 8y ago
    what is it written in now ?
    - Tomte 8y ago
      In C.
tilt_error 8y ago
You have Erlang the programming language, Erlang the system (OTP, philosophy), and even Erlang the eco system (including Elixir). Personally I like Erlang the language, but it is still Erlang the system that truly shines. It says a lot of Erlang the system that we’re fondly criticizing the language, warts and all. Erlang is all about pragmatism and we hand it over to the academy (the Swedish one, notch, notch, know what I mean?) to dwell on the Important Details about ‘.’, ‘,’ and ’;’ ;)
dixel 8y ago
> Instead you are forced to do something like this: if Logging -> log("Something happened"); true -> ok end For this particular use-case there is much more elegant way in Erlang: Logging andalso log("Something happened"); Even though I agree that the syntax and the concepts are unfamiliar for the general audience, I mainly see those arguments as the main reason to learn the language rather than put it away since it's sometimes the only way to learn something new. Regarding the "alien" syntax and expressing my point of view, I think Erlang syntax is usable, very simple and sometimes prevents you from doing "too fancy" things. Erlang's main areas are fault tolerant, high throughput applications and network protocols. Once it's declared as the focus - I wouldn't punch the ecosystem too much for the syntax but rather just use another tool for solving the problems that require more expressive programming languages. On the critics of the areas of focus I'd recommend the work done by Fred Herbert, the author of Learn you some Erlang for Great Good (http://learnyousomeerlang.com/ http://learnyousomeerlang.com/). There is a book on pitfalls while maintaining Erlang platform at large scale: http://www.erlang-in-anger.com/ http://www.erlang-in-anger.com/
- jlouis 8y ago
  Another good trick is to never log: report(Msg) -> hopefully_traced. You can then add a trace probe to your report/1 function and this allows you to have debug information when you need it.
moomin 8y ago
Reminder that there exists a BEAM fork of PureScript. https://github.com/purerl/purescript https://github.com/purerl/purescript

145 points by jxub 8y ago

Programming discussions would be much better if everyone could be this critical of their favourite programming languages. There are languages everyone is happy for you to criticize online. Then there are a small few that cause people to lose their shit when you offer a critique. It's really sad - you really shouldn't be so personally invested in a tool you didn't write.

saagarjha 8y ago
Every language has its flaws, and experts know their language's ones and work around them. Unfortunately sometimes in doing so they forget that their methods of skirting around problems are workarounds and instead call people out for trying to do something "the wrong way".
6nf 8y ago
'You can divide programming languages into two groups - those that people complain about, and those that nobody uses'
- HumanDrivenDev 8y ago
  C# is widely used, but it's a bit of a sacred cow.
  - brianberns 8y ago
    I was a C# programmer for years, and got tired of it. But instead of complaining, I just switched to F#. That's one of the nice things about the .NET platform.
  - moomin 8y ago
    C#’s a weird one: it’s widely used, but still unpopular. It’s got genuinely large problems (like the anemic OS ecosystem) but when considered as a language on its own, it’s been ahead of the game in its class.
    - GordonS 8y ago
      It may be unpopular with the HN crowd, but that's more by proxy, in so far as a Microsoft stack in general is unpopular here. C# is however very popular in the enterprise world. I've been using it for work and side projects alike for many years, and personally I love it.
      - Gibbon1 8y ago
        Offhand thought just now. Java programmers seem to argue a lot back and forth about build/deployment systems. I don't see C# people do that much.
      - Const-me 8y ago
        Not just enterprise. Mainstream uses for .NET are windows desktop software (WPF & XAML are the best GUI toolkits for the platform), videogames (Unity3D is quite popular), cross platform mobile development (Xamarin). Now when .NET Core supports ARM Linux, it also works well for some embedded applications, but I don’t know whether somewhere except me does that.

kuon 8y ago

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.

jerf 8y ago
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.
- sb8244 8y ago
  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.
  - macintux 8y ago
    > as the community will move to Elixir 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.)
segmondy 8y ago
Elixir doesn't have a better syntax than Erlang, it has a syntax that you can relate to and a syntax that makes sense to you. The first time I encountered Erlang I said Meh! After doing serious development in Prolog for a year, Erlang clicked! The first version of Erlang was implemented in Prolog and retained Prolog's syntax. There's reason behind the madness. As I mentioned in my other comment, "," and ";" signify OR and AND. One of the great thing about OR and AND is that they can be greatly parallelized. We haven't seen the last of Prolog & Erlang. With multicores being a thing, the language of the future is going to look more like them. The last serious research I saw done on these where in the 90's. So that annoying syntax is going to allow programs to gain performance advantage with more cores without being rewritten. The only thing that needs to change will be the run time. BEAM for Erlang and WAM for prolog.

ams6110 8y ago

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.

staticassertion 8y ago
People fuck up commas and semicolons basically constantly in English.
segmondy 8y ago
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.
- PhantomGremlin 8y ago
  In Algol based languages ";" ends each statement. 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 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.
- tom_mellior 8y ago
  This could still be simpler without losing anything: It's kind of redundant to use ";" at the end of rules that are followed by another rule for the same function. Erlang could just use "." here as well. The parser could still tell that another rule for the same function follows by seeing if another rule for the same function follows ;-) (Prolog, which influenced this part of Erlang syntax an many others, does it this simpler way. It still sucks if you want to comment out the last line of a clause, or switch the last line of a clause with some other line.)

facetube 8y ago

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.

lallysingh 8y ago
I've tried to use it. I hadn't realized it was erlang based, but now I respect erlang less
- brightball 8y ago
  I haven’t used it personally, but I looked at it enough to know that its goals are different from most DBs. 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.
  - HumanDrivenDev 8y ago
    I don't quite get pouchdb. Do you need to store multiple revisions of the same document in a browser database? Locks/transactions seem like a better approach here for writing to data client side.
    - brightball 8y ago
      The main point is to sync server side data to a client side database, smoothly, so that the application can continue to function offline and then resync once the connection is re-established. Couch has always been good at this use case where systems on both ends may have changed in the disconnect time.
      - HumanDrivenDev 8y ago
        but you could store Ids and revisions on any key/value store on the client. Why does the client need pouchdbs multiple revisions?

losvedir 8y ago

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), plus you get all the good stuff.

latch 8y ago
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 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.
- shadowycoder 8y ago
  Can you share a bit about the deployment story. I haven't really been able to get a good view of the automation behind that. Granted, I have yet to develop anything actually deployable, but would love to hear some opinions about that.
  - latch 8y ago
    My point is that you can achieve many of the same benefits of microservices within a single app (or "vm" in erlang terms). So you get isolation (beam processes), decoupling (message passing) and resilience (supervisors) without having to deploy and maintain N different apps and the pain points that come with that (monitoring, discovery, integration testing, debugging, ...) Our company has other systems, in other languages, and a pretty involved deployment process (docker+nomad) so our deploys are pretty specific to that. But, I can tell you that as a developer, having only a few "apps" that internally have hundreds of services, has more or less freed us up of having to worry about any of that cognitive (and performance) overhead.

plainOldText 8y ago

I turned to Erlang a few years ago as I wanted to experiment with more exotic languages. Then I discovered Elixir and never looked back. It’s a truly enjoyable, expressive and productive language. I highly recommend it.

rdtsc 8y ago

It's a 10 year old blog post from the creator of CouchDB who then later declared the project dead despite it already having a vibrant open source community with multiple users and contributors. Then went on to create another project that had a similar name but was a merge of a bunch of other technologies which lead to endless confusion years on after the fact. http://damienkatz.net/2012/01/the_future_of_couchdb.html http://damienkatz.net/2012/01/the_future_of_couchdb.html Yes, of course the argument should stand on its own despite the author's other claims or blog posts, so let's review some claims: > Because Prolog sucks ass for building entire applications. There have been entire applications written in Prolog. Attacking syntax is is just silly. Had Prolog used statements and not expressions or ; instead of . I doubt we'd would have a seen a lot more or less applications in Prolog. > But that hasn't deterred Erlang from stealing it's dynamite syntax. The syntax is consistent. That's the point. It has relatively few syntax and semantic rules. It has strong types and behaves consistently, comparing say, with "this" in Javascript. js has semicolons but it behave inconsistently sometimes. You'd have to explain why {} + [] = 0 for example. Picking on js here since the author used js as an example of a "good" language. > editing code is much harder than conventional languages. Have not found this to be true. It is a bit harder. But not much harder and not a show stopper. You can't randomly copy and paste code and reorder statements because compiler will not like it. That's probably a good thing. Variables being immutable is helping when inserting a new function call in the middle, you have to think well if that modified value is suitable for the operations that follow below. > If Expressions There are 6 paragraphs talking about the "if" expression. "if" is not even used that often and focusing on it just because it has the same name as the "if" statement from Algol (C) type languages is a waste of time. Use "case" instead or even better multiple function clause heads. Yes, you can't do an early return so you have to explicitly handle every case. I see it as a good thing. You can cheat and say "_ -> ...DefaultValue" but it will stand and be obvious what's happening to the reader. > You Say String of Characters, I Say List of Integers Or list of unicode code points... You have a choice to use binaries instead of lists of integers. They are closer to the traditional strings in other languages. This is a better explanation of how they work: https://medium.com/@jlouis666/erlang-string-handling-7588daad8f05 https://medium.com/@jlouis666/erlang-string-handling-7588daa... > but it's surprisingly limited and verbose, requiring you to state the type of the record for each reference in the code. Since the blog was written Erlang got maps other languages call them dicts or hash tables for example. All in all I'd say syntax is often what people talk about but it is closer to bike shedding. It is easy to argue about because it's right there and everyone can see a . instead of a ;. It would better to talk about the semantics of the language, sending messages, concurrency, modeling applications as a set of communicating processes, supervision trees etc.

hoodoof 8y ago

I seem to recall the author of the old post ditched Erlang at some later point.

odammit 8y ago

I disagreed up until the docs section. I like all the other things he critiqued!!1! Rearranging: the punctuation helps you think about how you’re rearranging. You can’t copy/paste around in any function and expect it it work! The records comparison to a struct is unfair. He could have patterned matched on the record instead of destructuring and accessed the attributes of the record. Immutability! Fuck yeah! I tend to name subsequent variables with the mutation that was applied to them. It’s wordy. Name = “wayne” NameCapitalized = ... Now get off my lawn!

phoe-krk 8y ago

f(X) -> X1 = foo(X), X2 = bar(X1), baz(X2). If I use the pointless variable names like that, sure, I run into trouble, but this means I'm a shitty programmer who cares little about program readability. f(X) -> fooedX = foo(X), baredX = bar(fooedX), baz(baredX). f(X) -> fooedX = foo(X), fabedX = fab(fooedX), baredX = bar(fabedX), baz(baredX). Or just f(X) -> baz(bar(fab(foo(x)))).

didibus 8y ago
Ya, actually, I often use this style in other languages to be clear about the intermediate steps. My understanding though is that the problem is mixed with Erlangs pattern matching it can cause issues, because it won't necessarily fail to repeat the variable name, it'll just behave wrong. At least that's what I heard.
cygned 8y ago
I am not an Erlang programmer, but that style of programming bothered me, too. This variable per function application is a code smell in my point of view and should be handled with function composition or partial application (not sure how Erlang handles these, though).
- jxub 8y ago
  Elixir has pipes for this, effectively solving this painpoint.

pulsarpietro 8y ago

Is it right to say that Erlang and Prolog are actually that close as stated at the beginning of the article ? As far as I am aware Erlang does not run the unification algorithm and it is very different, you can, for instance, assign variables. I don't think it is right to compare the two as close languages as it is claimed but I would be interested in your opinion

Tomte 8y ago
It's true that Erlang is not a logic-based language like Prolog, but the first implementation of Erlang was written in Prolog.
- pulsarpietro 8y ago
  what is it written in now ?
  - Tomte 8y ago
    In C.

tilt_error 8y ago

You have Erlang the programming language, Erlang the system (OTP, philosophy), and even Erlang the eco system (including Elixir). Personally I like Erlang the language, but it is still Erlang the system that truly shines. It says a lot of Erlang the system that we’re fondly criticizing the language, warts and all. Erlang is all about pragmatism and we hand it over to the academy (the Swedish one, notch, notch, know what I mean?) to dwell on the Important Details about ‘.’, ‘,’ and ’;’ ;)

dixel 8y ago

> Instead you are forced to do something like this: if Logging -> log("Something happened"); true -> ok end For this particular use-case there is much more elegant way in Erlang: Logging andalso log("Something happened"); Even though I agree that the syntax and the concepts are unfamiliar for the general audience, I mainly see those arguments as the main reason to learn the language rather than put it away since it's sometimes the only way to learn something new. Regarding the "alien" syntax and expressing my point of view, I think Erlang syntax is usable, very simple and sometimes prevents you from doing "too fancy" things. Erlang's main areas are fault tolerant, high throughput applications and network protocols. Once it's declared as the focus - I wouldn't punch the ecosystem too much for the syntax but rather just use another tool for solving the problems that require more expressive programming languages. On the critics of the areas of focus I'd recommend the work done by Fred Herbert, the author of Learn you some Erlang for Great Good (http://learnyousomeerlang.com/ http://learnyousomeerlang.com/). There is a book on pitfalls while maintaining Erlang platform at large scale: http://www.erlang-in-anger.com/ http://www.erlang-in-anger.com/

jlouis 8y ago
Another good trick is to never log: report(Msg) -> hopefully_traced. You can then add a trace probe to your report/1 function and this allows you to have debug information when you need it.

moomin 8y ago

Reminder that there exists a BEAM fork of PureScript. https://github.com/purerl/purescript https://github.com/purerl/purescript