Hacker News Reader

Comment by eloisant | Hacker News Reader

It feels to me like a better Java, but still very limited compared to Scala. It stays very much in Java's paradigm.

So while Scala doesn't have to fear Java's evolutions, Kotlin seems to be risking obsolescence when Java gets good enough - and it's already happening with Java 8. Just look at the article: they talk about Kotlin as a good language for people stuck with Java 6.

View on HN

Compared to Java 8 Kotlin still has quite a lot to offer:

* Type-safe DSLs

* Named parameters with default values

* Non-nullable types

* Raw strings (which make working with regular expressions quite nice)

* Type inference

* Properties

* Smart casts

* the when keyword which is much better than using switch statements

* data classes (very nice when working with APIs which expect Java beans)

* a lot of stuff I probably forgot

first-class functions is another big one

That was the headline feature of Java 8.

Java functions are still not first class. The headline feature of Java 8 was lambda function, which arguably isn't first class either (they are implemented as instances of object subtype, so essentially still is object nonetheless)

They also don't close over their parent scope.

  // this hack is gross  
  final String[] val = new String[1];  
  Callable func = () -> val[0] = "Hello";  
  func.call();  
  System.out.print(val[0]);

  >  so essentially still is object nonetheless

http://www.c2.com/cgi/wiki?ClosuresAndObjectsAreEquivalent

Kotlin can inline lambdas (sometimes), which matters a lot on Android. For example there is no over head to writing your code so that it uses map and a lambda to writing a native loop.

In addition, because the code is inlined it can use the actual type of generic arguments. Not sure when that is useful.

First class functions mean you can define functions outside of classes. Java 8 does not have any such feature.

Kotlin has quite a lot of hidden treasures in it, typically at the intersection points of several features. People who think of it as a better Java, or something Java can easily catch up with, should take a closer look.

Technically first class functions means functions can be treated like objects and passed around like any object (for example, python).

That said, I agree with you that Java does not have first class functions. They have something tacked on that is nowhere as elegant and lacks full support.

On the other hand, not every language that lets you define functions outside of classes lets you treat them like objects. C for example is generally not considered a language with true first class functions because it doesn't allow passing nested ones without additional support within the chosen complier.

Alright, in that case Kotlin has that other sense of first class functions as well. You can get a function typed object that supports the invoke operator, amongst other things.

>It feels to me like a better Java, but still very limited compared to Scala

That sounds very good. Scala overdid it.

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

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

That sounds very good. Scala overdid it.

You are wrong.

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.

Extension methods vs implicits is one of those things that people seem to really like about Kotlin, on the balance of comments I've read. For instance because they are more predictable, higher performance, implicits are apparently a leading source of Scala compiler slowness, because to fix the issues with implicits you end up needing what Scala calls value types (but which have so many restrictions, they're more like type aliases than actual value types), etc.

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?"

"foo".asSequence() works fine. I understood your long hypothetical conversation: you want to avoid an intermediary method that returns a collection of chars. I just fail to see why anyone would care about this.

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...

That file contains the definitions of asList and asSequence, for example. If you're saying "but look at the other methods", that's not very convincing to me either because honestly I don't think having a fold method directly on String is very useful - if they scrapped a lot of those extension methods I'd be totally OK with that.

At any rate, you never addressed the core point I raised. Saying "implicit resolution isn't related to implicit classes" doesn't seem very convincing. If solving that issue was so easy then why is the use of implicits so frequently identified as a performance issue for tools?

> But then I would need to create a real instance of that trait first which implements the missing abstract metho

You don't seem to know that Kotlin supports delegation natively. Look up the `by` keyword.

And please just post some code next time you're trying to make a point like this because this dialogue is pretty much impossible to follow.

Arguably they got the 20% of features that provide 90% of the value. It depends on whether you're looking at Scala from the perspective of "a better Java" or "Haskell for the JVM".

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

Which features do you have in mind?

Interestingly, "oh people could maybe need this" immediately made me think you were talking about Scala.

The key point is that Android will never be on par with the latest version of Java. Scala has a lot of great features but its size and the learning curve is bigger than Kotlin. It's easier to start right now to develop with Kotlin instead Scala.

You could also just use Java.

No, that was the first argument – android will soon be 3 versions behind Java, it already is using Java 6 compiled for Java 5 bytecode. The distance is getting worse with every day.

It also supports a couple of Java 7 features... but... I totally agree with your point here.

This far past the Oracle lawsuit and the increasing divergence between "real Java" and "Android Java", it is actually kind of bizarre Google hasn't really presented any kind of useful guidance on what they plan to do moving forward (unless their plan is actually to just keep limping along with a gimped Java implementation indefinately).

