justthistime_

No, I don't think you understood it. There is a large qualitative gap between what you propose, and what Scala does:

In Scala, it is an _one_ time effort to make String act "like" collections, while the only solution Kotlin provides means doing the work manually _n_ times: At every call site of the string in question.

Kotlin developers also didn't feel like your point was too convincing: https://github.com/JetBrains/kotlin/blob/master/libraries/st...

I think you got all of that pretty mixed up.

- Implicit resolution can be slow, because you can make the compiler do arbitrary work for you. This is completely unrelated to implicit classes themselves.

- Scala had the option to either not ship value types at all, or support only a limited subset of things that can be made work well under the current restrictions. If Scala didn't ship value types, the JVM would have probably never gotten them. You can thank Scala developers later for dragging Java people into the 1990ies.

- Extension methods looks totally cool on paper, but are pretty much useless for writing maintainable, readable code, which also does something useful:

    Dev:    "Ok, I want to be able to use String as if it 
             was a collection of chars."
    Kotlin: "Sure, just implement all the collection methods
             one-by-one."
    Dev:    "But, but ... all implementations I need are
             already implemented in that trait over there?"
    Kotlin: "Bad luck, I guess. You could of course just
             delegate all your methods to that trait."
    Dev:    "But then I would need to create a real instance
             of that trait first which implements the missing
             abstract method ... that's more boilerplate than
             just copy-and-pasting the code?"
    Kotlin: "Yeah, you have to decide whether to write a
             short implementation on your own or pay the
             price for sharing common pieces of code."
    Dev:    "... <much later> ... ok, I now implemented all
             all the methods of the collection interface of
             my own ... I guess ... the compiler will warn me
             if I forgot to implement a method from that
             interface or messed up a signature, right?"
    Kotlin: "No."
    Dev:    "I just tried passing my String to a method
             expecting a collection ... it doesn't even
             compile?"
    Kotlin: "Just because you went to all the trouble to make
             String act like a collection doesn't mean it's
             supported as soon as abstraction enters the
             picture."
    Dev:    "So I can write cute things like myString.map(...)
             but as soon as map(...) is moved to a method,
             I have to overload that method to accept both
             Strings and collections?"
    Kotlin: "You could also just write a
             StringCollectionWrapper and wrap every String
             in that when you need it."
    Dev:    "I guess the compiler will figure out when I need
             to wrap it?"
    Kotlin: "No, you have wrap it manually every single time."
    Dev:    "So extension methods are basically just syntax
             for writing static methods in a nicer way?"
    Kotlin: "Can you please stop asking questions while I
             waste your time?"

I think the whole comparison with C++ just demonstrates the author's lack of research.

People who think that – in the end of 2015 – everything we need is a slightly nicer Java show an scary lack of insight and vision.

It seems that Scala has much more uptake on Android than Kotlin will ever have.

As we have seen in most milestones, Kotlin is gradually moving closer and closer to Scala, because even they realize that "a slightly better Java" won't cut it in the mid-/long-term.

Use tools which translate from Java 8 to Java 6 bytecode and be careful to use only Java 8/7 classes? (IDEs help with that).

They have way too many "oh, people could maybe need this" features, which are completely redundant, just to save a line of code somewhere.

Not sure I get your point. I would both prefer a language which either had 20% of the futures and 20% of the cost, or 100% of the futures and 100% of the cost.

In Kotlin you get stuff like extension methods, which bear almost all the costs of implicit values, but don't support most use-cases you would use implicit classes for.

Just because they didn't do their research doesn't mean it's not a no-brainer.

> it requires build complexity

All languages benefit from not having to deploy their standard library on every iteration, not only Scala.

It's easy to say "Kotlin has no projects with poor documentation" when it doesn't have many projects at all. :-)

I think Scala library authors would love some links to those things where you consider the documentation to be lacking.

To me it feels Kotlin paid 80% of the cost of features, but got only 20% worth of features.

You could also just use Java.

There so many things different in C++' approach compared to Scala that your whole comparison is disingenuous to begin with.

I think

    I believe that such claims are unwarranted,
    mostly coming from beginners with a superficial
    understanding of the language

fits fairly well here ...

I'd say yes. The whole weak conformance stuff is terrible, not well-designed, and (in Scala) only exists for "Java compatibility" (the worst reason one can think of).

Things which silently throw away precision, change values and semantics in dangerous ways should never happen automatically.

Are there any stats regarding the work that goes into the "IDE/editing" components vs. the amount of work on Eclipse as a modular, pluggable AbstractFactoryFactory platform for random companies to add their proprietary stuff on top?

As a long term user it feels like no one from the Eclipse project actually uses Eclipse to write code anymore.

> it Just Works

That's what I'm praying for every single day before I start Eclipse. Sadly, Eclipse keeps inventing new ways in which it breaks.

> Akka is essentially an actor library bolted onto a VM that really doesn't like what it tries to do.

Given that it already beats the shit out of Erlang, I can only wonder what would happen if the Hotspot guys added a little bit of additional support ... :-)

The whole problem with NULL is that practically no one can use it correctly.

I think your failure to use Option correctly cannot be blamed on Option alone, given that many people use it successfully.

You continue to amuse me.

> This is where I lost a track of your arguments.

Then maybe you should maybe spend some time studying these topics instead of acting up on HN.

> Lisp did not fail. It's in pretty much all the mainstream languages now.

This is where I lost the last doubts about the reality and your lack of closeness with it.

Your whole comment tells me that you are completely unaware of how macros in Scala work and how they are developed further.

Type systems are by-definition only a conservative approximation of all programs.

The good thing is that 99.999999999999% of all programs never need to be written, and there are plenty of type systems which deal well with the last 0.00000000001.

> No, it does not.

Ok, that leaves the failure of Lisp outside of hobbyist mom's basements a mystery.

The strength of a type system is that there is one. If everyone uses his/her own self-made pet of a typesystem most of the benefits are gone as soon as you are more than a one-man-hobbyist project.

Probably explains why most Lisps consist of one-man-hobbyist projects, though.

Python's days have come and gone.

Computation has grown more complicated. They need real computer scientists and a real language that supports real development, not some scientists which learned just enough Python to automate running some 20 year old Fortran code.

The module story is pretty comparable and many things can be translated directly between OCaml's module system and Scala's.

With the module being roughly equal, and while objects suck in OCaml, but don't suck in Scala, I'm kind of surprised by your judgment.

Which languages have better IDE support than Scala?

Java, C# ... and both received probably hundred times more man-power than Scala IDEs.

What else?

My experience: All dynamic languages – probably not. C++? Hell no. F#? No. OCaml? No. Haskell? No.

Which language do you think of?

What makes you think that Scala has no macros?

Scala is more functional because it encourages immutability more strongly and allows better abstractions like typeclasses, higher-kinded types while being roughly even on the modularity front with OCaml (there are a few things easier done in OCaml and a few things easier done in Scala) and beating the shit out of F#.

Not having a separate module and object system is another plus when compared to OCaml.

It unifies OO and FP better than OCaml and F#, because OO implemented in OCaml and F# feels like the designers tried to make a point about how much they dislike OO. What's the first thing OCaml/F# devs tell others about OO in their langauge? To avoid it.

> I'm genuinely curious about one point, though: How is Walmart a "real business" vs Twitter?

  - One of them actually earns some money from time to time.
  - If one of them disappeared overnight, it would have some impact on peoples' lives.