papauschek

For data-processing-heavy apps you're going to want Scala.

I don't see why Ruby/Scala interop should be more difficult than Ruby/Java interop.

Would love to hear in more detail about your experiences integrating Scala teams and the challenges that come with it.

I only worked in a small team so far (3 devs) and had a good experience introducing Scala, but I can imagine that with people who have previous Scala experience and "their own style" can be problematic.

I talked with Vlad Ureche (from the EPFL Scala Team) about this very topic a few months ago after Scala Days Berlin. He said that some Scala features would not be possible to implement on the CLR because of its restrictive generics implementation. So while JVMs generics type erasure is a pain, it seems to give more room for innovation on the language level.

Unfortunately I did not understand the specific reasons he gave, but it had to do something with reification.

wohoo, ScalaJS, Scala-iOS, Scala everywhere ;-)

Slick is not without flaws. After using it for more than 2 years and following each new release, I ran against its limitations quite often and started looking for other DB libraries that supported some kind of type safety.

But of all the other libraries I tried (jOOQ, ScalikeJDBC, and some others) none of them were as elegant and easy to use as Slick, although some of them are easier to set up.

Right now, Slicks SQL queries are not optimized, so you better use a db that's good at query optimization (i.e. not MySQL 5.6, which will do unnecessary full table scans for some of slicks generated SQL)

Same here.

The article also highlights that adopting Scala often also means adopting a more functional programming style.

That's right. For the early version we decided not to support video entries. But we are counting every request. And it is on our radar. I like the idea of videos as well. I'd like to know what kind of videos you want to share? How long are the videos you currently make?

We are from Wien that's right. :) Hope you had a great time there! At the moment we are in San Francisco. At least until October.

Thanks! design credits go to bbusetti! Tagging is not possible in this version. But we already started looking into that, as we are working on a feature to collaborate with two or more people on the same trip.

Totally get your point! Thanks will pass on the UI/UX credits to bbusetti. she is responsible for the design. In fact we really tasted a lot with older people. My parents now use it a lot, as they can also follow via web and email.

Glad you like it! If you have any feedback then let me know!

Thanks for the feedback. It's great to hear that you're willing to pay for such a service. If you're interested i put you on our list of testers for freemium?!

Thanks for the feedback! Will look into that issue immediately. Find my answer on monetization above.

The business model is going to be freemium. We're currently evaluating different features to decide which should go into a premium bundle. So we're always happy to hear from our users about their problems and limitations of the app. but basically the idea is to charge for additional storage. hth

no doubt, journi is a niche product, as I built it for people on the go. What I saw on FB is that users are tired of people over-spamming their timeline with vacation photos. And other users don’t want to share certain things on facebook because the data might be too private or too spammy for others. And last but not least, it’s hard to recover important moments on facebook. Moments easily get lost in your timeline or your friends streams and stay there unnoticed.

Great to see more and more libraries making use of Scala.JS.

Autowire seems like a first step towards a framework like Google Web Toolkit, where client and server code can be written in the same language. The questions is then, what can we learn from GWT and what can be done better?

Maybe Java was the reason why GWT never became widespread (being less flexible than Javascript with closures and stuff), but this should have changed with Java 8?

Very interesting comparison, thanks for pointing out the advantages / disadvantages of the different implementations.

I can see why the corner cases of CanBuildFrom are perceived as very troublesome, but I have to say that after working with Scala for many years now, this has never been an issue in practice.

I've read this before a couple of months ago. Why post it now when it's now almost 4 years old?

I feel that the Scala community has learned a lot in the past 2 years and I applaud all the ongoing simplification efforts that are being done all over the Scala community. (That's not to say Scala is for everyone)

It's easy to get lost in the type system if you use type-complex frameworks like Slick.

Right now, there are a lot of frameworks to choose from and to evaluate. And there are a lot of "experiments" going on. I think that this will improve as the community matures and settles on fewer ways to do things.

We've been using Scala now for 18 months in production, and I sometimes feel that library designers need to step back and try to not overuse the power of the language.