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

Explicit term inference with Scala 3

scala-lang.org

Post reply on HN
Print view View original

31–40 of 77 posts

Re: Explicit term inference with Scala 3

#31

Post by Fiahil »

aphexairlines wrote: post #25
Fiahil wrote: post #24

Earlier quoted context omitted.

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?

In no particular order:

- the JVM

- the tooling for writing with VSCode

- SBT

- NullPointerExceptions bubbling up from Java libs

- the split between the functional programming community and the "Scala is just Java without ;" one

- everything related to implicits (creation, resolution, etc) and everyone using them

- the ability to write the same 0-100 loop with 4 different keywords and 3 different styles

- the inability to enforce a coding style properly and consistently with a team of more than 1 engineer

- too much people writing DSLs for no particular reason

- ++, +:, :+, :++, ++=, _+_, ::, :::, _, `, , :>, >:, (╯°□°)╯︵ ┻━┻, ., .., ...

- compiler errors

Re: Explicit term inference with Scala 3

#32

Post by chriswarbo »

xyzzy_plugh wrote: post #5

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.…

> - it's so very implicit that you end up having to hold a lot of state in your head to understand what's going on.

I wouldn't use the word "state", since that has connotations that implicits are somehow changing at runtime. It's certainly true that scope is much more important and non-obvious than explicit variable names.

Type aliases can also get in the way when thinking about implicits (e.g. we might want an implicit 'Foo[Bar]', but if those are aliases then the compiler might start chaining Maps of Lists of Strings of whatever to resolve it).

Implicit conversions definitely seem like they could cause headaches (e.g. performing 'String' operations on a 'List[Char]' and having it implicitly and silently converted). I've only been using Scala for the last year, and thankfully implicit conversions seem to be avoided these days!

Re: Explicit term inference with Scala 3

#33

Post by maattdd »

Fiahil wrote: post #31
aphexairlines wrote: post #25

Earlier quoted context omitted.

what did you resent?

In no particular order: - the JVM - the tooling for writing with VSCode - SBT - NullPointerExceptions bubbling up from Java libs - the split between the functional programming community and the "Scala is just Java without ;" one - everything related to implicits (creation, resolution, etc) and everyone using them - the ability to write the same 0-100 loop with 4 different keywords and 3 different styles - the inabili…

- compilation time

Re: Explicit term inference with Scala 3

#34

Post by JackFr »

vvillena wrote: post #11
lmm wrote: 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,…

Maven had some real issues which left Scala developers unsatisfied. So they created SBT which solved none of those and introduced some new ones.

I believe the tagline/motto of every build tool should be “Don’t worry; You’ll get used to it.”

Re: Explicit term inference with Scala 3

#36

Post by JackFr »

lmm wrote: post #18
BossingAround wrote: post #10

Earlier quoted context omitted.

Personally, I wouldn't recommend Maven to beginners. I would recommend beginners to learn Maven as it is one of the de-facto standards in JVM dependency management, but the documentation is highly confusing and the learning curve is very steep. Beginners will likely struggle with Maven concepts.

I very much disagree; the only people I've known to have trouble with Maven are experienced developers who expected their build tool to work in a very specific way (i.e. that they would define a bunch of commands for it to execute and tell it what to do). For a beginner who comes to it with no preconceptions, maven is very easy: you fill in the parts your XML editor tells you to, list your dependencies, and then run…

The things I want to do, are they ‘goals’, ‘tasks’, ‘phases’ or ‘executions’? And do I manage my dependencies in ‘dependencies’ or ‘dependencyManagement’? And how is it that none of the ‘dependency’ goals can tell me the origin of the version - I have to use ‘help:effectivePom’?

Maven is powerful and people forget how innovative it was. But it’s not easy.

Re: Explicit term inference with Scala 3

#37

Post by MrPowers »

Fiahil wrote: post #31
aphexairlines wrote: post #25

Earlier quoted context omitted.

what did you resent?

In no particular order: - the JVM - the tooling for writing with VSCode - SBT - NullPointerExceptions bubbling up from Java libs - the split between the functional programming community and the "Scala is just Java without ;" one - everything related to implicits (creation, resolution, etc) and everyone using them - the ability to write the same 0-100 loop with 4 different keywords and 3 different styles - the inabili…

There have been some great improvements in Scala tooling in recent years. Li Haoyi talks about all these new tools in the Hands-On Scala programming book. Some specific responses:

* tooling for writing VSCode: the metals project is great: https://github.com/scalameta/metals

* NullPointerExceptions: those should be handled with Option/ Some / None

* the inability to enforce a coding style properly - scalafmt is great for this and provides a "Go-like" automatic formatting experience https://scalameta.org/scalafmt/

* SBT - there are now alternatives like Mill: https://github.com/lihaoyi/mill

Glad you're happier with Rust, but know that Scala is a lot better now if you ever come back ;)

Re: Explicit term inference with Scala 3

#38

Post by marcinzm »

wiradikusuma wrote: post #17
valenterry wrote: post #9

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.

For exploratory work you're in a notebook so your auto-complete usually has access to the exact object instances in question. There's also some good machine learning based autocomplete systems out there nowadays.

Re: Explicit term inference with Scala 3

#40

Post by marcinzm »

valenterry wrote: post #9

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…

>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.

I disagree. And I've done a lot of Scala ETL work. The issue is that in Scala ETL work your data structures are either untyped (Spark Dataframe), case classes or typed tuples. If they're untyped then there's little to gain from Scala vs. Python in terms of type safety and a lot of overhead. If they're case classes then you're moving around a lot of unnecessary data fields and you've got the overhead of making fifty intermediate case classes yourself. If it's typed tuples then it's on you to remember which field is what as nothing is named.

Some sort of intelligent compile time case class subset generation would have helped the situation immensely. I think frameless (https://github.com/typelevel/frameless) gives you that power but it's a lot of shapeless black magic overhead and I've never seen it used in production (and probably various maximum field limitations and much slower compile times).

edit: Case classes also have (or had) a steeply increasing compile time memory requirement as you add more fields which is fun when your data is 200+ fields long. Almost as fun as having to make a 200 field case class to read in a single file of which you only need 50 fields but want to be type safe.

edit2: Scala is popular in ETL because the Hadoop ecosystem is JVM and Java used to be atrocious. So Spark (which wanted Hadoop compatibility) picked Scala because it was better than the alternatives. However nowadays Databricks is investing a lot more into their Python support from what I can tell and there's Python native competitors out there (Dask, Ray, etc.).

Post reply on HN