So doesn't this mean GrapheneOS is effectively controlled by Google now?

Also, how is keeping anything secret under NDA possible at all if you want to know what's in a security update and be actually able to build that update yourself from source?

People sometimes act as if the one would be an viable alternative to the other. Even both are effectively the exact same shit for the exact same reasons.

How about we move instead to open systems?

At the same time Apple keeps telling their users some fairy-tales about "privacy".

No, Apple isn't honest. Definitely not.

I think that's actually true. But what does it mean, what's the way forward?

They are, as always, using Windows to sell all their other crap, especially Azure and 365. Things like their AD or office tools are tightly integrated into the cloud so you realistically can't even use the one without using the other.

I would hardly notice, TBH.

There are alternatives for all of that.

They are big in everything that is mass scale developer oriented with things like GitHub, VSCode, or all their libs, tools, and integrations (they "own" in large parts for example Python, TS, and Rust). Governments and public services are all running on Azure. So do a lot of companies; more or less all small and mid sized. They are still dominant in the gaming market, and get stronger there with every year.

Microslop was always, and still is the same Microslop. They are very successful with what they do since decades. Whether one likes that or not.

That's also part of what I've said.

The point still being: Where you need a safe language there is no way around it, and Scala is still one of the very few options you have at all. Scala is in that regard indispensable.

> I feel that Scala 3 really hurt the community angle

I don't see that.

Everything relevant, besides Spark, is now on Scala 3, and this is already like that since a few years.

But I agree that Scala documentation / references / tutorials are to this very day lacking. This was and still is a real issue, and that's actually a very relevant one. I really hope this gets better with time.

The sub-optimal situation regarding docs does though not prevent people from starting new projects in Scala.

In fact Scala 3 is again ahead of the pack. It provides features not seen so far in any real world language and will almost certainly again pioneer the implementation of new language concepts in the large, as it did already in the past with its pragmatic approach to a OOP / FP fusion.

Just see for yourself what is currently happening:

https://softwaremill.com/understanding-capture-checking-in-s...

Of course such non-discoverable and unintuitive design gets ignored everywhere!

We just established that even in Python the correct way to do it would be

  Iterable[str].join(str) -> str

> For example I'm lost which abstract class to inherit in Scala to obtain mkString for my custom container.

So you're saying you've been able to implement custom Scala collection types, which is regarded some of the more difficult stuff one could possibly do, but you don't know how to implement an Iterator for your custom collection—as this is all needed for mkString to work? BTW, how did you implement the collection type at all without implementing Iterator for it? Your collection is not Iterable?

TBH, this does not sound very realistic. This sounds more like typical HN Scala FUD. People throwing around some vague, most of the time outright made up issues they've heard about somewhere about 10 - 15 years ago.

The semantically correct one is "Container[T : Printable].join(): String"; T must implement the Printable concept, but Python lacks concepts (or type-classes as these are alternatively called).

But this all is irrelevant as this is anyway not the signature of `str.join()` in Python. It's `str.join(Iterable[str]) -> str` there. With sane design and syntax it would just become `Iterable[str].join(str)`.

I can't find it.

Could you link to that "best Scala development experience by some margin"?

All I know is that the Eclipse plugin is dead since about one decade. But maybe I just missed something.

> the integration/bridging piece is still flaky

What concrete issues do you have?

I'm using Metals on a daily basis and don't know about any such problems.

Could it be that the last time you've seen Scala (if you actually ever seen it at all) was about 10 years ago?

The discussions here on HN regarding Scala seem always massively dishonest, with a lot of people always spreading outright FUD for some reason I don't understand…

Linking some GitHub repo does not explain anything.

What is "abuse", what is "magic" in this context?

It was about translation strategies and macro expansion.

But this makes no difference. You have all issues you just named exactly the same in so called "high level languages" as you have in C. C is in fact a high level language, and the code you write in C has not much in common with what the machine actually executes. The last time this wasn't like that is about 40 years ago.

1. Whether the C optimizer kicks in or not is pure dark magic. Nobody can tell from just looking at the code. The optimization techniques are way too complex to be understood ad hoc, not even experts can do that.

2. The difference between the optimizer doing its work, or instead the computer just verbatim executing whatever someone written down is hilariously large! Adding -O2 can make your code many orders of magnitude faster. Or it does almost nothing… (But like said, you can't know what will happen just from looking at the code, that's point again 1.)

3. You neither can express what the machine does in C. The machine does not execute anything like C. The last time it did is over 50 years ago… Since at least 30 years we have kind of JIT compiler in the CPUs which translate the result of compilation to ASM into the actual machine language. A modern CPU needs actually to emulate a computer that still works like a PDP-11 to match the C machine model even the real hardware does not look anything like a PDP-11 any more! You have only very indirect influence on the actual machine code when writing C. It's mostly about forcing the CPU internal JIT to do something, but you have no control over it, exactly as you don't have control over what for example the JVM JIT does. It's the exact same situation, just a level lower.

The point was to show that big corps are dependent on Scala, often at their core.

Scala is likely not for everybody, but where you need to write safe high level code there is more or less no alternative, not even on the horizon. Scala is simply very likely where Rust will end up after the honeymoon, when people realize that feature rich, safety first languages aren't for the mass market, where mostly only the cost of initial development counts.

> If I recall correctly, later they added a switch allowing one to choose between syntax versions in the online docs.

Stating this, which is not, and never was true creates the impression you're talking about things you have no clue about.

The point is: Removing braces really makes code much easier to read for people who get distracted by useless line noise!

> So reading unfamiliar syntax is literally harder. > […] > Source: have a degree in neurophysiology.

You need a degree to understand something such obvious? Never mind…

The point is: New syntax is only new in the first few hours of contact with it.

Anybody who uses more than one language knows that switching languages is in fact a bit distracting, but at latest on the second day you completely stop thinking about syntax, and than switching back to whatever was before is as hard as the previous switch to the current thing. Usually this happens already after a few hours for languages you already know.

As we're talking about neurophysiology: As a matter of fact filtering "noise" — irrelevant information — from sensory input is a hard task for the brain. So having less distracting useless noise in the input helps to concentrate on the stuff that actually matters!

Braces in code are 100% redundant, useless noise. The only reason they were added in the first place was to make code simpler to parse for computers, something that does not matter any more since many decades. So there is no rational reason any more to pollute code with useless, distracting noise.

Scala 3's macros support staged compilation, so you can have macros which create code in later stages at runtime.

https://docs.scala-lang.org/scala3/reference/metaprogramming...

Doing so is a feature of high-end VM runtimes like the state of the art JVMs or JS runtimes.

The great new syntax is the very reason I don't want to even touch Scala 2 any more.

The syntax change is the absolute highlight in Scala 3. It makes the language so much better!

The only real problem was that it happened so late; at least a decade too late.