still_grokking

Extremely weird list.

The Scala spec is much shorter than the C spec… Also it's of course much shorter than Rust, where nobody has a real issue with its complexity, at least nobody is complaining really loudly.

The C and Go specs are actually extremely involved, long, and complex given that the languages almost don't have any features at all.

But comparing language specs isn't a 100% fair metric.

One should instead look at formal language semantic definitions written all in the same way.

If you look at these you will for example learn that the C semantics are much more complex than for example Java.

Check out https://kframework.org/ to learn more. (A list of semantics for different languages can be found on the "projects" sub page).

> In the end it was "so bad so sad you can always reenable brackets".

This is not true.

Nobody ever proposed to replace the old syntax!

The new syntax was, and is, optional, and that's exactly like designed from the very beginning.

> Its nice but to pretend it prevents bugs or is even a great design goal is questionable and not backed up by research (as they claim).

That's why people use JavaScript instead of Rust for critical systems, right?

Claiming in the year 2025 that strong static types don't provide massive advantages is almost laughable, TBH. This was settled long ago, and the whole industry now understands that type safety is inevitable to create reliable and scalable systems.

> It was a little weird it blew up in industry for a while.

It never went away. It only got more:

https://business4s.org/scala-adoption-tracker/

> It's really a shame because in many ways I do think it is a better language than anything else that is widely used in industry but it seems the world has moved on.

No it didn't. Scala is powering some of the biggest companies on this planet.

https://business4s.org/scala-adoption-tracker/

It does apparently so well that nobody is even talking about it…

So it seems even better than all the languages people are "talking" (complaining) about.

> PS Perhaps they should make an actual unit test suite for their compiler. Instead they have a couple of dozen tests and have to guess if their compiler PR will break things.

You did not even try to formulate it in a way that could be interpreted as you just not knowing; instead you make blatant false statements in the most confident way possible.

Your statement is therefore an outright lie, spreading FUD.

As a matter of fact the Scala compiler has thousands, likely even tens of thousands of test cases.

https://github.com/scala/scala3/tree/main/tests

But that's not all. Scala (2 & 3) has also a test case called "community build" where new compiler releases are tested by compiling millions of LOCs from all kinds of Scala OpenSource projects.

https://github.com/VirtusLab/community-build3

https://github.com/scala/community-build

> My main recollection of it is getting Java compiler errors because Scala constructs were being implemented with deeply nested inner classes and the generated symbol names were too long.

Sounds like you've used some beta version over 15 years ago.

Nothing like described happens in current Scala and it's like that as long as I can think back. Never even heard of such bugs like stated.

Coming up with such possibly made up stuff over 15 years later sounds like typical FUD, to be honest.

What parent describes is pretty simple: That's just how the compiler transforms some code.

Do-notation in Haskell, or for-comprehensions in Scala are just syntax sugar for nested calls to `flatMap`, `filter`, and `map`.

I think this here shows it nicely:

https://www.baeldung.com/scala/for-comprehension#for-compreh...

In Scala you can add the needed methods to any type and than they will "magically" work in for-comprehensions. In Haskell you need to implement a Monad instance which than does the same trick.

The concrete implementations of these methods need to obey to some algebraic laws for the data structure which defines them to be called a monad. But that's pretty much it.

In my opinion all that Haskell in most "monad tutorials" just blurs an in principle very simple concept.

