What Sucks About Erlang (2008) | Hacker News Reader

What Sucks About Erlang (2008)

damienkatz.net

145 pointsjxub103 comments

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.

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.

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

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.

I have to ask someone to bring kubernetes into the comparison -redundant with Erlang?

I also want to know this. We have a team of 3 people maintaining our microservices infra (services written in NodeJS), out of ~15 developers. It feels like a waste, these (monitoring, logging, deployment etc) are all problems that have been solved many times over.

I would say they are complementary. Kubernetes is a standard solution for packaging and deploying apps. If you run a lot of apps, you want your ops team to be able to manage them without knowing all the details. You get better utilization of your servers by allowing them to deploy standard units and manage resources at a higher level.

You can put an Erlang/Elixir app into a container and deploy it, but containerization doesn't provide as much value as it may for other languages. The Erlang VM doesn't depend much on the operating system. The mix build tool tightly manages runtime library dependencies, and building a release combines the VM and the app's libraries into a single tarball that you can deploy as a unit. So we don't find it particularly useful to use Docker/Kubernetes to deploy.

Erlang/Elixir makes it very easy to take advantage of all the CPU cores available, so you generally benefit from having one instance with lots of CPUs instead of lot of little instances. And it can be a lot cheaper to do this in a dedicated server environment instead of the cloud.

So on the whole, Kubernetes is not that big a win for Erlang, but they work fine together.

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.

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

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.

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.

Is Elixir being used extensively outside Silicon Valley? Can you list some well known success stories? Looking at job listings and open source projects, it doesn’t seem to be widely used. In fact, I don’t know anyone outside Silican Valley who has built anything non-trivial in Elixir.

I am not saying it is bad. But I’d like to know about it before I dive in.

The ones that come to mind immediately are Discord, Pinterest, Teachers Pay Teachers, Bleacher Report.

After a quick Google I also discovered this nifty site: https://elixir-companies.com/

Why exclude the success stories in Silicon Valley - seems like an arbitrary decision to exclude Discord say or Pinterest?

It does seem there aren't that many very big companies outside of Silicon Valley using Elixir but maybe that's a factor of Silicon Vally having the vast majority of winners period.

Well, I don’t live in Silicon Valley, and as a result, the company I work for is not a Silicon Valley company. If I am going to convince the management to invest in Elixir, I need to be able to answer questions like this. Pretty much everyone I have spoken to about Elixir, inevitably brings up this point.

I don't understand why you make the distinction between Silicon Valley and not Silicon Valley because where something is done makes absolutely zero difference as to if it's a good idea to use software or not.

If there was a text editor that you thought was good but was only in use in Silicon Valley would you still recommend it? I've never ever in my life discounted a piece of software because it was only in use in Silicon Valley.

Maybe you could expand on the argument because I don't understand it clearly!

Cabify, an Uber competitor from Spain operating mostly in South/Central America and recently valued at 1.5B has been moving from a primarily Ruby stack to Elixir over the past year.

I've built major crawling infrastructure at [#paid](http://hashtagpaid.com) with Elixir.

My anecdatum. :)

Not publicly documented, but CNN's ingest scheduling system (basically the backend that says "at this time, record this incoming feed, on this encoder, associate it with this metadata", and all the ensuing complexity that comes with finding a free encoder, responding in the event of hardware failure, allowing users to plan recordings that there isn't space for, etc) is in Erlang. Because it needed to be bullet proof; if it goes down, CNN doesn't record incoming video.

Had Elixir been mature at the time, we would have used it instead.

That's interesting. Do you guys have to build a lot of custom tooling in TV? Are CNN's requirements particularly novel compared to other stations with live programming and remote feeds?

I've since left, but yes and no. Video at that scale requires some unique hardware, which in turn requires some unique software. But for broadcasters of that scale, many of the problems are the same.

We actually had, prior to this system, been relying on one built by a French company, that cost hundreds of thousands, possibly millions, per year in licensing. Updates were infrequent, often included regressions, but it mostly worked.

