7 ms·

This is going to sound weird, but I would like to see a garbage-collected Rust. Take away the borrow checker, and you still have a modern language with UTF-8 su

• trumpsamerica 9y ago
  Garbage collected allocation is coming. There's even an rfc I think. Manishearth is working gon it
• grayrest 9y ago
  > Ocaml almost fits the bill, but the tooling around it is lacking to put it mildly. I know the Reason guys want to tackle project setup / build / deps in addition to their syntax changes. I've found the current release's bsb toolchain to work pretty well for js targets but I haven't tried to set it up for native compilation.
  • yen223 9y ago
    I've built several toy projects with ReasonML. I found the overall experience fairly positive, so please take this comment kindly. I'm concerned about the ReasonML -> OCaml -> Bucklescript -> JS compilation chain. The laws of leaky abstraction pretty much guarantees this is not a robust way to do things. I also wished the ReasonML folks started from scratch, instead of inheriting OCaml's baggage (no forward references, a plethora of file types to deal with, no UTF8 strings without bringing in an external lib, and so on).
    • xfer 9y ago
      No builtin utf-8 strings is a good/bad thing is debatable. You don't need to use bucklescript toolchain to write Ocaml, it has a very good package manager, the build-system tooling is getting better, already has great editor support for many years now(merlin). I think the tooling scene is much better than Haskell. Not sure what you mean by "no forward references"?
      • bjz_ 9y ago
        > Not sure what you mean by "no forward references"? I'm guessing they are talking about having implicit mutual recursion between items in a module, like Haskell has.
      • yen223 9y ago
        > Not sure what you mean by "no forward references"? I probably got the name wrong, but it's the ability to use a function before it is defined. In OCaml/ReasonML, you'd have to use the rec keyword and structure your codebase in a particular way to define mutually-recursive functions. It is a small but noticeable papercut, especially since recursion is so common in a functional language.
        • botverse 9y ago
          May be the word I’d “hoisting”
    • fhars 9y ago
      There ist no ReasonML -> Ocaml compilation step in that chain, ReasonML is just another syntax for ocaml.
      • yen223 9y ago
        There is still a necessary syntactical transformation sstep via `refmt`, and that transformation step does occasionally break.
    • phillipcarter 9y ago
      There's a similar chain for F# running with Fable: F# code (with a catch) --> F# AST --> Bable AST --> JS The big thing here is that the F# code you write has slightly different semantics than "normal" F#. That's because the runtime environment is different, and so you can't escape that. Rather than attemp to gloss this over, the Fable creators are pretty explicit about this, including documenting each of the (small) differences. The result is pretty good. Abstractions don't seem too leaky from my vantage point.
• readittwice 9y ago
  Yep, that's exactly what I would also like to see. AFAIK there is some work on a GC in Rust, but it doesn't take away the borrow checker like you wished ;) So you will still need to use `.borrow()` and `.borrow_mut()`. A language similar to Rust but with GC (and no borrow checker) could be quite useful for a lot of applications out there. Basically Go but a more "modern" language.
  • weberc2 9y ago
    Just seeing this. You might be interested in my previous comment here: https://news.ycombinator.com/item?id=16145940 https://news.ycombinator.com/item?id=16145940
• Manishearth 9y ago
  This sounds like Swift :) (ARC, not tracing GC, but still.)
  • littlestymaar 9y ago
    If Arc counts, then it juste sounds like Rust actually ;).
    • K0nserv 9y ago
      I dunno if I agree, the borrow checker in Rust requires a lot more active thinking and intervention to get memory right. Objective-C and Swift ARC is really straightforward and there are few gotchas. Kinda like GC.
      • littlestymaar 9y ago
        If you use Arc everywhere you just end up with the same behavior than Swift (except for closures I guess).
    • steveklabnik 9y ago
      Small note: Swift's ARC and Rust's Arc are different: Rust's Arc is atomic reference counting, while Swift's is automatic reference counting.
      • dbaupp 9y ago
        The acronyms are different, but at runtime they're pretty much the same: the only difference is the Swift compiler inserts the clones that a Rust programmer has to do manually (that is, Swift retain/releases are atomic too).
        • steveklabnik 9y ago
          Yes, I should have elaborated more, thanks :)
    • 9y ago