The in practice relevant part is that a monad can be seen as an interface for a wrapper type with a constructor that wraps some value (whether a flat value, some collection, or even functions, makes no difference), does not expose an accessor to this wrapped value, and has a `flatMap` method defined. It also inherits a `map` method, coming from an interface called "Functor". The thing is also an instance of an "Applicative", which is an interface coming with a `combine` method which takes another object of the same type as itself and returns a combination of again the same type (classical example: string concatenation can be a `combine` implementation if we'd say that `String` implements the `Applicative` interface).

Scala's new effect library Kyo just uses `map`. See:

https://getkyo.io/#/?id=the-quotpendingquot-type-lt

All pure values are automatically lifted into the Kyo monad, so `map` is effectively `flatMap`.

From the linked docs:

> This unique property removes the need to juggle between map and flatMap. All values are automatically promoted to a Kyo computation with zero pending effects, enabling you to focus on your application logic rather than the intricacies of effect handling.

In the end it makes a lot of sense I think. What you do is manipulating values inside some wrapper. Whether this wrapper is a monad or not should not matter. Just do something with the value(s) inside, and that's mapping.

> the user is responsible to obey the license of the original work

The user is in this case the "AI" company.

They already violated law almost certainly by copying stuff from the net in the first place. (Almost certainly as it by now does not look like this was fair use, and there is no other means to make legal what they did.)

That's not true.

Some people (like the NYT¹) are in fact demanding before curt the destruction of the trained models as they obviously contain copyrighted content.

¹ https://pressgazette.co.uk/media_law/new-york-times-open-ai-...

But why should things work differently for "AI"?

One could of course say that "IP" ("intellectual property") is an ill concept all in all and abolish it. But than without exceptions! If it's not a valid concept in regard to "AI" it's not a valid concept in general. But if we want to keep that concept "AI" needs to bend to the same rules that apply to anybody else. Simple as that. Law is universal. (At least it should be like that everybody is equal before the law.)

As you say, "China" is here only a placeholder.

This "logic" that you need to do obviously illegal stuff (under current legislation) because otherwise someone else would do it and take the loot from that raid remains highly questionable no matter what country you put in that placeholder.

The same "logic" would for example dictate that you should dismiss patents as otherwise "someone in China" could do it before you. Somehow nobody would agree that this is a valid approach in that case…

I'm not sure you tried to understand what I've depicted.

As long as you don't know how the end result should look like there are no "mistakes".

The whole point of explorative work is to find out how to approach something in the first place.

It's usually impossible to come up with the final result at first try!

After you actually know how to do something in general tools which help to avoid all undetected mistakes in the implementation of the chosen approach are really indispensable. But before having this general approach figured out too much rigidity is not helpful but instead a hindrance.

To understand this better read the linked article. It explains the problem very well over a few paragraphs.

Rust? Since when is Rust the pinnacle of static type safety?

After I've worked for some time with a language that can express even stronger invariants in types than Rust (Scala) I don't see that property anymore as clear win regardless circumstances. I don't think any more "stronger types == better, no matter what".

You have a price to pay for "not being allowed to do mistakes": Explorative work becomes quite difficult if the type system is really rigid. Fast iteration may become impossible. (Small changes may require to re-architecture half your program, just to make the type system happy again![1])

It's a trade-off. Like with everything else. For a robust end product it's a good thing. For fast experimentation it's a hindrance.

[1] Someone described that issue quite well in the context of Rust and game development here: https://loglog.games/blog/leaving-rust-gamedev/

But it's not exclusive to Rust, nor game dev.

By chance I came just today across GitHub's SpecLang:

https://githubnext.com/projects/speclang/

Funny coincidence!

I leave it here for the nice contrast it creates in light of the submission we're discussing.

> isn't that just copilot "explain", one of the earliest copilot capabilities. It's definitely helpful to understand new codebases at a high level

In my experience this function is quite useless. It will just repeat the code in plain English. It will not explain it.

AI can predict how some code behaves when run?

So AI can predict whether some program halts?

Seriously?

I didn't watch any other talks of this conference, but it looks to me as part of the issue here was that the presenter didn't explain basic (ML) types upfront. Maybe they did in other talks earlier, IDK.

If you never seen such types before it may look intimidating. But if you ever seen any ML style language the type of said function looks actually very ordinary. It does not use any really more complex concepts, it's just regular nested generic types. Pretty standard stuff.

In Rust you could also have things like:

  fn foo<'a, T, U, V, W>(a: &'a T, b: U, c: V, d: W)
  where
      T: MyTrait<U> + Debug + 'a,
      U: Debug + Hash,
      V: SomeOtherTrait<V> + Debug + std::marker::Copy,
      W: Box<dyn Fn(V) -> U> + Debug,
  {
      todo!("Just a demo");
  }

That's indeed much more involved, even it doesn't use any deeply nested wrapper types.

But I think nobody would force such complex signatures on API end-users.