This started as a way to get some of the smaller bureaus to have some basic functionality, and grew into a system that was deployed to every bureau, eventually replacing what we had in Atlanta (that previously mentioned system). It was extremely popular, and the business stakeholders even characterized it as the biggest success they've had from our department.

One of our group's VPs showed it at an industry trade show, just offhandedly, and an exec from another broadcaster indicated regret of having just signed a deal to purchase the aforementioned system above, rather than attempting to roll their own (seeing the success CNN had).

It's not a key differentiator for CNN, but they also don't have software sales as a core competency. So they have basically best of breed software sitting there unnoticed. shrug C'est la vie.

It also has the benefit of, since it's Erlang, largely just working without issue. There's not many there still with Erlang knowledge, but that isn't really much issue for another 20 years if it continues just working without issue.

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.

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

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

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.

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.

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.

People fuck up commas and semicolons basically constantly in English.

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.

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

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.

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

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.

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

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

but you could store Ids and revisions on any key/value store on the client. Why does the client need pouchdbs multiple revisions?

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

Not familiar with Realm

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

I mean I both get it, and don't get it. CouchDB is all about master-master, and pouchdb just brings that to the browser. But at the same time I don't understand why you'd want a 'master' at the edge of the network, or the overhead of multiple revisions when a users browser isn't going to have tones of concurrent connections.

I fully admit I'm not very well-versed on databases or distributed computing, happy to have things clarified.

I had to make that distinction fairly early on wether PouchDB would be an edge client or a full node and I decided full node, tradeoffs either way but pros of being a full node:

