Multiple Scala-lang questions

Arnaud Estève

unread,

Oct 9, 2016, 10:17:47 AM10/9/16

to vert.x

Hello Jochen, hello everyone,
I'm currently in the process of learning Scala mainly for cultural purposes and learning it in a well-known (comfort-zone) environment would be easier.

So, thanks a lot for your work, that's greatly appreciated.

Question 1 :
How can I set-up a project using vertx-scala (early access) using sbt ? I'd be very happy to help debugging or giving an "end user" point of view !

Question 2 :
Are there utilities to deal with Scala built-in patterns ?
When reading the Scala in Action book, I found some useful patterns I'm used to deal with in Vert.x. For example : Either seems to fit AsyncResult very well. Did you manage to do this mapping with codegen ?

If not, would a small extension library over io.vertx.scala.core.AsyncResult (or Future) be interesting in your opinion ? I think writing such extensions are a nice way to dive into a new language. Wdyt ? Are you interested ?

Thanks again Jochen. Let me know what I can do to help you from a "Scala newbie but Vertx experimented developer" point of view.

Jochen Mader

unread,

Oct 9, 2016, 1:31:40 PM10/9/16

to ve...@googlegroups.com

Hello Arnaud,

Scala-support is already pretty usable right now. If things go well we will release it with 3.4.0 without any further API-changes.

To get started I'd suggest to take a look at my sbt-quickstart-project (which will later on be moved into the vertx-repos): https://github.com/codepitbull/vertx-scala-sbt

Take a look at the README and start coding.

You might also want to take a look at the language-project itself: https://github.com/vert-x3/vertx-lang-scala

About your questions:

Question 1:

see above :)

Question 2:

We decided to go full-Scala and adapted Vert.x accordingly. You won't find any AsyncResults as they all have been mapped to Futures. There is als a VertxExecutionContext which is implicitly available if you extend your Verticles from the ScalaVerticle.

I am looking forward to your (and everybody else who jumps on :) ) feedback. Just test it and tell me what you think. the more problems and bugs we catch before the final release the better.

So far it really looks like I will be done with everything for Vert.x 3.4.0.

CU

Jochen

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/4beecc98-c9c3-42d2-a88b-00ec64ce3acd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Jochen Mader | Lead IT Consultant

Arnaud Estève

unread,

Oct 9, 2016, 2:45:53 PM10/9/16

to vert.x

Thanks, I forked the repo and am starting to implement the todomvc example, it's a good way to start.

Where should I ask questions ? Is this fine if I ask them in this thread ?

You told me you went "full-scala", does this mean Futures are Scala Futures and not Vert.x Futures ?

Because in the expression : override def start(startFuture: Future[Void]): Unit

Future is io.vertx.core.Future, so I guess I'm completely missing your point :P

Thanks !

To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.

Visit this group at https://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/4beecc98-c9c3-42d2-a88b-00ec64ce3acd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Jochen Mader

unread,

Oct 9, 2016, 2:57:06 PM10/9/16

to ve...@googlegroups.com

That's actually the only place where I still have a vert.x-Future. That's because I extend this class from the Verticle-baseclass.

I don't know if it would be good to divert here.

Will check how the other lang-implementations are handling this.

To unsubscribe from this group and stop receiving emails from it, send an email to vertx+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/ad1d36c6-9855-43d0-864c-213b880bbaa7%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Arnaud Estève

unread,

Oct 10, 2016, 2:52:10 AM10/10/16

to vert.x

OK cool :)

Not sure other implementations have the same issue actually. Maybe only RxJava has this kind of mapping to native language features. I don't think js implementation targets Javascript ES2015 + Promises.

I'll try to build the doc locally unless it's already deployed somewhere, 'cause I don't understand how to instantiate objects like HttpServerOptions and stuff.

Thanks for the help.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/ad1d36c6-9855-43d0-864c-213b880bbaa7%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Arnaud Estève

unread,

Oct 10, 2016, 2:58:19 AM10/10/16

