5 ms·

I agree; if you use dynamic `Arc`s almost everywhere in your code, what's the point in a systems PL whose essence is in managing static lifetimes? Sometimes peo

I agree; if you use dynamic `Arc`s almost everywhere in your code, what's the point in a systems PL whose essence is in managing static lifetimes? Sometimes people use Rust just because many other languages suck; they are choosing between two evils: tedious programming in Rust or inadequacies of another language. It should not be like this. This is why I think we need a high-level, no-BS version of Rust.

jen20 4y ago
Which parts of Rust would you give up to make this happen? And how would this be implemented?
- 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
AndrewGaspar 4y ago
> This is why I think we need a high-level, no-BS version of Rust. F# is probably what you're looking for if you want functional-lite programming with a strong type system, but don't want to deal with the pains caused by static resource management.
- olalonde 4y ago
  It might sound superficial but the simple fact that there is seemingly a hard dependency[0] on Visual Studio (Code) is a major turnoff for me. I am quite attached to my Vim/command line workflow. [0] https://docs.microsoft.com/en-us/dotnet/fsharp/get-started/install-fsharp https://docs.microsoft.com/en-us/dotnet/fsharp/get-started/i...
  - deleted 4y ago
    [deleted]
  - Paradigma11 4y ago
    There is no hard dependency on VS Code: https://github.com/ionide/Ionide-vim https://github.com/ionide/Ionide-vim https://github.com/fsharp/emacs-fsharp-mode https://github.com/fsharp/emacs-fsharp-mode https://www.jetbrains.com/help/rider/F_Sharp.html https://www.jetbrains.com/help/rider/F_Sharp.html ...
  - nickduggets 4y ago
    That link includes documentation for building and running F# projects using only the .net core framework. Seems like the main set of headings is misleading, making it sound like you must install VS or (shudder) VSCode to get F# installed.
- chalst 4y ago
  F# has some nice things in it: I especially like how it handles multiple return values. But compared to the language it is most clearly decended from, OCaml, it ties you to .NET Core and it lacks an ML-like module system and macros. If you want to use .NET, F# is a fine choice. But otherwise, and especially in the context of an alternative to Rust, I recommend OCaml.
DeathArrow 4y ago
>This is why I think we need a high-level, no-BS version of Rust. F# to the rescue. :)
deleted 4y ago
[deleted]
therockhead 4y ago
>if you use dynamic `Arc`s almost everywhere in your code, Right but you dont have todo this everywhere, just some sporadic use where it makes life a lot easier. It doesn't have to be all or nothing.
danielheath 4y ago
Being able to build on libraries that are efficient means that your inefficient rust can still be lightweight.
adwn 4y ago
> I agree; if you use dynamic `Arc`s almost everywhere in your code, what's the point in a systems PL whose essence is in managing static lifetimes? You can have the best of both worlds: In many cases, I simply put an object into an Arc, clone that a bunch of times, and pass/store it to wherever it's needed. Then, within loops, I pass a reference to local function calls (instead of cloning the Arc for every call). For any given v: Arc<T>, doing &*v is zero-cost – unlike in many other languages, where you'd have to pass the Arc itself, which would involve atomic increments/decrements without escape analysis.
spopejoy 4y ago
Vote here for Haskell, which receives great hate on HN because it allows essentially unlimited abstraction. Meanwhile it has one of the fastest concurrent+GC runtimes, obliterating Ocaml in this regard, and competing handily with JVM or CLR langs. Finally, it has standard abstractions for concurrency and parallelism that are basically flawless. Clearly, the hate comes from the association of Haskell with category theory, which is frankly useless/borderline harmful to the working Haskell programmer. CT was critical to core library devs being able to deliver the main workaday abstractions that make Haskell such an unreasonably productive app languages. But since 2012 you can simply use these main abstractions and enjoy a level of safety and maintainability that rust, c++, ocaml, kotlin, java can't touch. It's not perfect, but there's been huge improvements of late to tooling (cabal) so there's never been a better time. I really wish the tide could turn, because if you're willing to take on rust for low-level, you're missing out if you don't try haskell for everything else server-side.

jen20 4y ago

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

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

AndrewGaspar 4y ago

> This is why I think we need a high-level, no-BS version of Rust. F# is probably what you're looking for if you want functional-lite programming with a strong type system, but don't want to deal with the pains caused by static resource management.

olalonde 4y ago
It might sound superficial but the simple fact that there is seemingly a hard dependency[0] on Visual Studio (Code) is a major turnoff for me. I am quite attached to my Vim/command line workflow. [0] https://docs.microsoft.com/en-us/dotnet/fsharp/get-started/install-fsharp https://docs.microsoft.com/en-us/dotnet/fsharp/get-started/i...
- deleted 4y ago
  [deleted]
- Paradigma11 4y ago
  There is no hard dependency on VS Code: https://github.com/ionide/Ionide-vim https://github.com/ionide/Ionide-vim https://github.com/fsharp/emacs-fsharp-mode https://github.com/fsharp/emacs-fsharp-mode https://www.jetbrains.com/help/rider/F_Sharp.html https://www.jetbrains.com/help/rider/F_Sharp.html ...
- nickduggets 4y ago
  That link includes documentation for building and running F# projects using only the .net core framework. Seems like the main set of headings is misleading, making it sound like you must install VS or (shudder) VSCode to get F# installed.
chalst 4y ago
F# has some nice things in it: I especially like how it handles multiple return values. But compared to the language it is most clearly decended from, OCaml, it ties you to .NET Core and it lacks an ML-like module system and macros. If you want to use .NET, F# is a fine choice. But otherwise, and especially in the context of an alternative to Rust, I recommend OCaml.

DeathArrow 4y ago

>This is why I think we need a high-level, no-BS version of Rust. F# to the rescue. :)

deleted 4y ago

[deleted]

therockhead 4y ago

>if you use dynamic `Arc`s almost everywhere in your code, Right but you dont have todo this everywhere, just some sporadic use where it makes life a lot easier. It doesn't have to be all or nothing.

danielheath 4y ago

Being able to build on libraries that are efficient means that your inefficient rust can still be lightweight.

adwn 4y ago

> I agree; if you use dynamic `Arc`s almost everywhere in your code, what's the point in a systems PL whose essence is in managing static lifetimes? You can have the best of both worlds: In many cases, I simply put an object into an Arc, clone that a bunch of times, and pass/store it to wherever it's needed. Then, within loops, I pass a reference to local function calls (instead of cloning the Arc for every call). For any given v: Arc<T>, doing &*v is zero-cost – unlike in many other languages, where you'd have to pass the Arc itself, which would involve atomic increments/decrements without escape analysis.

spopejoy 4y ago

Vote here for Haskell, which receives great hate on HN because it allows essentially unlimited abstraction. Meanwhile it has one of the fastest concurrent+GC runtimes, obliterating Ocaml in this regard, and competing handily with JVM or CLR langs. Finally, it has standard abstractions for concurrency and parallelism that are basically flawless. Clearly, the hate comes from the association of Haskell with category theory, which is frankly useless/borderline harmful to the working Haskell programmer. CT was critical to core library devs being able to deliver the main workaday abstractions that make Haskell such an unreasonably productive app languages. But since 2012 you can simply use these main abstractions and enjoy a level of safety and maintainability that rust, c++, ocaml, kotlin, java can't touch. It's not perfect, but there's been huge improvements of late to tooling (cabal) so there's never been a better time. I really wish the tide could turn, because if you're willing to take on rust for low-level, you're missing out if you don't try haskell for everything else server-side.