Live data from Hacker News

What Sucks About Erlang (2008)

damienkatz.net

31–40 of 105 posts

Re: What Sucks About Erlang (2008)

#31
post #8

Earlier quoted context omitted.

'You can divide programming languages into two groups - those that people complain about, and those that nobody uses'

C# is widely used, but it's a bit of a sacred cow.

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.

Re: What Sucks About Erlang (2008)

#32

Earlier quoted context omitted.

Huh? I have never heard of anyone saying erlang is bad because of couchdb. I've heard criticisms of couchdb itself, sure. But they've been more along the lines of "MVCC multi-master document stores are not a good solution for this problem" more than "CouchDB is a bad MVCC multi-master document store".

It doesn't use real node-local/shard-local MVCC AFAICT. It's O_APPEND on flat files.

Sorry, wasn't clear if you were talking about MVCC in a replication context or in a node-local context. It does the former, it definitely does not do the latter.

Re: What Sucks About Erlang (2008)

#33
post #26

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…

He was right to abandon CouchDB. Here's my rationale: https://news.ycombinator.com/item?id=17116306

Re: What Sucks About Erlang (2008)

#34
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's syntax is inconsistent mess compared to Erlang.

An opinionated take: https://medium.com/@dmitriid/in-which-i-complain-about-elixi...

Re: What Sucks About Erlang (2008)

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

Re: What Sucks About Erlang (2008)

#36
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.

I'll share our deployment stack with Elixir, which is pretty hands off. We use docker with AWS ECS and have a simple release process:

  1. Our jenkins CI builds a docker image which contains an erlang release (using distillery).
  2. This image gets pushed to ECR (AWS's image repository), every version is tagged with a $GIT_REF.
  3. We have another jenkins job which updates our AWS ECS Tasks to use the new version of Docker images.
  4. AWS ECS now spins up a few new containers and drains out the connections from the old ones.

Re: What Sucks About Erlang (2008)

#37

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.

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.

Re: What Sucks About Erlang (2008)

#38

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

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.

Re: What Sucks About Erlang (2008)

#39

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

Re: What Sucks About Erlang (2008)

#40
post #8

Earlier quoted context omitted.

'You can divide programming languages into two groups - those that people complain about, and those that nobody uses'

C# is widely used, but it's a bit of a sacred cow.

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.
Post reply on HN