It is hard not to look at things like Swift and wish Google would make a similar push to update the "offical" Android language. Technically speaking, Kotlin is a great alternative, but without the sort of official blessing Swift has coming from Apple, for most developers it will be politically very difficult to get by the inertia that appears when suggesting you use a "non-standard" language, regardless of how interoperable it is technically.

Outside of really lean startups you might as well be asking to write your app in brainfuck if it isn't going to be in Java.

This is the proof that Sun was right all along and Google just played a Microsoft on them.

Oracle might have chosen some dubious arguments, but the reality is that Google forked Java and doesn't have any will to improve developer's lifes.

Before anyone replies how Jonathan praised Google, check Gosling history how things really went.

Gosling stopped all technical involvement with Java in the late 90s.

So what? The issue is legal not technical.

Gosling was at Sun until the end.

Sun just lacked the money to sue Google.

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).

> It feels to me like a better Java, but still very limited compared to Scala. It stays very much in Java's paradigm.

You've basically summarized Kotlin's design goals. Java was designed to be a simple language for widespread use, hiding an extremely powerful runtime beneath it. The very first paragraph describing its design reads[1]:

Java is a blue collar language. It’s not PhD thesis material but a language for a job. Java feels very familiar to many different programmers because I had a very strong tendency to prefer things that had been used a lot over things that just sounded like a good idea.

So: 1/ not PhD thesis material, 2/ familiar, 3/ adopt tried-and-true solutions.

Scala's design is the exact opposite of each and every one of these goals, but Kotlin tries very much to follow them. As such, they are very different languages (even though they share many features) because they are guided by opposite philosophies, and are therefore meant for completely different audiences. Kotlin aims to be exactly what Java would have been if it had been designed today; Scala aims to be something completely different.

[1]: http://www.win.tue.nl/~evink/education/avp/pdf/feel-of-java....

> but still very limited compared to Scala.

The fact that Kotlin has fewer features than Scala is what makes it appealing to me.

Scala has become a kitchen sink with too many features, it's kind of the C++ of the 21st century in that respect.

I'm not really sure how to interpret that. To you, what's the negative aspect of a feature? If features are things to avoid, what's the benefit of Kotlin over something with less features, like Java 6?

A car plus an airplane has downsides in both car and airplane mode that cars and airplanes do not have.

Cars and airplanes are things, not features. The ability to drive on roads and the ability fly don't necessarily entail the downsides of a car or of an airplane.

I'm honestly wondering what the reasoning is behind the dislike of too many features, and how people justify the "right" amount of features. I can think of at least one argument against too many features, and that's managing what features a team should use in production, but there are solutions to that and I think that's a weak argument for the original assertion, which was entirely unsubstantiated.

I haven't used C++ or Java in over a decade, and I've never used Scala, so I don't have a horse in this race, but vague assertions deserve substantiation.

For me, language design is a balance between being expressive and being readable. Coders love the ability to concisely express nuance and therefore gravitate towards expressive languages, but there's a hidden cost that most underestimate. And that cost is paid by all the readers of the code that do not share the same style and context of the author. Note that this includes the original author when they're revisiting code they haven't touched in months. Most modern languages can be seen to be somewhere on that continuum between expressive and readable.

Languages like Go fall completely on the side of readable. I found that in my first few hours of Go, I could easily read through all the code that I found online and found it incredibly easy to reason about. But, as you'll hear time and again in critiques of the language, there's a lot of boilerplate that makes things explicit and many programmers dislike the lack of expressiveness.

Which brings me to Scala. Scala is on the entirely opposite end of the spectrum. When I first dove into Scala, I was constantly having to look up language constructs to understand the code that I was reading. And, worse yet, there was often no keyword or other indicator to tell me which feature was being used. In short, it was a nightmare to learn to read. But I'm sure the author loved it. S/he could express what s/he wanted from the computer in a few short lines that were entirely comprehensible to h[er|im].

My own personal view is that it's a right tool for the job situation. I think Go is a great language for large teams with high turnover. The fact that you could onboard a new Go developer and s/he would be able to read everything in your codebase and start contributing on day 1 is a huge plus. But if you've got a small, cohesive team that can agree on the subset of Scala features and overall patterns to use when developing, Scala could be a good choice since it would allow the team to move very quickly. There's a cost to both and it's important to consider when choosing a language. The main difference is that people too often evaluate the cost of a language based on their experience writing it rather than reading it.

I understand and agree with your point, but have always cast it in a slightly different light. I think some languages having longer or steeper learning curves than others, but when used effectively this can allow the language to be more expressive and efficient in developer time for both writing and reading. It's analogous to the communication in a field between an expert and novice, or between two experts. The experts can rely on their shared experience to succinctly explain a concept, which the novice requires detailed explanations for. This makes communication between experts highly efficient, but requires a lot of investment to get to that level of expertise.

