11–20 of 31 posts
Then how about writing some documentation. Your half-page README, half of which is spent making big claims, but then barely scratching a hello-world, left me rather underwhelmed.
Here's a simple question: How do you handle errors? (exceptions, transport errors, timeouts)
This is pretty sweet sauce. You get the modular ideology like Erlang.. without the syntax. Ew.
So, you want to take on erlang? Then how about writing some documentation. Your half-page README, half of which is spent making big claims, but then barely scratching a hello-world, left me rather underwhelmed. Here's a simple question: How do you handle errors? (exceptions, transport errors, timeouts)
You'll have to be way more specific about what you mean by "handle errors". Do you mean node to node connection errors? Node to node messaging errors? Errors localized in a custom Hook?
I suggest just reading through the codebase, it's not that big. The entire philosophy is crash only processes which are supervised by Forever. In the current early version of hook.io we usually get let things crash and restart. This isn't idea for guaranteeing delivery of messages, but it's a good start.
>nodejitsu
No.
>i/o framework...node.js...take on erlang >nodejitsu No.
This is pretty sweet sauce. You get the modular ideology like Erlang.. without the syntax. Ew.
So, you want to take on erlang? Then how about writing some documentation. Your half-page README, half of which is spent making big claims, but then barely scratching a hello-world, left me rather underwhelmed. Here's a simple question: How do you handle errors? (exceptions, transport errors, timeouts)
The project is pre semver 1.0.0, it should not be considering suitable for production. You'll have to be way more specific about what you mean by "handle errors". Do you mean node to node connection errors? Node to node messaging errors? Errors localized in a custom Hook? I suggest just reading through the codebase, it's not that big. The entire philosophy is crash only processes which are supervised by Forever. In t…
> we usually get let things crash and restart.
>This isn't idea for guaranteeing delivery of messages
That is not Erlang.
This is pretty sweet sauce. You get the modular ideology like Erlang.. without the syntax. Ew.
Syntax is potentially the most shallow thing to complain about, particularly when it actually makes sense in the structure of the language in question (like Erlang) and doesn't hurt readability for anyone (unlike some perceptions of Lisp).
Earlier quoted context omitted.
Syntax is potentially the most shallow thing to complain about, particularly when it actually makes sense in the structure of the language in question (like Erlang) and doesn't hurt readability for anyone (unlike some perceptions of Lisp).
Shallow? I can't roll my eyes at those whom complain about noisy/unpleasant syntax. It's quite important that it's agreeable to you if you have to stare at it all day long. Sure, there are many other important considerations when evaluating a language, but being concerned with syntax is hardly shallow IMHO.