Live data from Hacker News

Explicit term inference with Scala 3

scala-lang.org

21–30 of 77 posts

Re: Explicit term inference with Scala 3

#21

A summary of what Scala is great for: - Safe and high performant concurrent programming. Scala is miles ahead of most other languages here and pretty much on par with the best ones (such as Haskell) - ETL / data transformations. Python is a big player here - but for stable and performant data pipelines, I strongly believe Scala is the better choice. For explorative things, python has the edge though. - Actor systems…

"For explorative things, python has the edge" -- I'm a lazy programmer, how can I get contextual auto-complete like I can with Scala (and other type safe languages)? From my experience, auto-complete for Python shows everything (like JavaScript's), so I end up googling.

From my experience, for exploration of data, you usually use the functionality you already know and you visualize things as much as possible. So there is not a huge advantage for Scala in terms of autocompletion and such, but there is quite a bit of advantage for python for batteries-included, visualisation and speed of execution.

But yeah, I get your point, I find it annoying too.

Re: Explicit term inference with Scala 3

#22
post #7

Earlier quoted context omitted.

> Scala is a beast and the package manager + build tools were giving me headaches. Ignore them and use maven. It's much better documented, consistent, and backwards-compatible. I struggle to understand why SBT ever gained any popularity, and it should certainly have never been recommended to newcomers.

SBT is easy to use at the beginning, simply because the build files are 1/10 the length of a Maven XML build description, the console output looks better, the build REPL has lots of commands that make things easier, and the simple projects just work fine. Once you start to dig deeper, you find out that setting multimodule projects is still easier in SBT. And if you decide to dig deep and really learn the build tool,…

> SBT is easy to use at the beginning, simply because the build files are 1/10 the length of a Maven XML build description, the console output looks better, the build REPL has lots of commands that make things easier, and the simple projects just work fine.

The build REPL has lots of commands that aren't documented, and when you search for tutorials the commands have changed (e.g. runMain is apparently now run-main, and if you write runMain you get the wonderfully helpful error "Expected ';'"). There's nothing so simple as Maven's list of phases https://maven.apache.org/guides/introduction/introduction-to... ; instead each project has its own slightly different set of build commands.

> Once you start to dig deeper, you find out that setting multimodule projects is still easier in SBT. And if you decide to dig deep and really learn the build tool, it doesn't really matter which one you choose.

Disagree. Maven multimodule projects are very simple: you can have a module that contains a list of submodules to build and... that's it. Importantly, every submodule acts exactly like a normal top-level project, so if you only ever want to work on one module you don't have to understand anything about the bigger project. And moving between single-module and multi-module projects isn't a big conceptual leap.

SBT multimodule projects are not only their own unique thing, they make the above problem even more confusing, because each project has its own slightly different set of build commands, and each module has a slightly different subset of them that works.

And even if you really learn it in detail, SBT is still awful on multiple levels. https://www.lihaoyi.com/post/SowhatswrongwithSBT.html talks about the deeper problems.

Re: Explicit term inference with Scala 3

#23
post #12

This is a nice write-up, it's beeb some time since I've written Scala and Scala 3 looks promising. Though, I am curious if there is anyone else who shares my mindset on Scala. In a corporate environment, I found it to be an extremely expressive and powerful language but that power comes at a grave price, which I'll try to summarize: - it's difficult to understand other people's code compared to other languages (e.g.…

Agree. It's a shame because I do believe it is very much cultural - it is possible to write very clear, expressive and safe Scala code. But it doesn't seem the community has settled on that as a cultural idiom. Instead they frequently favor maxing out the power of the language and type system at every opportunity and that means you often encounter lines of code that look like a string of hieroglyphics, or functional…

I agree with most of what you said, but for the last point, I think I can add a different perspective.

Because, once I got used to the (pure) functional programming style, I found it more difficult to mix this style with imperative code. It's almost always easier to for example use for example the state monad than writing it with mutation. This is probably quite subjective and it depends what you are used to.

For me, I make an exception for tests. E.g. when I mock my key-value database with an in-memory map, I choose a mutable map. But I know that some people prefer FP style even for tests.

Re: Explicit term inference with Scala 3

#24

A summary of what Scala is great for: - Safe and high performant concurrent programming. Scala is miles ahead of most other languages here and pretty much on par with the best ones (such as Haskell) - ETL / data transformations. Python is a big player here - but for stable and performant data pipelines, I strongly believe Scala is the better choice. For explorative things, python has the edge though. - Actor systems…

