21 ms·

Scala 3.0

• xvilka 5y ago
  I wonder why it's not on the official site [1]. [1] https://www.scala-lang.org/ https://www.scala-lang.org/
  • txdv 5y ago
    they just created a tag, i guess they are preparing the press release :)
    • kjaer 5y ago
      Indeed, the blog post is up now! https://scala-lang.org/blog/2021/05/14/scala3-is-here.html https://scala-lang.org/blog/2021/05/14/scala3-is-here.html
• logicchains 5y ago
  Is Dotty the official compiler now?
  • hardlianotion 5y ago
    Yes
• leroman 5y ago
  I get paid to write TypeScript, it has come a long way to a relatively enjoyable experience compared to how expressive i feel with Scala. Looking forward to giving Scala 3 a spin to learn whats new
  • a_humean 5y ago
    I was looking at dotty/scala 3 earlier in the year and I was quite surprised to see familiar friends from Typescript in the form of literal types and union types. val scala: "Scala" = "Scala" const typescript: "Typescript" = "Typescript" "Scala" | "Typescript"
    • KMag 5y ago
      This creates two types with quotes in their type names, and then creates a union type of the two? Then the compiler needs to determine if the token's context requires a type or a value, and disambiguate accordingly? In the example above, the created type "Scala" is distinct from a type Scala, correct? I did some quick poking around for Scala literal types, but I found stuff like https://github.com/jeremyrsmith/literal-types https://github.com/jeremyrsmith/literal-types , which don't look like the example above.
      • nicktelford 5y ago
        No. It's a Singleton type, which means that instead of just being a String, it has to be exactly the String "Scala". i.e. val x: "scala" = "scala" // would compile val y: "scala" = "java" // would produce a compile error Union types are an orthogonal concept, and work as you'd expect: val z: String | Int = "foo"
        • KMag 5y ago
          Interesting, and I presume it works for singletons of any type, correct? val x: 1 = 1 val y: 2.718281828 = 2.718281828 That's kind of cute. I presume its main purpose is for overrides in order to get something similar to template specialization. C++ templates can be specialized by types and by values, but Scala method overrides are only by type, and literal types allow you to present a value as a type, so if the value can be statically proven to match, then the override is called?
          • paavohtl 5y ago
            In TypeScript perhaps the most important use case for literal types is the ability to to create discriminated unions, or algebraic datatypes (ADTs). Many modern languages have a separate feature for this (such as enums in Rust), but in TypeScript they can be constructed using literal and union types. Here's an example: interface ProductOffer { kind: 'productOffer' eans: Ean[] discountPercentage: number } interface GroupOffer { kind: 'groupOffer' groups: GroupId[] discountPercentage: number } type Offer = ProductOffer | GroupOffer Also check the TypeScript handbook for more information: https://www.typescriptlang.org/docs/handbook/2/narrowing.html#discriminated-unions https://www.typescriptlang.org/docs/handbook/2/narrowing.htm...
  • maxov 5y ago
    As someone who has spent a lot of time diving deep into Scala (I worked on compiler related semantic tooling for scalameta, worked on a experimental parallelizable Scala compiler, and even have a single commit in this release from almost four years ago LOL), and who more recently has been working with TypeScript, I find this really interesting and agree in some ways. Scala 2.x already had path-dependent types, which combined with implicits and type inference were technically sufficient to implement versions of of the dependent function types we have now in 3.x. In my opinion, how you did this previously could get really clunky (See e.g. hlist mapping in https://github.com/milessabin/shapeless/blob/8933ddb7af63b8be75704617ffdf5141ff1a1ab7/core/src/main/scala/shapeless/ops/tuples.scala#L577 https://github.com/milessabin/shapeless/blob/8933ddb7af63b8b...). Lots of things that frankly felt like casting magic spells, and there were sometimes fragile and weird bugs especially with how implicits were resolved, see e.g. https://github.com/scala/scala/pull/6139 https://github.com/scala/scala/pull/6139. The native type-level meta-programming coming in 3.x along with a lot of streamlining of the underlying type system and implicit resolution rules (e.g. https://github.com/lampepfl/dotty/pull/5925 https://github.com/lampepfl/dotty/pull/5925) could help a lot. This is just one example of a more advanced feature, but there are lots of things like this that changed in Dotty (maybe the most interesting is the DOT calculus that makes a better backbone for the type system). I don't know what tooling for Scala 3.x looks like, but even Intellij's frankly amazing Scala plugin broke down sometimes for 2.x. After using TypeScript, I just personally enjoyed the experience better. Technically Typescript's type system is equally as powerful as Scala's, but the primitives for expressing more complicated types just seem much easier compared to the path-dependent stuff you would need to do in Scala. I was amazed to find stuff like this https://github.com/aws-amplify/amplify-js/blob/dedd5641dfcfce209433088fe9570874cd810997/packages/datastore/src/types.ts#L263 https://github.com/aws-amplify/amplify-js/blob/dedd5641dfcfc... in mainstream wide usage. I'm not even sure how you could write these type of transformations as well in any version of Scala. I suppose maybe records work, or in this specific case there are functional patterns that are preferred. Caveat, I haven't followed Dotty for a couple years now, so I could be missing a lot. Regardless, I have really enjoyed the tooling around Typescript as well as the design. The real-world usage of more complicated dependent types (and there are good uses IMO) have been more fluent and easier to understand, and less dependent on tricky behavior like for implicits. VS Code's tools are really magical, and I hope with some of the amazing underlying work done in Dotty the Scala developer experience could look more like that.
• kimi 5y ago
  While we wait for an official document: https://docs.scala-lang.org/scala3/new-in-scala3.html https://docs.scala-lang.org/scala3/new-in-scala3.html - there is quite a lot of things in there!
  • humps 5y ago
    There is a blog post now https://www.scala-lang.org/blog/2021/05/14/scala3-is-here.html https://www.scala-lang.org/blog/2021/05/14/scala3-is-here.ht...
    • riffraff 5y ago
      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 :)
