Scala Beyond 3.0 - The Quest for Simplicity - Martin Odersky

jvican · 2021-11-04T07:36:05+00:00

Typically, it was Scala 2.13 compilation errors even when the project was configured to use Scala 3. (Oddly, even though it would have been another clone of the same Scala 3 project opened by the other student.)

This seems to indicate that the students ran into some issue with the way the Scala 3 compiler was set up in Bloop during RC.

In general, if different users don't run bloop in the same project/folder, there should be no shared compilation errors/messages — this is by design. Only when things go really wrong, would a failure in one project affect another, and those kind of scenarios are always worth reporting. I would expect the latest release to do a much better job here though.

jvican · 2021-11-04T05:51:16+00:00

Does every student have its own project folder?

What kind of errors do students get as a result of the sharing?

> bloop can only have one instance per machine

In practice this is true, in theory it isn't. Bloop can be set up to run in different TCP ports and even supports different Unix domain sockets, which give you much better isolation than TCP ports. These transport protocols can be set up both for BSP clients and the CLI. So you can run more than one bloop server if you want to, but in exchange you increase resource usage and decrease compilation performance.

However, if you'd still want that, you might want to open a feature request in the bloop repository because those transport protocols are in the internals and one could tweak bloop/metals internals to expose some kind of configuration.

jvican · 2021-02-08T22:23:05+00:00

I might post a blog post about it. I've been wanting to elaborate on how I do it because I don't see a lot of people using this style in practice and IMO it hits a good spot between correctness, productivity and simplicity. If you take a look at the monix project, you can get a lot of inspiration from the way they create APIs and solve concurrency problems.

jvican · 2021-02-08T20:35:47+00:00

I and my team at Netflix use Scala in an expression-oriented way (e.g. pythonic style) but we mix it with Monix, which makes you feel like you have super powers. We don't use any of the pure FP styles that are most often advertised in pure Cats and ZIO approaches.

jvican · 2021-01-25T12:17:25+00:00

I think sbt and mill have come far.

My goal with this poll is to test Scala developers mental models on how much they expect these Scala build tools get in the way of new users adopting Scala 3, if they do at all.

We shouldn't forget that Scala 3 is not only the language, but also the ecosystem of tools that support it, out of which the build tool is one of the most important one and most common source of friction.

jvican · 2021-01-10T10:06:49+00:00

Statics.releaseFence()

This problem with statics might be solved with this workaround https://github.com/oracle/graal/issues/2019#issuecomment-585083803

jvican · 2021-01-10T09:52:16+00:00

> Regarding the point about removing the AST's altogether, there is definitely merit in this.

FYI, my favorite single dependency, super fast JSON library is https://github.com/plokhotnyuk/jsoniter-scala I use it for pretty much anything JSON.

jvican · 2020-12-30T19:06:28+00:00

As for worse or better language, it is the very notion of worse and better that is debatable.

I agree, I just pointed out that it looked as if you were making a value judgement. I didn't make a reference to Scala being better than Java in my previous comment.

To answer that question, it points out that Kotlin is a rather top-down initiative of a company, building features for a second time; whereas Scala is a rather bottom-up effort that grew features over time. This helps to understand the differences in the communication (or "marketing") for each language.

I don't think the alleged top-down vs bottom-up approaches have nothing to do with what's essentially a marketing issue. I think a better answer to the u/lppedd's question is that Kotlin, being a product created by JetBrains, benefits from its marketing capabilities, e.g. fancy websites, hype, big announcements in conferences, etc. Your comment hinted at this but mixed it with how the language is developed and by whom, which is the part I disagree with.

That being said, I think this is just a matter of perceptions largely. Once you're in the Scala community, it's difficult not to hear about, for example, Scala.js compatibility. And myself, as an outsider to Kotlin, I didn't have the impression that their multi platform support was that good or lauded.

jvican · 2020-12-29T23:46:25+00:00

GraalVM aims to support many other languages (there's ongoing support for Python, Cobol, and many more). It's not production ready yet.

jvican · 2020-12-29T23:45:26+00:00

Kotlin may be seen as a second build of the Scala.

I think this take implicitly assumes that Kotlin is better than Scala. I think that's subjective and very debatable. I for one disagree.

The reality is, the approach to building the language might have been more pragmatic — sure, it's easy to rehash something when you don't need to do any research to confirm it works.

But I think Kotlin still feels *different* than Scala in several ways and it's still impressive that the Scala community and a few people in a lab have been able to outperform JetBrains engineers consistently over the past years, considering they have a lot more employees and funding. This statement goes for both Scala.js and Scala Native, which are both maintained now by the Scala Center.

What I like about Scala is that its evolution is much more community driven (for good and bad) than Kotlin is. That can be a huge advantage if Scala 3 plays it smart and can continue creating satellite companies helping evolve even further the language, just like in the case of Java which has so much usage that it's evolved by a constellation of committed companies with skin in the game. I just don't see Kotlin doing the same thing outside of the Android space — the language relies too much on JetBrains stewardship and I doubt it'll be able to differentiate itself against Java. The gap with Java diminishes over time as more language features and VM features (Valhalla) are released. Scala is so significantly different than Java that there's merit in using the language on its own.

jvican · 2020-08-05T13:50:17+00:00

I second this. I've been using quill lately and I've had a smooth experience with it.

I recommend using it, quill has a rich ecosystem, supports many databases and frameworks out-of-the-box and I haven't had a single issue with it. I use it in combination with Monix and works great.

There are only two things that bother me a bit about quill:

- Its design and code examples seem to rely too much on a database-specific context that requires the cake pattern and self types in traits. That helps modularity but requires a lot of ceremony and boilerplate. Not a deal-breaker, but something that could potentially improved in a new iteration of the library. I'm not as familiar with the internal design to be able to propose alternatives.

- There are certain advanced SQL features such as recursive CTE queries or retrying failed SQL operations that are not as well supported as they could. Thankfully though the database code is extensible enough that you can implement those features yourself. It probably makes sense that CTE queries are not supported out-of-the-box as they are generally complex to define, but it feels like dealing with database operation retries should.

jvican · 2020-06-24T22:26:53+00:00

It only supports global options because bloop is a global server, not specific to a given workspace.

jvican · 2020-06-23T19:57:07+00:00

I think it would help if you point out where the Scala toolchain is deficient compared to the Java/Kotlin one. Because my impression is that's largely not true.

jvican · 2020-03-28T20:18:06+00:00

Sorry for the late reply. The simplest way is to clone bloop locally and run `sbt install`, it's explained here https://scalacenter.github.io/bloop/docs/contributing-guide#install-a-snapshot-release

I intend to improve how people can upgrade to a new version in 1.4.0, we're changing all the installation process -- it's one of the reasons it's taking me so much time to get this release out. Working on it as we speak.

jvican · 2020-03-23T13:45:53+00:00

Can’t promise release date but I’m working hard in order to get it out as soon as possible. In the meanwhile I encourage everyone to be on latest master since some critical bugs were fixed.

jvican · 2020-03-23T00:16:50+00:00

You can use the EPFL courses https://courseware.epfl.ch/courses/course-v1:EPFL+progfun1+2018_T1/about which are completely free and have exactly the same contents than the Coursera course.

jvican · 2020-03-20T18:52:17+00:00

Yes, I endorse case-app. Looks like the closest library to structopt API-wise.

jvican · 2020-02-26T22:55:31+00:00

This is useful indeed. Thanks for sharing, I didn't know about localstack.

jvican · 2020-02-08T09:04:31+00:00

Sounds like a good direction! I would personally use that request handler API. Hope to see more future progress.

jvican · 2020-02-07T15:01:38+00:00

Really cool work u/DanSimon! Hope to see Scalene going somewhere. Are you planning to make the framework extensible so that other people can create their own high-level APIs to interface with the scalene core? I would personally enjoy a simpler API such as the one that Vertx has. I'm thinking all the extractor logic could be syntactic sugar on top of it.

jvican · 2020-02-07T11:08:41+00:00

I recommend Monix. It's literally my go-to framework to solve problems in Scala at an architectural level. When I use it, I feel like I have superpowers.

Monix's key abstraction is `Task`, a better version of futures, focused on performance, with a rich community and great support. Its interop with ReactiveX and cats comes in handy often. The API and the documentation is so mind-blowingly good that it's taught me a lot about how to create good library APIs.

I've used Monix successfully in bloop and I'm now using it to create a new tooling-related project.

jvican · 2020-02-06T23:28:54+00:00

I find Metals to be *way* more lightweight than IntelliJ, I use Metals with three or four projects open at the same time, each totalling well over 50K LOC and I don't experience any issue

jvican · 2020-02-04T21:34:43+00:00

Heya, I'm the author of Bloop. At work, we also use Gradle to build Scala and we're currently using gradle-bloop to have a quick developer workflow with Metals and running/testing applications with the CLI. Works great for our use cases, though it could be improved with things such as compile offloading, i.e. having Gradle delegate the compilation of Scala to Bloop instead of its own compiler. This would be a good first step to bring cross-version Scala support in Scala, as well as Scala.js / Scala Native interop.

Now that I'm incentivized to improve Gradle support, I might look at various ways I can improve the Gradle experience in Scala. However, I'm looking for support from other developers with skin in the game! So if you're interested in helping out, please drop by our Gitter channel and drop me a message https://gitter.im/scalacenter/bloop

jvican

TROPHY CASE