justthistime_

The thing is that while Scala's main focus is not on being "a slightly nicer Java", it does that job fairly well.

There just doesn't seem to be a good point in using Kotlin, as you can tell from how fast the Kotlin proponent in this thread is changing the frame of reference.

- Higher-kinded types? Better compare with Haskell!

- Compilation speed? Let's pick Java, the language with the least useful typesystem!

- Popularity? Let's compare Scala with Java, but compare Kotlin to Scala!

- Commercial backing? Let's conveniently ignore that the language lives by the cross-subsidization of JetBrain's IDE business, instead of relying on the success of their language.

Point is, there is nothing that Kotlin does substantially better that would give it a niche between Java and Scala.

- Non-incremental compilation speed is not that much faster compared to Scala, and substantially slower than Java.

- Most of the things regularly used in Scala cannot be expressed in Kotlin, it only makes Java idioms slightly nicer to write down.

- Like in Scala, IDE support is ongoing work.

- Compared to both Java and Scala, the ecosystem isn't there.

Compared to Scala, Kotlin makes you pay 80% of the cost for 20% of the benefits.

I predict that future Java releases will keep cannibalizing Kotlin from the bottom, while Kotlin will fail to attract developers from more expressive languages.

Absolutely. I think persons in charge will think at least twice before raiding an event organized by the people writing opinions for the Federal Court of Justice.

Given the amount of weed consumed, I think the copyright infringements would be the smallest of their issues. :-)

While I agree with many points in the video, it feels kind of disheartening to me how many people just wave it around as if it could be used as an attack against the language and its community.

(A general observation, what you say here is totally fair.)

Of course the video is about Scala, but the problems mentioned are widespread throughout the industry.

What most of those people miss is the fact that Scala is sometime light years ahead of figuring out hard problems. The things considered to be an issue in Scala is often stuff that hasn't even been considered elsewhere.

The video is now 2 years old, and in terms of Scala, that's a lot of time. The strength of the language and the community is that it can adapt pretty fast, and many issues have been/are being addressed.

There are plenty of libraries out there which experiment with different approaches to collections, there is a new, faster and cleaner backend, the new compiler is shaping up nicely, the new IR will solve a lot of binary compatibility/cross compilation/Scala<->Scala.js issues, and scala.meta seems to become one of the best metaprogramming abstractions in languages.

Things are working really well in Scala, so if you have any question or concerns, feel free to voice them, and I'll give you my 2 cents about what's happening in that space! :-)

> It strikes me that bringing functional programming to the JVM can / has been done simpler: Clojure being the obvious one, but F# on the CLR is another good template.

Scala's FP is more expressive than all of them, by a large margin. Additionally, Scala also supports an useful OO system, unlike for instance the stuff F#/OCaml/... ships.

> It's all very well having some new great language on the JVM, but simplicity is a huge virtue if you want people to build an ecosystem around it.

You realize that Scala has probably the largest, and most meaningful ecosystem of all (non-Java) JVM languages, and is driving a lot of the changes in the Java and JVM space? (Reactive streams, value types, specialied generics, ...)

[...] it was so mustache-twirlingly out of touch that it could have been from the Hacker News.

FTFY :-P

Not sure you understood that.

I've been doing this for a while, after being sick of all those poor quality JavaScript frameworks and it works perfectly fine.

Usually the "main" JavaScript framework code is bloated, but kind of working, but as soon as you need some add-on or extension you are entering bug hell.

I'll just write the code in Scala, and have the assurance that it works without having to deal with unmaintained, bug-filled JavaScript libraries.

> be concise but still expressive, toolable, as fast as Java, easy ramp-up time, and very important, interoperable with all the existing code base we had

... and when you went to the Scala developers, they said "no, we aren't interested in such improvements at all, even if you implemented them yourself"?

Hard to imagine...

I think you are missing the motivation behind some of these things:

Oracle would probably never have started to experiment with value types and specialized generics, if Scala didn't take the plunge and implemented, tested and shipped it years ago already.

Of course there are restrictions... but the choice was basically either never getting value types and generics, or accepting some restrictions until Scala drags Java into the 1990ies.

It's the same with extension methods. If the only thing you ever knew where extension methods, they would look pretty exciting. But after being aware of the full range of approaches, extension methods are "meh" ... they only implement the least useful part of implicits.

If I had to decide between extension methods and nothing, I'd pick nothing. Extension methods are just not pulling their weight.

Scala does a lot of things in a certain way, because the have > 10 years of experience experimenting with various approaches.

I suggest that you try to understand _why_ Scala does things this way, instead of assuming Scala devs are stupid. It's pretty likely that everything Kotlin does has been considered by Scala developers 5 years ago already–and discarded because better designs were discovered.

I think you see for yourself where your example falls apart.

That sounds like a horrible idea in both cases ...

Yeah, I'm really getting tired of these imbeclies.

It's really convenient how they switch to _SECONDS_ on the x-axis.

Sorry, if they need an y-axis in seconds, GC is far from solved.

Some people like a browser to be a browser, not something which grows into a poorly engineered, sand-boxed, slow operating system inside of another operating system.

Sorry, I just don't trust JavaScript developers that much.

> Stop using internal API's

So what's the alternative? It's not like people are using sun.misc.Unsafe for the fun of it.

Java 8 support will run out in a while.

I'm pretty sure it won't "be around for long enough" except if you decide to stay on unmaintained versions full of unfixed security issues.

Why should third-party libraries pay for Oracle's technical debt?

Looks like they are trying to exhaust all possible bad ideas, before picking the solution that works.

I expect that they don't even know what works yet, because NIH and "it didn't exist in the 1970ies".

> OpenGL is an open standard, and has an open-source implementation by the name of [Mesa](http://www.mesa3d.org/).

I think that's kind of misleading. Mesa lags years behind any current OpenGL standard.

No. Scala neither needs to compile dependencies, nor does it need to recompile everything on a change.

The first compile might take a bit, but after that all changes are usually incrementally compiled in less than a second.

That gave me a good chuckle.

> I don't think Go is really about catering to hordes of cheap junior devs

Rob Pike disagrees with you.

It's more functional than most languages called "functional".

> Then you have the compile speed issues, the problematic tool chain [...]

Did you ever use Haskell? Those issues are far worse in Haskell than in Scala.

You just hear more people complaining about Scala, because it is used, while Haskell projects are usually not developed and maintained anymore after the author finishes his PhD.

Exactly. It's not like we don't know plenty of mistakes yet, which will bite them a few years down the road.

> The way to get Apple's attention is for Google or Firefox > to develop a superior browser and browsing experience on > Android, that users take notice is missing from iOS and is > regarded as a USP for Android.

I think not suffering from websites saying "sorry, iOS is not supported" qualifies as a superior browsing experience.

So there will be basically no change to the status quo?

Looks like Kotlin will join Ceylon in terms of promising things and then failing to ship them. Post-1.0 Ceylon is still breaking compatibility.

> This sentiment is incredibly anti-intellectual.

Yeah, he keeps trolling various discussions with his "Java is the best thing ever" chants.

+1.

If I wanted a worse-is-better language to work with worse-is-better developers, I have plenty of languages to choose from.

Personally, I prefer using a good language. Judging from all the butt-hurt responses some people here think that I'm not allowed to. I wonder why.

I guess I must have been dreaming when seperate compilation fell apart in Koltin recently due to backward-incompatible changes.

Seriously?

The same people who couldn't maintain their fork of Unity are now writing their own home-grown runtime, complete with their own garbage collector.

I don't see a chance of this working out "well" for any sane or bizarre notion of "well".