4 ms·

Oh Vert.x, I despise it. We jumped on that in 2014 (Vert.x 2) and it's still haunting us. Half-broken build with an outdated Gradle plugin (should've stuck with

by minus7 9y ago

Oh Vert.x, I despise it. We jumped on that in 2014 (Vert.x 2) and it's still haunting us. Half-broken build with an outdated Gradle plugin (should've stuck with the official build system), doesn't integrate with the major part of the Java ecosystem due to being callback-based (exceptions can hardly be used, nor can anything that blocks on IO) and tooling for managing tasks doesn't exist either (e.g. running a couple of IO-tasks in order requires you to nest the callbacks if you don't write your own tooling). I assume Vert.x 3 is doing a better job there, but the fundamental problem remains: callbacks don't work well with exceptions. Maybe Kotlin helps wrapping this nicer, I don't know. All I know is that I'll be more careful when selecting a framework for productive use now. And maybe that I won't be using Vert.x again.

zbentley 9y ago
As a Node.js dev: don't hold your breath waiting for better exception support in callback-based asynchronous code. Node didn't really have a procedural legacy; it was always async (sorta), and exceptions are awful to try to reason about with callbacks. Then we got Promises, which made it worse. Now we have async/await, which helps restore typical exception behavior a bit . . . until you have to integrate with any code written in a callback- or promise-oriented style (anything older than 15 months, almost all of the standard library). In general, I think without language-level support for continuations (callbacks, coroutines, promises, async-"colored" functions, whatever), projects like Vert.x are going to cause a lot of friction with regards to exceptions. Having a large synchronous legacy to contend with doesn't help either.
- thenewwazoo 9y ago
  I don't mean this to be flippant: there's a Javascript standard library?
  - eropple 9y ago
    Node has more of one than your browser.
  - Too 9y ago
    Its small but there is one. Thats where you would find stuff like Math, string, json, promise.
- minus7 9y ago
  Actually it can work quite well without language-level support. Python's gevent library [0] shows that. It "simply" monkey-patches the standard library's IO functions to implicitly switch to another "greenlet" when blocking IO is performed. On the user side you don't really see anything of that (no "await" or similar). Admittedly, that hides possible points of context switches, but is still far less dangerous with regard to race conditions than OS threads. Unfortunately, gevent seems to be shunned quite a bit and I haven't seen other languages do similar things. [0] http://www.gevent.org/ http://www.gevent.org/
bdavisx 9y ago
Kotlin coroutines support in Vert.x 3.5 allows you to write "regular" exception handling code inside of a method, it's nice. http://vertx.io/blog/vert-x-3-5-0-released/#kotlin-coroutines http://vertx.io/blog/vert-x-3-5-0-released/#kotlin-coroutine...
- minus7 9y ago
  Oh, lovely. I'll have to check out Kotlin's coroutines in more detail. So far I haven't seen many coroutine/green thread implementations I like. In fact the only one I like is Python's gevent since it's very non-intrusive and often works with existing libraries without modification, whereas Python's async/await or C# (I think) require every part to be aware of the coro (and unwind the stack when suspending)

by minus7 9y ago

zbentley 9y ago

As a Node.js dev: don't hold your breath waiting for better exception support in callback-based asynchronous code. Node didn't really have a procedural legacy; it was always async (sorta), and exceptions are awful to try to reason about with callbacks. Then we got Promises, which made it worse. Now we have async/await, which helps restore typical exception behavior a bit . . . until you have to integrate with any code written in a callback- or promise-oriented style (anything older than 15 months, almost all of the standard library). In general, I think without language-level support for continuations (callbacks, coroutines, promises, async-"colored" functions, whatever), projects like Vert.x are going to cause a lot of friction with regards to exceptions. Having a large synchronous legacy to contend with doesn't help either.

thenewwazoo 9y ago
I don't mean this to be flippant: there's a Javascript standard library?
- eropple 9y ago
  Node has more of one than your browser.
- Too 9y ago
  Its small but there is one. Thats where you would find stuff like Math, string, json, promise.
minus7 9y ago
Actually it can work quite well without language-level support. Python's gevent library [0] shows that. It "simply" monkey-patches the standard library's IO functions to implicitly switch to another "greenlet" when blocking IO is performed. On the user side you don't really see anything of that (no "await" or similar). Admittedly, that hides possible points of context switches, but is still far less dangerous with regard to race conditions than OS threads. Unfortunately, gevent seems to be shunned quite a bit and I haven't seen other languages do similar things. [0] http://www.gevent.org/ http://www.gevent.org/

bdavisx 9y ago

Kotlin coroutines support in Vert.x 3.5 allows you to write "regular" exception handling code inside of a method, it's nice. http://vertx.io/blog/vert-x-3-5-0-released/#kotlin-coroutines http://vertx.io/blog/vert-x-3-5-0-released/#kotlin-coroutine...

minus7 9y ago
Oh, lovely. I'll have to check out Kotlin's coroutines in more detail. So far I haven't seen many coroutine/green thread implementations I like. In fact the only one I like is Python's gevent since it's very non-intrusive and often works with existing libraries without modification, whereas Python's async/await or C# (I think) require every part to be aware of the coro (and unwind the stack when suspending)