6 ms·
A couple of strange things: * the use of decorators in even the most basic example * no async/await. You fall back to Promise.{then,resolve}. The example give
by skywal_l 5y ago
A couple of strange things:
* the use of decorators in even the most basic example
* no async/await. You fall back to Promise.{then,resolve}. The example given is not that clear to me.
* You can't have two files with the same name in different folders??
And in general, for me, the ability to be a little less strict at times makes Typescript way more easier to deal with. It's a 80/20 thing. Most of the time I want type enforced but in some situation, I know it's OK and I just want to move on with my day.
- Asraelite 5y ago> no async/await Doesn't this mean we're basically back to callback hell? This was one of the primary criticisms of Node before async/await was introduced.
- skywal_l 5y agoCallback hell was before the introduction of Promises. Promises tried to abstract away the callback mechanism and it made things a little clearer, but you still had the pyramid effect of successive Promises. Await/Async kind of streamlined all this.
- dsnr 5y agoI still somewhat prefer the readability of promises vs. await. I like the expressiveness of a then/catch as functions as opposed to try/catch blocks, which I‘ve always disliked. But I agree that await is more suitable for more complex scenarios.
- nsonha 5y agoasync/await is just a syntax sugar, most languages didn't have it until very recently when it became a trend or something. In OCAML it's just like any other monad you use the bind operator instead. No need for special keywords.
- lolive 5y agoI will probably be banned from any Haskell forum after that, but isn't the do notation a async, and the <- a await ?
- nsonha 5y agowhat do you mean by banned? You got it the other way around, async is a special case of the do notation, and await is the special case of <-
- Zababa 5y agoIt's basically that. Example: hello.then(a => return op1(a)).then(b => return op2(b)).then(c => console.log(c); const a = await hello(); const b = await op1(a); const c = await op2(b); console.log(c) In Haskell (>>= is pronounced "bind", \a -> is like a => in JS): hello >>= (\a -> op1 a >>= (\b -> op2 b >>= (\c -> show c))) do { a <- hello; b <- op1 a; c <- op2 b; show c } There is a slight difference, in that JS promises aren't monads. But the idea is still here.
- rsrsrs86 5y agodo { a <- m; return r } Ia desugared to m >>= (\a -> return r) Think of it m.then(function (a) return r)
- dmitriid 5y ago> it's just like any other monad Ah yes. The magic word "just". You "just" do something that does something. And yet even the example in the article uses Promise.then and eventual callback hell.
- nsonha 5y agoI have to admit I don't know much about ReScript and only have very basic exposure to OCAML, here is how you do await in it: https://github.com/ocsigen/lwt https://github.com/ocsigen/lwt The `let* in` is a generic syntax for monads, it doesn't need a special one just for promise. This was in fact a debate back when async/await was in consideration for ECMAScript, but special syntax is hip so now we have `async/await` for Promise, `.?` for optionals and `flatMap` for arrays, basically the same thing.
- greyblake 5y ago> the use of decorators in even the most basic example Can we agree that JSX is not a valid JS? So decorators are required indeed to simulate "JSX magic" > no async/await. As I mentioned, it's not an really an issue (although I though it will be). At least from my experience. > You can't have two files with the same name in different folders?? This sucks indeed :) The problem that those 20% corrupt the value of another 80% :/
- MoSattler 5y ago> Can we agree that JSX is not a valid JS? Neither is rescript - so why not make jsx a first class citizen?
- greyblake 5y agoBecause a programming language is not a template engine.
- scrollaway 5y agoNeither is jsx. It’s just syntactic sugar for some recursive function calls.
- yawaramin 5y agoJSX is a first-class citizen in ReScript. No decorators required for JSX. Only required for React component function signature.
- deleted 5y ago[deleted]
- deleted 5y ago[deleted]
- ronenlh 5y agoTypescript is “breath-first,” you can convert your entire project to typescript in a minimal pull-request. Gradually adopting the syntax. ReScript requires a lot of commitment, as you have to completely rewrite each module to 100% comply with the type algorithm. Typescript even transpiles when it encounters type errors.
- greyblake 5y agoYou don't have to. You can have write a single component in ReScript and use it with the rest of the project written in JS or TS. See https://rescript-lang.org/docs/gentype/latest/introduction https://rescript-lang.org/docs/gentype/latest/introduction
- thegreatpeter 5y agoSorry but that's not true. You can adopt ReScript one file at a time. ReScript supports importing and exporting typescript types out of the box so you still get the type safety from "the other side" We started using Rescript by adopting individual files until most of our codebase is ReScript. We still have Typescript lingering around but folks _choose_ to refactor it to Rescript because they've found it easier to work with.
- knuthsat 5y agoNo async/await is a good thing, IMO. Using fp-ts there is never a need for async/await and the code is still linear, (Promise is transformed to TaskEither<Error, Result>, similar to the example in the article, although you can ignore the error and just map over the result, handling the error somewhere near the end of the chain). Problem with async/await is that the syntax is so easy that eventually the whole codebase gets polluted by it, even parts that could have been completely separated. From the coding perspective, the problem with promises arise when there is a need to bind the intermediate results. You can either store them in an object and return that object for the next .then(fn) call, or you can nest inside a promise. I guess nesting is what annoys people the most (pyramid).
- agumonkey 5y agoI think I've heard that underneath, async/await gets desugared into a Task "monad" anyway.
- sergiomattei 5y ago> Problem with async/await is that the syntax is so easy that eventually the whole codebase gets polluted by it, even parts that could have been completely separated. Curious, why is this bad?
- knuthsat 5y agoSometimes you don't want to pause (with await) and give something else the chance to execute (happens a lot in UI). When code is sloppily written you realize that at some point you can't use much of the existing code outside of async. One nice example of polluting the codebase is having async local storage. Now everything that reads from the storage needs to be annotated async and now your initialization pipeline might be insanely async. Good way to avoid it is to read the whole local storage at the beginning (having a sync interface) and then everyone just reads without await. From recent experience, I did exactly that with storage and ended up removing thousands of async annotations that were no longer necessary. Similar "mistakes" happen for other things and then at some point you are putting loading guards everywhere because your async operations are always awaiting and letting the UI update when it should not.
- thegreatpeter 5y agoThere are a lot of stranger things typescript makes you do make things work properly =P Rescript doesn't make you do strange things. The async/await stuff is annoying for sure, but after 3 years of using it, we've kinda forgotten about it.