I find programming languages follow the same rules, but often you are communicating with yourself (sometimes time shifted by minutes, hours or days). If you are an expert in a language that allows complex concepts to be defined concisely, you can use those idiomatic constructs to express your intent and another expert may easily grasp that intent, but a novice may find that much harder to comprehend. Conversely, a language that does not allow complex concepts to be expressed concisely will be easier for a novice to understand, but there is an inherent loss in efficiency for experts in that language that must resort to continuously defining complex concepts with the simpler concepts the language supports (boilerplate, in this case).

Neither type of language is inherently better than the other (as much as people like to assume so), they are just trade-offs that have different benefits and drawbacks based on the people or teams that use them. A team with low turnover and high experience could benefit greatly from the long-term use of a language that supports higher level concepts succinctly, while a a team with lower expertise or high turnover might find that extends the learning period of new hires. It's fairly easy to point out languages that have chosen one path over the other, such as Java and Haskell. I think an interesting case is Perl, which supports both, and I think that's a large source of the idea that Perl code is unreadable. It's made to be easy enough to understand in many cases at first glance, while also supporting a lot of higher level concepts. This can cause people that use it to experience very different levels of complexity in close proximity, which can be jarring for the novice, and sometimes the competent user as well.

Go is definitely a good language for high turnover chop shops. A Cobol/Java for the 21st century, if you will.

Feature is not a good thing per se. A presence of feature is a cost the makers and the users pay to be able to do something efficiently.

Good design has the smallest number of features making the greatest amount of things efficiently possible. Scheme and Forth are brilliant designs by this metric, Haskell, Python, and Go good ones, while C++ and Scala, well, not so much, frankly. BTW, Odersky himself admits it.

If the cost is less than the benefit, aren't we overall in a better place? Can't some people value the gain in efficiency, or whatever else the feature provides more than the cost? This sounds suspiciously subjective, regardless of how many people assert that many features is a bad thing, or that it's a metric of "good design" and then list a few languages categorized fairly arbitrarily, IMO.

It's perfectly fine to have an opinion, but it shouldn't be stated as fact without any substantiation (as in the GP) or with evidence consisting entirely of subjective elements unless those elements are further explored and explained in less subjective term (using "good language design" as evidence does not count as less subjective).

> BTW, Odersky himself admits it.

Was I supposed to know who that was referencing prior to googling? I'm not sticking up for Scala, I'm interested in exploring the concept of too many features as a negative in language design.

The reason Scala has so many features is that it chooses to be 100% compatible with Java, which means it needs to be a superset of Java. Benefit greater than cost? Many would say that.

> The reason Scala has so many features is that it chooses to be 100% compatible with Java,

Not sure what you mean, the ABI compatibility doesn't require any feature to work. Does Scala support higher kinded types to be compatible with Java? This does not make sense to me.

Scala is stack-compatible with Java. You can call any Java function from Scala and vice versa. Additionally, for ease of migration, any valid Java class is a valid Scala class. The Scala standard library includes the Java standard library copy-pasted in.

For the sentence "Scala is compatible with Java", there is almost no interpretation of "compatible" that would make the sentence untrue.

> If the cost is less than the benefit, aren't we overall in a better place? Can't some people value the gain in efficiency, or whatever else the feature provides more than the cost?

If you work alone, you're right. Problems start when working in a team. The average lifetime of a codebase is about a decade, in which time it is read and touched by many hands, and falls under several management administrations. We know that languages that are too feature-rich can prove troublesome under these conditions.

> sounds suspiciously subjective

Of course its's subjective -- like many things that have to do with the choice of languages -- but unlike many other debates, we actually have some very good data on this: C++. For a few years, C++ was considered a blessing. Expressive, sophisticated, powerful. But after a few years, as codebases started to mature, the industry as a whole discovered that maintaining C++ codebases is a nightmare. Every team had its own style and its own subset of features it chose to use. Some features (like operator overloading and esp. cast and assignment operators) while useful, ended up making long-lasting, large-project collaboration extremely costly. Java's design was very much a reaction to C++, eliminating features right and left, and declaring from the get-go that it aims to be less expressive and more verbose. It worked. The question now is whether any new "rich" language would share C++'s troubles or not, and that is indeed subjective (so far). But at least we know that sometimes a combination of too many features can be really bad, especially when working in large teams.

BTW, today C++ is quite effective because it's become a (relative) niche language (even according to its creator). Niche languages are used by specialized teams that are good at enforcing discipline, and/or tend to be smaller.

I suspect there are several interpretations of "feature" being used in these discussions, and without someone being a bit more explicit in what they mean, I doubt much useful progress will be made.

I also think that complex languages may be harder for teams with high turnover or a lower average skill set within that language (and as such the average allowed complexity per expression may play a role in this). I went into some depth on this in a cousin thread[1], but my conclusion may not be quite the same as yours. Part (well, most actually) of my original question on this topic was to ask for clarification, because I thought the assertion was inherently ambiguous.