to vert.x

Actually I don't even need to : https://github.com/vert-x3/vertx-lang-scala/pull/10 helped me. I think I'm good to work now. We'll discuss the implementation as soon as I'm finished porting https://github.com/aesteve/vertx-kotlin-todomvc to Scala.

Jochen Mader

unread,

Oct 10, 2016, 10:42:39 AM10/10/16

to ve...@googlegroups.com

Great!

A little sidenote: I took your suggestion and refactored the ScalaVerticle to use scala.concurrent.Promise. This is part of the currently open PR and should be available in the SNAPSHOTS soonish.

To unsubscribe from this group and stop receiving emails from it, send an email to vertx+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/e8229c82-7e37-40c3-bc3d-42618cd2f1d5%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Arnaud Estève

unread,

Oct 10, 2016, 12:56:06 PM10/10/16

to vert.x

Here you go

I struggled a lot but I guess this is normal. I annotated with FIXME / TODO / QUESTION the places where I think something might be missing in vertx-lang-scala.

Please correct me where I did some stuff wrong, or not scala-ish, I'd be very heppy to have feedback. (open issues, this is maybe the best way)

I still have a lot of trouble with implicits, I'm pretty sure there is alot of elegant stuff we could do with it (like automatically failing the routingContext, etc.).

Also the VertxExecutionContext implementation seems weird (at least in the snapshot I downloaded), it does nothing but runnable.run() and e.printStackTrace is this normal ?

Thanks for your help, hope this will be useful

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/e8229c82-7e37-40c3-bc3d-42618cd2f1d5%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Jochen Mader

unread,

Oct 10, 2016, 4:48:16 PM10/10/16

to ve...@googlegroups.com

The best way to live with implicits is to ignore them :) Use the ScalaVerticle, it takes care of the things you need.

implicits are also dangerous things and I am currently not planning to introduce more than the VertxExecutionContext.

About the VertxExecutionContext: All executions are done on the Vert.x eventloop. All actions are enqueued with the correct thread, that's what Vert.x takes care of. The execution context therefore doesn't have to worry about such things.

You won't have to use the VertxExecutionContext directly, Vertx-Scala takes care of everything and you can simply work with Future/Promise inside a ScalaVerticle.

I won't have time until Wednesday to take a look at your code but I will try to give you some feedback then.

To unsubscribe from this group and stop receiving emails from it, send an email to vertx+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/717f27ad-93d4-4a71-9de6-3ecbee3f857f%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Arnaud Estève

unread,

Oct 11, 2016, 3:28:33 AM10/11/16

to vert.x

Thanks for the insight. Next step is to implement different types of services instead of a simple map. (VertxLocalMap, VertxClusteredMap, Mongo, Redis, JDBC). That should be an exhaustive tour of the different modules. If TodoBackend works for all these implementations, we should be (almost) fine.

But there's something weird though :

As soon as I leave the ScalaVerticle class (and this will happen all the time, as soon as your application grows and you're organizing logic within traits), you have to deal with an ExecutionContext.

Not sure how this is handled within jdbc-client, mongo-client, etc. But within my own map implementation, simply using futures for the matter of respecting the "async" contract, I had to define an ExecutionContext.

Either passing it as a class attribute, or using the scala default one (which I should avoid at all costs I think). I don't know how to deal with this situation properly.

In my mind, if my code (dealing with futures) is only called from a scala verticle the compiler should know that there's an execution context and leave me alone. But it's not the case in my code the compiler complains. If it's really the case for users, it's gonna be a pain to either forward the execution context to every class or put every logic in a Verticle... But once again, there must be something I'm missing.

See you wednesday then. Looking forward to your comments.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/717f27ad-93d4-4a71-9de6-3ecbee3f857f%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Arnaud Estève

unread,

Oct 21, 2016, 4:55:28 AM10/21/16

to vert.x

Let me know if there's something else I can do to help you Jochen.

Did you by any change give a look to the todobackend implementation ?

Reply all

Reply to author

Forward