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

231–240 of 383 posts

Re: Towards Scala 3

#231

Post by dominotw »

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…

> 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

What if you want functional programming without having to go to MS stack and stay on JVM. You only have have two real options clojure and scala.

Re: Towards Scala 3

#232

Post by munificent »

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.

> Is it actually unsound if you perform no casting?

Yeah, it is. At the very least, I know that function parameters are bivariant, which isn't sound:

    function foo(callback: (obj: Object) => void) {
      callback("not a bool");
    }

    function main() {
      foo(function (bool: Boolean) {
        if (bool) window.console.log("!");
      });
    }
This compiles without a type error but ends up assigning a string to a parameter of type bool.

Re: Towards Scala 3

#233

Post by AnimalMuppet »

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…

Agreed.

Here's my view on languages: They have strengths and weaknesses. They cater to different needs, as you say. If you have the need for what Rust, say, does, and Rust solves some real problems for you and makes your job a lot easier, then it's kind of natural that you think Rust is wonderful. In fact, what you found is that Rust is wonderful for that problem, not that it's wonderful in general. But it's real easy to think that your situation is more universal than it is, and therefore that Rust (in this example) is this wonderful language that makes all of programming so much better.

Once you've fallen into that flawed perspective, then it becomes easy to criticize other languages. Why would you ever want to use Scala? It doesn't have Rust's advantages. But people miss that, if you have a Scala problem rather than a Rust problem, and you pick Rust anyway, it's not going to go well...

Re: Towards Scala 3

#234

Post by Blaisorblade0 »

cinnamonheart wrote: post #157
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…

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.

Scalac has evolved considerably, but it appears to be much harder to evolve. The Scalac team and contributors are backporting some of the Dotty features, but this is far from a trivial effort. Doing the same changes in Dotty is typically much easier in comparison.

Re: Towards Scala 3

#235

Post by Cyph0n »

AsyncAwait wrote: post #217
Cyph0n wrote: post #66

Earlier quoted context omitted.

Charging for debugger access sounds so 90s lol

They're not charging for debugger access. CLion is the only IDE where they have tie ins to GDB etc. so the Native plugin is only for that, but most Kotlin users are on the JVM, where the IDEA Community Edition is not only free, but open-source.

> CLion is the only IDE where they have tie ins to GDB etc. so the Native plugin is only for that

Both me and the parent were referring to Native.

So they are charging for a Kotlin Native debugger, no? Do they provide a GDB fork or something that can use without CLion?

Re: Towards Scala 3

#236

Post by naasking »

YorkshireSeason wrote: post #153
saosebastiao wrote: post #145

Earlier quoted context omitted.

> One of Odersky's motives in creating Scala was bringing the power of Haskell into the JVM world, although this is not the only motive (thigh integration of OO and FP being another). I'm not sure why you would think that. Odersky has long claimed ML as his primary functional programming influence, not Haskell. It does have HKT, so there's that...but that's about it. Typeclasses aren't really a part of the language.…

From an abstract PL theory POV, Haskell's key innovation over ML was HKTs. It was an experiment at the time, but one that was successful beyond all expectation: I cannot imagine designing a new PL without HKTs. (Note that Rust is also trying to add HKTs, but has been running into difficulties with type-based lifetime tracking IIRC.) Implicits are a generalisation of default arguments (I don't know where they were pio…

Thanks for the Simplicity reference, hadn't seen that yet. Seems like it builds on the implicit calculus [1], which applies more generally to any lambda calculus than in the Scala context.

[1] http://homepages.inf.ed.ac.uk/wadler/papers/implicits/implic...

Re: Towards Scala 3

#237

Post by jrq »

throwawayjava wrote: post #183
gaius wrote: post #148

Earlier quoted context omitted.

The thing with Scala if you’ve come from OCaml is there’s no substitute for real Hindley-Milner, and the Scala object system isn’t good enough to compensate

Does anyone use Scala in cases where OCaml is a viable option? My impression has always been that Scala is "better than OCaml if you need the JVM"

Mainly Spark, but it really depends on the domain, what libraries exactly that you'll need, hell I look at what kind of deployment routine the client wants, what their maintenance crew looks like compared to what they want from me.

There is plenty of scala in fintech, I can tell you that. But there's plenty of ocaml, f#, matlab, excel macros, r, kdb, cobol, fortran, c++, a vast array of different technologies.

Most places that choose scala are choosing it over erlang or Java or c#, they USUALLY only choose scala over ocaml if they want to have some old ocaml code talk with new infrastructure that they want built in scala, ime. Because of how performance works and that multi core isn't working yet, ocaml is limited in application if they're willing to find or already have scala programmers.

Re: Towards Scala 3

#238

Post by ItsMe000001 »

munificent wrote: post #232
naasking wrote: post #222

Earlier quoted context omitted.

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.

> Is it actually unsound if you perform no casting? Yeah, it is. At the very least, I know that function parameters are bivariant, which isn't sound: function foo(callback: (obj: Object) => void) { callback("not a bool"); } function main() { foo(function (bool: Boolean) { if (bool) window.console.log("!"); }); } This compiles without a type error but ends up assigning a string to a parameter of type bool.

I'm a Flow user rather than TS (and Flow complains about that code out of the box), but you are not telling us all:

Since TS 2.6, if you enable all the optional "strict" mode checks than TypeScript does complain about that code.

I see no disadvantage in those checks, e.g. "strictFunctionTypes", being optional, since you can always make them mandatory for your own project(s).

To test it:

- Go to the TS Playground at https://www.typescriptlang.org/play/

- Enter the above code

- Select "Options" and enable at least "strictFunctionTypes"

Re: Towards Scala 3

#239

Post by hota_mazi »

cinnamonheart wrote: post #157
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…

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.

Re: Towards Scala 3

#240

Post by naasking »

snuxoll wrote: post #112
pjmlp wrote: post #38

Earlier quoted context omitted.

Not everyone is getting into .NET Core. In fact, Microsoft has to advocate library writers to actually care about .NET Core and .NET Standard. https://channel9.msdn.com/Shows/Visual-Studio-Toolbox/NET-St...

Meh, the reason many people weren't targeting .Net Core until recently was because of the huge pain in the ass it involved. .Net Standard 1.0/1.1 were missing a LOT of API surface area that many libraries needed. .Net Standard 2.0 fixes this, and makes life easier for library authors who already support multiple runtimes in the process by providing a sane upgrade path from the hell that is PCL's. It's all about tooli…

> Meh, the reason many people weren't targeting .Net Core until recently was because of the huge pain in the ass it involved

+1000. It wasn't even library support, it was the tooling that was a huge pain in the ass. Half the time it didn't work right, builds broke unexpectedly, build file formats kept changing, cripes what a pain. I swore off it until the early .NET 2.0 standard prereleases when things seemed more stable, and it's been much easier to port my libraries.

Post reply on HN