Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Elixir has gotten this down perfectly.

I always wished js was sync by default and only async when you tell it to. Now you have the words async/await (and not too long ago promises, bluebird, waterfall), spread out all over your code for that since you only need async perhaps less than a quarter of your code base. but i dont see js ever becoming procedural first anytime soon.

then I discovered Elixir, i was curious to see how they tout their highly concurrent functional language solved this issue. and surprisingly its as simple as wrapping a block of code inside an async block. its such a pleasant experience finally having best of both worlds, especially coming from years of callback hells and trying to debug what becomes a set of spaghetti code for performing simple things.



>I always wished js was sync by default

I am confused by this. JavaScript is synchronous and blocking by default due to its single-threaded nature as far as I know?

Sure, async will yield different behaviors for functions than without that decoration but that's a very new language feature.


> I always wished js was sync by default

`let res = await someAsyncOperation();`


so, i was hoping for not even having to type in async/await and make this possible: let res = someAsyncOperation()

and whenever you want an async operation (non-blocking), thats when you do something like:

async { let res = someAsyncOperation() }


I'm not sure what that's supposed to solve since you want to handle error/results at that top-level `async` in your example.

For example, in Javascript, you would often just have a top-level async function and stay inside async world the whole time.

Putting your example in the middle of some random code can already be done by calling a promise but not putting the downstream code inside its .then() block.

One of the nicest things about Javascript is the absolute simplicity of its concurrency model, one of those perks coming from its single-threaded nature. I look at something like C# and Kotlin with their BYO await semantics as something I'm glad Javascript doesn't have.


I agree with this - everything should be sync first and async when needed with a keyword (similar to how Go has goroutines and channels, coincidentally this is how UNIX executables and streams traditionally worked). Javascript gets it just exactly backwards. Going from imperative to functional programming is like leveling up, and it's very hard to go back down to mutable variables, side effects and nondeterministic flow control. So I understand why Node devs prefer async how it stands now, but it's hard to unsee Go/Elixer/Erlang once it clicks.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: