81–90 of 118 posts
I really like Node, but I want a language with sane semantics. What's the best option apart from JS and CoffeScript. TypeScript is awesome, but I'm afraid that there will no good community, because of MS stigma.
Earlier quoted context omitted.
I don't know node very well and only Javascript minimally but I understand what streaming I/O is and have used generators / iteratees for a long time in many languages. I understand the benefits and that's why Pipes in HS is such an exciting thing because it gives us a formally reasoned and general set of stream computing tools - you can compute anything with type-level guarantees . It's just as flexible and general…
> JS's lack of strong typing limits your ability to reason about streams (a lot more than just streams, too) and further limits your ability to write performant stream computing software I think you missed my point so I'll restate: in practice you don't reason about streams in Node, because the community (a product of the simplicity of the streams API) has a packaged solution to your problem. It plugs right in. And t…
It looks like this whole notion of 'stream' is just a syntactic sugar for javascript guys who lost themselves in a bunch of nested stupid callbacks, which is worse than lisp parens. Instead of nesting whole callbacks, create a stream in the middle; execute first half of callback chain and dump the result into the stream so that next half of callback chain can be executed later. Why is this so an enlightenment for nod…
I really like Node, but I want a language with sane semantics. What's the best option apart from JS and CoffeScript. TypeScript is awesome, but I'm afraid that there will no good community, because of MS stigma.
When did sane and static typing become synonymous?
I really like Node, but I want a language with sane semantics. What's the best option apart from JS and CoffeScript. TypeScript is awesome, but I'm afraid that there will no good community, because of MS stigma.
You can use Haskell for the same semantics if I understand you correctly. Actually coming from Node, Go might be a better fit.
I really like Node, but I want a language with sane semantics. What's the best option apart from JS and CoffeScript. TypeScript is awesome, but I'm afraid that there will no good community, because of MS stigma.
I really like Node, but I want a language with sane semantics. What's the best option apart from JS and CoffeScript. TypeScript is awesome, but I'm afraid that there will no good community, because of MS stigma.
Earlier quoted context omitted.
When did sane and static typing become synonymous?
sane has nothing to do with static typing. Python is a language which is dynamic and has a sane semantics. e.g. in JS {} + {} is NaN and many other examples.
Earlier quoted context omitted.
From Great British Node Conf, maybe two months ago: a speaker talking about promises asked what people use for flow control: - promises: about 20% of the room. - async: about 80% of the room For me async.waterfall([list of functions]) is little nicer than 10 chained .thens(). And people advocating promises still keep saying it keeps things flat. No it doesn't, we're already flat because we're all using async. Stop pr…
I have a question about the async library: what does it do if an asynchronous function or a callback raises an exception? The word "catch" doesn't appear in https://github.com/caolan/async/blob/master/lib/async.js . I ask because I wrote some Lisp macros (I work in a Lisp that compiles to JS) to implement a few async patterns I need, and making sure that exceptions are trapped and threaded into the callback chain cor…
From a practical perspective, it doesn't make sense to try to catch exceptions in asynchronous code, anyway. Once you do something asynchronous, you lose the stack and thus the try block. The way to catch thrown exceptions in asynchronous code is with domains, which something as low level as async would not be expected to handle.
Earlier quoted context omitted.
I have a question about the async library: what does it do if an asynchronous function or a callback raises an exception? The word "catch" doesn't appear in https://github.com/caolan/async/blob/master/lib/async.js . I ask because I wrote some Lisp macros (I work in a Lisp that compiles to JS) to implement a few async patterns I need, and making sure that exceptions are trapped and threaded into the callback chain cor…
It doesn't do anything about thrown exceptions. The correct way to deal with an error in asynchronous code is to pass an object describing the error as the first argument to the callback. Any code that takes a callback is expected to know this and not throw exceptions. From a practical perspective, it doesn't make sense to try to catch exceptions in asynchronous code, anyway. Once you do something asynchronous, you l…
Sure, but what if the error is thrown at you as an exception in the first place—which happens a fair amount, because that's how the JS runtime tells you when something is wrong? How do you get from there to the callback way?
What the Lisp macro I mentioned does is generate a separate try-catch around each block of code that runs at a different time and thus might throw an exception that would not otherwise get caught. In that way it catches every exception that's thrown, converts it to an error object, and passes the error back through the callback chain. The async library could do the same, albeit with a lot more code. I'm curious why it doesn't.
From a practical perspective, it doesn't make sense to try to catch exceptions in asynchronous code, anyway.
I don't think that's right. Asynchronous code is just synchronous code that runs at different times. Each block of synchronous code can generate exceptions. I agree that if you don't catch them then, they become useless; but you can catch them then. The reason this is not a "practical perspective" in JS is not that it doesn't make sense, it's that the language doesn't support it. Even the minimum code necessary to catch every exception involves so many try-catch blocks as to obscure the rest of the program. So no one writes such code by hand in JS.
Yet it is, I think, code that one wants, because without it you don't have a consistent error model. You end up having one model for first-class errors—the ones you detect and pass to callbacks before an exception has a chance to arise—and a second one for the dregs—the ones that come from any code that didn't know about or follow the callback convention (which, critically, includes the language runtime). The latter kind of error either crashes the server or gets caught by a top-level handler so it "only" crashes the request it was processing. That's a half-baked system.