5 ms·

Rust better figure out quick how they can shut down the Haskell & C++ language artisans or it will be their downfall (in favor of something like Zig).

josephcsible 4y ago
Rust getting more of Haskell's type system features is a good thing. The stronger your type system is, the more mistakes you can discover as compiler errors instead of runtime bugs.
- bsaul 4y ago
  If a typesystem has any impact on the popularity of a language, then i assume rust doesn’t want to copy too much of haskell and needs to know where to stop..
  - pjmlp 4y ago
    Typescript. As for Haskell, their motto is "avoid success at any cost" for a reason.
  - gpderetta 4y ago
    C++ sorta has the equivalent of this feature in the form of nested templates. C++ is kind of popular and rust wants to be a direct replacement. Next step: template template parameters!
  - kibwen 4y ago
    The whole design of GATs is predicated on the notion that Rust doesn't want to go as far as Haskell does here. See boats' comment: https://news.ycombinator.com/item?id=33506540 https://news.ycombinator.com/item?id=33506540
- titzer 4y ago
  > The stronger your type system is... I used to think a stronger and stronger type system was a universal good, then I got experience with code written by architecture astronauts[1] armed with such type systems. Knowing exactly which kinds of things to make impossible at compile time and which not is absolutely an art form. Unfortunately, such type systems seem to result in so many nightmares. https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/ https://www.joelonsoftware.com/2001/04/21/dont-let-architect...
  - ghostwriter 4y ago
    at the end of the day architecture astronauts delegate pipe laying to plumbers, and the plumbers benefit from existing build plans created by architects with all their sophisticated tooling.
  - exceptione 4y ago
    The linked article talks about abstraction, and that you could abstract so much that the concrete problem doesn't fit in your abstraction. I.e., your abstraction is broken. I think that is precisely why OOP started to disappoint (tbh: I also think many people did not understand OOP really well). Haskell pushes you to compose types instead of building inheritance hierarchies. Multiple inheritance turned out to be a bad idea too, so yeah, OOP program do typically not have the best models of the problem domain they were intended to model. At the other end of the spectrum you see people just give up: everything is a kind of dict or a string, or wo knows, null? Looking at you php, python, javascript.. All the improvements you see in todays OOP languages are ideas stolen from functional languages like Haskell. What Haskell could have done better is be strict instead of lazy by default. To model the real world and make assumptions explicit, a type system, as Haskell gives you, is so nice. I agree that you can make types also really abstract like some people indeed do. It's fine if you do that as a library author, but you should offer a facade with some simpler type aliases. If you stick to Haskell98 and possibly enable GADT support you already get an immensely powerful language. Also, I have not used Haskell for a while, but I heard the compiler error messages have become way more human friendly these days, so that helps with complex types.
    - titzer 4y ago
      As with anything, it all goes well until it doesn't. When you have a single bug (e.g. type error or dynamic error), the guts of whatever is in the box spill out. Case in point: all the implicit template parameters to std:: in C++ these days. The only way to add configuration options in a backwards-compatible way was to add default values for template arguments. That's all fine and good when you can't see them, but as soon as you have a nasty type error, the types that come spilling out in error messages have zillions of default arguments that get printed. It's almost always the same with inference. I would be very, very wary of doing so much type sophistry that it requires heavy inference to be usable.
- throwawaymaths 4y ago
  There will always be more things that someone will want to formally verify that don't exist in the type system. How do you decide what is and isn't worth putting into the type system?
