Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What Sucks About Erlang (2008)

damienkatz.net

Post reply on HN
Print view View original

61–70 of 105 posts

Re: What Sucks About Erlang (2008)

#61

Post by kuon »

segmondy wrote: post #15
kuon wrote: post #4

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.

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 O…

I should have been more precise. I'd say elixir makes erlang more accessible and easier to work with, not "better" as they are two different beasts with two different focus.

Re: What Sucks About Erlang (2008)

#62

Post by jrs95 »

latch wrote: post #17
losvedir wrote: post #14

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…

Asynchronous messaging is overly complicated for request-bound tasks in web applications when using an external message queue. When it’s a first class feature of your language though, it’s way less painful than it would be with something like Python and SQS. If I were going to build something that was heavily built around asynchronous messaging, I’d definitely want to do it in Elixir. Otherwise, I tend to prefer REST or RPC except in situations where messaging is really necessary.

Re: What Sucks About Erlang (2008)

#63

Post by brightball »

jinjin2 wrote: post #43
brightball wrote: post #37

Earlier quoted context omitted.

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.

Realm looks like a much more modern solution to that problem.

Not familiar with Realm

Re: What Sucks About Erlang (2008)

#64

Post by Jtsummers »

tom_mellior wrote: post #48
segmondy wrote: post #13

Earlier quoted context omitted.

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.

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 thi…

Semicolon also appears in other places in erlang (like guards) where it similarly means “choice”. It’s a consistent use of the symbol throughout.

Re: What Sucks About Erlang (2008)

#65

Post by Const-me »

GordonS wrote: post #44
moomin wrote: post #40

Earlier quoted context omitted.

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.

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.

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.

Re: What Sucks About Erlang (2008)

#66

Post by dixel »

> 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/). There is a book on pitfalls while maintaining Erlang platform at large scale: http://www.erlang-in-anger.com/

Re: What Sucks About Erlang (2008)

#68

Post by exikyut »

facetube wrote: post #29
joshlemer wrote: post #11

Earlier quoted context omitted.

Any complaints in particular? I had been contemplating CouchDB for a new application at work, maybe you have a link I could read about it? I thought that the incrementally updating mapreduce style views looked really powerful, especially when combined with the changes subscriptions / long polling features.

God, where to start. Map/reduce views ("secondary indexes") are currently built by serializing JSON down a pipe to an external process called couchjs that links against a seven year old version of Mozilla Spidermonkey (1.8.5, released on March 31st 2011, and the only version it currently works with). This external process then pipes the map results back, again as JSON. Forget zerocopy; we're serializing and deseriali…

> You can write map/reduce views in Erlang itself as an alternative, but that engine is disabled by default due to security concerns – it's "not sandboxed".

I get the impression the author(s) of this DB were still at the stage of needing to brow-beat the infrastructure into submission, or somesuch :S

Re: What Sucks About Erlang (2008)

#70

Post by jacquesm »

latch wrote: post #17
losvedir wrote: post #14

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…

Seconded, though I don't mind Erlang as much as some. The most complex stuff I ever built was built long before I knew about Erlang (and before Erlang was available to outsiders afaik). Message switches and other distributed systems would have been impossible with the degree of reliability required without the kind of architecture that message passing enables.

I did it using QnX re-inventing quite a bit of the Erlang philosophy along the way, if I had had access to either Erlang or Elixer at that point in time I would have been overjoyed, that would have saved so much time.

Post reply on HN