oxnrtr

I readily believe that PHP devs struggle with anything more complex with Go, but that makes me question how people end up with the lack of will to learn and improve in this profession.

Go doesn't have a one-page spec, so what do you expect the GP to point to? You are proving his point.

Especially when other languages got them right.

Read the article maybe?

Maybe the core issue is that you are just not a good programmer.

Do you really think your incredibly arrogant and condescending comment adds anything to the debate?

I encourage you to try and consider the author's points instead of simply attacking her character.

I'll be there if you need help with that.

I can't tell whether this satire.

Tell me you have basically no understanding of the subject matter without telling me you have basically no understanding of the subject matter.

There are good reasons for it, and I'm certain you will gain a better understanding as you gain more experience as a developer.

No.

    fun read(path: &Path): io.Result[Vec[UInt8] {
      var file = File.open(path).orReturnErr()
      var bytes = Vec.new()
      file.readToEnd(&mut bytes).orReturnErr()
      Ok(bytes)
    }

would be good enough for me, tbh.

Paying people properly has very little impact on customer prices, see countries who enforce this.

CanBuildFrom got killed in 2.13, but taking a step back is exactly the right thing to do:

The desire to return the same type of collection lead to overall slow performance; it turned out it's a design dead-end that Scala is still suffering from.

It should simply have been abolished and replaced, instead of applying some minimal fixes in 2.13 that preserved the wrong design choices.

Joking? Scala 3 added 20 keywords (14 of them contextual), many of them with entirely new syntactic constructs behind it.

Using [] is the optimal choice for languages in general, but they can't even use that because they blew away that syntax for indexing.

They parse it one way, and if they figure out the other parse option was right, they go back and fix the parse tree.

Basically, unlimited look-ahead.

Not really. That Rust forced total order and partial order into a sub-typing relation is a completely unnecessary, self-inflicted wound.

Can you link to such an action happening?

... and on Lobsters you would neither need to speculate what happened nor kneel in front of the mods to fix it, because moderation actions are publicly logged¹. :-)

¹ https://lobste.rs/moderations

Having a smaller community doesn’t mean "same composition of people, just fewer of them".

I think Lobsters has done extraordinarily well in attracting domain experts while keeping out the valley-style surveillance capitalist blockchain AI expert “investors”. Non-tech articles are explicitly off-topic on Lobsters.

Lobsters may have fewer experts in total numbers, but experts make up a bigger share of the community, which means that the amount of pointless, fluff, snarky comments is way lower.

The hats¹ also means that experts are easily recognizable, because they can display the badge when they comment somewhere as an expert-on-that-topic.

¹ https://lobste.rs/hats

Core team didn't care about Android. Simple as that. :-)

It absolutely does not.

It removes a few things and adds a whole lot of new stuff to it.

It's a bigger, more complex language, even if you credit all the cleanups that were already in Scala 2 to Scala 3.

So, no, Scala 3 won't help. Most people who cared left years ago.

As the person who was involved in Scala on Android (and particular in creating the website), I'll chime in with this:

What sunk Scala on Android was largely the completely lack of interest from the core team.

Everything that Scala on Android achieved was pretty much _despite_ the actions of Scala's upper echelon.

- It's hard to get a good message out, when core members spread FUD by bringing up problems that were solved year ago (like the big std lib issue).

- The core team's perception of Scala was always inward – new platforms existed such that Scala developers could run their code in more places, not because it could attract new developers from these existing ecosystems to Scala.

(Scala.js partially overcame this by herculean efforts of individual members of the Scala.js community that got the word out to the JavaScript world about Scala.js.)

- Core Scala pulled the plug from Android support in the backend. So Scala on Android was pretty much left to die on an outdated Scala version.

- Something like TASTY (an interchange format that can be recompiled on the fly to target new backends), which could have dealt with the problem above – was promised for years, but still hasn't shipped.

- The core team was against even acknowledging the existence of Scala on Android on the website – good luck in convincing that Scala on Android works, if the official website/documentation doesn't mention it with a single word.

- Core Scala treated the main contributor with so much public disrespect, that I'm still surprised he didn't outright quit back then. It takes balls to publicly blame the main contributor of Scala-on-Android for not working on the project full-time, but also conveniently managing not to tell him this crucial "requirement" for half a decade. And with "full-time" I mean "unpaid full-time".

It's a sad story, because Scala-on-Android shipped with some amazing features like hot-code-replacement years before Google managed to ship it. The typed resources stuff was also pretty impressive.