Hacker News Reader

Comment by maxaf | Hacker News Reader

When I gave up on Scala in 2016, I did so because its future looked fragmented and uncertain. Fast forward more than three years, and the first release of Scala 3 won’t be out until another year from now. Compare this with the pace of development of Go or Rust: those languages are driven by a vision, and have a dedicated team behind them. Scala is declining because no one could figure out for the longest time what was next and how to work on it.

It’s too bad, as Scala did the most of any language to bring me into the fold of statically typed programming. I miss it sometimes, but then I remember all the times Scala wasted my time, and get back to writing Go like a happy little camper.

View on HN

Go is just barely statically typed though, with its lack of generics. Some day soon, it will tacked onto the language; a language that wasn't designed with that in mind.

I don't know about pace, but in absolute terms, Go is far behind even the oldest versions of Scala.

That would be missing the point of Go. It’s not as though the Go team is incapable of introducing genetics they just took a hard line on not putting anything into the language that wasn’t absolutely needed. This built a simpler language and because of that a stronger community, which is why Go has all but entirely eaten scalas lunch

The marketing is very impressive indeed, I won't argue against that. I can only think of Angular 1.0 as an equally impressive feat of advertising (I totally bought into that - for a while).

But logically, what you suggest implies that either generics aren't absolutely needed, and shouldn't be in Go, or it's absolutely needed, and Go has been lacking them for a long time.

no it just implies the don't willy nilly throw in any feature into the language like Scala, and I am incredibly grateful for it after writing Scala for a couple years, what a mess

Scala tends to be more of a kitchen sink, kind of an academic experiment brought to industry, whereas Go is way too far down the path of having only “absolutely needed” features - they promoted it as a “pragmatic, boring” language to focus on your business and write consistent code. As a result, this approach makes the language less expressive, really boring for many engineers, and also, unfortunately, it brought some bad practices - repetitions, error handling from last century, etc.

Languages are in a big part matter of tastes, and it does not make sense to criticize their chosen approaches beyond objective technical merits for your tasks.

Sure there are use cases for Scala, they are just few and far between nowadays. If your looking to experiment with crazy functional stuff have fun, just don't write actual software in it, which was unfortunately the outcome, and a bunch of companies paid the price

I’m sorry, I don’t think you can state absolutes like this with respect to languages.

After 5 years of programming in Scala, professionally, writing and debugging a cli tool in Go-Lang felt like a breath of fresh air. I agree with about go marketing, in that I think the creators of go found a larger “market” of devs and understood them better.

I think you're replying to the wrong person - I merely explained how the absolutes in the parent post were self contradictory.

haha yup, Go actually understands its community, Scala is more concerned with doing really "smart" stuff

This line of reasoning never made sense to me because there's plenty of stuff in the language that isn't absolutely needed, such as the various special syntax for certain concurrency constructs.

They look at how their software is being used and the problems people are encountering using it and then decide what is the best path. To roughly quote Rob Pike 'every feature is useful, but they all have a cost, and its about weighing the outcomes'

That’s precisely the issue imo: it’s a language carefully designed to meet Google’s requirements.

The whole “we don’t need generics” fiasco was hilarious, though.

Its actually not designed to meet Googles requirements, that just something people who don't know Go say. They have a survey they put out every year and take feedback from customers on issues that arise. They try and fix those issues with as little code as possible, because code and features have a cost.

Well, Go magically fits right between C++ and Java, which were both Google’s main backend languages AFAIK.

I wonder if generics and proper dependency management were on this survey you’re talking about...

Caught me, Go was developed for Google only because it fits between C++ and Java meaning its worthless to everyone else ;)

Generics and dep management were on the top of that survey last year. They are the primary focus of the Go team right now. Russ wrote Go Modules for dep managment, the implementation specifically addresses pain points from the community. Generics are a hot topic and looks like we're close to a finalized design.

Not “for Google only”, but to meet Google’s needs first and foremost. I know that I won’t be convincing you, though :)