• deleted 5y ago
  [deleted]
• killingtime74 5y ago
  Scala is not perfect but it’s very good. It’s competitive pressure arguably improved Java (streams, pattern matching, data classes).
  • isbvhodnvemrwvn 5y ago
    I think apart from streams it was Kotlin that did the trick.
    • pulse7 5y ago
      It doesn't matter "who did the trick". It is well known that Java was influenced by ideas in other programming languages from the beginning. And also other languages - including Scala and Kotlin - are similar in this respect... So yes: Kotlin influenced Java and Java influenced Kotlin. Let's compare final products with final products and not "how did we get there"...
    • pjmlp 5y ago
      Both are guest languages, Java owns the platform. What did the trick are the other programming languages that can stand on their own as platforms.
      • deleted 5y ago
        [deleted]
      • asdasdasdch 5y ago
        Scala can compile to JS or LLVM. Why owning a platform when amazing ones already exist?
        • pjmlp 5y ago
          One either gets to say where the platform goes, or keeps playing catch-up with its features, requires additional tooling, wrapper libraries, care about FFI, IDE plugins that understand all of that in a coherent way.
    • 5y ago
• mxcrossr 5y ago
  > 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.
  • kjaer 5y ago
    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.
  • dtech 5y ago
    Those are only the commits between 3.0.0-RC2 and 3.0.0
• Barrin92 5y ago
  Always wanted to look into Scala but it seemed very intimidating. Is there a good intermediate 'How to' for Scala 3 anyone can recommend?
  • hocuspocus 5y ago
    In no particular order: - If you're at least a little familiar with Java, Scala for the Impatient is pretty good, though a little dated (I think the last edition covers Scala 2.12). - Daniel Westheide's blog: https://danielwestheide.com/books/the-neophytes-guide-to-scala/ https://danielwestheide.com/books/the-neophytes-guide-to-sca... - https://www.scala-exercises.org https://www.scala-exercises.org (at least the part on the standard library). - https://www.handsonscala.com https://www.handsonscala.com Note: Scala 3 introduces quite a bit of new syntax that is specifically designed to make intimidating features less so. But at the beginner/intermediate level it won't matter too much, for instance if you learn how to implement typeclasses the old way, you'll easily understand the new syntax. Also the Scala Center has committed to providing a lot of training material along with the Scala 3 release.
  • lmm 5y ago
    If you know Java then you can start by writing very Java-like code using the same libraries you would in Java - there are a lot of intimidating functional techniques available but you don't have to use them from day 1 (indeed I'd say you probably shouldn't use them until you understand why you would want to). IMO you're much better off picking a small corner of a JVM project (e.g. maybe a migration tool or a couple of tests) and using a little Scala in practice, rather than trying to learn it all to start with.
  • Milner08 5y ago
    The thing with Scala is it depends on the pattern you want to use. I am a big advocate of it, and the function pattern being used fully with something like Cats or ZIO. However I would not suggest starting there. I would start by playing about with the syntax and writing standard OOP code, as its probably what you're most familiar with. When you want to dive into the power of FP then I recommend http://eed3si9n.com/herding-cats/ http://eed3si9n.com/herding-cats/. Its basically a companion to the Haskell book 'Learn you a haskell' (http://learnyouahaskell.com/ http://learnyouahaskell.com/) that takes the theory coming up in that book and translates it to Scala. I found it the most direct explanation of the different types and theories (Monads, Functors, Applicative, etc).
