12 ms·

I wonder how many Rust users really want linear types and borrow checking, instead of the other stuff Rust brings to the table: modern language design, large an

• deleted 7y ago
  [deleted]
• weberc2 7y ago
  I'm definitely in this category. I think I want "Go with generics and enums and Cargo" (and no, OCaml folks, I am not describing OCaml). I want to write more Rust, but I rarely can afford to trade off on Go's productivity for Rust's performance and safety.
  • lmm 7y ago
    What is it you don't like about OCaml, or similar ML-family languages (e.g. F#)? Most of "modern language design" seems to amount to the ML featureset.
    • wyatwerp 7y ago
      Indeed! For example, it is amazing how small Poly/ML is for a type-inferred multi-threaded language.
    • yawn 7y ago
      Not the grandparent, but... OCaml: multicore, standard library situation (which one?) is a mess, adoption. F#: Have to deal with null and lack of ADTs when you interact with .NET (or JS for Fable) standard lib. The tooling situation in F# has been a mess since .NET Core, especially in Linux. Treated as a 2nd class citizen by MS.
      • msvan 7y ago
        Multicore OCaml is actually making promising progress, but I agree that the standard library situation is a little bit unfortunate.
        • ynnn 7y ago
          Sadly, that's what I've been hearing for at least 5 years.
      • akra 7y ago
        I'm using F# tooling in Linux and both VS Code and Jetbrains Rider's IDE's outclass most functional language IDE's at present IMO. It's greatly improved within the last year or so. If you use code most of your app in F# the null factor doesn't really bite you all too often and its not too hard to handle when it does.
    • Hermitian909 7y ago
      As someone who really enjoys OCAML, it has a variety of issues that prevent it from becoming popular (though I'm hopeful for reasonML). No multicore Standard library has... issues No community consensus on a common base setup, questions about which library to use for a task often get answers like "well, do you want to use functors or monads? because that will change the library we recommend" which is really not what you want to hear when you're just trying to set up your first server. Documentation is, in general, bad. Most packages just give a list of function signatures. The community is small, academic, and often French.
      • xvilka 7y ago
        Modern OCaml (4.06+) is not that bad, but yeah, lack of proper parallelism and bad Windows support (without hacks like MinGW or Cygwin) is what still hurts. Standard library these days is only one - Base, one buildsystem - Dune, Camlp4 is dead, and compiler improved a lot recently (including speed if you enable flambda).
        • p0nce 7y ago
          You guys are welcome to D, you may enjoy unboxed floats, guaranteed monomorphization and native threads. Also, 3 backends.
          • wyatwerp 7y ago
            The reference compiler is as free-standing as OCaml's because it too has its own back-end. Its front-end is shared with the other 2 back-ends: feeds the ubiquitous LLVM in LDC, and is included as a supported front-end in GCC since version 9.1. Anyway, there is no way you'd give up ML-tradition pattern-matching; D doesn't have it.
            • p0nce 7y ago
              Well engineering decision are tradeoffs, using D i've never missed pattern-matching and I have used ocaml before.
    • wtetzner 7y ago
      I love OCaml, but my biggest pain point is not having something like Cargo. I haven't spent a lot of time with opam since 2.0 came out, so maybe it's better now, but when I used it it felt very much designed around installing packages globally, instead of defining dependencies per-project. The other issue with the package ecosystem is cross-platform support. While OCaml itself works on windows, opam doesn't (or at least didn't) without a lot of extra work, and it seemed like most packages were designed only for unixish OS's. There are projects where I've used Rust instead of OCaml, even though I'd have preferred to use OCaml, simply because the infrastructure is so much better and easier to use for Rust.
      • msvan 7y ago
        Esy (https://esy.sh/ https://esy.sh/) has completely solved the first problem, fwiw.
        • wtetzner 7y ago
          Thank you! I'll try it out.
        • weberc2 7y ago
          This is a huge step in making OCaml more approachable. I get the feeling that there are quite a few of these modernizations around, but you have to know about them up front in order to hit the happy path. Would be great if there was some sort of "OCaml Happy Path" repo that laid out all of the right tools to use to be successful right off the bat. Sort of on the subject, Reason would be great but last I checked it utterly neglected its native compilation story--it advertised native compilation but every time I ran into an issue the Reason community would tell me that OCaml support was broken and I should use Node. Excited for the improvements to be sure!
  • e12e 7y ago
    > "Go with generics and enums and Cargo" Isn't that d-lang?
  • eikenberry 7y ago
    From the looks of things you'll probably get the Go you want first. The only thing missing from the roadmap are enums and there are a few Go2 proposals for them.
    • weberc2 7y ago
      Maybe, albeit I'm concerned that the Go team might ship some broken version of generics or enums that we'll be stuck with for years and years. I think that would be strictly worse than no generics or enums. I hope they think holistically about the problem.
• yawn 7y ago
  This is exactly how I feel. I'd be all about Rust if it was GC'd. Go is close enough that it's what I reach for for personal projects, but not having ADTs and pattern matching is super frustrating for modeling data.
  • estebank 7y ago
    What would stop you from using Rc/Arc/RefCell to have reference counting and internal mutability where you need it?
    • steveklabnik 7y ago
      It's really, really awkward to use them everywhere.
      • estebank 7y ago
        They are, and it is one of the places where I'd see us working towards improving their ergonomics in the next couple of years. In the meantime I'm convinced that most code falls either on "small enough that they can be Copy" or big balls of state that also need internal mutability. For people just arriving to the language I always recommend "don't be afraid of .clone(), .clone() until you understand the rest of the language, then jump deeper into borrowing/lifetimes". I would love to have some affordances to avoid having to give that advice.
        • thenewwazoo 7y ago
          It's funny, I give almost the exact opposite advice when I'm helping Rust newbies. My diktat is "clone is banned unless you can explain why you must have it", and then I teach people about what a move is and how to think about lifetimes. w.r.t. Arc/Rc, I'd say that it might feel verbose at first, but it makes explicit what a GC does implicitly, and you can get all the benefits of Rust's ownership model at the same time. I can pick and choose when to rely on the GC and when to explicitly manage lifetimes myself. That's really cool! I maybe a bit weird in this, but I like complexity to get surfaced so I can't pretend it's not there.
• wyatwerp 7y ago
  Are you describing the D language? https://dlang.org https://dlang.org C-like syntax and execution speed with high-level scripting-language-like conveniences, close to Lisp-level ability to generate code at compile time, an active user-base (https://forum.dlang.org https://forum.dlang.org) that continuously strives to get the language improved. Its (thread-local) memory heap is GC'd by default. They also have an LLVM back-end if that is pertinent. Recently, it even became another supported front-end in GCC, alongside Go, Ada, etc.
  • thrower123 7y ago
    D is a weird one, because it has been lurking around for at least a decade and a half without really picking up the kind of steam and hype that later entrants have. I remember dabbling with D for game development way back in high school, as a friendlier alternative to C++.
    • adamnemecek 7y ago
      I think that part of the reason it didn't pick up is because it was made during an era when talking about the problems of C++ was brushed aside with "learn to program kiddo".
      • catach 7y ago
        I suspect we are at least partially still in that era.
    • wyatwerp 7y ago
      Well, Standard ML is a weird one too in that sense (lurking around for a couple of decades without picking up steam (outside academia?)). Languages having type inference and modules designed into them seems to have a good chance to live long.
    • pornel 7y ago
      D excluded itself from being C/C++ killer by having a GC. I know they've backtracked on that, and the -betterC subset of D looks interesting, but it's a bit late for that.
• logicprog 7y ago
  In that case, would ReasonML[1] suit you? ReasonML is based on OCaml, just with a more C-like syntax and nicer tooling, etc. OCaml's semantics are very similar in a lot of ways to Rust, perhaps even better in certain ways. Although it's pitched as a compile-to-JS solution for web development, it's perfectly usable as a natively compiled PL too, using `jbuilder` (dune). [1]: https://reasonml.github.io/ https://reasonml.github.io/
• mlevental 7y ago
  swift is the language you're looking for. unfortunately it's pretty much only useful for ios dev.
• lhorie 7y ago
  Personally I started looking at Rust precisely because borrow checking is a massive improvement over the C/ASM wild west. If you like GC, I feel like there are plenty of other good options, like D, Ocaml, CLR languages (C#/F#).
• leshow 7y ago
  That's what I love about Rust, you get all of those things without having to sacrifice performance. i.e. I get a modern language, get to write code at a relatively high level, and still don't even have to use a GC. You learn to love the borrow checker, it's an amazing tool to work with.
  • p0nce 7y ago
    Having a GC doesn't "sacrifice performance" in itself
• the_mitsuhiko 7y ago
  > I wonder how many Rust users really want linear types and borrow checking, instead of the other stuff Rust brings to the table: modern language design, large and friendly community, nice type system, native compilation, good package ecosystem. I think there are probably more users that would love this but they are not users of the language to begin with. The community that actually forms around Rust is the type of community that does not want GCs, wants the borrow checker and the constraints that form the language.
  • deleted 7y ago
    [deleted]
• pornel 7y ago
  There are already several decent GC languages. If Rust was just another GC language, I don't think it would have attracted such a strong community required to develop all of these things and break out of obscurity. It'd be another Go with generics, or Elixir-native, or Swift with uglier syntax. In the no-GC no-runtime niche for a very long time there was nothing viable besides C and C++. For programmers who want C-like level of control, performance and low-level compatibility there are very few alternatives, and if you want non-crash-prone parallelism on top of that, there's nothing but Rust.
  • wyatwerp 7y ago
    Taking nothing away from the Rust community that has managed such a complex language so well so long, I have to say that there never was anything viable in the no-GC no-runtime niche (that is why it is a niche - otherwise why would anybody be using GC'd languages). We were/are just gritting and bearing C++. If it is a typical program, i.e. not a device driver or OS kernel running on low-memory hardware, having a GC + runtime doesn't preclude performance, for a long-running program. Of course, for short-running programs, just malloc, don't free, is the fastest.
    • pimeys 7y ago
      Having a GC also kind of makes it nasty to write libraries to other GC'd languages. In Rust all of this is very easy, and you can get the speed bump to your Ruby/Python/JavaScript libraries using a modern and safe language.
      • wyatwerp 7y ago
        Is the speed bump for other-language libraries or for other-language applications? For speeding up other-language libraries, D has a -betterC mode, which prevents you from using the subset of the language and the libraries (standard & user-defined) that relies on GC. The remaining language is a very clean C that simply works on the other language's GC'd memory (using the other language's C interface), and can use stack allocation or any heap allocation strategy of your choice for its working set (reference counting ala C++ shared_ptr could be the obvious choice, but it is your party). For other language applications, it is a valid option to speed up the entire application by writing it in D, as it has "all" the features of those other languages + all the convenience that is afforded by a GC + threads if you don't want a multi-process design. I quote "all" because I mean useful things like blocks/closures, generic data structures, etc. - of course, neither Rust nor D give you runtime devices like monkey-patching/meta-class hackery/prototype changes.
• eridius 7y ago
  If you don't want the borrow checker, why are you even using Rust? The borrow checker is the foundation of the zero-cost safety guarantees that make Rust such an incredible language to work with.
• rubber_duck 7y ago
  You can AOT C#/F#/.NET It has value types, Span, PInvoke etc. that make low level interop simple, GC and higher level semantics and better ecosystem/tooling than most alternatives. Runtime size and GC limit some use cases
  • lenkite 7y ago
    AFAIK, F# has still got some wrinkles for AOT support. https://github.com/dotnet/corert/issues/6055 https://github.com/dotnet/corert/issues/6055