This link has been bookmarked by 62 people . It was first bookmarked on 10 Mar 2008, by someone privately.
-
21 May 18
sunil-joglekar" This list isn't meant to put down Erlang, but as an honest assessment of it's weaknesses, which I think aren't discussed enough."
-
28 Sep 14
-
21 Jul 14
-
19 May 14
-
26 Feb 13
-
The first problem is that every time an
ifexecutes it should match at least one of the conditional expression branches. When it does not, an exception is thrown. -
Erlang allows a subset of the built-in functions (BIFs) in conditional expressions, but no user defined functions can be called whatsoever.
-
So much of the code seems to want to be expressed in a recursive, functional manner and the lightweight, shared nothing concurrency is a great match for network servers and database internals.
-
Records are a compile time feature -- not a VM feature -- and are statically compiled down to regular tuples, with the first slot holding the record name atom, and each slot N + 1 corresponding to the Nth entry in record declaration. At compile time the record member references are converted to integer offsets for tuple operations.
-
-
10 Sep 12
-
06 Sep 12
-
06 Aug 12
-
31 Jan 12
-
04 Jul 11
-
15 Feb 11
-
25 Dec 10
-
18 Dec 10
-
13 Oct 10
-
16 Aug 10
-
30 Dec 09
-
01 Dec 09
-
16 Nov 09
-
Erlang's syntax does away with nested statement terminators and instead uses expression separators everywhere
-
Erlang's expression terminators vary by context,
-
If Erlang were a side-effect free functional language, such a restriction would make sense
-
You cannot even call user defined functions in
ifconditional expressions -
Erlang allows a subset of the built-in functions (BIFs) in conditional expressions, but no user defined functions can be called whatsoever.
-
you can't distinguish easily at runtime between a string and a list, and especially between a string and a list of integers.
-
I personally wouldn't pick Erlang for most front-end web application work
-
CouchDB, a network database server
-
when it came time to write the test suite code for CouchDB, I found Erlang to be needlessly cumbersome, verbose and inflexible.
-
Erlang wasn't a good match for tests and for the same reasons I don't think it's a good match for front-end web applications
-
surprisingly limited and verbose, requiring you to state the type of the record for each reference in the code.
-
compile-time static and record members cannot be added or removed at runtime, and don't fit with Erlang's otherwise dynamic nature.
-
they aren't usable from the REPL command line, it won't accept record syntax without special steps and it still doesn't show you result records in record syntax.
-
we have to roll our own "restart the dead VM" solution and deal with cross-platform issues providing something I'm still shocked Erlang can't handle itself.
-
The extra file creation artificially spreads out the code over the file system, making things harder to follow
-
-
02 Sep 09
-
27 Aug 09
-
11 Jul 09
-
11 Apr 09
-
11 Mar 09
-
26 Oct 08
-
13 Oct 08
-
20 Sep 08
-
25 Jul 08
-
03 Jun 08
Micah ElliottThere are the languages everyone complains about, and there are the languages no one uses. Having said that, it's time to whine about my favorite language I use quite extensively. Erlang, I love ya, but we need to have a word.
-
06 May 08
-
In Erlang, there is no string type, strings are just a list of integers, each integer being an encoded character value in the string.
It's not all bad. It has the benefit of taking the same built-in list operations, libraries and optimizations and reusing them for string processing. But it also means you can't distinguish easily at runtime between a string and a list, and especially between a string and a list of integers.
-
Once I got over Erlang's weirdness and accepted its warts, I almost couldn't imagine using anything else. So much of the code seems to want to be expressed in a recursive, functional manner and the lightweight, shared nothing concurrency is a great match for network servers and database internals. The code is typically much more compact, elegant and reliable than it would be in more conventional languages.
-
records often feel like a tacked-on hack. They are compile-time static and record members cannot be added or removed at runtime, and don't fit with Erlang's otherwise dynamic nature.
Records are a compile time feature -- not a VM feature -- and are statically compiled down to regular tuples, with the first slot holding the record name atom, and each slot N + 1 corresponding to the Nth entry in record declaration. At compile time the record member references are converted to integer offsets for tuple operations.
-
The only code organization offered is the source file module, there are no classes or namespaces. I'm no OO fanatic (not anymore), but I do see the real value it has: code organization.
Every time time you need to create something resembling a class (like an OTP generic process), you have to create whole Erlang file module,
-
What I wish for is a simple class facility. I don't need inheritance or virtual methods or static checking or monkey patching. I'd just like some encapsulation, the ability to say here is a hunk of data and you can use these methods to taste the tootsie center.
-
The Inets httpd server we've found incredibly frustrating to use in CouchDB and are discarding it for a 3rd party Erlang HTTP library. The XML processor (Xmerl) is slow, complicated and under documented. Anything in Erlang using a GUI, like the debugger or process monitor, is hideous on Windows and pretty much unusable on OS X. The OTP build and versioning system is complicated and verbose and I still don't understand why it is like it is.
-
-
06 Apr 08
-
14 Mar 08
-
11 Mar 08
-
10 Mar 08
-
rampionnow I'm curious to see a column about what he loves about erlang
-
Jeremy JamesA well reasoned critique of Erlang from someone developing in it, day to day.
-
-
09 Mar 08
Would you like to comment?
Join Diigo for a free account, or sign in if you are already a member.