• deleted 5y ago
  [deleted]
• wokwokwok 5y ago
  I presume from the major increment this is a breaking change. What will tangibly be broken with 3.0, and is there any migration tooling? — Nevermind, https://scalacenter.github.io/scala-3-migration-guide/ https://scalacenter.github.io/scala-3-migration-guide/ seems to cover this quite respectably.
  • valenterry 5y ago
    Yes - and in particular, Scala 3.0 makes use of TASTy, which will reduce backwards/compatibility issues a lot for future development. Luckily Scala has one of the strongest statical type-systems, which will make migrating much smoother (not completely painless though)
• charkubi 5y ago
  Docs: https://docs.scala-lang.org/scala3/ https://docs.scala-lang.org/scala3/
• truth_seeker 5y ago
  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 ?
  • hocuspocus 5y ago
    http://dotty.epfl.ch/docs/reference/metaprogramming/inline.html 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.
    • kjaer 5y ago
      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.html#recursive-inline-methods http://dotty.epfl.ch/docs/reference/metaprogramming/inline.h... This effectively makes it possible to have a limited form of partial evaluation.
• valenterry 5y ago
  Amazing!!! Great to see Scala improving at such a fast pace! I'm especially excited about union/intersection types. I think we could all witness how well they work out in typescript and I believe that every language with the concept of subtyping should have this feature. It is one of the things that make working in a statically typed language feel much more dynamic/lightweight without giving up on safety guarantees.
  • KajMagnus 5y ago
    Amazing! That's the word that popped up in my mind too. Scala 3 is my on shared 1st place favorite language Union/intersection types — indeed, I use all the time, in Typescript. And Opaque Types looks lovely too. All across my code base, I have type aliases like "UserId" or "PageId" or "PostNr" or "DraftNr" etc, and it'll be nice that this can now be type safe for real, not just type aliases. (Just waiting for opaque types to arrive to Typescript too.)
  • geodel 5y ago
    From their blog: > After 8 years of work, 28,000 commits, 7,400 pull requests, 4,100 closed issues – Scala 3 is finally out. Since the first commit on December 6th 2012... I mean it is lot of work for sure. But is it such a fast pace?
    • valenterry 5y ago
      It is. Scala does not use semver. The last major release was 2.13.0, not 2.0.0. That's a bit confusing I guess. What that means is, they haven't just added some features, they redesigned/rewrote to language from ground up to simplify it and make formally sound. I actually don't know any other language that does that (though I'm sure there are others, maybe Haskell is one of them). In addition, a lot of features are very impactful and unprecedented, such as match types. To me, for a mainstream language (even though a smaller one), it certainly feels fast pasted.
      • dtech 5y ago
        they switched to semver starting with Scala 3. They intend to remain compatible throughout 3.x.
• deleted 5y ago
  [deleted]
• rtoway 5y ago
  The optional brackets really makes the code look clean and easy to read!
  • acjohnson55 5y ago
    I largely agree. It was (and is) a contentious issue, but I think it helps a lot in removing textual noise, in most cases. And it's always possible to add the brackets in where clarity helps.
    • vips7L 5y ago
      I largely disagree and am not looking forward to dealing with mixed brace code at work.
      • caoilte 5y ago
        Hopefully there will be a scalafmt rule that can enforce consistency.
        • The_rationalist 5y ago
          And hopefully more than 0.1% of projects will turn the lint on..
• Sunscratch 5y ago
  Amazing work. Scala language and it’s ecosystem are amazing. Thanks to Odersky and all contributors, early adopters.
