5 ms·

Which parts of Rust would you give up to make this happen? And how would this be implemented?

by jen20 4y ago

Hirrolot 4y ago
Hide memory management under a language runtime. Make a single Fn trait/string type instead of multiple ones. Add effect polymorphism to deal with function colours. Remove async/.await and express it using algebraic effects, do the same for streams and iterators. How it'd be designed and implemented is probably a theme for a separate blog post, not a HN comment.
- pjmlp 4y ago
  So basically OCaml.
  - jules 4y ago
    OCaml is great, but it lacks traits / type classes. That plus some syntactic tweaks would make OCaml amazing for most general purpose programming.
    - pjmlp 4y ago
      That is what functors and modules are for. And then the O in OCaml is all about OOP.
      - jules 4y ago
        Functors and modules are nice but do not have the convenience of traits and type classes. The problem with functors and modules is that you have to manually instantiate the right functors and modules when you want to use some operation. Type classes and traits build the right instantiations for you based on the types. I want to write `toString (1,true)` not `ToStringPair(ToStringInt)(ToStringBool).toString (1,true)`.
lelanthran 4y ago
> Which parts of Rust would you give up to make this happen? And how would this be implemented? Traits, maybe? Switch to an OO model more closely aligned to what the majority of developers understand. Dump all of the line-noise-type syntax. My Own Toy Language (ComingRealSoonNow)^tm that I started designing had exactly one goal - prevent the majority of memory errors, not prevent ALL memory errors. All I wanted was to indicate when/where an object will be destroyed/mutated. That's enough for me.
- pjmlp 4y ago
  Actually something like traits (as concept) is what powers COM, WinRT, the basis of Objective-C protocols that influenced interfaces in more common OOP languages. Also the basis for one programming language that used to be widespread in the enterprise for quick and dirty solutions, VB and its ecosystem of OCX libraries. It is more widespread that people think, because when many argue about OOP, they miss the full spectrum of how OOP is approached.
  - NoGravitas 4y ago
    Traits seem, to me, a lot like generic functions and methods in CLOS (Common Lisp). It's just that CLOS doesn't bundle a group of generic functions into a trait, they're a la carte.
    - pjmlp 4y ago
      Yes they do, they are called protocols.
  - lelanthran 4y ago
    > Actually something like traits (as concept) is what powers COM, WinRT, the basis of Objective-C protocols that influenced interfaces in more common OOP languages. So? Giving up Rust-Traits doesn't mean that I will give up on interfaces as a whole. I don't like the way C++ does interfaces, for example, but that doesn't mean that my ideal language won't have interfaces.
- 4y ago

Which parts of Rust would you give up to make this happen? And how would this be implemented?

by jen20 4y ago

Which parts of Rust would you give up to make this happen? And how would this be implemented?

Hide memory management under a language runtime. Make a single Fn trait/string type instead of multiple ones. Add effect polymorphism to deal with function colours. Remove async/.await and express it using algebraic effects, do the same for streams and iterators. How it'd be designed and implemented is probably a theme for a separate blog post, not a HN comment.

pjmlp 4y ago
So basically OCaml.
- jules 4y ago
  OCaml is great, but it lacks traits / type classes. That plus some syntactic tweaks would make OCaml amazing for most general purpose programming.
  - pjmlp 4y ago
    That is what functors and modules are for. And then the O in OCaml is all about OOP.
    - jules 4y ago
      Functors and modules are nice but do not have the convenience of traits and type classes. The problem with functors and modules is that you have to manually instantiate the right functors and modules when you want to use some operation. Type classes and traits build the right instantiations for you based on the types. I want to write `toString (1,true)` not `ToStringPair(ToStringInt)(ToStringBool).toString (1,true)`.

lelanthran 4y ago

> Which parts of Rust would you give up to make this happen? And how would this be implemented? Traits, maybe? Switch to an OO model more closely aligned to what the majority of developers understand. Dump all of the line-noise-type syntax. My Own Toy Language (ComingRealSoonNow)^tm that I started designing had exactly one goal - prevent the majority of memory errors, not prevent ALL memory errors. All I wanted was to indicate when/where an object will be destroyed/mutated. That's enough for me.

pjmlp 4y ago
Actually something like traits (as concept) is what powers COM, WinRT, the basis of Objective-C protocols that influenced interfaces in more common OOP languages. Also the basis for one programming language that used to be widespread in the enterprise for quick and dirty solutions, VB and its ecosystem of OCX libraries. It is more widespread that people think, because when many argue about OOP, they miss the full spectrum of how OOP is approached.
- NoGravitas 4y ago
  Traits seem, to me, a lot like generic functions and methods in CLOS (Common Lisp). It's just that CLOS doesn't bundle a group of generic functions into a trait, they're a la carte.
  - pjmlp 4y ago
    Yes they do, they are called protocols.
- lelanthran 4y ago
  > Actually something like traits (as concept) is what powers COM, WinRT, the basis of Objective-C protocols that influenced interfaces in more common OOP languages. So? Giving up Rust-Traits doesn't mean that I will give up on interfaces as a whole. I don't like the way C++ does interfaces, for example, but that doesn't mean that my ideal language won't have interfaces.
4y ago