Real example from my experience: you use a Scala Map and pass it to something like FreeMarker, expecting that it will work like Java Map there. It will not and depending on your test coverage and SQA capabilities, you may notice it very quickly or very late (you'll get no compile error, since template engines usually accept generic objects and then analyze their type via reflection).
Why would you expect this to work? In fact given that API a map from another java library(say guava) would have crashed you just as well
> Why are people so intent to bash sombody else's language choices?! Partially it's simple tribalism. But part of it is also the rational awareness of the opportunity cost of investing in a language other than the author's preferred one. The more people using language X that I don't like, the fewer people using my preferred language Y. That means fewer libraries I can use, docs I can read, bugs that get fixed, etc. L…
That might be true to some extend, but many languages have completely different target audiences. People whose favourite language is Go, will probably not move to Scala (and vice versa). Kotlin vs Scala is an easier to understand competition. In any case, if people want other people to invest in "their language", they should focus on making that language and its ecosystem compelling to use, not bash other languages..…
> People whose favourite language is Go, will probably not move to Scala (and vice versa). Kotlin vs Scala is an easier to understand competition.
That said, in terms of language features and type system, Kotlin is arguably closer to Go than it is to Scala. Yes, Kotlin competes with Scala on the JVM, but it's a very different language. Scala is much closer to a language such as OCaml than it is to Kotlin.
So many cool things already done and even more to come. Some parts that excite me as a Scala nerd: * One can now use implicit function types to basically build your own table language syntax that is type-safe. [1] * Multiversal Equality: you get to decide whether it makes any sense to compare an Apple and an Orange using "==" or "!=", as opposed to Java's forced requirement of allowing you to compare anything with an…
Also, no plans to get rid of implicits apparently. Sorry Scala, we're not gonna be friends.
What is your main complaint with implicits? If you don't like them, why don't you add "Use of implicits forbidden" to your coding style guidelines, and check in code-reviews, and add a "grep implicit" check to your CI setup that refuses to commit Scala code with implicits? Let me paraphrase M. Odersky's PLDI 2017 keynote: The essence of Scala is implicits You can find it at https://www.youtube.com/watch?v=br6035SKu-0
> If you don't like them, why don't you add "Use of implicits forbidden" to your coding style guidelines, and check in code-reviews, and add a "grep implicit" check to your CI setup that refuses to commit Scala code with implicits?
Because Scala libraries that do useful stuff are infested with them. Akka loves the things.
> main complaint
They obscure complexity, pretending that complex stuff is simple. It makes simple stuff trivial but complex stuff harder.
Real example from my experience: you use a Scala Map and pass it to something like FreeMarker, expecting that it will work like Java Map there. It will not and depending on your test coverage and SQA capabilities, you may notice it very quickly or very late (you'll get no compile error, since template engines usually accept generic objects and then analyze their type via reflection).
Why would you expect this to work? In fact given that API a map from another java library(say guava) would have crashed you just as well
Well, I wouldn't even try to have a source code written in two different languages in the same component. But I've seen this problem in someone else's real code, which was probably caused by a not really well-thought migration of Java code to Scala. Basically, a developer replaced one Map with another, fixed all the places where API was different on source code level and a number of tests. However, interoperability issues like this one may be hard to catch in general (even with good test coverage and regular code reviews) and they show the complexity of the problem, that requires certain level of development skills and discipline to do it right.
The reason why Kotlin is gaining marketshare is specifically because they aren’t chasing after things like HKTs. Kotlin is squarely going after the better Java market and not the advanced FP one.
I think Kotlin's design - adding lots of ad-hoc support for specific use cases but without the underlying general constructs that make them coherent - will come to bite them as and when the language needs to evolve over time. (Indeed to a certain extent it already has, as Java 8+ adopts Options which don't play nice with Kotlin's ?. etc.) I guess we'll see how things look in a few years.
I was excited about Kotlin at a first glance but came to feel this way as well, after looking into it a bit more.
Typescript does indeed do frequent releases, though they're not nearly as ambitious as Scala 3.0. A Typescript release usually has 1-3 exciting new features, and a number of smaller bug fixes and improvements.
Correct, but collectively, between now and 2020 it's almost certain in aggregate, Typescript will have significantly more `features` than Scala 3.0, and they will have the benefit of being used and iterated upon for 2+ years.
There are developer releases through 2019 as well.
> Common Lisp is languishing can you elaborate more on that?
I don't think CL is attracting a lot of new developers or there's a lot of new libraries getting developed. But I would be glad to be proven wrong. Perhaps Racket will eventually become a CL replacement, now it's adopting a lot of Chez low-level stuff and it's multiparadigm efforts keep growing.
Do you have any ideas why Racket has not had the commercial success of Clojure for example?
As a fellow emigrant of `Scala is the best island` forced off for pragmatic reasons. I've been around scala long enough to see the rise and fall of multiple expeditions into the bowels of the OSGI eclipse cave of horrors (Sean McDirmid / Miles Sabin etc). Before switching horses and settling in Intellij for several years. So I understand where you are coming from. I've since jumped ship again to vscode (along with ty…
Could you expand on what this all is? I'm not familiar with what benefits an LSP provides. What is the world like before and after LSP support?
It moves code completion and refactoring into a dedicated process behind the LSP API, which is maintained by the language devs. As a consequence the IDE automatically keeps up with language changes.
Disclaimer : I'm nobody important, but I do have an opinion If scala team were to disavow sbt, that'd be the single best thing they could possibly do for the ecosystem. I used to write a lot of scala, and working with sbt was enough to eventually get under my skin. I really like some of the OOP aspects of scala, the left-to-right style of thinking matches how my brain works. Scala having a lot to offer can distract n…
I don't think SBT is in any way officially endorsed in the first place? Many popular libraries use it, but there are plenty of other options. If you're not maintaining a public library that has to cross-build against multiple versions of Scala, IME there's no reason not to just use Maven, which gives you simple and well-documented builds.