Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Towards Scala 3

scala-lang.org

Post reply on HN
Print view View original

221–230 of 383 posts

Re: Towards Scala 3

#221

Post by clhodapp »

willtim wrote: post #164
Cyph0n wrote: post #59

Earlier quoted context omitted.

So your biggest complaint is "Scala doesn't look like Python"? I mean, I love Python, but indentation-based syntax isn't that great. I think Scala is fine as it is.

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.

As someone who likes both FP and curlies, I for one am glad to have at least one language that caters to that combination of preferences.

Re: Towards Scala 3

#222

Post by naasking »

munificent wrote: post #205
stephen wrote: post #118

...ships in 2020? I'm impressed with what they're doing (and love the language), and it's hard work, and their speed is faster than, say, Java's dead-pace evolution in the 2000s. But, poking around at TypeScript, I've been blown away with the MS/TS speed of development. ~2-3 month release cycles, with non-trivial changes to the language (mapped types, conditional types, etc.), that are themselves unique/novel type sy…

TypeScript has a comparatively easier job because the type system is unsound. They can add new type features without needing to be paranoid about a hole in the system or a usability pitfall because the tools don't rely on types for correctness or optimization, and because users can easily cast to "any" or otherwise work around an annoyance. When you want the whole system to actually deeply rely on the static type sys…

Is it actually unsound if you perform no casting? That seems to be a more interesting property, because then the additions they're making still have to mesh cohesively.

Re: Towards Scala 3

#223

Post by benjaminjackman »

lmm wrote: post #192
DandyDev wrote: post #174

It's amazing how many people in this thread justify their own language choices by making negative, sweeping statements about another language (Scala in this case) that is successfully used by people other than themselves. Yes, some people who previously used Scala, now use Kotlin. And some people who would've used Scala if Kotlin didn't exist, use Kotlin. Same probably goes for Rust. But there is a big enough market…

The reality is that a language lives or dies by its ecosystem - particularly when it comes to a language like Scala that's in a tightly symbiotic relationship with its IDEs (the next time someone tries to sell you a "visual programming language", look at Scala for a language that makes really effective use of the GUI for programming without compromising the things that make textual programming languages good - see e.…

As a fellow emigrant of `Scala is the best island` forced off for pragmatic reasons.

I've been around scala long enough to see the rise and fall of multiple expeditions into the bowels of the OSGI eclipse cave of horrors (Sean McDirmid / Miles Sabin etc). Before switching horses and settling in Intellij for several years. So I understand where you are coming from.

I've since jumped ship again to vscode (along with typescript), and in my humble experience / opinion, vscode & it's language server protocol (LSP), alleviates quite a bit of this. It abstracts away a lot of common operations from a language to the languages compiler, while providing a consistent front-end. I think if scala eagerly adopts supporting this it would be a good thing. Having a language server protocol applies back-pressure in a certain sense on language features, if you are going to add them, then the tooling (and LSP) needs to support them.

Re: Towards Scala 3

#224

Post by dbattaglia »

nnq wrote: post #2

Just curious, what companies (or kinds of companies) are betting on Scala nowadays? It seems that the people wanting "better Java" all decided they like Kotlin, and the functional programming people now gravitate more towards either F# (for .NET ecosystem) or OCaml/Reason (for the more unixy world). And the academic/research/learning crowd seems to like Haskell more. Who's still in Scala boat? Are Google or Fb or oth…

We use Scala as the primary backend language at Elastic for the Elastic Cloud SAAS & enterprise products (along with Java, Python and Go).

Re: Towards Scala 3

#225

Post by benjaminjackman »

actsasbuffoon wrote: post #154
manojlds wrote: post #133

Earlier quoted context omitted.

It's not the next release. There is 2.13 and 2.14 to be released. Are you saying Typescript has major version release every 3 months?

Typescript does indeed do frequent releases, though they're not nearly as ambitious as Scala 3.0. A Typescript release usually has 1-3 exciting new features, and a number of smaller bug fixes and improvements.

Correct, but collectively, between now and 2020 it's almost certain in aggregate, Typescript will have significantly more `features` than Scala 3.0, and they will have the benefit of being used and iterated upon for 2+ years.

Re: Towards Scala 3

#226

Post by mason55 »

MichaelMoser123 wrote: post #218
lmm wrote: post #192

Earlier quoted context omitted.