I mean I'm sure if Google specifically wanted something they could get it, but honestly I don't get the impression from any of the Go authors they are there to serve Google. They seem genuinely interested in just building the best language they know how. The fact that the features being worked on are the ones that are requested by the community tells me thats authentic.

Don't get me wrong the Go authors have overridden the community a couple of times and there was some serious outrage. Don't think that was a Google thing though, more of an "We know better" from the authors.

This is all marketing.

I've never found a more sophisticated type system anything but helpful. It's easy for beginners to start, but when you don't have a good type system and you have a complicated project things quickly become a nightmare.

eh, there is still a cost to it, don't get me wrong I generally think generics are worth the cost if done right, but they can also go really wrong

When?

Scalas insane generic type system would be an example of them going wrong. The current proposed Go method seems fairly reasonable.

Scala’s type system goes far beyond simple generics.

and thats fine in an academic setting, but please don't bring that into the real world unless you have a really good use case.

So then please don't cite Scala as an example of type parameters being not worth it.

it's working fine in the real world enterprise setting too ;)

I've seen nothing but chaos in every org thats adopted it and they all moved to java/kotlin/go, only place I've seen it successful is around Spark. Usage stats back this up

I'll give an example of the Scala type system: let's define combining 2 integers as adding them together, then combining 2 lists of integers will give a new list where an element is the result of combining of 2 elements in the given 2 lists. Now we can make it a bit more generic: if a type A has a method combine, then 2 lists of elements of type A can be combined together to give a new list of which each element is from combining 2 elements in the 2 given lists.

How do you implement it in Go? It can be done in Java with generics, but if I make the problem a little bit more generic, a little bit more complicated, then I don't think Java can do it.

It would depend on how generics are implemented in Go, with the current proposed implementation that would be possible. Without generics today you could use an interface, wouldn't be as pretty but would get the job done.

IMO this would be a bet that the Go team does not implement generics in the vague near future. There's a difference between the Go team making a fundamental design judgment against generics vs the Go team feeling that no super-obvious proposition which balances all the values of Go has been put forth. I think it's a matter of time and resource.

They are just against features with a high cost to the community, generics are pricey as they can go quite wrong. They are now entertaining ways of adding them while limiting their downsides.

Is it declining? Citation needed? I agree that Scala is not the new kid on the block anymore but I don't see it decline. When you look at the language rankings of the last few years, Scala seems to have settled at about ~12th place currently.

Scala is nowhere near the first 20.

Depends on the criteria and the group of companies you survey. In our customer survey done mostly among top 100 enterprises it comes at #3 very close to Python (which is #2), and it is much stronger in absolute numbers than C# or JS. And the trend is growing.

Of course, this is not representative to the whole market and heavily biased towards big companies with big backends that need to scale, but neither are Tiobe, GitHub or SO rankings.

What about kotlin?

Yes, Kotlin seems to me like the future of Java.

Kotlin is not the future of anything. They got the Android boost and still, two years later, all they have to offer is a molasses-slow improvement pace and a shitty dev experience in their signature IDE (which also happens to be made by the same company).

Last time I tried to create a Kotlin project in IDEA, it couldn't provide type information on hover. The Kotlin dialect of Gradle was barely supported enough to be called a "third-class citizen". It's super embarrassing.

We're writing new apps in Kotlin instead of Java, works fine for us. shrug Vert.x , Ktor apps, Kafka streaming apps. IDEA handles it absolutely fine these days, I suspect you last tried it sometime ago.

Can't comment on the Gradle stuff though, I vastly prefer Maven.

Is vertx better than ktor for production?

Vert.x is doing us well for high volume apps, Ktor is early stages but looks alright also. That said, haven't benchmarked identically feature compete implementations of the same app in both, so don't really have the metrics to properly compare, but so far at least, it seems comparable.

Yeah, Jetbrains marketing wants you to think it is the other way round, but actually tooling support for Scala is ahead of Kotlin by far, except maybe Android.