That said, if you have actual numbers or studies to bolster your statements about C++ I would love to see them. What you assert is a common refrain here, but I'm truly not sure how much of it is confirmation bias and squeaky wheel. There are plenty of C++ supporters as well as detractors, but I'm not sure how to sort through the noise here to get an accurate assessment of the landscape. Interestingly, my relative distance from C++ may actually help here since my own experiences may not sway me as much, but that might be entirely overshadowed by C++'s similarities and differences to other languages that I like or dislike in some aspect that I am more familiar with.

In the end, since it's not as simple as "less features us better, more features is worse" (otherwise we would all be writing assembly), I suspect there are a few other important axes of comparison that actually describe the situation better, and language features is a useful abstraction but only over a very short range of values, outside of which it becomes increasingly useless as a metric for how hard or easy it is to manage a codebase.

> BTW, today C++ is quite effective because it's become a (relative) niche language (even according to its creator). Niche languages are used by specialized teams that are good at enforcing discipline, and/or tend to be smaller.

Is it? I know there have been other systems eating into the market share for C++ for a while, but my impression has always been that it's still extremely popular in certain segments where there hasn't been much new competition for a while. E.g. high performance computation, cutting edge/AAA games, etc.

1: https://news.ycombinator.com/item?id=10292093

> I know there have been other systems eating into the market share for C++ for a while, but my impression has always been that it's still extremely popular in certain segments where there hasn't been much new competition for a while.

"Extremely popular in certain segments" is typical of "niche languages" -- those segments are its niche(s).

Yes, but "eating into the market share" doesn't necessarily mean it isn't still a heavy contender. I think we can agree that while Internet Explorer has been losing market share for quite a long while, you can't classify it as niche. In that respect, my original statement regarding it dominating some industries and your reply don't really affect the answer to the question of whether or not it's a relatively niche language. The blame is mostly mine though since you were responding to something I put forth that wasn't really relevant.

Fine, but C++'s "niche" is larger than all but maybe four other language's total market share. So the word "niche" doesn't really fit very well...

> Fine, but C++'s "niche" is larger than all but maybe four other language's total market share. So the word "niche" doesn't really fit very well...

If the niche is well-defined, the size doesn't really matter in many respects, because its effectively a completely different market, and it doesn't matter whether that markets large or small in terms of what goes on outside that market.

But those four other language's total market share covers over 80% of the industry.

> In the end, since it's not as simple as "less features us better, more features is worse" (otherwise we would all be writing assembly)...

Arguably, assembly is the most feature-full language - everything is possible. But those features are very expensive, which is why it's only used where there is no alternative.

Well, in that respect, every turing complete language is at feature parity, but I think the meaning of "feature" here for most people (I still think there's a few specific differences in people's interpretations) is "language construct making hard, complex to program construct or methodology more easily expressed through language level support."

That is, both C and Perl can implement Hash data objects, but C requires a library or implementation, and Perl makes it a core data type of the language.

No, assembly is more than turing complete. On many CPUs, you get instructions like "enter supervisor mode" or "flush the data caches" or "change the interrupt mask", which aren't part of the definition of a turing machine. (I know, floating-point multiplication isn't, either, but you're going to have to be able to do at least some kinds of arithmetic to implement a turing machine, whereas supervisor mode is completely outside the spec.)

And C, Java, Perl, etc, also don't have anything like "enter supervisor mode". But if the CPU supports it, assembly will let you do it.

Again, that depends entirely on how you define "feature". If the feature in question is "easy use of hashes as a built in data type" assembly doesn't have it. Yes, you can implement hashes in assembly, the the feature as outlined is not something you can ascribe to assembly. Additionally, assembly has a few features that are not replicated in most languages (but not all, some languages allow inlining assembly). So they are often just partially overlapping sets.

> if you have actual numbers or studies to bolster your statements about C++ I would love to see them.

Note that most real-world case studies were done in the late '90s-early '00s so they are not that easy to find. A quick Google search, however, came up with this[1].

> There are plenty of C++ supporters as well as detractors

It's not about C++ supporters and detractors today. It is an undisputed fact is that the industry as a whole abandoned C++ (except for its relevant niches) and practically no one has looked back.

> In the end, since it's not as simple as "less features us better, more features is worse"

I'm not saying it is simple. I am saying that we have one experiment with conclusive results. Perhaps there are other variables, but given the strength of the results, the burden of proof -- IMO -- lies with those who claim that their super-feature-rich language will not meet the same fate.

> it's still extremely popular in certain segments

It is, and those are its niches. They form a largeish share of the market, but not anywhere as large as the segments that used C++ in the 90s or the segments that use, say, Java today. It is most certainly no longer a general-purpose cross-market industry-wide language.

