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

51–60 of 105 posts

Re: What Sucks About Erlang (2008)

#51

Post by jxub »

cygned wrote: post #39
phoe-krk wrote: post #35

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)))).

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).

Elixir has pipes for this, effectively solving this painpoint.

Re: What Sucks About Erlang (2008)

#52

Post by daleharvey »

HumanDrivenDev wrote: post #24
brightball wrote: post #16

Earlier quoted context omitted.

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.

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.

Not entirely sure what you misunderstand, PouchDB stores multiple revisions because thats how CouchDB's sync protocol works, the point of PouchDB was to match CouchDB semantics. PouchDB (as CouchDB) provides options to control how much you track (revs_limit, auto_compaction) and there are improvements we could do to handle tracking less information better

We use transactions under the hood actually writing data to indexeddb

Re: What Sucks About Erlang (2008)

#53

Post by Tomte »

pulsarpietro wrote: post #47

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

It's true that Erlang is not a logic-based language like Prolog, but the first implementation of Erlang was written in Prolog.

Re: What Sucks About Erlang (2008)

#54

Post by jake_morrison »

shadowycoder wrote: post #18
latch wrote: post #17

Earlier quoted context omitted.

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…

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.

We run in cloud or dedicated server instances. We deploy using Erlang "releases" using systemd for process supervision. We build on a continuous integration server and deploy using Ansible or AWS CodeDeploy.

I have written a detailed guide here: https://www.cogini.com/blog/best-practices-for-deploying-eli...

Re: What Sucks About Erlang (2008)

#55

Post by jake_morrison »

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 has a very regular syntax, so you get Erlang plus the power of lisp-style macros, which is HUGE. It also adds features like Clojure-style protocols. And then with pattern matching, we get to dispatch on all the function call arguments, like CLOS. So basically, it's got much of the power of Lisp, in a mainstream syntax. I love it.

With those syntax improvements, we get the power of Erlang with the ease of use of Rails: http://www.littlelines.com/blog/2014/07/08/elixir-vs-ruby-sh... (A bit dated, but this is the post that sold me on the platform.)

Re: What Sucks About Erlang (2008)

#56

Post by triska »

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…

In Prolog, there is a neat technique that lets you "comment out" any goal of a clause, including the last one, in a completely uniform way.

The trick is to define * as a prefix operator, and then define the predicate ( * )/1 to generalize away its argument. You only need two lines to do it:

    :- op(920,fy, *).
    *_.
Now, you can put * in front of any goal to "remove" it. For example:

    pred :-
         true,
         * false.
With this definition, ?- pred. succeeds.

In Erlang, you cannot easily replicate this. You can try parse transformations to rewrite code at compilation time:

http://erlang.org/doc/man/compile.html

In Elixir, defining otherwise unused operators is generally discouraged:

https://hexdocs.pm/elixir/master/operators.html

For exchanging lines, an editor macro may be useful for Erlang and also for Prolog.

Re: What Sucks About Erlang (2008)

#57

Post by Gibbon1 »

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.

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.

Re: What Sucks About Erlang (2008)

#58

Post by nickjj »

latch wrote: post #22
shadowycoder wrote: post #18

Earlier quoted context omitted.

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.

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

And to further add to this. When he says "same benefits of microservices within a single app", that's because there's this concept of an "Umbrella app".

Basically you could split up your apps and hack on them independently (but actually have a good way to share dependencies if needed) and at deploy time you could choose to deploy all of them, or just the ones you want.

Phoenix (Elixir's goto web framework) also tries to nudge you in a good direction to split up your code base in a way that allows you to separate the specific pieces of your app. This is really good for people who just want to make maintainable projects. It's sort of like the first step in splitting up your application without dealing with any type of real additional complexity since changing things around just involves renaming and moving files.

Re: What Sucks About Erlang (2008)

#59

Post by chriswarbo »

lallysingh wrote: post #10
facetube wrote: post #9

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

I don't follow your reasoning here: why would the badness of an application propagate up to the technology it's based on? Even the best systems in the world can be abused.

I can understand it working the other way around, e.g. an application initially seems good, but opinion of it drops when finding out it's written in COBOL.

I can understand if the CouchDB authors agreed with criticism of their application, and explained them as being inherent to the language. AFAIK they haven't. EDIT: Ah, looks like the author wrote CouchDB!

I can understand if Erlang and its proponents held CouchDB up as a shining example of their philosophy. AFAIK they don't (e.g. it doesn't appear on https://www.erlang.org/community ).

Re: What Sucks About Erlang (2008)

#60

Post by newlaptopnewacc »

latch wrote: post #22
shadowycoder wrote: post #18

Earlier quoted context omitted.

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.

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

I have to ask someone to bring kubernetes into the comparison -redundant with Erlang?
Post reply on HN