(Even there is of course also no magic going on. It's just the quite quite expressive type language in Rust).

I agree that something like "over-typing" exists. But where it starts is imho very context dependent.

For the lowest level (e.g. an OS) you really want an extremely strict regime. Bugs are "simply not allowed"…

For application level code I think it depends. Nobody would finish anything if the requirement would be to formally verify all your code.

The other thing is: How far you can get before "over-typing" starts is also dependent on the language and how powerful it's type inference system is. Rust is quite weak in this regard.

In a language where the compiler can pass context for you one can have very strong guaranties without making working with the code too awkward. Of course, changing the code will need work. But that's the whole point of type systems: If you change something the compiler will tell you any places where something needs repair. In less strongly typed languages you can just pray that your tests are good enough to cover the changes.

In case of changes a good compiler will even rewrite the trivial cases for you if you ask, and just leave what really needs human oversight. But such automatic rewriting (with the guaranty that nothing went wrong!) works only if you had very strong types in the first place.

> Replacing `Either<this, that>` with something like `this | that`

That's not the same.

The first one is an ADT instance with exactly two cases, whereas the other is an arbitrary union type.

The difference is when you pattern match on them. In the first case the compiler can statically verify that you handled all (two) cases. In the second case you can deconstruct the union, but you're not forced to handle all cases, simply because there are no know "all cases"; you could have arbitrary unions of any amount of things. (Of course the compiler could create for any usage of an union type some synthetic ADTs behind the scenes and check exhaustivity on them, but this would explode pretty quickly, I think, because of code bloat and compile times. Also that's not the expected behavior of union types in general).

> Designing an API is a typing issue, because an API is essentially nothing more than a list of types.

It's more a list of signatures, and some interaction protocol on top of that. (Frankly not expressed in types usually. We don't have simple ways to use things like session types still).

The types used in your signatures can be as specific or general as you want. It's the choice of the API designer. There is no issue with typing as such. You could just declare everything being a function from `Any => Any`… That's of course as bad as having so specific types that there can be more or less only one object shape that fits it. Classical over-typing, and that's imho just bad API design…

But it's not template magic. Not even something close.

It's just nested generic types.

How would you otherwise express all the constrains in a type?

Imho quite bad example.

Not even one tubo-fish. No multiple lines of `where` clauses. No (dyn) trait impl. Not even a lambda!

On top of that Rust's syntax is full of noise. Curly braces, semicolons, ugly angel brackets, `::` instead of points for namespaces, etc.

Rust is a quite good language on the technical level. But the surface syntax is really ugly.

I don't think this would go well for Linux.

The companies actually paying for the kernel development want Rust. That's a matter of fact.

Just see who's sponsoring the Linux Foundation, and check what they said elsewhere about their long term commitment to Rust.

The main sponsors would likely just fork Linux should Rust be removed again. Than Linux would be left with "community contributions" and the trademarks, but all the big money would go to the fork.

Of course nothing like that will happen. Because Linus knows very well where the money is coming from.

There is a flaw in this reasoning.

Nobody ever said that a subsystem maintainer needs to fix Rust bindings.

As Ts'o correctly states, that's the problem of the bindings maintainers.

But there is no problem at all. All that the Rust people want is to be informed about breaking changes. Also they said they're happy to get instructions on the semantics of the C APIs. They seem to want to collaborate. The C people just want them out, as it seems looking at this episode.

Debian is already ported (in parts) to different kernels.

Windows "Teletubby Edition"? :-) No, Win2k was "peak Windows", imho.

Frankly MS later ditched the quite ambitious Windows NT 5.0 project, which was the planed Win2k successor, for a Frankenstein monster made out of the super buggy WinME and Win2k. That became Windows XP.

Coming from Win98, Win98SE, WinMe, WinXP was for sure quite good. But compared to the super stable, fast, and well structured Win2k it was quite a disappointment. It didn't have almost any of the advanced features planed for WinNT 5, it was much more unstable and buggy than Win2k, it was quite chaotic with "old Win95" parts, stuff coming from Win2k, and some things on it own placed randomly.

But you're not running Microsoft's Windows. You're running the output of an AI! And as everybody knows, there is no copyright on the output of an AI.

The (real-time) training of the AI was also completely legal, as an AI may train on anything found on the web, as that's freeware anyway.

The AI never stored or stores any copyrighted material. It just learns from it. Now in revolutionary real-time!

So how could wget.ai, or anything produced by it, be considered illegal? Using data found on the web to train AI models is fair use after all!

Excellent trolling! Funny thread.

Use of humor on HN triggers down-votes quite often.

Why it's like that, IDK.