still_grokking

I've said I'm not sure about the validity of that reasoning.

I've liked it nevertheless for context, as augmentation to parent's post.

Exactly! Completely new languages without large amounts of reference material are terrible for LLMs.

Or it's just some AI brain fart…

The whole things looks vibe-coded, and vibe-designed.

You're looking for Scala… ;-)

https://news.ycombinator.com/item?id=47957121

That's in large parts Scala.

It doesn't have Hindley-Milner type inference, but it has very strong type inference.

We will get linearity soon thanks to and as part of the Capybara[1] effort.

Refinement types are already long a reality.

The whole new effect tracking thing is based on delimited continuations.

The Unison style content addressability comes up now and then, maybe it will become a reality at some point. It's though mostly not a language thing but more a build system thing.

Scala is already great for for LLMs also for other reasons:

https://arxiv.org/html/2510.11151v1

[1] https://2025.workshop.scala-lang.org/details/scala-2025/6/Sy...

Why would you need "header files" when a LSP server can give you just the outline of some file?

Why would anybody use a vibe-coded and vibe-desinged language which effectively does not exist yet instead of an established one with such features, like Scala?

https://arxiv.org/html/2510.11151v1

Wasn't that legalize the reason Gram got created?

https://gram.liten.app/

Yeah, that's great!

Imagine we would download random code from the internet and just execute it, like with NPM, PIP, Maven, Cargo etc.

How about SELinux, like on Android?

Will this continue like that even when the prophesied Mythos Vulnocalypse hits the Kernel?

This stance doesn't seem sustainable any more to me.

As I did not know what AF_ALG is in the first place I've searched for it and found this here:

https://www.chronox.de/libkcapi/html/ch01s02.html

It states the following:

There are several reasons for AF_ALG:

* The first and most important item is the access to hardware accelerators and hardware devices whose technical interface can only be accessed from the kernel mode / supervisor state of the processor. Such support cannot be used from user space except through AF_ALG.

* When using user space libraries, all key material and other cryptographic sensitive parameters remains in the calling application's memory even when the application supplied the information to the library. When using AF_ALG, the key material and other sensitive parameters are handed to the kernel. The calling application now can reliably erase that information from its memory and just use the cipher handle to perform the cryptographic operations. If the application is cracked an attacker cannot obtain the key material.

* On memory constrained systems like embedded systems, the additional memory footprint of a user space cryptographic library may be too much. As the kernel requires the kernel crypto API to be present, reusing existing code should reduce the memory footprint.

I can't judge whether this is a good justification, but there is one.

Can someone ELI5 that for me?

Is this the mathematician's variant of "my language is better than your language", or what does this post actually discus? Something fundamental in the philosophy underpinning things or just the way to express them?

the only real advantage for local models (privacy/secrecy) hasn't proven convincing for broader IT either

Because of nonexistent regulation. Just wait for it…

The legal situation in for example the EU is crystal clear, only that it will take some time to go though all court instances.

Looks like the Chinese are, again, winning the long game.

There is simply nothing that could compete with their open models. At the same time more and more corps got "AI addicted", so they will either have to pay ridiculous amounts of money, or use the Chinese stuff.

Their vibe-coded "documentation" sucks so much…

If you want to keep your shiny Apple stuff you're effectively trapped. Their walled garden approach works extremely well…

The "quality" Apple delivers is by now a complete joke. It's going south since over a decade, and this never stopped.

It's like that because people are still buying. Even for the ridiculous prices Apple asks for.

So why would Apple actually care? They get away with this "quality", so from a business standpoint there is simply nothing that needs investments or even just attention.

It's a race to the bottom. Like everywhere else. That's simply how the system which people created works.

This "test" makes no sense. Cyan, and especially turquoise are neither blue nor green, they are a mix (similar to orange between red / yellow).

I had actually a very hard time to answer the questions, needed to overlay most of the color with some mostly white / light gray window and only squint at the color around it to decide. In the end my result was 176, which is almost the exact turning point for most people (and that even while my monitor is set to be more cold than default; but like said I had whatever my monitor shows as "white" to compare; even that "white" is likely technically slightly blue-ish).

Color perception is anyway much more influenced by contrasts then anything else. (Likely similar to acoustic tones, which are very hard to name / locate absolutely than when comparing to some reference tone.)

Besides the things mentioned in the about popup, blue is AFAIK the color we have the most receptors for. So it's imho quite "natural" that most people perceive cyan—which is technically the exact middle—as blue-ish, and of course the color left to it, turquoise, is green-ish (and as it seems, for most people, the mentioned turning point).

GrapheneOS had to sign some sort of non-disclosure for them, in order to roll them into updates.

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?

Just to switch to an even more aggressively monitored and tightly controlled walled garden?

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?

Don't forget that Apple is spying on their users even more then Google does (which is gross in its own). Apple controls much more user data then Google does.

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

No, Apple isn't honest. Definitely not.

That escalated quickly.

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

Just use µBlock Origin for most of the annoyances, and for the stupid google popup a simple Stylus CSS rule is enough.

TBH, you could change a few terms and that text wouldn't look much different in the 90's. Microslop never gave a shit on end-users and what they think. Nobody ever "liked" Microslop. People were always complaining that Windows is shit, Office is shit, MS Servers are a joke, etc. Nobody at Microslop ever cared. They always cared only about having all the companies and governments in ransom, which was always their golden egg goose. The only other thing they care about, to make the first thing happen, are developers. They put a lot money into keeping people developing using their tech, and this actually works. Even on Linux it's hard to avoid Miroslop tech. (I've got just today a Pipewire update which pulled in some MS libs for ML; and there is for sure more as they have even code in the Kernel.) Microslop's EEE strategy is a long game, which is actually pretty hard to beat.

Most client PC are still running on Microslop Windows.

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.

mail, maps, docs, search, etc. It would be pandemonium

I would hardly notice, TBH.

There are alternatives for all of that.

I'm not sure where you are but at least here Microslop is still ruling more or less everywhere besides the online ad market.

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.

But safety is not the only important aspect of a programming language.

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...

Python has convenient and good type design with str.join ignored by other languages.

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.