deleted 4y ago
[deleted]
valenterry 4y ago
Well, it's not academic, it solves real problems. More so for library developers than for application developers, but a thriving and great ecosystem of libraries is also good for application developers.
exceptione 4y ago
Well, in this realm Haskell - allows you to write these things with less effort - is more expressive I keep an eye on Nim as well. Their syntax for algebraic data types could use some syntactic sugar, but it looks like a powerful and fast language, and the syntax allows you to do away with all the c-style braces, curly braces and semicolons that pesters so many languages and gives me RSI. More upsides I found: macros on the AST-level and fast compilation; it is a language that deserves more attention.
pjmlp 4y ago
Actually I find C++ concepts much easier to grasp than GATs. Zig still has to win the love of the giants that ship C++, and increasingly Rust, in their products.
- gpderetta 4y ago
  Aren't GATs equivalent to nested template classes? I.e. they are really orthogonal to concepts.
  - pjmlp 4y ago
    Might be a bit of job deformation, knowing C++ since 1993, and I still need to get myself used to those patterns. Maybe I should delve again into GADTs in OCaml, before having a second look.
    - Rusky 4y ago
      GATs are completely unrelated to GADTs.
      - pjmlp 4y ago
        From my point of view they look quite similar from language type theory point of view, plus the machinery for affine types.
        Rusky 4y ago
        The only thing similar about them is the acronym: GATs are generic type aliases which are defined inside traits. GADTs are generic sum types with extra constraints on which variants may be used with which type arguments. There is no reasonable way in which they are "quite similar," nor do either of them have anything at all to do with affine types.
        pjmlp 4y ago
        Where is the type theory for Rust's GATs for us to educate ourselves?
kibwen 4y ago
GATs are an essential part of Rust's long-term async/await story. It's not language-wankery, this is driven by actual real-world use cases. Rust's own stdlib would have benefited from this in many places had this feature existed years ago.
- nrc 4y ago
  No, they're not. GATs are used internally in the compiler to implement async methods, but there is absolutely no need for them to be in the language for that (just like generators are used to implement await but are not part of the (stable) language). GATs may or may not be useful, but IMO the actual real-world use cases are pretty weak.
  - kibwen 4y ago
    Yes, I've read the stabilization thread and I'm aware of your stance. :P Whether or not it's exposed, the mechanism still needs to exist in the compiler, and enough library authors are clamoring to use it that I think the argument in favor of exposing them is stronger than you're giving it credit for. You mention generators, but a lot of people are clamoring for those as well, and I fully expect them to be exposed to end-users someday.
    - nrc 4y ago
      My point is that there or may or may not be reasonable justification for adding GATs, reasonable people can disagree on that. But async methods are not part of that justification. Similarly, generators may or may not be good for the language (IMO they would be good to add, if they can be made to work etc.) but they didn't need to be part of the language to add await.
  - josephcsible 4y ago
    Even if the use cases outside the standard library were weak, given that the work needs to be done anyway for the standard library, why wouldn't you expose them?

josephcsible 4y ago

Rust getting more of Haskell's type system features is a good thing. The stronger your type system is, the more mistakes you can discover as compiler errors instead of runtime bugs.

bsaul 4y ago
If a typesystem has any impact on the popularity of a language, then i assume rust doesn’t want to copy too much of haskell and needs to know where to stop..
- pjmlp 4y ago
  Typescript. As for Haskell, their motto is "avoid success at any cost" for a reason.
- gpderetta 4y ago
  C++ sorta has the equivalent of this feature in the form of nested templates. C++ is kind of popular and rust wants to be a direct replacement. Next step: template template parameters!
- kibwen 4y ago
  The whole design of GATs is predicated on the notion that Rust doesn't want to go as far as Haskell does here. See boats' comment: https://news.ycombinator.com/item?id=33506540 https://news.ycombinator.com/item?id=33506540
titzer 4y ago
> The stronger your type system is... I used to think a stronger and stronger type system was a universal good, then I got experience with code written by architecture astronauts[1] armed with such type systems. Knowing exactly which kinds of things to make impossible at compile time and which not is absolutely an art form. Unfortunately, such type systems seem to result in so many nightmares. https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/ https://www.joelonsoftware.com/2001/04/21/dont-let-architect...
- ghostwriter 4y ago
  at the end of the day architecture astronauts delegate pipe laying to plumbers, and the plumbers benefit from existing build plans created by architects with all their sophisticated tooling.
