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

Linus Torvalds talks AI, Rust, & why Linux is the only thing that matters

zdnet.com

Post reply on HN
Print view View original

121–127 of 127 posts

Re: Linus Torvalds talks AI, Rust, & why Linux is the only thing that matters

#121

Post by still_grokking »

zozbot234 wrote: post #98
aeurielesn wrote: post #76

Earlier quoted context omitted.

IMHO, as a C developer, I love Rust's features but the syntax is terrible.

Yup, Rust syntax is just the worst - except for all the other syntax proposals that have been made over time: https://matklad.github.io/2023/01/26/rusts-ugly-syntax.html

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.

Re: Linus Torvalds talks AI, Rust, & why Linux is the only thing that matters

#122

Post by still_grokking »

flohofwoe wrote: post #111
commodoreboxer wrote: post #106

Earlier quoted context omitted.

Maybe it's because I'm working a lot with V8, but that looks quite a lot like most C++ generics I've been looking at lately. Especially when working with concepts, it's easy to end up 5 or more nested angle brackets in.

Yeah, but is that a good thing? Complex template magic is hardly one of the good parts of modern C++.

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?

Re: Linus Torvalds talks AI, Rust, & why Linux is the only thing that matters

#123

Post by trissi1996 »

pif wrote: post #113
trissi1996 wrote: post #82

Earlier quoted context omitted.

Did we see the same video ? The rust guys were just asking for semantic information about the current C apis so they could try to encode them into the type system. All they got in response to that were made up problems of them supposedly forcing everyone to adopt their religion, rust being too OOP or other nitpicks that had nothing to do with the issue the presenters were trying to talk about. Nobody even answered th…

> people which obviously didn't even look at rust Since when is Rust a requirement to help Linux development? Only an utter idiot could think that such a big and successfully community would put any effort in addressing any issue that is not posed in their natural language! If you want to introduce Rust into Linux, you learn C, you learn Linux, you add and maintain whatever you want.

> Since when is Rust a requirement to help Linux development?

It's not and it shouldn't be, but it is most definitely required if you want to criticize it's integration into the kernel due to its supposed flaws/merits in a "technical" discussion.

Nobody is forcing anyone to learn rust, the RiL folks are fine with maintaining bindings and handling the fallout of C API changes. They didn't even get to say that, because they were shouted at for asking a question.

> If you want to introduce Rust into Linux, you learn C, you learn Linux, you add and maintain whatever you want.

Which is basically exactly what the RiL community is doing. In the posted video you can see them TRYING their best to learn about the undocumented invariants of a C API and getting nothing but flak for it for completely made up reasons. I might be hard to understand, but many of the strongest advocates of rust know C well and are opposed to using it themselves for good reasons. The folks maintaining C API don't have to care much about the rust part, except maybe giving a friendly heads-up when they change API's they depend on, like you would in any kernel development work where you are impacting another subsystem.

Apparently this is too much to ask from some of these C grandpas.

While these guys have undoubtedly made great contributions to Linux and FOSS and I'll be forever thankful for that, some of their behavior towards the RiL community has been appalling and petty. They have been resistant to any sort of change, even if it does not impact them at all, are quick to criticize without any attempt at understanding the efforts and benefits of Rust integration or even making any technically coherent argument. Constructive criticism and open discussion is important, but it should be based on accurate information and a willingness to learn instead of knee-jerk reactions and reacting to people wanting to learn about the API of your subsystem with outright and unwarranted hostility.

Re: Linus Torvalds talks AI, Rust, & why Linux is the only thing that matters

#124

Post by still_grokking »

flohofwoe wrote: post #109
tcfhgj wrote: post #100

Earlier quoted context omitted.

How would you like Rust to describe such Types? > a PITA to work with in real world projects, and on both sides of the API. Don't see how this is a Typing issue, sounds more like API issue

> How would you like Rust to describe such Types? If I knew the answer I would design programming languages ;) Replacing `Either ` with something like `this | that` like in Typescript might be going into the right direction though. Zig has similar syntax sugar for Rust's Result and Option . Such things are so fundamental that they should be part of the language instead of the stdlib IMHO. > Don't see how this is a Ty…

> Replacing `Either` 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…

Re: Linus Torvalds talks AI, Rust, & why Linux is the only thing that matters

#125

Post by still_grokking »

flohofwoe wrote: post #110
steveklabnik wrote: post #99

Earlier quoted context omitted.

I mean, it’s very straightforward generics. There’s just nesting, each of these types has one or two parameters and that’s it. I’m not sure there’s a simpler way of communicating the same thing. But I also think that I wouldn’t design an API that works like this in Rust natively; this is adapting a signature from C rather than doing the API you’d want if you were creating something from whole cloth. I also believe th…

IMHO there's a pretty wide range between static weak typing and static strong typing even within a single language. Going too far into either extreme has more downsides than upsides - yes, strongly typed code will be more correct because the types might catch usage 'logic errors' during compilation, but also harder to maintain when requirements change (because strong types tend to creep into every little corner of a…

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.

Re: Linus Torvalds talks AI, Rust, & why Linux is the only thing that matters

#126

Post by still_grokking »

flohofwoe wrote: post #94
dmm wrote: post #90

Earlier quoted context omitted.

What things are hideous about it and what would you rather it look like?

That video snippet which was posted by that former Rust/Linux maintainer has an excellent example: https://www.youtube.com/watch?t=1529&v=WiPp9YEBV0Q&feature=y... The return type of that get_or_create_inode() function is: Result >, inode::New >> I'd say that's a pretty good example for 'hideous'. It looks like some of the worst C++ code I've seen and then quickly tried to forget. If stuff like this ends up in the Lin…

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: &'a T, b: U, c: V, d: W)
  where
      T: MyTrait + Debug + 'a,
      U: Debug + Hash,
      V: SomeOtherTrait + Debug + std::marker::Copy,
      W: Box 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).

Re: Linus Torvalds talks AI, Rust, & why Linux is the only thing that matters

#127

Post by tcfhgj »

still_grokking wrote: post #124
flohofwoe wrote: post #109

Earlier quoted context omitted.

> How would you like Rust to describe such Types? If I knew the answer I would design programming languages ;) Replacing `Either ` with something like `this | that` like in Typescript might be going into the right direction though. Zig has similar syntax sugar for Rust's Result and Option . Such things are so fundamental that they should be part of the language instead of the stdlib IMHO. > Don't see how this is a Ty…

> Replacing `Either ` 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 be…

If you need a certain object shape, best require it in the API.

You can't be too specific there, because being as specific as possible has advantages: https://news.ycombinator.com/item?id=41409475

Post reply on HN