[1]: http://www.lanl.gov/projects/CartaBlanca/webdocs/PhippsPaper...

Thanks for the paper, I'll take a look.

> the burden of proof -- IMO -- lies with those who claim that their super-feature-rich language will not meet the same fate.

All you are doing is reducing the discussion to something so hand-wavey that it can't be argued anymore. I'm interested in how much is too much and what type of features increase tihs load. I assert that some features don't increase errors, but in fact decrease them (e.g. Java's automatic memory management), and if that's true, than the statement "more features is worse than less features" is trivially proven false. Is it really that hard to move the argument beyond the simplistic point of view that "features" are the problem?

Automatic memory management is what's known as an extra-linguistic feature. Those usually reduce complexity (JITs do the same, as they allow very efficient compilation while introducing different dispatch kinds -- static vs. virtual -- with different performance). I was talking about language-level abstractions. For example overloading, operator overloading, having both subtyping and explicit sum-types, etc..

It is handwavy because designing languages is an art, but usually providing too many ways to achieve the same thing or allowing code that hides its operation (or appears to violate the "normal" language semantics while looking innocuous) is, in general, bad (for large teams), as it hinders readability. Of course, things need to be balanced, and you have to consider what kind of projects the language is for, what would be the "average" code size, etc..

> I was talking about language-level abstractions.

And I've been trying to get people to at least define what they are talking about in every single comment I made. Kudos to you for doing so. :)

> Automatic memory management is what's known as an extra-linguistic feature.

While that makes your position easier to support (but it's not what the original comment stated, which is why I asked for clarification from them), I'm not sure I buy it entirely. I need an explanation why a language with more language level abstractions is worse than one with less, given that you can enforce the restriction of some abstractions. Why is artificially limiting yourself the better solution than enforcing restraint, which leaves the possibility to work outside those constraints when the conditions are correct?

Because what C++ has taught us that it's impossible to enforce restraint in a serious project[1], because the people enforcing the discipline change. The discipline enforced by you is different from that enforced by the team-lead to follow you, and by then the codebase lacks any discipline. That was exactly C++'s lesson, which is why people are weary of languages that say, "all you need is a bit of discipline".

[1]: This is less true of C++ today, when it's mostly a specialist language used by specialist teams working in fields that have always required a lot of restraint. They know how to do restraints (well, at least better than the industry at large).

> Because what C++ has taught us that it's impossible to enforce restraint in a serious project[1], because the people enforcing the discipline change.

So? the language's themselves change over the time frame you are looking at. You seem to be arguing that having the language enforce it is better than policy, but name one language that's seen any serious use that hasn't seen change to add new features over the last then years, of the exact sort you are saying cause problems. So we're supposed to entrust this to a third party that really doesn't care about our specific needs. The Java standards committee doesn't know who you are. And if they do, you are not a representative case of the vast majority of Java programmers. I would rather control my future, so I choose freedom with restraint.

I'm really not buying your C++ is niche argument. C++ is one of the top 3-5 languages in the world in every metric. Java is more popular, but not being the most popular has nothing to do with being niche. C++ is still in massive use in almost every industry. That is not niche. Using C++ as your go-to example and basing your argument on having lost so much market share as to be a niche language isn't really moving the discussion along. Shops switched to Java from many languages, not just C++, and for many reasons, not just because C++ features caused problems. That argument is far too simplistic and ignores far too many things for me to give it much credence.

> I'm really not buying your C++ is niche argument. C++ is one of the top 3-5 languages in the world in every metric.

If you see how Bjarne Stroustrup[1] describes C++ today, you'll probably agree that it's a niche language (he sees it that way today).

> That argument is far too simplistic and ignores far too many things for me to give it much credence.

Of course. But ignore it at your peril. If you want to use a language that is similar to C++ in many respects (many of the same respects that the industry complained about), you should at least acknowledge the risk and try to be damn sure that this is what you want or be sure that this wasn't a contributing factor to C++'s fall from dominance.

[1]: https://youtu.be/2egL4y_VpYg?t=12m9s

But Scala design is exactly that. In fact I'd bet that Kotlin has more features than Scala does, because it often has about five separate features to cover the use cases that Scala does with one feature like implicits.

Have to step in here :-). In fact I bet that Scala has fewer features than Kotlin. In retrospect I now think Scala could have had fewer features, and hope we can get to a state where we can remove some of the redundant ones. But that's because (1) hindsight is always easy and (2) I am at heart a minimalist. Almost all programming languages have too many features to my taste.

Language design is an exercise in balance between features and guarantees. More features = fewer guarantees and vice versa.