• wiradikusuma 5y ago
  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?
  • kjaer 5y ago
    Graal Native takes JVM bytecode as input, and Scala 3 is binary compatible with Scala 2, so it should be compatible with Graal Native out of the box.
    • brabel 5y ago
      Does Scala 3 not advance the capabilities of Scala Native, making GaalVM unnecessary (if still an option) for running Scala without the JVM?
      • kjaer 5y ago
        Scala Native and GraalVM Native Image are projects with different goals, so I wouldn't say that one makes the other unnecessary. Both projects aim to compile to native code, and have use-cases for projects where the JVM startup time is too high. However, one of the main goals of Native Image is to offer as much partial evaluation (PE) at compile-time as possible. Scala Native does also seem to do some PE, but my understanding is that it's less than what Native Image does. However, Scala Native has the advantage of working on a representation of the source code instead of the byte code, and may therefore be able to do certain Scala-specific optimizations that would be more difficult for Native Image. I think different projects may find that either one or the other project may be more suitable to their needs, so I think both projects can coexist.
        • mwcampbell 5y ago
          > However, one of the main goals of Native Image is to offer as much partial evaluation (PE) at compile-time as possible. This is tangential, but I wonder if Native Image's focus on compile-time PE, and the overall design of GraalVM, would make it feasible to AOT-compile a sufficiently static subset of JavaScript to efficient native code. If so, that could influence my choice of language for new projects.
• MrPowers 5y ago
  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/ 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 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 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/StrategicScalaStylePrincipleofLeastPower.html 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.
  • acjohnson55 5y ago
    Speaking of Li's work, he's also done a lot to improve the REPL and scripting experiences for Scala. Combined with Scala 3, this is great for rapid prototypes, simple tools, and glue.
• halayli 5y ago
  looking at the all time contributors, it further solidified my belief that a team of 2 to 3 solid engineers can almost take on any project that comes their way.
  • vaylian 5y ago
    Given enough time
    • kaba0 5y ago
      “3 women won’t birth 1 child in 3 months” There are problems you simply can’t throw more developer at. Compilers are very much that.
• atbpaca 5y ago
  This is super cool! Looking forward to metaprogramming in Scala 3!
  • asdasdasdch 5y ago
    Choose your flavor @ https://docs.scala-lang.org/scala3/guides/macros/ https://docs.scala-lang.org/scala3/guides/macros/
    • ptrwis 5y ago
      With "Expr" it should be possible to built an ORM similar to Entity Framework, it allows to write elegant queries thanks to Expression Trees in C#.
    • akra 5y ago
      This looks a little like inline in F# where it allows more generic method cases than standard generics do in C#/Java. Looking at the documentation I'm wondering does it allow things like - "any input type that supports the divide operator"? It's a feature I've appreciated previously when writing high performance math code on the .NET side.
• acjohnson55 5y ago
  I'm so psyched about this. I've followed the development of Scala 3 for pretty much the whole voyage, and I think they've done an incredible job bringing the community along through some pretty radical changes to the language. It has definitely not been an easy process herding a community with very big, informed, divergent opinions on the language. In the end, I think they did an awesome job. Many, many sacred cows of old Scala were confronted. I think the result is a much more approachable language, where simple things are easier.
  • agbell 5y ago
    I totally agree. I love the direction of Scala 3. This quote says it all I think: "Scala 3 takes a slightly different approach [from Scala 2] and focuses on intent rather than mechanism. Instead of offering one very powerful feature, Scala 3 offers multiple tailored language features, allowing programmers to directly express their intent" So rather than something like implicits, that can be used N different ways, only 2 of which are practical, Scala 3 adds those 2 features explicitly. https://docs.scala-lang.org/scala3/new-in-scala3.html https://docs.scala-lang.org/scala3/new-in-scala3.html
    • swader999 5y ago
      The days I spent chasing implicits are still lost to me forever.
      • darksaints 5y ago
        They should have never been a language feature before IDEs were capable of working with them and exposing them. Luckily they do now...but Scala 3 makes it so that understanding them with a simple text editor is much easier. The fact that they have to be imported in a way that acknowledges their usage is a simple but important way to ease that burden, and the distinction between `given` and `using` is extremely helpful for understanding them.
        • agbell 5y ago
