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

The Road to Scala 3

scala-lang.org

Post reply on HN
Print view View original

41–50 of 196 posts

Re: The Road to Scala 3

#41

Post by MiroF »

yahyaheee wrote: post #18
continuational wrote: post #14

Earlier quoted context omitted.

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

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.

Re: The Road to Scala 3

#42

Post by nullspace »

continuational wrote: post #22
yahyaheee wrote: post #18

Earlier quoted context omitted.

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.

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.

Re: The Road to Scala 3

#43

Post by MiroF »

yahyaheee wrote: post #33
jkachmar wrote: post #24

Earlier quoted context omitted.

Big ol’ “Citation Needed” on this one. The flip-side here is that a language that doesn’t support basic programming language theory concepts dooms its users to repeat the mistakes of those who discovered them. I also would personally disagree that any statically types language without generic types and without non-nullability (e.g. `Option`/`Maybe` and `Result`/`Either`) is severely lacking in the ability to express…

proof is in the pudding on that one, sorry don't think there are academics studying this but it's an obvious outcome from the war that was Go/Scala/Node. Go is eating Scalas lunch because its easy to understand and communities are stronger than individuals. Sure Scala has more 'features' but Rob Pike would say every feature has a cost and you need to weigh that, didn't see that ever happen in Scala. Go is taking the…

Adoption isn't everything and google has incredible marketing sway.

Tensorflow almost won the ML framework wars despite being clearly outclassed by Torch and it took until recently for Torch to overcome the Google brand name

Re: The Road to Scala 3

#44

Post by Cyph0n »

yahyaheee wrote: post #30
bcrosby95 wrote: post #23

Earlier quoted context omitted.

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.

Re: The Road to Scala 3

#45

Post by lihaoyi »

The way I look at modern Scala is a mix of Python and Java.

Do it badly, and you end up with the unmaintainability of Python and the clunkiness of Java. Awful.

Do it well, and you end up with the convenience and interactivity of Python and the typesafety, performance, and toolability of Java.

This lets you implement your code quickly the first time, and have it run blazing fast on a hot JVM, with the compiler having your back as you grow your codebase in size and complexity. Sure beats trying to prototype in Java, or porting half your Python prototype to C when you realize it’s too slow.

Scala has a bad reputation, well-earned due to an early culture of crazy experiments, crazy operators, and crazy tools. But those days are behind us.

You can no longer get stuff into the standard library “just because”, and a lot of the early experiments in that category (xml, parallel collections, parser combinators) has been consciously moved out.

Operator-heavy tools like SBT have largely replaced the crazy operators, while operator-heavy libraries like Dispatch have been largely replaced by less-operator-heavy equivalents.

SBT used to be awful, but it’s improved a lot. And you don’t need to use it: I haven’t touched an SBT build in years by now, in both OSS and proprietary contexts.

There remains a lot of different ways to write Scala, more than most languages, but you don’t need to write Haskell-in-Scala unless you really want to.

I’m personally very happy with my Python-like language with Python-like libraries, with static typing for maintainability, orders of magnitude better runtime performance, excellent parallelism and concurrency, one of the best compile-to-JS experiences in the world, and the best tooling (IDEs, profilers, monitoring, etc.) on the market.

As someone who maintains optimized programming language interpreters, distributed backend clusters, three-tier web apps, command-line tools, and many other things on a daily basis, I appreciate being able to do all this in one language rather than juggling 5 different languages (and 5 different sets of libraries, and 5 different sets of tools, ...) to satisfy each use case.

Scala may be diverse and fragmented, but it’s not as diverse or fragmented as the polyglot Python/Ruby/C/Go/Javascript codebase it would likely take to replace Scala for my daily work

Re: The Road to Scala 3

#46

Post by solicode »

I often see comparisons to Go, Kotlin, Rust, etc, and I agree that it's unlikely for Scala to have a second renaissance and have an steep upward trajectory like those languages, but is that really a death of a language? I'm actually fine with Scala narrowing its scope and focus at being really good at just a couple of things. Such as embracing its FP-side more so than its OO-side. Not to say there is no value in its OO-side (I still see some value there mostly pertaining to modules). But I just mean that not every language needs to aim to be a top 5 language. FP and advanced type systems still seems to alienate a significant percentage of programmers for various reasons. That's fine. It's not like that sentiment is going to change overnight.

