Regarding the 'checked exception issue'; an alternative technique to the method-wrapping-lambda is to use a default interface method to implement the non-exceptional interface, which delegates to the possibly-exceptional method. It's a bit fussy, but it's a nice technique to know:
As IOConsumer<T> is also a Consumer<T>, if you can assign the lambda to an IOConsumer<T> it will get this wrapping behaviour automatically. So your code might look something like:
try (Writer writer = new StringWriter()) {
final IOConsumer<String> ioPrinter = writer::write;
// hand ioPrinter off to something that expects a Consumer<String>
}
This is by no means beautiful; for 'writer::write' to be treated as an IOConsumer<T> requires that the target type be IOConsumer<T>, so typically would require an interim assignment. It does allow us to simplify the 'wrapping' method, though, so that lambdas can again be used as one-liners:
It would be nice not to have these wrinkles, but I think Java 8 has done a fairly decent job of preserving backwards compatibility while introducing language features and APIs which feel like a vast improvement. I'd love to see reified generics in the future, particularly if the type parameter can be extended to support primitives.
I was trying to work around this problem also and found this library: https://github.com/jOOQ/jOOL, from the guys at Jooq. They did all the hard work to wrap all the FunctionalInterfaces in unchecked exceptions. Hope this helps.
All this makes me very happy I nowadays work almost exclusively in Scala. No language is perfect, but Scala supports all the things Java 8 does (a few things are experimental until the next release), has straightforward FunctionN interfaces (as the article mentions) in addition to SAM synthesis (I mean, why not just do both?), and while a recent emphasis on compatibility means it's starting to accumulate its own cruft, it at least drops the first ~10 years of Java's backwards-compatibility awkwardness.
And it makes me happy for ditching Scala in favor of Java some years ago after realizing that if you're writing a 2MLOC software that your organization is going to depend on for the next decade, backwards compatibility is so much more important than any language feature (even if that feature is an extremely clever type system that extremely clever developers who like that sort of thing can use to statically prove that their function's argument is always prime).
You do realize that the compatibility issues are binary compatibility, not source compatibility right? It does seem to be the case that many Java project groups are not setup to build their dependencies from source, but for such a large code-base I think building dependencies from source and hosting your own binary repository is probably not a bad idea.
It's (almost) just as bad when you try to manage lots of dependencies.
> but for such a large code-base I think building dependencies from source ... is probably not a bad idea.
That's a bad idea. You want to manage as little code as possible, especially given the already large codebase. It's certainly doable, but in the end you realize the benefit is just not worth the effort.
Of course, that was just a symptom of a far larger problem: It always seemed that when faced with the dilemma of favoring some PL research goal vs. real working-man's use, Scala always chose the former; it was like its real (though not stated) target audience were PL PhDs. It seems the winds have shifted recently, but probably too late, and Scala is already weighed down by too many "PhD" features that need to be removed in a way that would severely break source compatibility.
Say what you want about Java, it's really great for big projects you must depend on and need to maintain for many years.
>It's certainly doable, but in the end you realize the benefit is just not worth the effort.
The benefit of using a language that, at _worst_, is as productive as Java, and at best miles better?
>faced with the dilemma of favoring some PL research goal vs. real working-man's use, Scala always chose the first
Scala is pretty straightforward in terms of features, classifying it as "PL research" is a bit much.
>Say what you want about Java, it's really great for big projects you must depend on and need to maintain for many years.
My experience has been that larger projects end up accumulating so much boilerplate that it becomes extremely hard to manage (I fear that Scala's standard library is becoming like this too, but third-party libs seem to avoid this).
I have trouble finding any non-deployment-related argument against Scala in the Scala vs. Java comparison.
> The benefit of using a language that, at _worst_, is as productive as Java, and at best miles better?
I completely disagree with this. If "productive" means fewer lines of code -- then yes. But for a large-scale project, productive usually means code that another developer can understand quickly, and by that metric I think Scala loses big-time.
> I have trouble finding any non-deployment-related argument against Scala in the Scala vs. Java comparison.
Then either you haven't had enough experience with Scala (not on your own, but in a large team[1]) or you haven't looked. I and many others can list plenty, but I've said much of that before, and you can find a lot of other people's experiences online. In the end, it all comes down to tradeoffs, and you can find many valid arguments for both preferences.
[1]: It can be argued that almost no one had (and neither have I) because Scala hasn't been around long enough, but overseeing development of (non-Scala) software that needs to last for at least a decade, as well as the later evolution of similar projects, it quickly became clear (to me, at least) that Scala isn't a great fit for such projects (at least not for many developers). People had a harder time understanding Scala code that was written by another team member a week earlier than Java code written 7 years earlier. While you certainly can be too clever in Java if you put in enough effort, it's waaay to easy in Scala. You can immediately see how the programmer became too bored of the actual problem they had to solve and decided to amuse themselves by playing with the language. This is something I've seen happen in C++ projects too, but to a lesser extent. I can guess that part of the reason is that when almost everyone was using C++, the internet, and certainly blogs, weren't so widespread and influential, so the really clever tricks couldn't spread so quickly. Also, when C++'s harm became apparent, discipline was quickly enforces in many organizations, and it was much easier to enforce discipline over C++ developers back then, than over Scala developers today, because many of those are cowboys to begin with. Still, maintaining long-lived C projects is easier than maintaining C++ projects, so much so that many wish they had chosen C over C++ when they first began development.
I realize you're trolling, but let me try to explain this (hopefully for the last time): I can certainly understand why people don't like -- or don't choose to use -- the languages I choose to use (Clojure, Java, C). Hell, I can give you some very serious criticism against them myself (Java can become tedious to write, especially if you're working on relatively boring problems, and this might lead to demoralization, which is a very serious issue; in the past couple of years Clojure is also turning its attention to cleverness rather than getting things done, it's also not obvious how to construct and maintain a large-scale project in Clojure, and its syntax is a real turnoff to many developers; C's simplicity often comes at the expense of basic abstractions, like polymorphism, that actually assist in maintaining large codebases and dividing up work among developers, its concurrency story is severely lacking, and its security is terrible). So if someone tells me those languages aren't for them -- for example, hiring young developers and keeping them enthusiastic by using a clever language is more important to them than long-term maintenance of the project -- I get that, I really do.
I also understand that you think it would be a wise decision on the part of Bank of America to write their software in Scala, or Raytheon to choose Scala for their aircraft carrier's C3I system; maybe you believe that a more expressive type system will lead to fewer bugs in such large systems, or that fewer lines of code offset its cleverness. You might think that the extreme lengths taken to ensure you never have to cast a type during collection transformations isn't PL-research showmanship that comes at the expense of code readability and getting stuff done, but a wise bug-preventing measure. But you should realize that people criticize your favorite language(s) for valid reasons. Maybe they have different constraints from yours, and maybe they favor other tradeoffs. Especially given that Scala -- unlike Java, Swift or Go -- was never meant to be "a language for everyone" (and neither is Clojure), it should come as no surprise that not everyone likes it, and for good reasons. Why, those reasons were deliberate! What I find annoying is trying to disown those decisions, deny those tradeoffs, and pretend Scala was a language designed not by professors and PhD students but by industry veterans. Both are, of course, excellent candidates for language design (look at Erlang and Haskell), but each group would choose different tradeoffs, and the languages they produce reflect that. Personally, I think "PL research" languages pave the path to the future and influence "industry" languages, but are often the wrong choice for serious industry projects. Going back to Erlang and Haskell, they're an interesting example because both try to solve kind of the same issues, and they're both superb languages; still, if the CTO of an airport asked me which language to use for their next critical system, I wouldn't hesitate before recommending Erlang and warning -- quite strongly, in fact -- against choosing Haskell.
I'll try to give a short answer, but suppose for the purpose of this discussion that Haskell and Erlang both address the project's initial code concerns equally well. Large, dependable projects, with a long projected usage, have some general requirements that are well-known and tend to be the same for most of them. They include ease of training, ease of hiring, ease of reading and modifying other people's code, ease of upgrade, ease of debugging, ease of profiling, ease of monitoring running software and more. In short, ease of maintenance. Languages built by the industry and designed and used by industry tend to put a lot of emphasis on this, while languages built in academia tend to care more about language expressiveness, code reuse (through graceful abstractions) etc.. Those are important things that matter to the industry too, but not nearly as much as the ones I mentioned. Because language maintainers have limited resources, often one set of requirements comes at the expense of the other. Sometimes the concerns in the latter group can even directly conflict with those in the first; for example, powerful abstractions can become too clever, hard to learn, and hard to understand by reading the code (I think this might be the case with Haskell, but not necessarily so for any hypothetical "academic" language).
Your criteria make it impossible to use a language that came 'out of academia'. The problem is of course that there is no serious jvm language that can really fill the niche that scala has created. If you look at the top libraries/frameworks that are build on top of Scala: akka, play, lift, slick, spark they are radical improvements if you compare them with their java counterparts (if they exist), they deal with very hard problems and manage to make the problem significantly easier to handle.
btw, these libraries are developed by industry veterans & all of them have commercial support. For success stories go here: https://typesafe.com/company/casestudies
> Your criteria make it impossible to use a language that came 'out of academia'.
Well, it would be silly to make such a broad, and hypothetical generalization, but as far as the "academic" languages I've seen, let's say a lot of caution is required before adoption in the industry. See my answer to tome.
> If you look at the top libraries/frameworks that are build on top of Scala...
While I can dispute your claim about most of the libraries you've mentioned, I can wholeheartedly agree that some Scala libraries provide much prettier APIs than Java libraries can. Still, the same can be said about C++ APIs vs. C APIs, and in spite of their elegance, a lot of large projects wish they had stuck with uglier C APIs, because most benefits come with costs attached. I'm not saying that Scala doesn't have any benefits -- it's got plenty. I'm just saying that in the case of Scala, its costs far outweigh its benefits.
The interesting question to me is, can we extract some of the goodness Scala brings without paying so dearly for it? The question is yet to be answered satisfactorily, but I think languages like Kotlin (or Swift, which, from what I've seen, looks very similar to Kotlin) show that this might indeed be possible.
> You might think that the extreme lengths taken to ensure you never have to cast a type during collection transformations isn't PL-research showmanship that comes at the expense of code readability and getting stuff done, but a wise bug-preventing measure.
This is a complete caricature of the benefits of type-safe languages. Why should anyone engage with you when you can't be bothered to look into the (claimed) benefits of what you're arguing against?
1. If you could manage to make a single point without
using multiple strawmen and sweeping generalizations,
people would take you more seriously.
2. Just read your own text. You have made up your mind
(perfectly fine), but you are desperately making up
arbitrary claims to fit your own view (increasingly
ridiculous).
3. Additionally, you are completely unable to refer to
specific instances of what you think is wrong and only
respond with abstract platitudes which could include
everything or nothing.
4. Reading a bit about Scala on the Internet and
repeating it doesn't make you an expert.
You can dismiss my claims (hey, I'm just expressing my opinion), but to make one point clear: I have over 20 years experience writing software professionally (yeah, I got my first paid programming gig at a relatively young age), and I've been following Scala since its initial release. A few years ago I tried switching my project's team from Java to Scala, and the results of the experiment were very negative. True, my hands-on Scala experience (which was rather comprehensive at the time) ended several years ago, but much has changed for the worse since then, though some has changed for the better in the past few years. I don't need to try and switch a ten people team to Scala with every major version in order to make valid claims. What killed us then was that Scala was posing as "a better Java" -- less boilerplate etc. -- while in fact it was "a more complex Haskell, minus all the constraints which make Haskell safe" (in addition there were serious compatibility issues and more). We found that Scala code was less readable, and getting people to understand other people's code was a lot harder than in Java. In short, the language was the exact opposite of what a large scale, dependable project required, so we ended the experiment. Since then, Scala has gotten a lot more complex with even more features.
Also, your insistence that Scala isn't a research language is based on... I don't know what. Unlike, say, Clojure or Erlang, that tried to solve specific software engineering pain points (state management, fault tolerance), Scala started as a research language designed to test a PL hypothesis: how well can FP and OOP mesh, and will doing so be helpful. It also experimented with advanced type systems, and recently with statically typed language. None of the motivations behind these features was an industry problem. No one in the industry said, "you know what, type safe macros is what's going to make our automation control software easier to maintain". Their motivation came from conjectures compiler writers had about novel language features and how they might be used when writing a piece of code. You can deny this all you want, but those are facts. What is opinion is the analysis of the result: I claim that the result is a kitchen-sink language with too many features -- most of them marginally useful when building the next stock-market exchange -- and all of them contribute complexity whose cost far exceeds its benefit, resulting in a language whose net contribution to industry projects (not research projects) is negative. Feel free to disagree. If you think valid claims only pertain to the discussion of the for comprehension syntax, then you should try managing large projects and see that it's the philosophy of the language and combination of features that matters.
You keep making huge claims and sweeping generalizations based on a completely irrelevant version of Scala ("a few years ago" == "not a version which would give any useful information to judge Scala today"), without being able to support any of it with even a glimpse of detail.
At the same time, you come up with requirements where there is just no chance to actual fulfill them, e. g. bashing the language for both being not production-ready before 2.8 (is that even a point worth discussing?) and for rapidly improving on exactly these issues (OMG!!! It is changing too fast!).
I think you should really make your mind up on these things, because you can't have it both ways.
I'm saying this because this incoherent reasoning is constantly happening in your comments, it's not some isolated case.
> without being able to support any of it with even a glimpse of detail.
I'm sorry, but you're just not getting it. I don't take issue with Scala's choice of square brackets over angled brackets. I take issue with the language philosophy and combined set of features. Here are the most detailed details: too many features, many of them overlapping (traits, structural types); too much complexity (type system, implicits); less readable; not enough constraints (e.g. immutability not enforced, casts allowed everywhere). That's as detailed as it gets. All in all, it came out benefits << cost. That's it.
Either you don't want to understand or you think that when Boeing wants to write some big aircraft software thingy they say, "hmmm., the type inference is insufficient for our needs", or, "if only we had non-strict evaluation...". Because that's not how it works. In the industry languages are evaluated as a whole based on the project's criteria, with all their combined benefits weighed against their combined costs. This is what we've done. Scala came out lacking: too much overall cost for too little overall benefit. It was too complicated, too unconstraining, too unreadable, and too difficult to upgrade and build. What more do you want?
> "not a version which would give any useful information to judge Scala today"
No, I'm sorry, but you're just plain wrong! I gave up on Scala some years ago, but I can still tell its evolution has been in the opposite direction from what we wanted. Since then the language has become even bigger, more complex, more obtuse (collections) and even less constraining (macros). Even if the build and upgrade issues are better, the PL research philosophy is still there and its effects are only worse than they were some years ago.
And I wish I hadn't :)
Just kidding. I don't think it's that terrible. And it does have some nice features that other, more industry-oriented languages have selectively adopted -- and will adopt in the future. I just find it utterly inappropriate for the kind of applications we're discussing.
There have been plenty of source compatibility issues since 2.7. Just ask anyone that works at Twitter how long it takes to upgrade between Scala versions.
... You really don't have to follow many links to find out that Sam Pullara is quite a real person, and that he has in fact worked at Twitter. Twitter does, as a matter of public record, have some investments in scala, and I daresay some employees at twitter might have valid practical comments on the outcomes.
Accusing one person of FUD, and then accusing him of sockpuppeting in the same thread, while failing miserably at turing-test level human detection... really, I think this comment does more credibility damage to itself than to anyone it's trying to cast shade upon.
Your reaction is precisely why some of us feel that Scala is not ready for projects that are targeting long term backwards compatibility and are large. A 5 year old release is not prehistoric when you are thinking of building a system for the long term that will be very big. In that style of system you often see corners of the code base that are not touched for much longer than 5 years.
The Scala team has further caused optic issues here by using what appears to be a semantic version number but in no way shape or form following semantic versioning procedures around compatibility breaking changes.
[edit] Further bringing Java 1.4 into this is really problematic as it is past the 10 year mark on age and will run just fine with nearly any Java project right now.
> The Scala team has further caused optic issues here by using what appears to be a semantic version number but in no way shape or form following semantic versioning procedures around compatibility breaking changes.
a) Scala and the major.minor.patch version format predate semVer. You don't get to take the format that a lot of projects are already using and declare that it now has your particular semantics.
b) Scala does comply with semVer if you take "compatibility" to mean "source compatibility", which is the most natural interpretation; the spec talks about API rather and not about ABI.
c) Java's version numbering history is a total mess ("Java 2" is much older than "Java 1.8", for example). I really don't think industry is massively concerned about version numbering schemes.
"a) Scala and the major.minor.patch version format predate semVer. You don't get to take the format that a lot of projects are already using and declare that it now has your particular semantics."
No. The major.minor.patch version format predates either semVer or Scala and Scala's use of it may predate the codification of the semVer standard but most of that standard was very widely spread long before that. Most importantly, the expectation that only additive changes would bump minor versions and breaking changes would be indicated by a major version change has been near universal for a very long time.
Scala to this day, breaks source compatibility with minor version bumps of the compiler. That is not a natural interpretation.
Of course the industry doesn't care about version numbers. You could call it Scala Foo, then Scala Bar, then Scala Waz and no one would care in the least, but having expectations around and controls around source compatibility is very important to a certain segment of the development world and Scala has historically been very bad at that.
I think that Scala has gotten much better in this regard over time, but for a lot of its history it was bad at this. This has made some people rightly leery of using it in projects with long time horizons.
> A 5 year old release is not prehistoric when you are thinking of building a system for the long term that will be very big.
Then enterprises should probably stay away from Java, too.
Java 7 GA: July 2011.
Java 7 EOL: April 2015.
That's not even 4 years.
> The Scala team has further caused optic issues here by using what appears to be a semantic version number but in no way shape or form following semantic versioning procedures around compatibility breaking changes.
Yes, I agree.
I have suggested changing this multiple times, so that the HN peanut gallery isn't intellectually overwhelmed with the epoch.major.minor.patch scheme anymore.
> Further bringing Java 1.4 into this is really problematic as it is past the 10 year mark on age and will run just fine with nearly any Java project right now.
You could also run old Scala code on a current JVM.
_But_ you can also deploy current Scala to a 10 year old JVM, which is not possible with Java.
"Then enterprises should probably stay away from Java, too.
Java 7 GA: July 2011.
Java 7 EOL: April 2015.
That's not even 4 years.
"
You are being either extremely confused or employing a pretty smarmy rhetorical tactic by equating what the thread was about, source compatibility, and jvm support lifetimes.
"I have suggested changing this multiple times, so that the HN peanut gallery isn't intellectually overwhelmed with the epoch.major.minor.patch scheme anymore."
Here you further degrade your argument by:
1) debasing the people who are arguing against you, people who have used and are using Scala currently and historically, just because they have issues with your pet language and
2) belittling the actual issue with using a semantic version number without using semantic version scheme. Some of the high level complaints about Scala include that they don't follow industry standards, that they show a lack of industry experience, that there is no idiomatic Scala way for newcomers to adopt. All of those are in evidence with the way they handle compatibility and versioning. It's not a reason in and of itself to give up on the language, but it is a damning problem that many people have run into many times. Scala is getting better at this but they have traditionally been abysmal so that is small comfort.
"You could also run old Scala code on a current JVM.
_But_ you can also deploy current Scala to a 10 year old JVM, which is not possible with Java."
Once again you are either intentionally changing the goal posts, or are showing extreme ignorance. We were talking about source compatibility. You can count on 1 hand the number of source compatibility issues you will run into with a 1.4 code base and a modern jdk. Even turning on deprecations will leave you with a very small amount of changes that need to be done. This is an extremely valuable property for some projects. Instead of trying to argue poorly against this benefit with bad rhetorical techniques, why don't you just admit what the rest of us know. Java made compatibility a huge priority. That it is a huge priority causes many many issues with the language. For many projects those issues make other languages more appropriate, but for others it is a huge boon. Scala simply made different trade offs, which make it more appropriate for some projects and less appropriate for others.
I am a Scala developer currently and hope they don't try to emulate the compatibility model of the Java world because the kinds of projects I work on are better served without it. But I completely agree with pron when it comes to dismissing it as suitable for a large project with long time horizons.
Finally, another thing I have to fight as a Scala developer in discussing it's suitability is a perception that the Scala community is overrun with zealots who dismiss real industry concerns at the altar of cutting edge features. I think that is a real but overblown concern, but you are displaying all the hallmarks of that caricature. You are making my job harder. Please stop.
Well, if this whining is what you get when a language seems to have some industry appeal, I think I need to work a lot harder to get rid of these people.
You have plenty of language design disasters to choose from if you want to have a language which cares about "industry concerns".
Even in Scala, the most painful warts and horrible "features" exist because of "industry requirements".
I could live without all those crazy conversions from Strings and numbers for instance.
Or all that crazy stuff necessary to support Java's idea of Generics.
Listening to the industry is exactly the reason why criminals can own machines by sending a web request with a bash function embedded in a bash variable to a remote server somewhere. In. 2014.
Until "industry" gets their shit together, their opinions are more than worthless.
So I'm glad we agree that Scala is not a good fit for many projects. No maybe you can stop arguing that it is fine for any project under the sun every time the topic comes up.
I think the compatibility policy has evolved at a sensible rate as adoption patterns have shifted. Pre-2.8 it was a language for experimental, actively evolving codebases only, and it would absolutely have been unsuitable for "a 2MLOC software that your organization is going to depend on for the next decade". 2.8 to 2.9 had closer source compatibility, 2.10 introduced binary compatibility guarantees and standardized deprecation cycles. 2.10 -> 2.11 was completely painless. If you look at e.g. the way scala-actors deprecation was handled, or the testing and infrastructure (e.g. mima) around 2.10-2.11, it's clear that typesafe is taking compatibility very seriously and it is now a language suitable for that "2MLOC software that your organization is going to depend on for the next decade" (not that the system's going to be 2MLOC when you write it in a much more expressive language).
I rather use Java, as I like to take vacations and for the majority of traditional enterprises, JVM == Java and .NET == C# | VB.NET.
So I am not the one bringing new technologies into the project, if the customer didn't explicitly ask for them, even if I enjoy playing around with them.
I don't know, I think VS express is one of few batteries-included dev experiences. What's easy is subjective of course but to me, having to configure an editor to use a compiler (downloaded separately) is a huge turnoff. I agree the .net ecosystem leaves a lot to be desired in aux tools like build system/pkg management, but it's no worse than Java, JS or Python in that respect imho.
> I don't know, I think VS express is one of few batteries-included dev experiences. [...] , having to configure an editor to use a compiler (downloaded separately) is a huge turnoff.
Yep, there are a few others. Netbeans is clearly high on the list of those that tick all the boxes and is still free. It still doesn't come close to the most expensive versions of VS (with ReSharper), and IntelliJ, but those don't compete in the free tier.
Ms finally clued in that their big missing feature wasn't yet another fancy-shmancy framework full of god-classes, but a decent OSS community. They've been making great strides with NuGet, open development of ASP and EF, etc. A lot of ground to catch up on that front, but the cathedral is finally opening up the courtyard.
You don't have to work in a traditional enterprise to get good conditions. I work 7-hour days and have 25 days' paid holiday / year (plus public holidays).
Of course I try to use appropriate technology for given requirements. But if language X lets me solve the same problem in a clearer, more expressive way than language Y, and satisfies all the requirements, why wouldn't I use language X? The customer is the business expert, I'm the technology expert - I should be collaborating in the technology choices, not relying on them to make technical suggestions.
To my mind Kotlin means paying most of the costs of using Scala, but getting fewer of the benefits. You're using a more obscure language that's harder to hire for, has a smaller (idiomatic - obviously both can use Java libraries) library ecosystem, is less mature, less well supported in tools (both at build time and at run time e.g. NewRelic), and so on. And many of the features that are simple and general in Scala become a number of special cases in Kotlin, e.g. implicits.
But it's way easier to set up than Scala (for Android), at least out of my experience. It works well and nearly out of the box in Android Studio; after all, it comes from the same company that does IntelliJ, which AS is based on. Not such a bad support in terms of tooling.
I wouldn't advocate it for production yet, I agree. I started using it for personal projects, though, and so far its lack of maturity mostly shows in documentation and harmless quirks. Not outright bugs.
It's 100% interop ensures that you can only implement bits and pieces in Kotlin, not necessarily the entire app. So you don't have to jump into it head first and commit yourself entirely.
Personally I would use it for bussines logic where the lack of LINQ / Streams / lambdas is hurting code readability. It is also very useful for plain data objects, since it removes so much of Java's verbosity.
> But it's way easier to set up than Scala (for Android), at least out of my experience. It works well and nearly out of the box in Android Studio; after all, it comes from the same company that does IntelliJ, which AS is based on. Not such a bad support in terms of tooling.
In IntelliJ at least, Scala "just works" out of the box. And IntelliJ is the tool that you'd expect to have the best Kotlin support, since as you say it's made by the same people. What about third-party tools - New Relic, or Takipi? What about third-party frameworks? (e.g. there's a wicket-scala project - it's not perfect but it takes a lot of the pain out of interop. I haven't used spring-scala but it seems like the same kind of thing)
> It's 100% interop ensures that you can only implement bits and pieces in Kotlin, not necessarily the entire app. So you don't have to jump into it head first and commit yourself entirely.
Scala's interop is actually more complete than Kotlin's - without existential types you can't express some types that it's possible to write in Java (e.g. nested bounds like <? extends T<? super...).
> But I'm already happy with the advantages Kotlin has over old Java, Android's Java. It's fancy enough.
If there were maturity or ecosystem advantages to Kotlin then I'd agree - after all, that's the reason I use Scala rather than Idris :P. But like I said, it seems to come with all of Scala's disadvantages, and fewer of the advantages.
And there's an element of the "blub paradox"; when I first started using Scala I wrote code that was more or less "Java without semicolons". Then I started using options. Then I started using case classes. Then I discovered that I could use the for/yield syntax to express some "wrappy" problems much more elegantly. Then I needed to make this work for collections, and I could abstract that. Then I discovered I could reuse the same code to handle a bunch of different abstractions, and that Scalaz already contained the most useful ones. And so on. Even today (after four years in the language) there are corners of Scalaz where I fear to tread, but at this point I'm confident that I'll need them sooner or later.
> In IntelliJ at least, Scala "just works" out of the box
Not for Android, unfortunately.
There are plugin issues and it doesn't cooperate with Gradle all that great. I admit that I wasn't able to set it up :) okay, I wasn't hellbent on it and didn't try for days, but it was a bummer.
Otherwise I'd be using Scala gladly - after all, you can write Scala for living, while I don't expect Kotlin to appear in job ads anytime soon.
The sooner Gradle and Android Studio lets us to use Scala or any other language we want for configuration, the better. I don't like being told I have to use Gruvy because I want a nicer DSL than XML when virtual every programming language has nicer syntax than XML.
Fair enough. When I last worked on Android it was all eclipse/maven-based, and using Scala was as simple as just doing the obvious thing (I mean, you had to install the relevant plugins, but that was all). Shame if they've lost that in the move to Android Studio.
While this is a valid point (although the comparison is probably outdated) we should keep in mind that years ago, Scala 1.0 (or something like that) was were Kotlin might be today.
There are reasons why Scala evolved from a "better Java".
Single Abstract Method. Allows you to use a lambda (i.e. a FunctionN) as an implementation of any interface that defines a single abstract method (if the signatures match), just like you can in Java 8.
To a large extent C# is basically Java 2.0, what you might build if you were starting a broadly similar language/runtime project after watching a few years of the first one (the initial release was about 5 years later, 2000 vs. 1995). The language is pretty nice imo, and I'd choose it over Java. But the runtime situation is somewhat worse if you need cross-platform support— the JVM is better than Mono overall. So I'd pick C# over Java iff you can use the official Microsoft runtime, i.e. you don't need cross-platform or open-source.
Can someone please define for me what exactly 'interface pollution' is and why it's so bad?
Because I read this article, and the article from the Jooq blog he references, and I can't see anything beyond one guy's preference for one thing, and Java 8 does it the other way.
We already have this 'explosion' in Java-land. What's the difference between interfaces implemented as a lambda and... interfaces with a single method implemented as an inline anonymous class? Which is effectively what these 'lambdas' are syntactic sugar for. It's still an improvement for Java the language.
I have tried to make that point but usually I'm told it's impossible ir unnecessary.
a compromise would perhaps be to allow at least reified primitive generics so that List<int> would be a proper runtime type whereas List<Object> would be the runtime version of all reference types in List<T>.
Obviously, this would be a half-assed solution unless custom value types like point structs would also be allowed without boxing in similar scenarios. I'm not sure but I think that these things need pretty significant changes to the runtime.
My conclusion is that Java doesn't need this. It won't be elegant no matter what amount of lipstick is added. I even think some of the current features like lambdas are overkill. Instead, features should be added at the vm level to allow for other jvm langs to use them. A good functional language with good generics over primitives and proper value types would be awesome. F# is a good example of such a language (scala and clojure aren't)
> a compromise would perhaps be to allow at least reified primitive generics so that List<int> would be a proper runtime type whereas List<Object> would be the runtime version of all reference types in List<T>.
This is actually pretty much exactly what the .NET runtime does. All value types get a separately-JIT'd version of the type, while all reference types share the same Object-based version. See section on implementation here:
Interesting. Curious to see if they choose exactly the same approach to e.g. value types as the CLR and C# teams did. In C# it feels like there are very few places where choices could have been made differently.
Something I really miss in C#/Java is a possibility to opt out of GC and use more stack allocation.
Java's value types will be immutable, while in C# I believe structs are mutable. This is a very important difference with serious implications to concurrency.
> Something I really miss in C#/Java is a possibility to opt out of GC and use more stack allocation.
The tradeoffs are often not what you think they are.
Mutable structs in c# are rare, rarely useful and often dangerous, but in some perf critical scenarios that hack is needed. Most notably the standard List<T>.Enumerator is a mutable struct because othrrwise an object would have to be created on the heap for the sole purpose of iterating a list.
Not sure whether this was actually one of the reasons for allowing mutable structs to begin with, the use case is critical enough that it might well have been.
Yes and you do things in Java like create an MyIntCollection to get around the shortcomings of generics wrt. primitives, but the point is that it is just that: workarounds.
What I really want is for perf to be good while the code is still clean/readable/expressive/idiomatic. In Java/C# you must usually write idiomatic+slow and then refactor into fast kludges.
I'd say that's always the case. Performance for the vast majority of code is good enough with idiomatic or even horrible code. Places where you need to work against the language for perf reasons should be rare (and if it concerns most of the code in a project, then I'd question the choice of language for that project). Also that holds true for most languages. Even in C you'll avoid allocations in tight loops that need to be fast because it comes with an unpredictable performance cost. That's not much different than pre-allocating a buffer to work on prior to an algorithm in C#.
Agree it's always the case regardless of language, but it's about moving that boundary where you have to leave idiomatic and make something less readable in order for it to perform.
As an example, C#'s value types and generics with primitives makes that a lot better than in java.
