Earlier quoted context omitted.
Ruby can use braces instead of end, both are valid.
Hm? Only for blocks. Not classes, methods, if/unless, while or begin/rescue.
Dang, you're right, I could swear otherwise but yup, just on blocks.
A taste of Rust
91–93 of 93 posts
Re: A taste of Rust
#92Earlier quoted context omitted.
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!), perform…
> 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/efsf2... Think about Erlang as a tank. A cool hipster comes to you says "LOL, my fixie bicycle is sooo much faster than…
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.
B,
A.
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.
Re: A taste of Rust
#93Earlier quoted context omitted.
I've on a few occasions had problems with semicolons in Java: accidently putting a semicolong like this: if (something()); { somethingOther(); } The semicolon seemed to shortcut the whole if-block. I don't know why that thing is even allowed by the compiler.
The semicolon following the conditional is an empty statement; it ends the if statement equivalently to "if (something()) { }". It's not often seen, but sometimes can be found in: for (i = 0; a[i] != x; i++) ; to find the first index equaling x. Personally, I always use braces in conditional and loop statements, so I'll never have the empty statement semicolon. But that's me.
> Personally, I always use braces in conditional and loop statements, so I'll never have the empty statement semicolon. But that's me.
But if you have
if (something()); { somethingOther(); }
Then you have a new problem: you intended the braced statement to execute iff the if-statement evaluated to true. But since you put the semicolon after if by accident, now the braced part will execute no matter what the if-condition evaluates to.
(my point was about unintentional use of semicolon after if-statement - in which case always using braces doesn't seem to help.)