It's not readily apparent to me how a feature necessitates that a guarantee can no longer be kept. In fact, one feature of a language might be an additional guarantee about some aspect of it's function (e.g. Rust and it's memory ownership feature).

I'm a Scala developer and personally I believe that such claims are unwarranted, mostly coming from beginners with a superficial understanding of the language. Not only is Scala not a kitchen sink, but it actually cuts down on Java features that were a bad idea.

This misunderstanding mostly happens because some people start learning Scala in the hope of finding a better Java. But Scala is not a Java++, but something else entirely, being the kind of language that makes sense outside the boundaries of the JVM.

As a piece of advice, if you aren't interested in trolling, you might want to name actual things that you don't like, as in things that you can talk about, instead of things that are non-falsifiable. That way, in case you have a point, then other people or even Scala's or Kotlin's language designers can learn from your feedback. And if you don't have a point, then you might get some useful piece of advice.

On Kotlin - I don't like that it doesn't diverge enough. This is because when picking a non-mainstream language, you lose the advantages of mainstream languages, like easily available documentation, copy/paste-able samples, big developers pool, etc, etc... so the advantages of the non-mainstream language would better be worth it to balance the disadvantages ;-)

> you might want to name actual things that you don't like, as in things that you can talk about, instead of things that are non-falsifiable.

Sure, I could name things that I don't like but they will be by definition non falsifiable as well, so I don't really see the point of what you're asking.

Overall, I just find the surface area of Scala way, way too big. I felt the same way about C++ compared to C in the 90s, hence my comparison. I've used Scala for five years and over that period of time, I've seen the language adding feature over feature instead of addressing critical aspects such as good IDE support or decent build tools.

I'm still stuck with Scala at work but I'm really hoping Kotlin takes off because using it on my personal projects has been a breath of fresh air compared to Scala. It's like getting 90% of the power of Scala with 5% of the cognitive load.

Scala's surface area isn't especially large though? Here's a list of Scala language-specific features I use & have to keep in my head on a daily basis:

- Case classes + sealed hierarchies (algebraic types, in other words)

- Implicit parameters

- Collections library

- Traits

- Function types, currying, partial application

- for-yield

- Pattern matching

None of those concepts on their own are especially complicated. In fact, I find Scala to have a bunch of orthogonal features that are easy to understand on their own and that compose in a variety of useful ways.

> Scala's surface area isn't especially large though?

You'll find plenty of disagreement with that feeling everywhere you ask...

The fact that you choose to use a small subset of all these features is irrelevant: eventually, you have to hold all the language in your head because you will work with other people and other organizations that have different standards than you do.

Which is why it's so important for a language to learn how to say "no" to new features, something I feel Scala has been unable to do.

What other features could someone even reasonably use though? I say this because what I listed above isn't some small subset of Scala. It's actually the majority of the language.

Hmm I'll try to think of some features that we don't use at work that would add additional semantic overhead:

- Inheritance? I mean okay but nobody I work with makes heavy use of this anyways and if I were working in a Scala shop where inheritance was used heavily it would be like working in a different language. So I suppose I'll give you that although I don't see how that makes the language hard to learn or work with.

- Mutable collections + references (vars)? Once again nobody I work with uses these outside of local mutability when they fail to be able to leverage immutable abstractions that do the same thing. If I worked in a Scala shop where mutability was used without care, it would be like working in a different language entirely true.

- while loops? I don't know what else I'm grasping for straws here.

If anything, the additional 'complicated' things we use in Scala aren't language features but rather libraries, mostly scalaz/shapeless.

> If anything, the additional 'complicated' things we use in Scala aren't language features but rather libraries

One thing with Scala is that various features of the language allow libraries to reshape the "feel" of the language, because a number of things that would be fixed in the language in many other languages can be modified by libraries in Scala.

Consider that whilst Kotlin does not support things like function currying and partial application out of the box, they can both be added by a library (funktionale). Kotlin has a focus on DSLs defined in libraries and has a few language features that are intended to make them work better, in this sense, Kotlin and Scala are similar.

Right, but by comparison Scala goes further than Kotlin on this. Consider the case of operators, for instance: Kotlin, like many languages, lets you redefined a predefined set of operators for new types with predefined precedence, Scala lets you create entirely new operators.

To some, this is a strength for Scala -- to others, it is a weakness.

Also IDE support in Scala is pretty much fine. Have you used it lately? IntelliJ is able to handle my code fine in almost all cases, and I make heavy use of scalaz and occasionally what Scala has for dependent types. The only problems I ever run into are IntelliJ sometimes telling me I don't use an import for a typeclass instance that I am definitely using.

I love Scala but the Intellij support is lacking in that it can't always find the right import to auto-import and I have to manually add it myself. I think it comes down to the fact that it takes the compiler a lot of cpu cycles to figure out what's actually in scope with implicits, etc. I soldier through it, but it can be annoying when I have to go hunting around for the import.

IntelliJ IDEA's auto-import works fine for normal imports. But it cannot guess what implicits you need imported in scope any more than the compiler can.