• currymj 9y ago
  rust at one point had garbage-collected references. And there's still Rc/Arc types for reference counting. I get what you're saying though. Another poster mentioned Swift and indeed Graydon Hoare, Rust's creator, is now working on Swift at Apple. And I believe some kind of notion of borrow checking/lifetimes is supposed to be coming to Swift in the future?
  • pjmlp 9y ago
    Yes, the initial support is already there in Swift 4, it is called enforced exclusive access to memory in Apple documentation.
  • joshlemer 9y ago
    Not all that familiar with Rust's history or anything but why would he leave to work on Swift at Apple? He creates a language which is getting a huge amount momentum and praise around it, and decides to do something else? Must have been a lot more money, because a situation like that don't come up very often.
    • steveklabnik 9y ago
      He didn't leave to work on Swift; he left, then got a different job, then left that job eventually to work on Swift. I'm being vague because well, it's his personal life, and he'd generally prefer people not talk about it too much or read too much into it.
• dom96 9y ago
  This sounds a lot like Nim to me. Give it a go if you haven't already. It's a systems programming language that primarily uses a garbage collector.
• devit 9y ago
  The problem is that it turns out that cyclic garbage collection is essentially useless, except for running existing code that expects a garbage collector to be present (e.g. JavaScript code if you are writing a web browser). Since it's useless, not having it is great since you no longer have to worry about it and the problems it causes like random pauses, sawtooth-shaped and excessive memory usage and inability to use swap properly (although you have to worry about heap fragmentation, but usually that's not as terrible). Also you'd need lifetimes and borrowed references anyway to have static guarantees like that there are no remaining references to mutex-protected data after you unlock the mutex, so having a GC as well actually increases complexity.
  • twic 9y ago
    If i've understood you properly, i would phrase this slightly differently: because Rust doesn't have GC, it has evolved a lot of language and library features that make it practical to not have GC, and so adding GC doesn't make Rust easier to use. I think there's a lot to that. I'd be really interested to try it, though, to see how it pans out.
• mmirate 9y ago
  That's easy, just change your program so that every value of type T is now a value of type Arc<Mutex<T>>.
  • foota 9y ago
    Reference counting does not handle cycles.
    • mmirate 9y ago
      Use Arc::downgrade() to get a Weak<Mutex<T>> as needed. Weak<U> is like Arc<U> but does not affect the value's reference count.
    • katastic 9y ago
      But it works for every other case.
• kazagistar 9y ago
  I would like to see a different GC rust... an ability to integrate into an external GC system that it is embedded in, like Javascript or Java or whatever else. In other words, `Gc<_>` would mean "owned by the other runtime". I think there was a proposal like this, though I am not sure what happened to it.
• robohamburger 9y ago
  I agree. Part of whats kept me going is the language is very nice, even though I don't always need borrow checking. I wonder how threading would work without the borrow checker though. It would be cool if you could still have the "fearless concurrency part".
