simon_o

That's true. More importantly, Rust and Kotlin work on improving things that matter to users, not on features that read nicely in a paper, but are largely irrelevant in the grand scheme of things.

Just compare Rust's announcement on tooling (https://www.ncameron.org/blog/dev-tools-in-2018/) with the state in Scala, where pretty much every promised improvement has been "around the corner" for the last 5 years. :-/

Not sure much how much can or will change here, given the departures of experienced tooling contributors in 2017.

It seems like it. I recently took the liberty to update the language rankings on https://en.wikipedia.org/wiki/Scala_(programming_language)#L... and compared to 2016, Scala took a hit on pretty much every ranking.

Outlook largely negative, falling in rankings across the board.

Not going to happen.

I assume that the "added feature" section of the Dotty documentation and this blog entry have been written by different persons, because it's utterly impossible to reconcile those documents:

More complicated features, more experiments, more NIH, more ad-hoc inventions, larger language footprint with more inconsistencies and surprising behaviors.

Not surprising. Compatibility between minor releases has been unceremoniously jettisoned.

> Low wage immigration from Eastern Europe has put downward pressure on UK wages.

How is this Europe's fault? That was a decision made by the UK, not the EU.

Scala has always been big on advertising it's abilities to abstract over things with it's type system (higher-kinded types, constructs from category theory, Haskell-inspired typeclasses), but has failed to actually out those capabilities to good use.

Just one example: Everybody pretends that e. g. the map function in collections is totally unrelated to the one in Futures, or the one in Slick, or the one in Quill, or the one in Spark. We all know that this is not just a random coincidence in naming.

The ironic thing us that Scala could have just implemented java.lang.Iterable and/or java.util.Iterator, instead of rolling their own interfaces with largely the same methods with identical signatures.

No, because Option/Maybe can nested, nulls can't.

But those language communities also have to do some self-reflection.

People are often hostile to things they don't know. Not taking this into account when trying to introduce new things is a recipe for disaster.

This means ...

– picking up developers from where they are, not telling potential adopters "if you write Java-like Scala we don't want you here".

– meaningful documentation, not answering efforts to improve documentation with "it's not necessary, because everyone already knows Scala".

– describing and explaining design choices like companion objects, type classes, context bounds, and so on; not expecting that beginners will understand their superiority through osmosis.

– making technologies accessible to people on their platforms, not treating backends such as Scala.js, Scala on Android or Scala-Native as add-ons for existing Scala users (or worse).

– taking tooling seriously, and not releasing major versions of the language without tooling support. Or breaking compatibility in minor versions like in Scala 2.12.

– clean-ups that removes unnecessary baggage from the language and its libraries. Not lecturing people about the number of keywords or counting the lines in the language's grammar in comparison to other languages.

Haskell does some things better in this regard, but both are far from a convincing value proposition over "worse is better" approaches like Kotlin (which will probably swipe the floor with Scala in the future, because they address the bad parts of Scala).

> The minor versions are interchangeable.

They are not, at least in Scala. See 2.12.x.

I'm not sure what you are arguing against.

All I'm saying is that the situation is bad as-is, and it would be good to not make it any worse.

But having to worry about compatibility between minor versions is still bad.

People have come to expect that minor versions are interchangeable (modulo fixes for clear regressions and changes made in reaction to important outside events like major releases of Java).

> If all you had was single return values (aka "int or throw Exception"), how would you model the io.Writer?

This is not an problem, because a single return value is _not_ everything one has.

It is superior for readability and parsing, and combined together with ident: Type, you have a very consistent syntax (unlike other languages with generics, where you define e.g. generic methods one way, but call them in another).

Just without the callbacks. At least you could abstract over error handling with callbacks...

> The last two options are not idiomatic Go.

Who are the authors of https://golang.org/pkg/io again?

Yeah, 90% of Go devs agree with you.

10% think it is a really great idea.

So you can never be sure without reading the documentation.

Like nil interfaces not being nil.

Or using characters from the Canadian Aboriginal Syllabics unicode block to emulate generics.

Exceptions are bad outside the "your computer just started burning" cases, but Go has replaced them with something even worse, "multiple return values".

So instead of some imagined return of "int or throw Exception" you now have "(int, error)", which basically means that the result of a function call can be any of these four options:

  - (   value, no error)
  - (no value,    error)
  - (   value,    error)
  - (no value, no error)

And due to the lack of Generics you can't abstract over your error handling.

