Live data from Hacker News

Explicit term inference with Scala 3

scala-lang.org

41–50 of 77 posts

Re: Explicit term inference with Scala 3

#41
post #22

Earlier quoted context omitted.

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

SBT's deeper problems are the 4-dimensional data model and the 3-layer meta-interpretation model. Probably not the best option for really complicated builds, but it's great for simple builds and I appreciate the tireless open source work the folks do to keep it maintained!

Re: Explicit term inference with Scala 3

#42
post #14
post #3

Earlier quoted context omitted.

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.

My main beef with F# is the .net library -- none of it is written from a functional perspective, which means you're constantly mixing functional and object-oriented paradigms.

Unfortunately Scala suffers a similar story on the JVM with Java libraries.

Re: Explicit term inference with Scala 3

#45
post #31

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…

Yeah, the symbolic method names can be quite annoying and (often) make code unreadable. Especially ScalaZ went really overboard there.

I'm happy to say that the convention is becoming more strict in this regard and symbolic method names are (mostly) discouraged [0].

[0] https://docs.scala-lang.org/style/naming-conventions.html#sy...

Re: Explicit term inference with Scala 3

#46

Earlier quoted context omitted.

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

I think Lucid (the charts, not EVs) use these internally: https://github.com/higherkindness/rules_scala

And they support Scala 2.13

Re: Explicit term inference with Scala 3

#47
> Avoiding repetition with contextual parameters

This is the type of stuff that made me go away from Scala.

Why implement a feature that optimises for code writing? How does my editor let me know that function receives that parameter without me going "???" and having to go into its definition?

Implicit conversions fall into the same category, of making code pretty to look at, quick to write, and a nightmare to understand when you're new to a codebase.

Shame, really. The good parts of Scala are wonderful.

Re: Explicit term inference with Scala 3

#48

> Avoiding repetition with contextual parameters This is the type of stuff that made me go away from Scala. Why implement a feature that optimises for code writing? How does my editor let me know that function receives that parameter without me going "???" and having to go into its definition? Implicit conversions fall into the same category, of making code pretty to look at, quick to write, and a nightmare to unders…

> How does my editor let me know that function receives that parameter without me going "???" and having to go into its definition?

IntelliJ has been able to do that for a while now.

> Implicit conversions fall into the same category, of making code pretty to look at, quick to write, and a nightmare to understand when you're new to a codebase.

Don't do it, and don't allow it in your codebase.

Re: Explicit term inference with Scala 3

#49

Earlier quoted context omitted.

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

I think Lucid (the charts, not EVs) use these internally: https://github.com/higherkindness/rules_scala And they support Scala 2.13

Interesting. Here is a comparison of the two rules_scala implementations: https://github.com/higherkindness/rules_scala/issues/261

Re: Explicit term inference with Scala 3

#50

> Avoiding repetition with contextual parameters This is the type of stuff that made me go away from Scala. Why implement a feature that optimises for code writing? How does my editor let me know that function receives that parameter without me going "???" and having to go into its definition? Implicit conversions fall into the same category, of making code pretty to look at, quick to write, and a nightmare to unders…

> How does my editor let me know that function receives that parameter without me going "???" and having to go into its definition? IntelliJ has been able to do that for a while now. > Implicit conversions fall into the same category, of making code pretty to look at, quick to write, and a nightmare to understand when you're new to a codebase. Don't do it, and don't allow it in your codebase.

> IntelliJ has been able to do that for a while now.

It has been 4 years since I did Scala everyday, back then it was hit or miss. Good to know things have improved.

> Don't do it, and don't allow it in your codebase.

I get your point, but that doesn't solve the issue if the community is down for using these features.

Post reply on HN