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.
What Sucks About Erlang (2008)
31–40 of 105 posts
Re: What Sucks About Erlang (2008)
#32Earlier 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.
Re: What Sucks About Erlang (2008)
#33It'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…
Re: What Sucks About Erlang (2008)
#34That 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.
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)
#36Earlier 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.
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)
#37Earlier 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.
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)
#38f(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)))).
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)
#39f(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)
#40Earlier 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.