Live data from Hacker News

Towards Scala 3

scala-lang.org

331–340 of 383 posts

Re: Towards Scala 3

#331

Earlier quoted context omitted.

For what it's worth, this isn't just an evolution of the language, but a complete rewrite of the compiler. I appreciate that they're taking the time to do it right. They probably could've pushed new, non-trivial features out faster if they weren't doing a total rewrite.

Pity that in this rewrite, they were unable to speed up compilation speed. From the latest reports, dotty appears to compile at about the same speed (if not more slowly than) scalac.

This is pure speculation on my part, but my guess would be that better, simpler foundations and a fresh start end up unlocking a lot of optimization opportunities in the long run. But it would seem foolish to invest too much in optimization while things are still in flux.

Re: Towards Scala 3

#332
post #199
post #188

"Scala has pioneered the fusion of object-oriented and functional programming in a typed setting." What about Ocaml (1996, well before scala) and F# (2005, not too long after scala)?

OCaml users tend to avoid its object system, so while it attempted to fuse object-oriented and functional I don't think we can say it succeeded. F# is, as you say, later.

OCamlers tend to avoid OOP mostly because we can get away with modules, functors, polymorphic variants to model subtyping, and now also GADTs and open variant types to precisely model and add cases.

When we do need to use it, it is actually pretty elegant and well-designed. It's just that since we've tasted the power of the more functional abstraction techniques, OOP loses its allure.

Re: Towards Scala 3

#333
post #105

Earlier quoted context omitted.

> I would start with operators and operator overrides, most of the time they don't make sense and it's difficult to know what it does, that's why most other languages banned them. Yeah, that's what I was talking about - in Scala operators are just functions, and badly named operators are an issue with some libraries rather than an issue with the language. They're unfortunate, but all one can really do is avoid them -…

What IDEs support this behavior?

Emacs + ENSIME also underlines implicit conversions.

Re: Towards Scala 3

#334
post #109

Earlier quoted context omitted.

If " is very powerful when used correctly, but terrible if not": think long and hard before adding to a language.

Completely agreed. Implicits are the one place where Scala genuinely pushes the art of language design a bit beyond what's really possible; I expect future languages to come up with a better solution to the same problem. But in the meantime the things they enable - typeclasses, extension methods, the magnet pattern - are too valuable to do without, and we can't just sit around and wait for the perfect language to arr…

Typeclasses: barely workable–if the implementor knows how to save the caller from paying the 'import tax'

Extension methods: too much potential for confusion

Magnet pattern: no idea what that is

Personally I feel OCaml strikes the best balance :-) But we may be arguing about an inch here rather than a mile.

Re: Towards Scala 3

#335
post #180

Earlier quoted context omitted.

Being brutally honest, compared to Haskell, ML and to a lesser extent Python, Scala's syntax is rather ugly and unnecessarily verbose. I'm almost certain its creators chose the syntax in order to tempt curly-bracket programmers, not because they liked it personally. I really hope that future high-level languages will use better syntax and move on from the C/C++ influence.

> compared to Haskell, ML and to a lesser extent Python, Scala's syntax is rather ugly and unnecessarily verbose I have never worked extensively with Haskell or ML, but what I can say is that Scala's syntax is better than that of most other mainstream languages. Three of Scala's syntax niceties are: 1) No semicolons 2) No braces required for one-line functions 3) No constructor required: instance arguments passed in…

The constructor syntax can be a source of confusion. People have to be taught that the class declaration parameter list is actually the primary constructor, and that the body of the class is also the body of the primary constructor, except for any method definitions, some of which may be secondary constructors!

Scoping is hard.

Re: Towards Scala 3

#336
post #28
post #24

Is there any plans to include async/await on the language level?

async/await is a special case of monads (expressible with a for-comprehension); it comes out to: def asyncFunction(): Future[Blah] = for { foo

For comprehensions are currently tremendously limited vs async/await. They constrain the top-level of your code structure to a tiny subset of the language.

Re: Towards Scala 3

#337

Earlier quoted context omitted.

For what it's worth, this isn't just an evolution of the language, but a complete rewrite of the compiler. I appreciate that they're taking the time to do it right. They probably could've pushed new, non-trivial features out faster if they weren't doing a total rewrite.

Pity that in this rewrite, they were unable to speed up compilation speed. From the latest reports, dotty appears to compile at about the same speed (if not more slowly than) scalac.

Where did you get that from? I’ve seen performance increases of 2-3x mentioned on conference talks: eg here https://d-d.me/talks/scalaworld2015/ slide 50.

Re: Towards Scala 3

#338

Earlier quoted context omitted.

Kotlin has many benefits that Scala has in terms of “being a better Java” without sacrificing the readability and usability benefits of Java itself. Scala is a fantastic language, but it’s not one your average Java developer can pick up in a day or two.

What readability and usability benefits are you claiming Java to have?

Java is a simple language, the syntax is easy to parse and logic is generally straightforward to reason about - as a programmer you have very little ability break expectations of how the language itself behaves (no operator overloading, etc).

Scala, on the other hand, gives you a huge toolbox down to some really complicated to reason about features like implicit parameters, creation of completely arbitrary operators, etc.

[Insert some funny pun here about Java giving you a simple tool while Scala gives you an incredibly complicated one]. They're both great languages, but they serve very different purposes and audiences - Kotlin happens to fit Java's demographic better than Scala as a result, it doesn't have the magic and complexity to the same degree Scala does (the most confusing new constructs probably revolve around builders/lambda's with receiver types which aren't needed by most developers not writing DSL's).

Re: Towards Scala 3

#339

Earlier quoted context omitted.

https://www.typescriptlang.org/docs/handbook/release-notes/t... > TypeScript 2.6 introduces a new strict checking flag, --strictFunctionTypes. > The --strictFunctionTypes switch is part of the --strict family of switches, meaning that it defaults to on in --strict mode. > Under --strictFunctionTypes function type parameter positions are checked contravariantly instead of bivariantly. > ...(etc.)

Contravariance then, right. Thanks! I haven't gotten into Typescript yet, and at this point it looks fairly large and a little daunting, so this is helpful.

And this project is super interesting: https://1c.wizawu.com/#/whatis Use TypeScript on JVM with both NPM and Maven dependencies

Re: Towards Scala 3

#340

As a heavy Scala user I'm excited by this. But really I don't think it will improve Scala adoption because the blockers there are all around developer experience (tooling is terrible - sbt, and feedback cycles are very slow). Personally, for a lot of my current use cases (APIs) I'm veering towards Go more and more as I find it a lot more productive.

At the Scala Center we’re working on addressing these problems. We now have working groups devoted to ease coding in Scala and make it easier for any dev to use any build tool.
Post reply on HN