• meatmakesdumb 5y ago
  Personally I'm looking forward to scala native 1.0 more than anything else. We'll have a strong Haskell competitor. I dont like jvm.
  • logicchains 5y ago
    What about OCaml? Soon it'll finally have multicore (and an effect system!).
  • deleted 5y ago
    [deleted]
  • amelius 5y ago
    You can convert .class files directly to native. https://dzone.com/articles/profiling-native-images-in-java https://dzone.com/articles/profiling-native-images-in-java
  • amw-zero 5y ago
    How is current Scala not actually a Haskell competitor today? Superficial dislike of a VM isn't a valid reason.
    • whateveracct 5y ago
      Haskell's runtime is just better for pure FP than the JVM. GHC's optimizations and general TCO go a long way.
      • amw-zero 5y ago
        ‘Just better’ is not a valid argument. Better at what? Better for what use cases? If we start to treat software like fashion, I don’t think we’re going to make very good decisions in the coming years.
        • whateveracct 5y ago
          I mean "just better" at every use-case? It eliminates the cost of functions where JVM languages cannot due to its limitations. I really don't think I'm treating software like fashion - I'm speaking from years of practical experience here. The main thing FP on the JVM does better is be permitted by your employer lol. So if we're talking runtime vs runtime, there's no use-case. In general, it's all soft/social reasons.
• jules 5y ago
  Scala 3 + VS code + worksheets is my favourite exploratory programming environment. Its has: * Powerful functional features * Powerful OO features * Imperative features * Powerful type system * Great stdlib * Great syntax * Very fast write/test cycle with worksheets, way better than a REPL * Great IDE features such as autocomplete Scala may not be the best on any one axis, but the combination is unparalleled.
  • sireat 5y ago
    I've been extremely happy with IntelliJ plugin for Scala. I do use Visual Studio Code for Python,JS,web, etc. What would be advantage of using VS Code over IntelliJ for Scala?
    • jules 5y ago
      I'm familiar with VS code and have a set up that I'm familiar with (shortcuts & settings) and I've only briefly looked at IntelliJ, so I'm not qualified to answer this question. What is the reason you're using IntelliJ rather than VS code?
      • merb 5y ago
        some shortcuts are just stupid. sorry, but coming from a mac some things are a little bit wierd.
      • sireat 5y ago
        Writing Scala with IntelliJ is just so fun - 99% of time I get the right suggestion for Scala and/or Java libraries that I have not imported yet. Nice style suggestions that do not nag. Instant ScalaDoc generation. Pretty much picks up on all my brain farts. I imagine it is because of deep integration with JVM - after all IntelliJ started with Java. By comparison VS Code is just an editor underneath without the I in IDE. Theoretically VS Code is a bit like emacs or vim, you can set it up to do everything for your language but it takes a lot of tweaking.
        • 5y ago
• namelosw 5y ago
  Congratulations! I always have great respect for Scala because itself and the community tried to adopt and push the novel idea in the industry. Take a look at the changes, they're no joke to design and implement. At the same time, they're also trying to make the language consistent and simple. (Yes, I mean simple, not easy or single-paradigmed) They are taking the hard way, and not only there are not enough people to appreciate the effort, but also attract some hatred from time to time. I hope Scala 3 would bring us and itself a bright future, and inspire more languages to move forward. (For example, there are a lot of type features added to TypeScript in most releases because it needs to do the typing on existing dynamically typed languages, it may also be a hint that dependent type actually makes sense in mainstream languages).
  • amw-zero 5y ago
    Can you elaborate on the changes in TS that hint at dependent types? That's interesting.
    • namelosw 5y ago
      I'm not referring to some specific changes. It's just there are many type operators already and still not enough to express JavaScript. In the earlier versions of TypeScript, I often stuck with something natural in JavaScript but cannot express the same thing with type annotations - It's like opening a pandora box, once some advanced type operators have been introduced, whenever I played with them I would quickly found more type operators to be desired. And so it did. Things were getting better over years, there were a lot more type operators, mapped types, the infer keyword, etc. I feel it points to a direction: There is still a lot of existing JavaScript functions' type depend on the input which cannot be well-typed. For example, there are functions similar printf in most languages, or return type T when 0 is passed otherwise return type U. To satisfy those cases, we'll basically reinvent a whole new programming language in the type system - if the new language happens to be JavaScript itself it would be similar to other dependent type systems.
      • aabbcc1241 5y ago