The reality is that a language lives or dies by its ecosystem - particularly when it comes to a language like Scala that's in a tightly symbiotic relationship with its IDEs (the next time someone tries to sell you a "visual programming language", look at Scala for a language that makes really effective use of the GUI for programming without compromising the things that make textual programming languages good - see e.…

> if the language is to live, I have to convince other people it's the best Aren't JVM languages interoperable - because they use the same classfile/byte code format? What does it matter if the jar is written in java or scala, as long as it is possible to use the external interface from any of these languages?

No single person can maintain an entire ecosystem around a language. And programming languages have strong network effects. If I think a language is dying then I won’t want to use it because I’ll worry about future support. It becomes a self fulfilling prophecy and a negative feedback loop.

Re: Towards Scala 3

#227

Post by YorkshireSeason »

MrBuddyCasino wrote: post #35
mavdi wrote: post #15

> Simplify where possible > eliminate inconsistencies and surprising behavior Oh dear god please.

Also, no plans to get rid of implicits apparently. Sorry Scala, we're not gonna be friends.

What is your main complaint with implicits?

If you don't like them, why don't you add "Use of implicits forbidden" to your coding style guidelines, and check in code-reviews, and add a "grep implicit" check to your CI setup that refuses to commit Scala code with implicits?

Let me paraphrase M. Odersky's PLDI 2017 keynote:

   The essence of Scala is implicits
You can find it at https://www.youtube.com/watch?v=br6035SKu-0

Re: Towards Scala 3

#228

Post by dtech »

MichaelMoser123 wrote: post #218
lmm wrote: post #192

Earlier quoted context omitted.

The reality is that a language lives or dies by its ecosystem - particularly when it comes to a language like Scala that's in a tightly symbiotic relationship with its IDEs (the next time someone tries to sell you a "visual programming language", look at Scala for a language that makes really effective use of the GUI for programming without compromising the things that make textual programming languages good - see e.…

> if the language is to live, I have to convince other people it's the best Aren't JVM languages interoperable - because they use the same classfile/byte code format? What does it matter if the jar is written in java or scala, as long as it is possible to use the external interface from any of these languages?

Yes and no.

JVM languages can usually use other JVM libraries, but they often aren't idiomatic to that language. Scala can use JVM libraries, but it often feels wrong or cumbersome, e.g. Java is full of mutable builder classes, which I've never once encountered in "native" Scala.

The other way around, in Scala you have to be careful if you want your library to be usable from other JVM languages. There's certain Scala features you just cannot use.

This is a problem that Kotlin actively markets itself with, they promise 100% Java compatibility all the time, going as far as encouriging to mix Kotlin and Java code in a single project.

Re: Towards Scala 3

#229

Post by raquo »

naasking wrote: post #222
munificent wrote: post #205

Earlier quoted context omitted.

TypeScript has a comparatively easier job because the type system is unsound. They can add new type features without needing to be paranoid about a hole in the system or a usability pitfall because the tools don't rely on types for correctness or optimization, and because users can easily cast to "any" or otherwise work around an annoyance. When you want the whole system to actually deeply rely on the static type sys…

Is it actually unsound if you perform no casting? That seems to be a more interesting property, because then the additions they're making still have to mesh cohesively.

Yes, look at how it deals with type param variance for example. It doesn't.

Re: Towards Scala 3

#230

Post by stephen »

munificent wrote: post #205
stephen wrote: post #118

...ships in 2020? I'm impressed with what they're doing (and love the language), and it's hard work, and their speed is faster than, say, Java's dead-pace evolution in the 2000s. But, poking around at TypeScript, I've been blown away with the MS/TS speed of development. ~2-3 month release cycles, with non-trivial changes to the language (mapped types, conditional types, etc.), that are themselves unique/novel type sy…

TypeScript has a comparatively easier job because the type system is unsound. They can add new type features without needing to be paranoid about a hole in the system or a usability pitfall because the tools don't rely on types for correctness or optimization, and because users can easily cast to "any" or otherwise work around an annoyance. When you want the whole system to actually deeply rely on the static type sys…

Good point; I've mused before that dynamic languages will always be a ~generation ahead of static languages, due to what you point out, that type systems are hard, and very few people start working on a new type system as their hobby project (vs. hacking out a new syntax with an interpreter).

But I hadn't appreciated the difference in difficulty between an unsound type system like TS and Scala's type system...

I guess I've taken the formalism that underlies Scala's type system (e.g. the academic research behind dotty) as a given/for granted, but you're likely right, that TS can move faster because it doesn't need/have that level of rigor.

Thanks!

Post reply on HN