1. Additional (p2p) use cases, honestly I dont use CouchDB much these days, I use express-pouchdb-server so I can embed pouchdb into my server easier than any other database, there is also pouchdb-server and p2p projects like Thali (http://thaliproject.org/)

2. CouchDB existed, sync is super hard, writing an edge client would have meant designing it myself, writing a couchdb clone meant I needed to make a lot less decisions about how it worked while being very confident it would work, The test suite runs the same tests against pouchdb/couchdb to ensure compatibility (and replication via each configuration)

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

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 deserializing twice per document. Almost all of this "external view server" (the only kind AFAICT) is actually written in Javascript on that seven year old engine. Nothing is streaming; your map function is sandbox-evaled in that process, the results of a single call are stuffed into a Javascript array via .push, then stringified and printed on standard output as a single line. The entire internal "view server" protocol is based on a pipe of single-line JSON commands and data payloads. Performance (and likely security, due to age of the engine) in this subsystem is extremely poor IME.

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". Performance in this area also appeared to be proportional to the code size of the map function, which sounded a lot like it was being serialized down a pipe with no caching.

If you make a change to a single view in a design document, the database system will rebuild all indexes in that design document unconditionally, even if the other view code hasn't changed. The only way to prevent this is to store a single view per design document, and manage those documents yourself.

Once you've endured your multi-day index rebuild on a couple million documents, you'll also have to issue an extra "cleanup" command to delete the old (now essentially useless) indexes. It's a full rebuild, so you need 2x the space at a minimum to pull it off.

The data itself is stored in a single file per shard, opened in O_APPEND mode, effectively serializing all writes on the shard. You also will not see kswapd active, ever, because the OS VMM is not being used effectively – no shared memory for IPC, and no use of mmap AFAICT.

Server-side changes feed filters appear to be extremely slow when compared to just filtering the results in the client.

Authorization: limiting read access will be difficult at best. Transactional behavior: no, aside from a single bulk write feature (make sure to use "all or nothing" mode though).

Logging: signal to noise ratio is poor. Giant stack traces for minor events. You may even see strings emitted as UTF-32 arrays of integers in base 10. Hope you brought an ASCII table at least.

Documentation: The following passage from section 5.2.5 of the CouchDB v2.1.1 manual just about says it all: "Views with the JavaScript query server are extremely slow to generate when there are a non-trivial number of documents to process. The generation process won’t even saturate a single CPU let alone your I/O. The cause is the latency involved in the CouchDB server and separate couchjs query server, dramatically indicating how important it is to take latency out of your implementation." I can't say anything nice here about that last sentence, so I'm just going to keep my mouth shut.

But worst of all: every time it starts up, it tells me "it's time to relax". Nothing about this is relaxing.

(These are my own private individually-held views, and do not reflect the views of any employer or organization)

For balance: there is a newer query/index system called Mango in Apache CouchDB 2.0+, that IIRC is internal and doesn't rely on any external view server. It wasn't in 1.7.1, though, so if you're coming from there, it's very much a "switch query APIs to get tolerable performance" situation.

Also for balance: it's unclear if there are CVEs. There may not be any that are exploitable due to the age of the library (i.e. the bugs landed post-release). However, it's also very tricky to rule these out one by one, and the dependency is slated for removal from some distros.

There may be no material security issue. But the age of the software does not instill confidence, and newer engines are likely far more performant.

> 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

One of the stated goals on their Spidermonkey replacement issue (N.B. it still won't fix the view server protocol performance, but at least it'll be a modern engine) is "Get my C skills back out of the closet", and will require https://github.com/jquery/esprima.

It's depressing.

> Nothing is streaming

Except CouchDB entire REST API, where nearly every endpoint streams result row by row, which is great.

> Performance (and likely security, due to age of the engine) in this subsystem is extremely poor

As of security: wrong guess. Go compare number of critical CouchDB CVE for last, say, 5 years, with any other DB you want.

As for query server: indexing is slow for the reasons you pointed out. Requesting persisted index is ok. Taking in account CouchDB persists everything, it‘s not in-memory DB (which is again great), I‘d say it‘s even fast.

> Performance in this (Erlang) area also appeared to be proportional to the code size of the map function

Performance in this area depends much more on how branchy is the json doc being processed. It‘s not about CouchDB itself, it‘s about json parser used. There might be a situation when you have better perf using JS views.

> Nothing about this is relaxing.

Indeed. But then it just works, for years, with zero maintenance even for replications – the result I‘ve never even nearly achieved with any other DB I used.

> Except CouchDB entire REST API, where nearly every endpoint streams result row by row

I'm talking about the internals of couchjs.

> As of security: wrong guess. Go compare number of critical CouchDB CVE

I'm talking about Spidermonkey 1.8.5, which is seven years old. Multiple CVEs have been reported including a full RCE, which was patched in later versions. If you believe these are patched in libmozjs185, I'd love to see a link to the source package showing where the fix was applied. Because I can't find it.

Further: https://www.cvedetails.com/vulnerability-list/vendor_id-45/p.... Another full RCE in CouchDB.

> Performance in this area depends much more on how branchy is the json doc being processed

Citation needed. There's an issue specifically about this in the CouchDB issue tracker if you'd like to read more.

> As for query server: indexing is slow for the reasons you pointed out.

Right. It is not performant. That's my point.

Curious what kind of database sizes you're working with too; you won't see this stuff with a few hundred documents.

Correction: the library is too old for that specific CVE to be exploitable. There may be others, there may not be. I don't know – and that's actually the problem.

The chief complaint here is that it's very hard to reason about the security of seven year old software that distros are pulling out of their package repositories citing security issues (e.g. Alpine Linux). Advisories tend to say "versions before X", and you're left to either wonder or read tickets/code. Not everyone wants to sign on for that, and it's work that isn't going toward writing your app.

> I'm talking about the internals of couchjs.

_list functions stream, and was specifically designed to be able to stream. However, streaming does not help much in this case, moreover too small chunks dramatically reduce already awful _list perf.

Taking this in account I see no value for views to stream. Sending all emitted KVs for the doc to Erlang bits in one turn seems both much more predictable and safe.

> Multiple CVEs have been reported including a full RCE, which was patched in later versions

Last CVEs has nothing to do with Spidermonkey. BTW they may be patched without upgrade, with 5LOC long design document in Erlang.

The main reason of last CVEs is inconsistency in parsing improper JSONs by Erlang parser. Namely, most JSON parsers process '{"abc":1, "abc":2}' as {abc:2}, but old jiffy parses it as {abc:1}. BTW severe inconsistencies in parsing JSON are pretty common across implementations, please read http://seriot.ch/parsing_json.php for more details.

> Citation needed. There's an issue specifically about this in the CouchDB issue tracker if you'd like to read more.

I‘ll give you no cite, sorry, because we discovered the effect during internal tests. Reason is simple: accessing values in deep branchy JSONs is generally faster in JS, because it‘s native format. JSON in Erlang is a monster like {[{<<"abc">>, 1}]} for {abc:1}, which, when has a lot of levels and nodes at each level, performs bad for selecting random node.

> Curious what kind of database sizes you're working with too

We sometimes measure number of docs with M postfix ) Not very often, however. In my humble opinion, if you plan to have CouchDB with, say, 100M docs in a single bucket, you probably chose wrong solution.