The only implicit (I can think of) from the standard library that needs to be explicitly imported is ExecutionContext.Implicits.global. It's a form of dependency injection meant for working with Future and the error message tells you exactly what to do, but it can't be automatically imported because the thread-pool used is a pretty big deal and you should pause for a second to think about it. Other than that, the implicits you need are probably your own doing, because common libraries usually have a design where you get everything needed with sensible defaults.

In other words, if it's painful to import, then you should probably rethink it. This is actually a very good rule for Java as well. People too often rely on IDEs to do the boring parts, not noticing the stench until it is too late.

As said on http://www.scala-lang.org/api/2.11.7/index.html#scala.concur... the default global should not be imported all over the place. It's better to declare functions with an implicit ExecutionContext and try to declare your execution contexts in a few well-known places.

The (web) app I'm working on uses several ExecutionContexts (database access has a specific one for example.)

Here's the reason for why I asked. You're saying that:

> I've seen the language adding feature over feature instead of addressing critical aspects such as good IDE support or decent build tools

Well, Scala 2.11 hasn't added any features, being a release meant for stabilizing, modularizing and optimizing the compiler and the library, fixing many non-withstanding issues. So zero new features.

Scala 2.10, released Jan/04-2013 (2 and a half years ago, OK?), was the release that added some features which included Value Classes / Implicit Classes (they are linked, for providing extension methods, as a refinement of implicit conversions), String interpolation (any sane language has it, plus Scala can now deprecate the conversion to String that was imported from Java), plus macros as experimental. Besides macros, everything else is minor and macros are meant for library authors as a neater way of building compiler plugins.

Scala 2.9, released May/12-2011, only includes changes to the standard library and not the language.

Scala 2.8, released Jul/14-2010 (5 years ago), introduced named and default arguments, package objects, changes to implicits, type constructor inference and a completely redesigned collections library. This release was so big for its users that it should have been called Scala 3. Before Scala 2.8 the language wasn't suitable for usage and Scala 2.11 is pretty much the same language as Scala 2.8.

So I'm really wondering what "feature after feature" you're referring to. Really, take other programming languages that aren't Java and compare the features added in the last 5 years to Scala's history. You'll have a surprise ;-)

Also IntelliJ IDEA is pretty awesome for Scala, I've been using it for the last 3 years. It's worse than IntelliJ IDEA for Java, but it is better than Eclipse for Java or Visual Studio for C#. There's also Scala IDE (built on top of Eclipse) and Ensime (a pretty capable Emacs / Atom / SublimeText plugin). Other platforms can only dream of such support, including Kotlin, or C# for that matter. I'm not joking.

> Sure, I could name things that I don't like

So why don't you name those things that you don't like?

> So why don't you name those things that you don't like?

Because then you will tell me that I don't like these features because I don't understand them?

But alright, here are a few:

- The type projector lambda syntax is absurdly arcane: `({type λ[α] = Either[A, α]})#λ]`

- The curry syntax is silly as well (multiple parentheses)

- The "_" character has eleven different meanings depending on where it's used [1]

[1] http://stackoverflow.com/questions/8000903/what-are-all-the-...

The type lambda syntax is arcane, but that's not a feature - indeed if anything it's the absence of a feature (would you favour explicit support for type lambdas, like the plugin does?). If you're complaining about the syntax of curried functions then again that's not a complaint about a feature; likewise _.

I'm not saying they aren't issues, but none of the things you mention is about Scala having "too many features".

To be fair, isn't type projection a Scala feature? Have you ever seen another language that can do it?

It's not a language-level feature. It's a pattern that makes use of several features - type members, structural types, member selection. (You can often write these things more readably by splitting them onto two lines, putting the type alias in one place and the use of it in another, avoiding the need for the structural type and member selection). It's like the visitor pattern in a language that doesn't have pattern matching, or an explicit Y combinator in a language that doesn't have recursion.

