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

71–80 of 105 posts

Re: What Sucks About Erlang (2008)

#71

Post by jlouis »

dixel wrote: post #66

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

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.

Re: What Sucks About Erlang (2008)

#72

Post by __sr__ »

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…

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.

Re: What Sucks About Erlang (2008)

#73

Post by jrochkind1 »

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…

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

Re: What Sucks About Erlang (2008)

#74

Post by brightball »

__sr__ wrote: post #72
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…

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/

Re: What Sucks About Erlang (2008)

#75

Post by andy_ppp »

__sr__ wrote: post #72
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…

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.

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.

Re: What Sucks About Erlang (2008)

#76

Post by degrews »

__sr__ wrote: post #72
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…

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.

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.

Re: What Sucks About Erlang (2008)

#77

Post by damienkatz »

facetube wrote: post #30
HumanDrivenDev wrote: post #23

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.

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.

Re: What Sucks About Erlang (2008)

#78

Post by ermouth »

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…

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

Re: What Sucks About Erlang (2008)

#79

Post by rdtsc »

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,

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.

Re: What Sucks About Erlang (2008)

#80

Post by facetube »

rdtsc wrote: post #79
facetube wrote: post #29

Earlier quoted context omitted.

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

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

Post reply on HN