- exceptione 4y ago
  The linked article talks about abstraction, and that you could abstract so much that the concrete problem doesn't fit in your abstraction. I.e., your abstraction is broken. I think that is precisely why OOP started to disappoint (tbh: I also think many people did not understand OOP really well). Haskell pushes you to compose types instead of building inheritance hierarchies. Multiple inheritance turned out to be a bad idea too, so yeah, OOP program do typically not have the best models of the problem domain they were intended to model. At the other end of the spectrum you see people just give up: everything is a kind of dict or a string, or wo knows, null? Looking at you php, python, javascript.. All the improvements you see in todays OOP languages are ideas stolen from functional languages like Haskell. What Haskell could have done better is be strict instead of lazy by default. To model the real world and make assumptions explicit, a type system, as Haskell gives you, is so nice. I agree that you can make types also really abstract like some people indeed do. It's fine if you do that as a library author, but you should offer a facade with some simpler type aliases. If you stick to Haskell98 and possibly enable GADT support you already get an immensely powerful language. Also, I have not used Haskell for a while, but I heard the compiler error messages have become way more human friendly these days, so that helps with complex types.
  - titzer 4y ago
    As with anything, it all goes well until it doesn't. When you have a single bug (e.g. type error or dynamic error), the guts of whatever is in the box spill out. Case in point: all the implicit template parameters to std:: in C++ these days. The only way to add configuration options in a backwards-compatible way was to add default values for template arguments. That's all fine and good when you can't see them, but as soon as you have a nasty type error, the types that come spilling out in error messages have zillions of default arguments that get printed. It's almost always the same with inference. I would be very, very wary of doing so much type sophistry that it requires heavy inference to be usable.
throwawaymaths 4y ago
There will always be more things that someone will want to formally verify that don't exist in the type system. How do you decide what is and isn't worth putting into the type system?

deleted 4y ago

[deleted]

valenterry 4y ago

Well, it's not academic, it solves real problems. More so for library developers than for application developers, but a thriving and great ecosystem of libraries is also good for application developers.

exceptione 4y ago

Well, in this realm Haskell - allows you to write these things with less effort - is more expressive I keep an eye on Nim as well. Their syntax for algebraic data types could use some syntactic sugar, but it looks like a powerful and fast language, and the syntax allows you to do away with all the c-style braces, curly braces and semicolons that pesters so many languages and gives me RSI. More upsides I found: macros on the AST-level and fast compilation; it is a language that deserves more attention.

pjmlp 4y ago

Actually I find C++ concepts much easier to grasp than GATs. Zig still has to win the love of the giants that ship C++, and increasingly Rust, in their products.

gpderetta 4y ago
Aren't GATs equivalent to nested template classes? I.e. they are really orthogonal to concepts.
- pjmlp 4y ago
  Might be a bit of job deformation, knowing C++ since 1993, and I still need to get myself used to those patterns. Maybe I should delve again into GADTs in OCaml, before having a second look.
  - Rusky 4y ago
    GATs are completely unrelated to GADTs.
    - pjmlp 4y ago
      From my point of view they look quite similar from language type theory point of view, plus the machinery for affine types.
      - Rusky 4y ago
        The only thing similar about them is the acronym: GATs are generic type aliases which are defined inside traits. GADTs are generic sum types with extra constraints on which variants may be used with which type arguments. There is no reasonable way in which they are "quite similar," nor do either of them have anything at all to do with affine types.
        pjmlp 4y ago
        Where is the type theory for Rust's GATs for us to educate ourselves?

kibwen 4y ago

GATs are an essential part of Rust's long-term async/await story. It's not language-wankery, this is driven by actual real-world use cases. Rust's own stdlib would have benefited from this in many places had this feature existed years ago.

nrc 4y ago
No, they're not. GATs are used internally in the compiler to implement async methods, but there is absolutely no need for them to be in the language for that (just like generators are used to implement await but are not part of the (stable) language). GATs may or may not be useful, but IMO the actual real-world use cases are pretty weak.
- kibwen 4y ago
  Yes, I've read the stabilization thread and I'm aware of your stance. :P Whether or not it's exposed, the mechanism still needs to exist in the compiler, and enough library authors are clamoring to use it that I think the argument in favor of exposing them is stronger than you're giving it credit for. You mention generators, but a lot of people are clamoring for those as well, and I fully expect them to be exposed to end-users someday.
  - nrc 4y ago
    My point is that there or may or may not be reasonable justification for adding GATs, reasonable people can disagree on that. But async methods are not part of that justification. Similarly, generators may or may not be good for the language (IMO they would be good to add, if they can be made to work etc.) but they didn't need to be part of the language to add await.
- josephcsible 4y ago
  Even if the use cases outside the standard library were weak, given that the work needs to be done anyway for the standard library, why wouldn't you expose them?