BTW, same for large kitchen DBs for buckets with, say, 10K docs.

> I‘ll give you no cite, sorry, because we discovered the effect during internal tests

We discovered the issue in internal tests and reported it upstream where it was confirmed; there's nothing to discuss here.

> BTW they may be patched without upgrade, with 5LOC long design document in Erlang.

I don't have to hand-patch other database systems. Further, as of now there are no functioning packages for multiple versions of Ubuntu. Multiple competitors do not have any of these problems.

> Last CVEs has nothing to do with Spidermonkey

It was a full RCE that didn't have vendor packages ready in time.

Sorry, but using seven year old language runtimes is daft. It might be fine for you, but it's not appropriate in environments where you care about security and performance, or care about the overhead of making your team reason about these things unnecessarily.

> We sometimes measure number of docs with M postfix

Yeah, we did this in 2003 on commodity hardware, and even it built indexes faster than CouchDB builds map/reduce indexes. Fix the external view server protocol or be honest with people and kill it off – the status quo is unacceptable.

Finally, here's a five year old issue that's still open admitting what I just explained: https://issues.apache.org/jira/browse/COUCHDB-1743

100M docs? Of json format? On commodity hardware? In 2003?

Hahaha, hello long waited friend from parallel universe!

Easy enough to convert on the way out, using a mature database system without these performance flaws. The app got done and performed well, and we weren't at the mercy of an unresponsive community that leaves seven year old dependencies in critical paths.

Keep going; it'll bite you eventually. Don't say you weren't warned.

> You can write map/reduce views in Erlang itself as an alternative,

Or you can use a query language mostly similar to what MongoDB uses http://docs.couchdb.org/en/2.0.0/api/database/find.html

> If you make a change to a single view in a design document, the database system will rebuild all indexes in that design document unconditionally,

That's a feature. If they don't usually change together put them in a separate design documents.

> and manage those documents yourself.

It's a document database. So managing documents yourself is kind of what you do. Isn't it?

> he data itself is stored in a single file per shard, opened in O_APPEND mode, effectively serializing all writes on the shard.

So have more shards? A lot of databases use append only mode. There is a reason for that. Having uses the db for a good number of years, it had never lost data. Even during power outages or brutal restarts. That's more than I can say about other databases.

> no shared memory for IPC,

Shared memory IPC doesn't magically solve problems but it is a minefield of bugs.

> use of mmap AFAICT.

Large blocks of allocated memory use malloc instead of brk so memory allocation uses mmap. For file IO mmap isn't a panacea either. If data is not there, reads will still go to the disk. If it uses regular reads through data should end up in the page cache

> kswapd active,

Hmm, seeing kswapd being active is not something I look forward on a production server. From what I remember I have seen page cache utilized correctly and that's what should matter. Not kswapd.

> Transactional behavior: no, aside from a single bulk write feature

bulk docks is not a transactional feature. The database is not CP database so it doesn't have transactional feature.

> But worst of all: every time it starts up, it tells me "it's time to relax". Nothing about this is relaxing.