• augustk 5y ago
  I think the best evolution of a programming language is when some features are removed and replaced by a unifying concept which makes the language both smaller and and more expressive. Has that happened in Scala 3?
  • kjaer 5y ago
    Yes! See the redesigned implicits [1] and macros [2]. [1]: https://dotty.epfl.ch/docs/reference/contextual/motivation.html https://dotty.epfl.ch/docs/reference/contextual/motivation.h... [2]: https://dotty.epfl.ch/docs/reference/dropped-features/macros.html https://dotty.epfl.ch/docs/reference/dropped-features/macros...
  • valenterry 5y ago
    I totally agree with that sentiment. Not only about evolution but in general. A good programming language trues to use unifying concepts as much as possible. Fortunately, Scala is one of the best (statically typed) languages in that regard that I ever used.
  • agbell 5y ago
    In some areas it is explicitly the opposite that happened, and in a way that is for the best — see implicits. Scala 2 is a very flexible language and a lot of outsider complaints seem grounded in this flexibility. Scala 3 is more opinionated in some ways: "Opinionated: Contextual Abstractions One underlying core concept of Scala was (and still is to some degree) to provide users with a small set of powerful features that can be combined to great (and sometimes even unforeseen) expressivity. For example, the feature of implicits has been used to model contextual abstraction, to express type-level computation, model type-classes, perform implicit coercions, encode extension methods, and many more. Learning from these use cases, Scala 3 takes a slightly different approach and focuses on intent rather than mechanism. Instead of offering one very powerful feature, Scala 3 offers multiple tailored language features, allowing programmers to directly express their intent " I think it is a very practical and grounded focus change. https://docs.scala-lang.org/scala3/new-in-scala3.html https://docs.scala-lang.org/scala3/new-in-scala3.html
    • 5y ago
