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

Scala 3.0

github.com

Post reply on HN
Print view View original

61–70 of 292 posts

Re: Scala 3.0

#61

Post by esarbe »

cutler wrote: post #32
paavohtl wrote: post #16

Earlier quoted context omitted.

Literal types quite simply means that values are types. For example in TypeScript the literal type "Foo" is a special string type, where the only valid value is the literal "Foo" – assigning "Bar" to a variable with the type "Foo" is a compile time type error. Literal types can be combined into union types like any other type.

Sounds like more Scala sophistry. I thought they were supposed to be aiming for pragmatism with Scala 3.

I can think of plenty cases where I would want to limit the input space of a function to a known set of literals.

Just as an example; the `document.getContext` [0] api takes a string argument to select the context canvas.

Without literal types, you cannot enforce this to a set of valid values. Literal types gives you the power to tell the compiler, which values are valid.

Since there are other programming languages that support literal types, it's not just Scala sophistry. :-P

[0] https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasE...

Re: Scala 3.0

#62

Post by nsonha »

cutler wrote: post #32
paavohtl wrote: post #16

Earlier quoted context omitted.

Literal types quite simply means that values are types. For example in TypeScript the literal type "Foo" is a special string type, where the only valid value is the literal "Foo" – assigning "Bar" to a variable with the type "Foo" is a compile time type error. Literal types can be combined into union types like any other type.

Sounds like more Scala sophistry. I thought they were supposed to be aiming for pragmatism with Scala 3.

that's exactly how it works in TS. You can call TS sophistry then. Most people I talk to put it on the pragmatic side

Re: Scala 3.0

#63

Post by kjaer »

hocuspocus wrote: post #35
truth_seeker wrote: post #31

Is the compiler multithreaded ? how far it supports inlining of types and data structures to achieve or get near to zero cost abstraction after normal warm up of the code on JVM ?

http://dotty.epfl.ch/docs/reference/metaprogramming/inline.h... But it's there for meta-programming purposes, not micro-optimizations. I don't think trying to outsmart the JVM at inlining is worth it.

This is correct, though the inline feature does also unlock some optimizations. For instance, see this example from the docs where a recursive method is optimized to a few sequential commands when some of its parameters are constants:

http://dotty.epfl.ch/docs/reference/metaprogramming/inline.h...

This effectively makes it possible to have a limited form of partial evaluation.

Re: Scala 3.0

#64

Post by doikor »

cutler wrote: post #32
paavohtl wrote: post #16

Earlier quoted context omitted.

Literal types quite simply means that values are types. For example in TypeScript the literal type "Foo" is a special string type, where the only valid value is the literal "Foo" – assigning "Bar" to a variable with the type "Foo" is a compile time type error. Literal types can be combined into union types like any other type.

Sounds like more Scala sophistry. I thought they were supposed to be aiming for pragmatism with Scala 3.

This is just making clear and easy to use something that people did using some type level magic (see shapeless Witness).

Something that people used through ugly hacks becoming part of the language natively in a easy to use and understand (and faster to compile) way sounds very much like pragmatism to me.

Here is the source code to Witness (and other singleton stuff in shapeless) https://github.com/milessabin/shapeless/blob/main/core/src/m...

Re: Scala 3.0

#66

Post by serial_dev »

hocuspocus wrote: post #29
isbvhodnvemrwvn wrote: post #22

Earlier quoted context omitted.

I think apart from streams it was Kotlin that did the trick.

How so? Kotlin doesn't even have proper pattern matching.

What they probably meant is that both Scala's and Kotlin's improvements pushed Java to improve. Both languages had many different features that back then weren't available in Java but since then got added to the Java language, and that made Java better, too.

Re: Scala 3.0

#67

Post by riffraff »

humps wrote: post #33
kimi wrote: post #7

While we wait for an official document: https://docs.scala-lang.org/scala3/new-in-scala3.html - there is quite a lot of things in there!

There is a blog post now https://www.scala-lang.org/blog/2021/05/14/scala3-is-here.ht...

I grinned a bit looking at that blog post and seeing how the highlighting of contributor names is completely messed up, presumably because of a bad regex.

Feels ironic, since Scala has a very advanced type system that would prevent such bugs, but the page contains the most classic issue of not handling non-ascii characters properly :)

Re: Scala 3.0

#68

Post by wiradikusuma »

I can't find this anywhere, maybe someone could help answer:

1. How much better is the performance? (In terms of compilation speed, and runtime)

2. Compatibility with Graal Native?

Re: Scala 3.0

#69

Post by kjaer »

mxcrossr wrote: post #14

> Fix typo in file name #12181 Tasty: set experimental to zero #12438 Ah key commits that you just know you have to bump the version up after receiving.

Luckily, these commits came in before the bump to 3.0.0! The second one, at least, seems to have been in preparation for the stable release.

Re: Scala 3.0

#70

Post by MrPowers »

I am excited about Scala 3. Scala is a powerful tool that can make teams hyperproductive. Here are the tooling shifts that can broaden the Scala 3 userbase:

* Community switching from SBT to Mill

* Community agreeing on automated code formatting and everyone using the same scalafmt settings. After using automated code formatting tools like black for Python and gofmt, programmers really don't want to talk about whitespace formatting on every PR. Scala has a lot of syntax, so this is more important than you might imagine. They need to change from this detailed style guide (https://docs.scala-lang.org/style/) to "use these scalafmt settings and don't talk about code formatting anymore"

* Make it clear what libraries are recommended for certain tasks. If you search for "scala json libraries" you'll arrive at these 16 options: https://stackoverflow.com/a/14442630. Devs don't want to do an extensive research project to figure out what JSON lib to use.

* Shift from Scalatest to utest / munit for the reasons outlined here: https://github.com/com-lihaoyi/utest#why-utest

* Fill in "obvious library gaps" with good solutions. Scala needs a graph library that's usable like networkx for example. Li's libs are so popular cause he exposes beautiful Python-like interfaces (with crazy, performant Scala implementations under the hood).

* Embracing devs that want to use Scala as a "better Python" rather than giving them the message "if you use Scala, you need to do it the Scala-way". Scala is a multi-paradigm language and using the language in different ways should be encouraged.

* Getting the community to use the Principle of Least power is perhaps the hardest: https://www.lihaoyi.com/post/StrategicScalaStylePrincipleofL.... I find the doc to be cut-and-dry, but have found it less useful than I originally thought for resolving technical disputes.

The hard work has been done to build Mill, utest/munit, scalafmt, metals, etc. Scala just needs to make some opinionated choices so the ecosystem is appealing to ppl that aren't as into programming.

It'll be interesting to see if Spark is able to upgrade to Scala 3 or if they get stuck on Scala 2.13.

Post reply on HN