And due to the lack of proper ADTs you can't even properly model "value OR error" manually.

Wrong thread? Nothing you wrote has any relationship with what GP commented on.

I think the Scala version does exactly what you want it to do, but you seem to be confused about something that I can't really pin-point.

> Why do I need a separate Person and Dog class?

You don't. It's an example.

> Can't a dog have a name as well?

It can.

> Why do I need to declare that upfront or ensure that no other part of code can give a Dog a name?

I have trouble understanding the meaning of that sentence.

> Mesa is lacking in terms of features compared to Nvidia's implementation

Mesa is open-source. Nvidia can submit patches at any time they want.

The right approach is to include your own package repository in the deb file so that it gets automatically added to the system when people install the application.

The biggest issue with claims like "there are only diminishing results when using a type system better than the one provided in my blub language" is that it assumes people keep writing the same style of code, regardless of the assurances a better type system gives you.

"I don't see the benefit of typed languages if I keep writing code as if it was PHP/JavaScript/Go" ... OF COURSE YOU DON'T!

This is missing most of the benefits, because the main benefits of a better type system isn't realized by writing the same code, the benefits are realized by writing code that leverages the new possibilities.

Another benefit of static typing is that it applies to other peoples' code and libraries, not only your own.

Being able to look at the signatures and bring certain about what some function _can't_ do is a benefit that untyped languages lack.

I think the failure of "optional" typing in Clojure is a very educational example in this regard.

The failure of newer languages to retrofit nullabillity information onto Java is another one.

Then let's ban cars in cities, considering the harm car traffic has caused to inner cities andvtgeir inhabitants.

Oh, and don't complain that infrastructure built for cars sucks when used by bikes.

Migrated to Vivaldi after 15 years of Firefox. I highly recommend Vivaldi and would pay for it, given the option.

It's 2017, I'm not placing ; by hand anymore.

We have computers they are perfectly able infer them for me.

> Javascript's handling of semicolon is nuts, I wouldn't say Rust's is.

- JavaScript does insane things, as usual. This doesn't mean every implementation of semicolon inference has to be that bad and broken.

- Rust goes the other way by pretending it's still 1990.

There are plenty of languages out there that handle semicolon inference perfectly fine.

(Heck, I even let the IDE show me where the compiler has placed them.)

> I just think that using the semicolon to make the function return unit instead is problematic.

Agree. The idea to attach additional semantics to ; is completely nuts, especially as ; is mandatory in Rust (usually, there are odd corner cases where it is not allowed).

Just get rid of mandatory ; completely and let the type system handle the rest.

This hardly makes any sense, is not practical to implement and theoretically questionable.

It makes decisions that break existing code and introduce pointless complexity, while failing to offer any tangible benefits in return.

> Maybe collections of values should be different from collections of references. The sensible use cases for the two are quite different.

I think all existing code disagrees with that. There has been great value derived from being able to abstract over element types.

What you are proposing would double the required number of collection classes and all of its traits, because it would require separate ones for Collection[E <: AnyRef] and for Collection[E <: AnyRef].

There is literally no reason for introducing this complexity. Go has demonstrated how poorly this idea has worked out in practice.

Additionally, this approach would make it nearly impossible to migrate reference types to value types, because it would break all users of the code.

> Meh, just allow NaN to compare equal to itself. Equality is supposed to be reflexive.

That's a complete non-option. You might not like the IEEEs definition of equality, but this is what it is. Messing with it would break all existing code using floating point numbers.

> Unboxed primitives don't have identity, only value equality.

Their identity is the bits they consist of, just like identity on references is the bits of the reference.

> They align well with what's being proposed.

What is being proposed?

> We could build the distinction into the language, so for every type you define you explicitly choose whether it's value or reference.

We already have that: AnyRef and AnyVal.

> Scala's already halfway there with the class/case class distinction.

That doesn't make any sense. The case keyword is basically just a compiler built-in macro to generate some code. It is already doing way to much, and overloading it with even more semantics is not the way to go.

> Disagree; comparison is so fundamental to most types that it's worth privileging. Using the wrong kind of comparison is a very common source of bugs.

What I'm proposing improves the consistency across value and reference types so that it's always obvious which kind of comparison happens:

- identity: Low-level comparison of the bits at hand. Built into the JVM and not overridable.

- equality: High-level comparison defined by the author of the type.

"Dynamically" typed languages are untyped, and are therefore likely considered out of scope in this document.