41–50 of 244 posts
It's not wasted, though. I use my knowledge of functional programming to write better, more stable programs in Javascript and C#.
The lessons of Erlang, of what can be achieved when one shrugs off the burden of state... are extremely valuable in scalable, concurrent programming - regardless of language.
Also, the "processes only" model is pretty off-putting compared to Scala IMO where you're able to choose between threads and processes. You lose _some_ benefit in reliability (I assume, since it's said so often), but I've never seen that actually play out in the real world. What I have seen is comparably slow IPC exactly a real world development cost. So I'm personally more of a "in-process first" kinda guy.
I may be completely wrong on that one BTW. It's just what I recall from reading half of some Erlang book and studying online material trying to pick up the language.
It wasn't until Scala and Akka that the benefits of both pattern-matching and actors really clicked with me. Though I still prefer Scala's versions on both counts so I don't feel a great need to revisit Erlang at this point since I'm not working with Telco equipment. ;-)
Like Clojure, I like that Erlang has lots of interesting ideas. I may never use either in production, but Erlang's OTP sounds very interesting as a way to handle real-world scenarios like failure handling. Similarly, Clojure's datomic, core async, etc. are interesting ideas, implemented by people with good taste. However, too many examples show trivial things like mapping over a list or calculating something recursiv…
I sat down one week and prototyped a rewrite of the core exchange in clojure. 40x better throughput and 10x better latency despite using only two threads, naive `pr-str` serialisation and storing all the exchange state in one huge immutable data structure (for easy rollback on errors). Much easier to debug and to wire up different setups without modifying code (eg swapping out the network layer without touching the io and batching code).
There are some interesting ideas in erlang but they are hidden behind an inexpressive language and poor libraries. I would think more than twice before taking on another large erlang project.
Honestly, I think what kills it is that it's not an Algol-descended language [1]. If Erlang was written with an Algol-esque syntax it would have taken off years ago. But instead it has this weird syntax, which it then doesn't really do that much with. What do I mean by that? Haskell has a radically different syntax, but it does things with that syntax and its pervasive currying to enable a powerful succinctness that…
Not knowing enough about Erlang/OTP or Go: Would it be possible for more of OTP to be replicated in a Go 2.0? What's missing? What would it take? What can never be replicated?
Honestly, I think what kills it is that it's not an Algol-descended language [1]. If Erlang was written with an Algol-esque syntax it would have taken off years ago. But instead it has this weird syntax, which it then doesn't really do that much with. What do I mean by that? Haskell has a radically different syntax, but it does things with that syntax and its pervasive currying to enable a powerful succinctness that…
It is also worth a note that Elixir adds language features, such as default UTF8 binary strings, real macros, Clojure-style protocols, tooling, etc, on top of the Ruby-style syntax.
- Ugly, yet simple syntax - Ugly OTP, yet powerful - emacs - Grumpy community, just like freebsd-dudes. - Isn't general purpose - Breaking meta on ever step: no loops, no variables, no strings, actors, recursions, no namespaces (i mean like in any popular language) - Nobody writes tutorials. - Poor library selection. Look at RoR, 40 dependencies is okay there. - Situations like you do everything like in Basho's getting started for webmachine, and nothing is working - A lot of libraries that do the same thing, which is funny because it lacks of other libraries. Don't you dare ask community which webserver to use. - If you ask about IDE on erlang@c.j.r - almost instant ban, because, you know, trolling.
Fun fact: I did a co-op at Ericsson in second year. I asked my interviewer (later boss) if they used Erlang at all, and she'd never heard of it. Some of the hackers in the company had a limited degree of familiarity with it, but none of the PMs/managers seemed to know what it was.
1. It doesn't fill a pressing need
2. It has foreign syntax
3. It's hard to tell if it has familiar semantics (due to #2)
Credentials: I looked at some Erlang sample code twice and haven't looked at it again since; also, I'm no stranger to new languages, I fully adopted Clojure within a month of learning it
Honestly, I think what kills it is that it's not an Algol-descended language [1]. If Erlang was written with an Algol-esque syntax it would have taken off years ago. But instead it has this weird syntax, which it then doesn't really do that much with. What do I mean by that? Haskell has a radically different syntax, but it does things with that syntax and its pervasive currying to enable a powerful succinctness that…
I wouldn't be surprised by this. Go's concurrency pattern is fantastic, but to match what Erlang does it needs to be easily extended beyond the running process. Can channels connect multiple "nodes" yet? That is, two running go programs, can they communicate via channels or do they have to use some other IPC mechanism? Across a network? That universal communication structure is (IMO) erlang's killer feature.
1. Erlang performance is not very good (forcing significant FFI usage which is a pain).
2. Debugging code which is a mix of Erlang and C is difficult
3. Weakly typed language seems unsuitable for larger projects.
4. Better interop with C++ or Java would be a plus.
5. The syntax I can see people complaining about but it didn't bother me.