I agree with your first point, Scala allows writing incredibly performant concurrent code. However, if -like me- you can't bear the thought of working with Scala anymore, Rust is an excellent competitor.

Note, I spent around 5 years working with Scala full-time and grew a profound aversion for the language and its ecosystem. It definitively affects my judgment. I found in Rust all the "good parts" of Scala minus the things I resented.

Re: Explicit term inference with Scala 3

#25
post #24

A summary of what Scala is great for: - Safe and high performant concurrent programming. Scala is miles ahead of most other languages here and pretty much on par with the best ones (such as Haskell) - ETL / data transformations. Python is a big player here - but for stable and performant data pipelines, I strongly believe Scala is the better choice. For explorative things, python has the edge though. - Actor systems…

I agree with your first point, Scala allows writing incredibly performant concurrent code. However, if -like me- you can't bear the thought of working with Scala anymore, Rust is an excellent competitor. Note, I spent around 5 years working with Scala full-time and grew a profound aversion for the language and its ecosystem. It definitively affects my judgment. I found in Rust all the "good parts" of Scala minus the…

what did you resent?

Re: Explicit term inference with Scala 3

#26

This is a nice write-up, it's beeb some time since I've written Scala and Scala 3 looks promising. Though, I am curious if there is anyone else who shares my mindset on Scala. In a corporate environment, I found it to be an extremely expressive and powerful language but that power comes at a grave price, which I'll try to summarize: - it's difficult to understand other people's code compared to other languages (e.g.…

To make sure everyone can understand each other's code in a corporate environment, use strict linting (scalastyle, wartremover) and formatting (scalafmt).

Re: Explicit term inference with Scala 3

#27
post #7
post #2

After a couple weeks of dabbling between Scala and F# to migrate Python and Node.js codebases (at a scaling startup serving big enterprises) I ended up choosing F#. Scala is a beast and the package manager + build tools were giving me headaches. I’m optimistic about the current trajectory with Scala 3 and simplifying the language.

> Scala is a beast and the package manager + build tools were giving me headaches. Ignore them and use maven. It's much better documented, consistent, and backwards-compatible. I struggle to understand why SBT ever gained any popularity, and it should certainly have never been recommended to newcomers.

or gradle, or bazel. Scala doesn't require sbt, and the other build tools work well for mixed codebases (scala, java, kotlin, javascript).

Re: Explicit term inference with Scala 3

#28
post #3
post #2

After a couple weeks of dabbling between Scala and F# to migrate Python and Node.js codebases (at a scaling startup serving big enterprises) I ended up choosing F#. Scala is a beast and the package manager + build tools were giving me headaches. I’m optimistic about the current trajectory with Scala 3 and simplifying the language.

I think F# is really underused - it fills a very similar spot in the trade off space and from what time I have read has excellent design.

It misses type-classes and HKTs unfortunately. But the ML-like way of defining types and data is top notch. Even with Scala 3, F#'s way of defining types looks cleaner to me.

Re: Explicit term inference with Scala 3

#29
post #7

Earlier quoted context omitted.

> Scala is a beast and the package manager + build tools were giving me headaches. Ignore them and use maven. It's much better documented, consistent, and backwards-compatible. I struggle to understand why SBT ever gained any popularity, and it should certainly have never been recommended to newcomers.

or gradle, or bazel. Scala doesn't require sbt, and the other build tools work well for mixed codebases (scala, java, kotlin, javascript).

Bazel is a nice build tool, but AFAIK it still doesn't support Scala 2.13, released mid-2019: https://github.com/bazelbuild/rules_scala/issues/809

Re: Explicit term inference with Scala 3

#30

This is a nice write-up, it's beeb some time since I've written Scala and Scala 3 looks promising. Though, I am curious if there is anyone else who shares my mindset on Scala. In a corporate environment, I found it to be an extremely expressive and powerful language but that power comes at a grave price, which I'll try to summarize: - it's difficult to understand other people's code compared to other languages (e.g.…

To make sure everyone can understand each other's code in a corporate environment, use strict linting (scalastyle, wartremover) and formatting (scalafmt).

This is necessary, but definitely not sufficient, I'd think.

Oftentimes one stares at a mile-long chain of methods on a list and is left wondering "exactly what did the original author want to do here, and why are things breaking"? In the end, the only way to find out part of the answer is to exercise the relevant codepath via some test data (if you're lucky) and use IntelliJ's excellent debugger to help you move forward. Even this just reveals the "what", not the intent.

No amount of consistent linting or formatting can make this better. And no, ExpressivelyVerboselyNamedFunctionsInAidOfSelfDocumentingCode don't help either.

Post reply on HN