Scala is not tied to a single IDE, it works great in VScode, Eclipse and Intellij and anything else that supports LSP, which is an open standard. And it works really well - including type inference and very advanced implicits stuff.

And recently Scala got excellent incremental compilation support by Bloop from ScalaCenter, which not only blows Kotlin out of the water but even Java with Gradle. The last year I develop purely in Java and I use Scala bloop for day-to-day development, because I couldn't stand multi-minute Gradle compile times. Getting incremental compile times counted in milliseconds (!) or single seconds at worst is something very hard to give up on.

I would have said that a year ago but I'm not so sure now. I actually think Kotlin is at risk of suffering the same fate as Ruby and perhaps Swift: so stereotyped into being viewed as a single domain language to the extent it gets ignored by the mainstream. To some extent Groovy suffers it as well - as soon as you say it people think either Jenkins or Gradle and recall their last nightmare debugging session trying to reason about its crazy dynamic behavior, all the while blind to the fact that it has huge general applicability to all kinds of application development. I even think this is starting to hurt Python where now everyone thinks it is for data science.

I'm not so sure. I don't see it being used on the server side a whole lot, it seems to be more or less synonymous with Android dev -- and Dart/Flutter is taking big chunks of that space now and growing rapidly.

I highly doubt it. Modern Java is quite good and is adapting the best features of Kotlin.

> Scala is declining And the proof of this is... Where?

I won’t even mention the anecdata from my own workplace. I’ll only say that within my extended network people are frantically rewriting Scala bits in other languages. Those who are stuck with it (because of, say, extensive prior investment into Spark) are scrambling to come up with alternate solutions.

Put your ear to the ground, and you too will hear it.

> rewriting Scala bits in other languages.

My employer is doing the same.

There is an ongoing work on creating Spark alternative in Rust[1][2]. Hopefully, that could help.

[1] https://github.com/rajasekarv/native_spark

[2] https://medium.com/@rajasekar3eg/fastspark-a-new-fast-native...

Will take years to get there, if they even get there at all. This is a single-man side project now. Also benchmarking something that has 1/100 of the original functionality and is not production ready is very unfair. It is much easier to get a specialized use case faster than a general purpose system.

He is not the first, Andy Grove worked on a similar thing last years, but he worked mostly alone, and without community you cannot take off such ambitious project: https://andygrove.io/2018/11/datafusion-2019/

Used to write scala, what a mess looking back on it now. Everyone I know that was writing it is now writing Go/Kotlin/Elixer

Sounds a bit like they just like to try out new languages.

Except they have all stuck with those languages, Scala was a disaster to maintain which is why you see companies fleeing from it.

I'll speak for myself. I just jumped ship from a Scala team and took a pay hit to get out because it was so horrible. No one on the team had a strong command of the language, which made it worse. The application was a ball of mud. The week I left, proposals to rewrite everything in Java were heard. I took a position on a Go team and am much happier.

I wouldn't jump ship to a Go project, but I am currently in the situation you fled from. Even the core team who started the project doesn't have command of the language. I have some experience with rust and Haskell (hobby) and JVM experience with Java and clojure so I can get by but it is not pleasant.

I think the situation is similar to c++ where too many features have been added over time.

While with c++ there is a body of compiled recommendations on what not to use and how to write c++, for scala that doesn't really exist.

This has nothing to do with languages. I saw the same happening in a company writing pure Java, JS or Python. Doing a project with people who don't have command of whatever stack they are using is asking for trouble.

On the flip side, Scala can be a very pleasant stack to work with if you have right people on the team.

> While with c++ there is a body of compiled recommendations on what not to use and how to write c++, for scala that doesn't really exist.

Principle of least power is what you need.

> for scala that doesn't really exist

https://nrinaudo.github.io/scala-best-practices/

Sometimes you need no proof, just to look around well enough.

Not everything is a science paper.

When I look around, I see more jobs, conferences, talks, meetups, libraries, open source communities ...

Sure, some companies are moving to other languages, that might be growing quicker than Scala ever was. But this isn't zero-sum.

Reply on news.ycombinator.com