3 ms·

Elixir is neat, but it's such a leaky abstraction; you still have to deal with a lot of Erlang stuff that Elixir doesn't cover. Also, Erlang is slow. Really re

Elixir is neat, but it's such a leaky abstraction; you still have to deal with a lot of Erlang stuff that Elixir doesn't cover. Also, Erlang is slow. Really really slow. It's faster than Ruby, I think, but not much. And It sucks at a lot of things that should be fast in a functional language, such as file I/O. Erlang itself is also neat, but the syntax is abhorrent (commas and periods instead of semicolons!), performance is awful, and the language has many warts (no Unicode, no structs, etc.). I see where you're coming from. As for me, I am intimately familiar with everything that Rust provides, and it's frustrating because it's close to what I have been waiting for, but it makes a bunch of design choices I disagree with. Same with Go. For now, Go is much closer to what I want than Rust, but performance is pretty awful for many things, so I'm not a happy clam.

rdtsc 14y ago
> Really really slow. If the goal is simulate n-body problems and solve one instance of sudoku it is not the right tool. If one needs a fault tolerant system to maintain 2M concurrent connections to clients then it is the best tool for the job. http://www.erlang-factory.com/upload/presentations/558/efsf2012-whatsapp-scaling.pdf http://www.erlang-factory.com/upload/presentations/558/efsf2... Think about Erlang as a tank. A cool hipster comes to you says "LOL, my fixie bicycle is sooo much faster than your tank" and he's right because in some cases you just want to go to the nearest coffee shop to pick up an espresso. However a time comes when you need to go into battle and putting a turret and shields on the bike only works so far, then it is time for a serious tool for the job. > performance is awful I don't know I wouldn't call something that can handle millions of concurrent connections slow. It is slow if you all you need to do is handle a single connection at a time. Fault tolerance is actually the main feature of Erlang everything else flows from it. You don't always need it but when you do need it there is nothing like it. Fault tolerance mean paying some performance penalty. > syntax is abhorrent (commas and periods instead of semicolons!), Don't those make more sense though? How does a semicolon ending a statement make more sense than a period. And if there are 3 things that are executed then comma seems quite natural as well. On the other hand few languages rival Erlang's pattern matching. > no structs Frames/Maps are coming next year as part of R17
- lobster_johnson 14y ago
  Erlang is great, but for me, its problems simply outweigh its benefits. For example, not every app has a need for Erlang's massive parallelism. I can't write desktop or iOS apps in Erlang. Small utility scripts are cumbersome. There seems to be no kind of strong graphics or game support for it. For web apps the lackluster performance means is not really a step up from Ruby, which I currently use, so in that area there is no reason for me to switch. In fact, the only area where Erlang is really perfectly suitable is in developing fault-tolerant, concurrent, parallel, distributed systems. And yet when I do need to write such a system, I look to Go instead. > Don't those [commas and periods] make more sense though? No, they really are a bad choice. First, any kind of statement terminator/separator should be unnecessary, as I have argued elsewhere. Secondly, distinguishing between two types of terminators is a bad idea because it makes editing harder. If I have A, B. and I want to switch the order to: B, A. then I can't just use my editor's nifty line-transposing mechanism. I have to edit each line and change the "," into a "." and vice versa. It's incredibly badly thought out. Really, I like Erlang, but whenever its syntax is discussed, its defenders come out of the woodwork to make arguments without ever really wanting to listen. Syntax does matter. From speaking to lots of people, I know that Erlang's antique and cantankerous syntax is the number one problem preventing people from adopting it. As long as erlangers do nothing about their syntax, it will remain a weird little language that people admire but don't use. Just look at Elixir -- people actually get excited about it. Because it has a nice syntax. > few languages rival Erlang's pattern matching Erlang's pattern matching is cool, but its reliance on ordered lists (which it calls tuples even though the fields are unnamed) makes it less cool again. I vastly prefer Haskell's pattern matching and overall approach to typing.

rdtsc 14y ago

> Really really slow. If the goal is simulate n-body problems and solve one instance of sudoku it is not the right tool. If one needs a fault tolerant system to maintain 2M concurrent connections to clients then it is the best tool for the job. http://www.erlang-factory.com/upload/presentations/558/efsf2012-whatsapp-scaling.pdf http://www.erlang-factory.com/upload/presentations/558/efsf2... Think about Erlang as a tank. A cool hipster comes to you says "LOL, my fixie bicycle is sooo much faster than your tank" and he's right because in some cases you just want to go to the nearest coffee shop to pick up an espresso. However a time comes when you need to go into battle and putting a turret and shields on the bike only works so far, then it is time for a serious tool for the job. > performance is awful I don't know I wouldn't call something that can handle millions of concurrent connections slow. It is slow if you all you need to do is handle a single connection at a time. Fault tolerance is actually the main feature of Erlang everything else flows from it. You don't always need it but when you do need it there is nothing like it. Fault tolerance mean paying some performance penalty. > syntax is abhorrent (commas and periods instead of semicolons!), Don't those make more sense though? How does a semicolon ending a statement make more sense than a period. And if there are 3 things that are executed then comma seems quite natural as well. On the other hand few languages rival Erlang's pattern matching. > no structs Frames/Maps are coming next year as part of R17

lobster_johnson 14y ago
Erlang is great, but for me, its problems simply outweigh its benefits. For example, not every app has a need for Erlang's massive parallelism. I can't write desktop or iOS apps in Erlang. Small utility scripts are cumbersome. There seems to be no kind of strong graphics or game support for it. For web apps the lackluster performance means is not really a step up from Ruby, which I currently use, so in that area there is no reason for me to switch. In fact, the only area where Erlang is really perfectly suitable is in developing fault-tolerant, concurrent, parallel, distributed systems. And yet when I do need to write such a system, I look to Go instead. > Don't those [commas and periods] make more sense though? No, they really are a bad choice. First, any kind of statement terminator/separator should be unnecessary, as I have argued elsewhere. Secondly, distinguishing between two types of terminators is a bad idea because it makes editing harder. If I have A, B. and I want to switch the order to: B, A. then I can't just use my editor's nifty line-transposing mechanism. I have to edit each line and change the "," into a "." and vice versa. It's incredibly badly thought out. Really, I like Erlang, but whenever its syntax is discussed, its defenders come out of the woodwork to make arguments without ever really wanting to listen. Syntax does matter. From speaking to lots of people, I know that Erlang's antique and cantankerous syntax is the number one problem preventing people from adopting it. As long as erlangers do nothing about their syntax, it will remain a weird little language that people admire but don't use. Just look at Elixir -- people actually get excited about it. Because it has a nice syntax. > few languages rival Erlang's pattern matching Erlang's pattern matching is cool, but its reliance on ordered lists (which it calls tuples even though the fields are unnamed) makes it less cool again. I vastly prefer Haskell's pattern matching and overall approach to typing.