[mdm12]

In my perusals into the Haskell ecosystem, discovering Hoogle[1] was definitely a revelation on the power of a strongly-typed language. Sometimes, you know the _shape_ of the thing you are looking for, but not the name. The ability to search a repository of packages for all functions conforming to a certain type signature (e.g., (a -> Bool) -> [a] -> [a]) is a superpower.

[1] https://hoogle.haskell.org/

[yakshaving_jgt]

FYI this exists for Elm also.

https://klaftertief.github.io/elm-search/?q=c%20-%3E%20(a%20...

[still_grokking]

This is by now also a build-in feature of Scala docs, in case someone prefers a mainstream language with such superpower.

https://docs.scala-lang.org/scala3/guides/scaladoc/search-en...

[msla]

Is Scala meaningfully more mainstream than Haskell?

[still_grokking]

Of course it depends on whom you ask.

But at least the usual programming language rankings would suggest that Scala is quite mainstream by now.

We have it currently at place 15 on RedMonk, place 15 on the IEEE Spectrum ranking, place 19 on PYPL; whereas Haskell does not show up in the Top20 anywhere there.

Also Scala job opportunities and salaries are quite good when looking at the IEEE and Stackoverflow surveys, ranking quite a bit ahead of Haskell.

I would say Scala is pretty much a mainstream language. There's not much room in the Top20 given there are hundreds of languages out there.

[mrkeen]

Yep, I've had multiple scala roles, no haskell roles yet.

Still, scala has always been promoted as being easier to learn (more like Java?) and being on the JVM, rather than winning on its own merits. So kotlin will probably eat scala.

[still_grokking]

One of the problems around Scala is that people come in with an expectation that Scala would be like Java. No, it isn't. It's a whole different language. It's much more similar to OCaml (besides the syntax, of course) than it's similar to Java.

Kotlin is only competition in the "better Java" space. But that's more or less quite a small part of Scala. Scala starts to be an interesting language in its own regard beyond this point. Kotlin OTOH does not even offer comparable features. So it can't replace Scala where Scala shines.

I would say that in the long run it's Kotlin that's "in danger" as Java becomes more and more a "better Java" itself. There is not much stuff left in Kotlin these days (besides the nicer syntax) that is still missing in Java. And it gets less with every Java release. As Kotlin, mostly "just a better Java", has not much to offer besides some syntax sugar it will have a hard stand against a future Java, imho. Scala does not have this problem as people mostly given up using it as a "better Java", or migrated to Kotlin (or even back to Java) for this purpose anyway, and are using it now in a more idiomatic way that can't be simply replaced by any "better Java".

Regarding simpler: That's for sure a strong point in favor of Scala compared to Haskell. Scala 3 is on its surface not more complicated than Python, I would say[1]. It's also easier to pick it up gradually, compared to Haskell where understanding even "Hello Wold" will require some understanding of monads.

For people who don't know Scala by now or didn't look into it for a long time: It's one of the better FP languages currently out there, but it won't drown you in alien concepts right form the start. It's easy to pick up. But it's still at least as powerful as Haskell. But more pragmatic and down to earth. It's worth having a look for sure!

The simplest and quickest way to give it a try is installing scala-cli[2], I guess.

Than, for bigger / real projects you would use likely Metals[3] for VS Code / vim, the Scala IDEA plugin, or, for the Emacs diehards, the new Ensime. (Where the Metals experience is imho currently the smoothest).

---

[1] https://docs.scala-lang.org/scala3/book/scala-for-python-dev...

[2] https://scala-cli.virtuslab.org/

[3] https://scalameta.org/metals/

[lolinder]

> I would say that in the long run it's Kotlin that's "in danger" as Java becomes more and more a "better Java" itself. There is not much stuff left in Kotlin these days (besides the nicer syntax) that is still missing in Java. And it gets less with every Java release. As Kotlin, mostly "just a better Java", has not much to offer besides some syntax sugar it will have a hard stand against a future Java, imho.

There are two things that I miss any time I try to go back to Java from Kotlin, and recent improvements haven't helped matters:

1) Null safety. Java has Optional now, but most of the standard library still may or may not return null, and you have to read the javadoc to find out if you should be handling for null.

2) The collections library. Kotlin has the most comprehensive and consistent collections library I've ever seen in any statically typed language; it's comparable to Python in expressive power. Java doesn't even come close.

The features that Java has adopted (sealed interfaces, records, etc) are nice, but not the core of why I use Kotlin.

[DonaldPShimoda]

A minor nitpick: the crucial element here is that Haskell is statically typed. "Strong" typing is not well-defined, and even in contexts where that word is appropriate, it only exists as a relative descriptor (not in a vacuum).

But I agree with your takeaway. Hoogle is one of the coolest development tools I've ever used, and I desperately wish every other statically typed language had their own Hoogle.

[msla]

"Strong" as a descriptor makes more sense if you see a type as a kind of contract: You agree that you will only perform these operations on this value, and the language agrees that all of those operations will be well-defined. "Strength" is how difficult it is to disregard those contracts and peel back the abstraction they enforce to get at some underlying representation, possibly all the way down to where "Bits Is Bits" and everything is permitted. You'll notice that this makes Python's type system stronger than the one C++ has, once you get over the idea that Python's types attach to values, not variables.

[DonaldPShimoda]

Right, so it's not very rigorously defined; it's kind of a "feeling" about how easy it is to subvert the high-level system, and it only makes sense to describe a language as "strong" in contrast to another language — which is kind of what I'd said originally. ;)

In any case, I think we agree that it's not what the parent comment of mine had intended to refer to!

[msla]

And it isn't even all that useful as your only metric: A hypothetical language with only strings can have strong typing if it only allows you to do stringly things on those strings and doesn't, for example, allow you to ever see the codepoints as sequences of bytes; however, you'd have to represent everything in that language as strings, so the semantic types of those objects would be purely conceptual, like types in BCPL, where the compiler only knew about machine words, or, indeed, assembly language.

So we have at least three axes: Static vs Dynamic, Weak vs Strong, and Conceptual vs Semantic, where more Semantically-typed languages allow you to represent more of the meaning you're going for in the type system, and have the language enforce semantic rules like not being able to add person-height to person-weight even if they're both integral types.

(Note that my imaginary string-only language is also statically typed of necessity, given that all variables must have type string and no value can ever move from a variable of one type to a variable of another type.)