5 ms·

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

andrewmcwatters 2y ago
Another developer here who writes in C and C++, same. I think a lot of people have this complaint. I'm sad about it because what Rust provides in principle sounds great. The language is hideous though, and I really don't want to write anything in it.
- dmm 2y ago
  What things are hideous about it and what would you rather it look like?
  - andrewmcwatters 2y ago
    [flagged]
    - kranuckle 2y ago
      [dead]
  - flohofwoe 2y ago
    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=youtu.be https://www.youtube.com/watch?t=1529&v=WiPp9YEBV0Q&feature=y... The return type of that get_or_create_inode() function is: Result<Either<ARef<INode<T>>, inode::New<T>>> 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 Linux kernel I would be pissed too as a Linux kernel greybeard.
    - steveklabnik 2y ago
      I agree that it could maybe use some new types, but it also does kinda get to the heart of this: I’ve never used this kernel API before, but I can say “oh, this function may error out, but if it doesn’t, it gives me either a new inode or a reference (I’m assuming that’s what ARef is) to an existing one. That’s a lot of valuable information, at a glance.
      - flohofwoe 2y ago
        > That’s a lot of valuable information, at a glance ...if you know how to decode it. That example looks like one of those C++ SFINAE hacks, e.g. trying to bend the template/generics syntax beyond what it was designed for. If Rust APIs want to go that way (of overly expressive strong typing) then Rust really should offer a better syntax for describing such types. But it's not even clear to me if such strongly typed APIs are even a good idea. From my experience in C++ and (especially) Typescript with similar APIs, it's a PITA to work with in real world projects, and on both sides of the API.
        steveklabnik 2y ago
        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 that static types are very different based on the language; I’d rather write Ruby than Java, but I’d rather write Rust than Ruby. More advanced type systems tend to actually pull their weight, whereas simpler ones don’t give enough juice for the squeeze, IMHO.
        flohofwoe 2y ago
        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 code base - and they are extremely rigid by design making the code which uses them also very rigid). My goto example where I burned myself in the past is splitting a vec4 into point and vector types. It totally makes sense from a theoretical design pov (e.g. `point + point` would be illegal, while `point + vector` or `vector + vector` are allowed). But in reality such code is awkward to work with for many little reasons, and the enforced correctness pretty much never catches bugs, it just adds pointless busy work when the code needs to change.
    - kranuckle 2y ago
      [dead]
    - commodoreboxer 2y ago
      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.
      - flohofwoe 2y ago
        Yeah, but is that a good thing? Complex template magic is hardly one of the good parts of modern C++.
        lifthrasiir 2y ago
        Rust generics are much underpowered than C++ templates in order to make them an integral part of type system. Many practical C++ programmers avoid excessive template magics for that reason and also for simplicity, and Rust's restriction is essentially its codification.
        still_grokking 2y ago
        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?
    - iknowstuff 2y ago
      enum ReceivedINode<T> { Existing(ARef<INode<T>) New(inode::New<T>) } fn get(..) -> Result<ReceivedINode<T>> Calm down with the bikeshedding. It’s just a complex C API and they wanted to convey the semantics concisely.
    - still_grokking 2y ago
      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).
zozbot234 2y ago
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 https://matklad.github.io/2023/01/26/rusts-ugly-syntax.html
- still_grokking 2y ago
  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.

Another developer here who writes in C and C++, same. I think a lot of people have this complaint. I'm sad about it because what Rust provides in principle sounds great. The language is hideous though, and I really don't want to write anything in it.

dmm 2y ago
What things are hideous about it and what would you rather it look like?
- andrewmcwatters 2y ago
  [flagged]
  - kranuckle 2y ago
    [dead]
- flohofwoe 2y ago
  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=youtu.be https://www.youtube.com/watch?t=1529&v=WiPp9YEBV0Q&feature=y... The return type of that get_or_create_inode() function is: Result<Either<ARef<INode<T>>, inode::New<T>>> 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 Linux kernel I would be pissed too as a Linux kernel greybeard.
  - steveklabnik 2y ago
    I agree that it could maybe use some new types, but it also does kinda get to the heart of this: I’ve never used this kernel API before, but I can say “oh, this function may error out, but if it doesn’t, it gives me either a new inode or a reference (I’m assuming that’s what ARef is) to an existing one. That’s a lot of valuable information, at a glance.
    - flohofwoe 2y ago
      > That’s a lot of valuable information, at a glance ...if you know how to decode it. That example looks like one of those C++ SFINAE hacks, e.g. trying to bend the template/generics syntax beyond what it was designed for. If Rust APIs want to go that way (of overly expressive strong typing) then Rust really should offer a better syntax for describing such types. But it's not even clear to me if such strongly typed APIs are even a good idea. From my experience in C++ and (especially) Typescript with similar APIs, it's a PITA to work with in real world projects, and on both sides of the API.
      - steveklabnik 2y ago
        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 that static types are very different based on the language; I’d rather write Ruby than Java, but I’d rather write Rust than Ruby. More advanced type systems tend to actually pull their weight, whereas simpler ones don’t give enough juice for the squeeze, IMHO.
        flohofwoe 2y ago
        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 code base - and they are extremely rigid by design making the code which uses them also very rigid). My goto example where I burned myself in the past is splitting a vec4 into point and vector types. It totally makes sense from a theoretical design pov (e.g. `point + point` would be illegal, while `point + vector` or `vector + vector` are allowed). But in reality such code is awkward to work with for many little reasons, and the enforced correctness pretty much never catches bugs, it just adds pointless busy work when the code needs to change.
  - kranuckle 2y ago
    [dead]
  - commodoreboxer 2y ago
    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.
    - flohofwoe 2y ago
      Yeah, but is that a good thing? Complex template magic is hardly one of the good parts of modern C++.
      - lifthrasiir 2y ago
        Rust generics are much underpowered than C++ templates in order to make them an integral part of type system. Many practical C++ programmers avoid excessive template magics for that reason and also for simplicity, and Rust's restriction is essentially its codification.
      - still_grokking 2y ago
        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?
  - iknowstuff 2y ago
    enum ReceivedINode<T> { Existing(ARef<INode<T>) New(inode::New<T>) } fn get(..) -> Result<ReceivedINode<T>> Calm down with the bikeshedding. It’s just a complex C API and they wanted to convey the semantics concisely.
  - still_grokking 2y ago
    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).

zozbot234 2y ago

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 https://matklad.github.io/2023/01/26/rusts-ugly-syntax.html

still_grokking 2y ago
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.