• rnikander 5y ago
  Looking at the new features. Can anyone say what dependent function types are good for? In the example (https://dotty.epfl.ch/docs/reference/new-types/dependent-function-types.html https://dotty.epfl.ch/docs/reference/new-types/dependent-fun...), what's the difference between: def extractKey(e: Entry): e.Key = e.key and: def extractKey(e: Entry): Entry.Key = e.key // the way I'd normally think of it
  • esarbe 5y ago
    With dependent types, each `e.key` has it's own and separate type. So, if you have two `e`s, the type of the first e's key will not match the type of the second e's key. So, with: def process(p: Path, key: p.Key): Something = ??? this will not compile: val p1: Path = ??? val p2: Path = ??? process(p1, p2.key) <- compile-time-error
    • rnikander 5y ago
      Interesting. Thanks! I've been using a lot of Swift lately, and they have a generic type roadmap that talks about "existential types" and being able to "open" an existential. This looks very similar.
      • esarbe 5y ago
        I don't know about in Swift, but in programming languages in general, existential types are usually a concept different from dependent types.[0] [0] https://stackoverflow.com/questions/292274/what-is-an-existential-type https://stackoverflow.com/questions/292274/what-is-an-existe...
• haolez 5y ago
  I'm in need of a functional language for a small part of my system and I'm considering Scala and Purescript[0] (mostly because of their ecosystems). Maybe Scala 3 is a good time to be boarding Scala's ship. I'd appreciate if anyone has any advices of one vs the other. [0]https://www.purescript.org/ https://www.purescript.org/
  • flurdy 5y ago
    I wouldn't jump on the Scala 3 ship just yet. Maybe if mostly a learning project but not for an important part. Whilst it was not a surprise release there will be long time until a majority of the libraries and frameworks will also work with it. The big ones are mostly there, but there are lots of smaller ones that are not and there will be teething problems, even after a long alpha-beta-rc train. Scala 2.13 is still great.
    • Scarbutt 5y ago
      Looks like many libs already support Scala3: https://index.scala-lang.org/search?targetTypes=jvm&scalaVersions=scala3&q=*&page=1 https://index.scala-lang.org/search?targetTypes=jvm&scalaVer...
      • virtualwhys 5y ago
        Not sure what Play Framework is doing at the top of the list, will most likely be many months before a Scala 3 supported version is released. Same for Spark, DB libraries, Akka, etc. Basically everything with large dependency graphs that depend on macros or removed Scala 2 features (e.g. abstract type projections, arghhhh) will take significant time to port over to Scala 3. What has had Scala 3 support from early on in the release cycle are the FP/Typelevel projects, which are obsessively maintained by the I'll-sleep-when-I'm-dead FP crowd.
        • ahel 5y ago
          Is Play Framework still used/developed? Haven't seen any progress from performance in the last years. Happy to get corrected, though.
• sesm 5y ago
  So, they removed implicits and introduced a number of other tools to replace common usecases for implicits. Can we take a step back now, and reflect on what was the original problem implicits were designed to solve and how it is solved now in Scala 3? I've heard the original problem was that they wanted a chain of functional transformations to return the same type of collection (unlike, say, Clojure or Java 9 which return a Stream).
  • amw-zero 5y ago
    I still don't fully understand it, but they wrote a lot about the topic here: https://dotty.epfl.ch/docs/reference/contextual/motivation.html https://dotty.epfl.ch/docs/reference/contextual/motivation.h...
  • halfmatthalfcat 5y ago
    They didn't "remove" implicits in the absolute sense but they made it much more ergonomic to work with implicit-like behavior using the "given" keyword now.
    • sesm 5y ago
      Sorry, maybe I was wrong. I was looking at this article https://docs.scala-lang.org/scala3/new-in-scala3.html https://docs.scala-lang.org/scala3/new-in-scala3.html and I had an impression that they split implicits into several other more specific features.
      • agbell 5y ago
        That is my understanding of what they did. "Scala 3 takes a slightly different approach [from Scala 2] and focuses on intent rather than mechanism. Instead of offering one very powerful feature, Scala 3 offers multiple tailored language features, allowing programmers to directly express their intent" So rather than something like implicits, that can be used N different ways, only 2 of which are practical, Scala 3 adds those 2 features explicitly.
  • melolife 5y ago
• zeec123 5y ago
  It is so bad, that in julia functions are not first class. Instead, I would love to use scala 3 for machine learning since this is the perfect type system for such a task, but linear algebra support is not good enough.
  • kinjba11 5y ago
    What do you mean by "not first class"? https://docs.julialang.org/en/v1/manual/functions/#man-anonymous-functions https://docs.julialang.org/en/v1/manual/functions/#man-anony...
    • zeec123 5y ago
      It means I cannot fully specify the type of function my interface expects as an argument. A function is of type ‘Function’. There is no way to define it with the type of its argument or the type of what it returns.
      • eigenspace 5y ago
        Actually, Julia functions are all subtypes of Function. Every julia function has a unique type. We don't parameterize a function by it's input and return types because functions are extremely polymorphic in julia. However, there's lots of tricks one can do to dispatch on whether or not a given function have methods that satisfy some sort of interface, see here: https://github.com/oxinabox/Tricks.jl#we-can-use-static_hasmethod-to-declare-traits https://github.com/oxinabox/Tricks.jl#we-can-use-static_hasm... Using this technique, you can do compile time dispatch on things like input and return types.
        • saiojd 5y ago
          Functions are polymorphic in many languages that let you annotate the their types. The concern is not really for dispatch here, it's for readability/correctness.
          • 5y ago
• doggodaddo78 5y ago
  Not to denegrate or barf on anyone's birthday cake but IIRC there were some complaints of unfriendly community support interaction styles. Is this still the case?
  • deleted 5y ago
    [deleted]
  • deleted 5y ago
    [deleted]
• monksy 5y ago
  Not a fan of the optional brackets. It feels like a huge, tone-deaf step back. It's also being agressively pushed for by the founder. Also, it adds "if then end if" to the mix as well. Sigh. https://dotty.epfl.ch/docs/reference/other-new-features/indentation.html https://dotty.epfl.ch/docs/reference/other-new-features/inde... RIP Code samples. Many of the other features are nice adjustments.
• deleted 5y ago
  [deleted]
• bgorman 5y ago
  What is the best way to get ramped up with Scala 3 for a dev without Scala experience, but strong FP experience.
  • esarbe 5y ago
    Have a look at the typelevel ecosystem of libraries. [0] [0] https://typelevel.org/ https://typelevel.org/
• zug_zug 5y ago
  Cool I guess. I just notice that say, unlike PHP, I don't know if there's a single thing in the scala 3.0 release I care about (as somebody who's preferred language as scala) [Edit: Except for fixing implicits, big win]. A lot of times it feels like it's a language with so much potential which then misses some basic real-world use-cases for the 99% who couldn't care less about covariant blah blah, and just want a clear, fast, reliable, reusable programming language as a means to an ends of delighting millions of users. Maybe I'll write a blog-post about it, but as I practice leet-codes in scala, I miss relatively basic things like c-style for loop (so I can use a for loop on linked lists rather than a while), or things like a list that can have more than Int.MaxValue numbers.
  • nine_k 5y ago
    It just so happens that "reliable, reusable" and "covariant blah" are interlinked — if you want any form of type inheritance, of course (which I usually don't).
• scruffyherder 5y ago
  It’s pretty impressive that an old Amiga presentation manager is still getting updates . Or is it more impressive that they have walls of text without saying what scale is? Also why would they wear an old product like Scala like a skin suit ?
• jmfldn 5y ago
  A big moment for Scala. I've used it professionally for 5 years and am still in love with it. The expressiveness, the power, everything about it is a joy. This just takes it to another level by removing a few warts and simplifying it whilst adding some amazingly useful new features. A really tricky balance needed to be struck. I think they've pulled off an unlikely and amazing feat with this release.
• moocowtruck 5y ago
  do i still need the jvm?
  • esarbe 5y ago
    No. [0] [0] https://www.scala-js.org/ https://www.scala-js.org/
• jamil7 5y ago
  I haven’t kept up with Scala but the LLVM target looks pretty interesting. Is anyone deploying it this way?
• playing_colours 5y ago
  Does Scala have a chance to regain popularity? It was my main language for 5 years, and there was always a variety of Scala jobs in Berlin: companies of different industries, sizes. Recently, I mainly used Python at work. I love Scala and wonder if it makes sense to invest in keeping up my Scala 3 skills.
  • Varqu 5y ago
    It looks like it's not the case, at least looking at: https://germantechjobs.de/jobs/Scala/all https://germantechjobs.de/jobs/Scala/all or https://swissdevjobs.ch/jobs/Scala/all https://swissdevjobs.ch/jobs/Scala/all
  • esarbe 5y ago
    There are lots of Scala jobs in finance and its weird sibling cryptocurrencies. These pay very well, although I myself wouldn't touch those (anymore). There are also lots of agencies using Scala, some machine learning and security stuff. Munich is a good place, Berlin, Zurich and Lausanne, if you want to stay in Europe. I love the language and I'm very happy to get paid to do stuff in it. I don't think I ever learned that much using just one language, Scala is definitively a class of its own.
  • zmmmmm 5y ago
    It's hard to say there isn't a downwards trend at this point: https://trends.google.com/trends/explore?cat=31&date=today%205-y&q=scala,groovy,kotlin https://trends.google.com/trends/explore?cat=31&date=today%2... Kotlin and Groovy both look pretty stable - both having core uses in their domains that I am guessing support continued traction as "the best tool for what they do". Scala I think peaked when it had the overlap b/w business use and data science. I feel like Kotlin / Scala / Java are all after the same essential core market - a solid, type safe language to shoulder the huge broad need of enterprises to keep business software pumping away reliably. So they are essentially all part of the ebb and flow of the one giant "JVM" ecosystem. Groovy sits a little outside of that since it specifically targets a different type of problem (providing an optimally integrated JVM scripting language for DSLs and rapid application development).
• zmmmmm 5y ago
  Fascinating to see not just the breadth and depth of new features but also what has been targeted. Stuff like Python-style significant whitespace[0] was definitely not on my radar. On the one hand, Scala is such a seductive language - there is literally nobody it doesn't cater to. Whether you're into FP, OO, data science, enterprise business logic, strict conservative style explicit semantics vs going wild with implicits and DSLs etc, and now whether you like significant whitespace or not ... But on the other hand its the same story as always - all this crazy optionality of features mean its got such a huge surface area for people to understand. Its a language where I get what I feel is functionally competent and then dive into a codebase in github and I can barely even recognise the syntax, let alone feel confident to make a change. [0] https://dotty.epfl.ch/docs/reference/other-new-features/indentation.html https://dotty.epfl.ch/docs/reference/other-new-features/inde...
• machinesbuddy 5y ago
  Scala was a unique language a few years ago. I'm very happy I adopt it a few years ago and I owe it a lot. As a lot of other modern languages or features of mainstream ones do. However, with the existing alternatives nowdays, Scala doesn't hold the same position. I have not coded in Scala for ~2 years and I'm not sure I'll ever need to. Anyway, all the best for Scala's awesome team and its ecosystem.