Yeah that is silly never liked that. From what I remember it was a DB that was built when MySQL ruled the open source DB world and many of the current DBs were not there. It was actually pretty relaxing being able to insert regular json object in it, index them, have master to master replication (which most dbs still don't support), have a nice built in web dashboard to inspect and query documents.

> Or you can use a query language mostly similar to what MongoDB uses

Yes, provided you started on 2.0, as I specifically stated in a reply.

> That's a feature. If they don't usually change together put them in a separate design documents.

Unnecessary computation and I/O is not a feature. They should hash the views individually. A database that makes me do extra work to keep it from doing unnecessary work is not helpful.

> So managing documents yourself is kind of what you do. Isn't it?

This doesn't have anything to do with the unnecessary index rebuilds. CouchDB has all of the information it needs to avoid this unnecessary computation and I/O.

> So have more shards

More shards spending time serializing and deserializing JSON instead of doing useful work. Throwing shards at inefficient code might help, but it doesn't address the underlying problem.

> Shared memory IPC doesn't magically solve problems but it is a minefield of bugs.

Lots of database systems manage to use it just fine. You probably use one of them. And it does solve a problem: it avoids serializing and deserializing all of your data down a pipe.

> Large blocks of allocated memory use malloc instead of brk so memory allocation uses mmap.

Yes, with MAP_ANONYMOUS. I'm not talking about anonymous mappings.

> Hmm, seeing kswapd being active is not something I look forward on a production server.

For swap? Sure. For file-backed mmap pageout guided by madvise? I actually do. It means the VMM is being used for its intended purpose.

> bulk docks is not a transactional feature

It was an example of the one way to achieve an atomic write of multiple documents, which comes in very handy for any nontrivial application.

I'd honestly be fine with them just deprecating the entire external view server protocol – but as it stands now, it's a supported feature, the performance documentation in 5.2.5 of the manual is nonsensical, and it performs very very poorly due to excessive serialization/deserialization and inefficient IPC.

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.

I don't know that much about databases, could you go into more detail?

From the point of view of a single cluster or node (ignoring replication for a moment), it just doesn't have any strong notion of transactions. There's no write-ahead log, no rollback, and no situation where you'd be able to operate in a mode equivalent to something like `SERIALIZABLE` on a relational database.

oh right, I understand what you mean now.

I guess most people should know that going in. Are their good master-master systems out there with local transactions?

The claim from daimenkatz was that transactions and MVCC are supported internally, but not externally. It's unclear to me if any of this is accurate. Here's the information that was offered: https://github.com/couchbaselabs/couchstore/wiki/Format. Let me know if you see MVCC or transactional behavior in there.

It _is_ append only. But doesn’t use flat files. The main storage files have 2 different immutable btrees to find documents (by id and by sequence num). And it does have mvcc for both storage and secondary indexes. Internally it has transactions but they aren’t exposed to the user, as multi document transactions don’t make sense for the replicated document model.

Thanks for the clarification. Can I ask how the MVCC is implemented (e.g. WAL, MVTO, MVRC, etc.), or if there's documentation around that might give some additional insight?

Here’s a link that describes the Couchstore file format. It’s the storage engine for Couchbase and is essentially the same design as CouchDB. https://github.com/couchbaselabs/couchstore/wiki/Format

Thanks a lot; this is super-helpful.

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!

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.

> 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/

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.

    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.

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.

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 ’;’ ;)

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

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

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

Minor points:

> Had Prolog used statements and not expressions or ; instead of .

Prolog uses "goals", which are a lot more like statements than they are like expressions. Also, Prolog doesn't use ; to separate the clauses ("rules") of a predicate, it uses . to terminate each one.

But I agree that whether or not Prolog sucks for building entire applications has nothing to do with these points.

Reminder that there exists a BEAM fork of PureScript.

https://github.com/purerl/purescript

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.

what is it written in now ?

In C.

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

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.

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.

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.

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

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.

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.

So you recommend learning Erlang by spending a year on Prolog? :)

Elixir's syntax is inconsistent mess compared to Erlang.

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

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

Reply on news.ycombinator.com