• Nelkins 9y ago
  F# sounds like it fits the bill. ADT, pattern matching, performant, great tooling (multiple amazing IDEs, a REPL, etc.), and a huge ecosystem of software packages to use with it (all of .NET). It's my favorite general purpose programming language (can be used for frontend programming, server, mobile apps, etc.).
  • trumpsamerica 9y ago
    Do you have a good learning guide and a development guide (setting up ide, vim, tools etc)? I want to jump start into f#
    • Nelkins 9y ago
      For learning the language, there is no better guide than F# for fun and profit. Start here[1], then maybe check out this series[2] and this one[3]. If you want to learn about monads and such, go through this series[4]. Look through this[5] page for other good stuff. Unfortunately, the fsharp.org site is kind of out of date. I think that's mostly a function (heh) of the MS F# docs becoming much better (can be found here[6]). These instructions for getting a dev environment set up are pretty good[7]. If you hunt around, you can also find blog posts which may be a little more comprehensive[8][9][10]. [1] https://fsharpforfunandprofit.com/why-use-fsharp/ https://fsharpforfunandprofit.com/why-use-fsharp/ [2] https://fsharpforfunandprofit.com/series/designing-with-types.html https://fsharpforfunandprofit.com/series/designing-with-type... [3] https://fsharpforfunandprofit.com/series/thinking-functionally.html https://fsharpforfunandprofit.com/series/thinking-functional... [4] https://fsharpforfunandprofit.com/series/map-and-bind-and-apply-oh-my.html https://fsharpforfunandprofit.com/series/map-and-bind-and-ap... [5] https://fsharpforfunandprofit.com/site-contents/ https://fsharpforfunandprofit.com/site-contents/ [6] https://docs.microsoft.com/en-us/dotnet/fsharp/ https://docs.microsoft.com/en-us/dotnet/fsharp/ [7] https://docs.microsoft.com/en-us/dotnet/fsharp/get-started/ https://docs.microsoft.com/en-us/dotnet/fsharp/get-started/ [8] https://atlemann.github.io/fsharp/2018/01/13/fsharp-on-ubuntu-16-04.html https://atlemann.github.io/fsharp/2018/01/13/fsharp-on-ubunt... [9] http://www.prigrammer.com/?p=363 http://www.prigrammer.com/?p=363 [10] https://medium.com/@edgarsanchezg/four-easy-steps-for-installing-f-in-ubuntu-linux-88122323f12b https://medium.com/@edgarsanchezg/four-easy-steps-for-instal...
• gbersac 9y ago
  I am surprised no one already mentionned Scala. It perfectly fit the bill ans is even more mature !
  • vvillena 9y ago
    The main problem of Scala is that it brings in the whole JVM. That's awesome for certain kinds of apps, but not so great for other things like small tools. I have high hopes on scala-native, though!
    • nine_k 9y ago
      Java 9 / Jigsaw should make small self-contained executables possible. Startup time could be an issue, though.
  • paulddraper 9y ago
    The biggest difference is that Scala requires JVM (or JS). But if you are willing to accept runtime GC, a JIT runtime like JVM/Node might also not be out of the question. So Scala Native would be spot on, if it were ready for production use.
• alkonaut 9y ago
  There are plenty of language choices fitting nearly every feature set. What I’d like to see is for one language to be possible to use “vertically” through a stack. That is - for example a C# systems version with manual memory that you can use instead of C interop for the small core of your app. Or, the opposite, a dumbed down version of Rust that works well for classic reference heavy UIs and similar.
• weberc2 9y ago
  I have a similar desire. OCaml and others push heap-allocated reference types by default (limiting your options for controlling allocations), and many have weak tooling and library support. F# looks neat, but it seems to have a lot of baggage relating to C# interop. F# also doesn't compile static binaries yet. I think I decided the best shot is to build a language that compiles to Go, since it has the right semantics, great libraries and tooling, and a world-class runtime (GC, painless async IO, lightweight thread scheduler for real parallelism). Obviously this is still a huge effort and probably a pipe dream, but its the path of least resistance to get a "Rust with GC".
• bvinc 9y ago
  You should know that rust always intended to have owned/shared references, Rc<T> reference counting, and Gc<T> garbage collected pointers. It turns out that LLVM made precise garbage collection a hard thing to add on to the language inside of it's standard library. I believe recent changes to LLVM make this easier and it's still a planned feature in the future. It still doesn't really meet your idea you probably have in your head. When people can choose between different types of pointers, people will choose rust's normal lightweight lifetime references 99% of the time. Gc<T> will probably only be used in those rare cases where an object has no clear owner. They figured this out in the early days of rust.
• deleted 9y ago
  [deleted]
• agbell 9y ago
  Scala Native may sort of fit the bill