Scala missed its opportunity with Android. I think you just have to concede that to Kotlin at this point and just focus on moving in a direction that is not occupied. Which is why I mention FP with a strong focus on types. There's not much competition there besides Haskell. And since Haskell for the JVM will likely never be a thing (a few have tried, but none have gained traction), Scala is still there. And with the direction Scala 3 is going and all the improvements it brings, it's actually looking quite positive. At least in my eyes.

And besides, I don't think Scala has to be a "worse Haskell" in everything that it does. I think ZIO is a good example of a great Scala library that actually resulted in something really special by embracing what Scala can do: https://zio.dev

Re: The Road to Scala 3

#47

Post by continuational »

nullspace wrote: post #42
continuational wrote: post #22

Earlier quoted context omitted.

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.

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.

Re: The Road to Scala 3

#48

Post by playing_colours »

yahyaheee wrote: post #28
continuational wrote: post #22

Earlier quoted context omitted.

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.

Re: The Road to Scala 3

#49

Post by bcrosby95 »

asimpletune wrote: post #40
jacobn wrote: post #32

I love scala, and am very much looking forward to scala 3. For all the complaints about the language that always pop up in these threads: yes, the language lets you shoot yourself in the foot (with great power comes people who don’t apply it responsibly), but it’s precisely that power that makes it so useful and exceptional when judiciously applied. I like to say that scala is as if java and ruby had a love child and…

I appreciate you taking the courage to share your honest thoughts despite how they may conflict with the views of others here. My heart goes out to the people I overhear at work, the ones who are struggling the most, lamenting and complaining that tool X (In this case scala) is “so” embarrassingly awful and, with the implication that it’s to blame for their poor performance. That sentiment resembles some of the comme…

Not every language has to be for every person. It's perfectly fine that people enjoy Scala. I think a lot of the negativity about Scala is because lots of companies went in hard on Scala less because of the merits of Scala, and more because Java had such a long period of stagnation.

Re: The Road to Scala 3

#50

Post by jkachmar »

yahyaheee wrote: post #33
jkachmar wrote: post #24

Earlier quoted context omitted.

Big ol’ “Citation Needed” on this one. The flip-side here is that a language that doesn’t support basic programming language theory concepts dooms its users to repeat the mistakes of those who discovered them. I also would personally disagree that any statically types language without generic types and without non-nullability (e.g. `Option`/`Maybe` and `Result`/`Either`) is severely lacking in the ability to express…

proof is in the pudding on that one, sorry don't think there are academics studying this but it's an obvious outcome from the war that was Go/Scala/Node. Go is eating Scalas lunch because its easy to understand and communities are stronger than individuals. Sure Scala has more 'features' but Rob Pike would say every feature has a cost and you need to weigh that, didn't see that ever happen in Scala. Go is taking the…

Another commenter points out that Go has Google backing it, which is a significant confounding factor in terms of figuring out how good it is on its own merits.

I’ll add to this and say that Go is a language that is very well-suited for Google’s issues. Namely, take a bunch of engineers with a particular area of familiarity (e.g. familiarity with C and/or Java) and throw them at code, scaling up by number-of-engineers where necessary.

My issue with pointing to this and calling it “practical” and “easy to understand” is twofold:

(1) Go implicitly makes its ease of understanding dependent on an having existing background knowledge of concepts that the HN crowd is likely to have, themselves, which biases people but isn’t particularly easy to learn on its own merits (versus, say, Python)

(2) Most companies cannot afford to solve engineering problems by throwing more bodies at it, but with Go your option is either that or leveraging external code generation

As far as “taking the time to get each piece right”, this stuff isn’t cutting edge technology development! Go isn’t doing dependent typing or borrow checking or scoped effects!

Everything that people lambast the language over not having is old hat, it’s like defending a car manufacturer who chose to use carburetors over fuel injection by saying that they’re trying to figure out how to do it right.

Post reply on HN