Some newer languages have this kind of functionality (in Haskell it's a GHC extension, I think).

Personally I'm not having discussions about Scala with the purpose of winning arguments, but rather with the purpose of clearing misunderstandings and this goes both ways.

The "_" character is a placeholder for things that can be named, but for which you don't care about that name. And because you don't care about the name, it can function as a wildcard (i.e. any). To me all use-cases of the underscore make perfect sense and I can't remember a single instance in which I was confused by its meaning.

Type lambdas are arcane, but as @lmm points out, this is more about the absence of a feature. Basically in Scala type lambdas do not have first class support and so they are based on Scala's abstract types.

As to why they don't have first class support? Well, because people complain about too many features ;-) But it's worth pointing out that the TypeLevel folks have plans to introduce first-class support in their fork and thus propose an improvement. And also, because of the work that happened in Dotty, Scala the language is heading towards a DOT calculus foundation, along with a unification of higher kinded types with abstract types, which should iron out the edge cases.

The curry syntax seems silly if you come from SML, Ocaml, Haskell or languages from the ML family in general. In such languages all functions have exactly one argument. But Scala is not an ML language and so it doesn't do currying by default. It's annoying sometimes, but as with all design choices there are disadvantages and benefits.

C++'s goal was to introduce a newly popular paradigm (oop) on top of an existing rich ecosystem (c). Scala's goal was to introduce a newly popular paradigm (fp) on top of an existing rich ecosystem (java). They both suffer from poor tooling, long compile times, and feature bloat with several predominant styles of writing it.

To dismiss the similarities is disingenuous.

Yeah, both are programming languages. Objective-C was also built on top of C, with the same original purpose as C++, yet you couldn't find two other mainstream languages that differ so much.

I can't really answer to your argument because it is superficial and there isn't anything in there to answer to. Whenever I ask folks what makes Scala complex or bloated, or what the conflicting "styles of writing it" are there, they always shy away. Because it's easier to be handwavy than it is to construct a good argument.

Unfortunately handwavy arguments are subject to marketing and social forces. This is how people end up worshiping Python's spirit and included batteries, which must be some of the biggest lies in our industry, since I can name more non-orthogonal and half-baked features in Python than in Scala, plus several clusterfucks in its standard library and ecosystem, starting from the build management tools, the async-I/O libraries and the web libraries, all of them screaming anything else but "there is only one way to do it". But that's just the herd mentality in action.

If you would like a specific, concrete issue with Scala, I find its documentation to be extremely poor compared to Kotlin.

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.

I wasn't talking about projects written in the language, I was talking about the language itself.

On Objective-C: yes, it's quite different from C++; that's because it took a very different approach to integrating object oriented programming into C, and because it had a much more traditional (at the time) model of what object oriented programming was. Essentially, Objective-C adds a completely new language for object oriented code, one which has a very good zero-overhead C FFI and one which happens to be source compatible with C. C++ really tries to make one cohesive language, so that you don't have that dichotomy (although it doesn't always succeed when it comes to templates).

Yes, Scala isn't exactly the C++ formula applied to java and functional programming; it doesn't, for example, strive for source compatability (C++ has to because of header files, it likely wouldn't otherwise).

Whenever I ask folks what makes Scala complex or bloated, or what the conflicting "styles of writing it" are there, they always shy away.

I don't think there's a good way to identify concrete examples for "bloatedness" because it's kind of a fundamentally handwavy concept. It's a feeling that you get while learning and using the language. One that people don't get with C, or Go, or Haskell or Scheme, but tend to get with Scala and C++ and Common Lisp, to name examples.

Complexity is easier to point to though. The interaction of inheritance and generics, the mutability semantics, the fact that it's not clear from the call site when arguments get evaluated (with defered evaluation and macros), anything that can result from an abuse of implicits, mutability semantics.

The various styles of writing Scala? Well there's the people who wanted to write Haskell but settled for Scala because it's what their bosses gave them, who write it with a lot of immutability and use the type system to a great extent. There's the people who wanted to write java but write Scala because their bosses make them, who write java in Scala because that's a totally viable way to do it. And there's a lot of people in the middle.

Addressing your python point: I agree that the "there's only one way to do it" mantra is kind of wrong in pythonland, but there are a lot of conventions in that community that people adhere to that make it true in a way. This comes with a lot of dogma unfortunately. Other languages have fewer "non-orthogonal and half-baked" features. Go, for all its issues, doesn't have many of those because it seems its designers are content to just not have the features at all rather than have them be imperfect. C doesn't either, really, nor Haskell.

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 ...

Regarding C++ having poor tooling: care to elaborate a little? Just one or two specific examples.

I know the grammar is really difficult to parse and that has hindered static analyzers in the past, for example, but what else are you talking about? Also, how good or bad is clang's static analyzer compared to those of other languages?

You got it wrong.

C++ goal was that Bjarne didn't want to code ever again in plain C, after being forced to use it.

It just felt wrong to him such a primitive language after his experience with Simula and other proper languages of the day.

So when he joined AT&T, he started to work a way to have Simula for his work. Then the language grew from there.

There a few Bjarne interviews were he tells this.

That's not trolling at all. I work at Gilt. We're always cited as one of the biggest Scala proponents. I still think the analogy to C++ is adapt.

C++ is a great language. Scala is a great language. Both are huge and require knowing which parts to work with.

I wasn't saying that you're trolling, I was just asking about reasoning since I'm curious.

Keep in mind the world's largest operating system is stuck with Java 6.

Java will never get good enough - for one it will always have checked exceptions and undesirable casting syntax, not to mention no native getters/setters.

Reply on news.ycombinator.com