6 ms·

> I believe that we are seeing the same kind of phenomenon in Rust: I don't know. I picked up OCaml fairly quickly, but I have consistently struggled with Rus

by jnbiche 10y ago

> I believe that we are seeing the same kind of phenomenon in Rust: I don't know. I picked up OCaml fairly quickly, but I have consistently struggled with Rust, trying it for a while before abandoning it in frustration with lifetimes, 2 or 3 times. I can program in Rust, but it still seems like an ongoing struggle, as opposed to the smooth brain to text programming I've gotten used to in Python, JavaScript, OCaml, and Lua, and to a lesser extend C, Go and Elixir (just because I haven't used to latter 3 as much, at least recently). I think Rust may be ideal for embedded software development, or low-level systems software, but for general application development, I think OCaml or perhaps Swift or Scala are more ideal, at least for me (or at least until I decide to try Rust again, perhaps it will stick this time). Edit: Oh yeah, and I was even able to become productive enough in Scala to build a significant project (a programming language) in a relatively short period of time. Now, I'm not silly enough to think I've really mastered Scala in such a short period of time, but I was using it productively as a functional language as I would OCaml with little difficulty. On the other hand, I've started 3 (3!) programming languages in Rust but have yet to get beyond much beyond the parser/AST stage before I quit in frustration.

smt88 10y ago
> smooth brain to text programming This isn't a good thing, in my opinion. Brains make mistakes. I don't want smooth, uninterrupted coding. I want the compiler to tell me when I'm making the mistake, even if it makes things choppier. It's a lot less painful to write code in fits and starts than to write a million tests or spend hours debugging.
- jnbiche 10y ago
  > I want the compiler to tell me when I'm making the mistake, even if it makes things choppier. You don't think the OCaml type system would do this? OCaml gives you just as much safety as Rust does, it just doesn't also give you no GC like Rust does. And the price Rust pays for the absence of GC is the lifetime concept, which adds a very significant layer of complexity to the language. Much like OCaml, Swift and Scala also provide very safe type systems. Again, if you can't have a GC, then Rust is an excellent option, and the only really safe GC-less language unless you use C with FramaC or similar static analysis (and FramaC also requires lots of training and time to use, just like Rust).
  - pcwalton 10y ago
    Ownership and borrowing are also useful for avoiding data races. OCaml solves the problem by not having any shared state at all, which is obviously a huge limitation.
    - jnbiche 10y ago
      Current OCaml needn't worry about data races since no state is shared. Unfortunately, current OCaml also only exploits a single core, but it's so insanely fast that usually doesn't matter. Upcoming OCaml multicore solves the shared state and data races problem with algebraic effects[0]. It is working, it's just not yet been released in mainline OCaml. Supposedly, that will happen this year, but we'll see. 0. http://kcsrk.info/ocaml/multicore/2015/05/20/effects-multicore/ http://kcsrk.info/ocaml/multicore/2015/05/20/effects-multico...
  - Bartweiss 10y ago
    OCaml seems like the argument against Rust's claim to trade usability for safety. It's not true for everything, I wouldn't write embedded OCaml, but it's an easy disproof-by-example for "Rust's difficulty is the inevitable price for trustworthy code!" Which isn't to say OCaml is trivial, or Rust is useless (GC and threading both being limitations). It just makes me skeptical of claims that Rust's difficulty is irreducible.
    - kibwen 10y ago
      Rust's difficulty relative to OCaml might be irreducible if we consider the difficulty added by not providing a pervasive GC, which is part of Rust's design goal and not part of OCaml's.
    - Ar-Curunir 10y ago
      But OCaml isn't intended for the use cases Rust is intended for: a replacement for C and C++
      - pjmlp 10y ago
- jackmott 10y ago
  I don't think they are any error classes that OCaml/F# will let you make that Rust won't.
  - pcwalton 10y ago
    Data races.
  - stonemetal 10y ago
    Rust prevents data races, OCaml/F# don't provide such guaranties. Though it isn't so much of a problem in OCaml since it doesn't have concurrent threads.
    - jnbiche 10y ago
      OCaml has GIL, is normally single core, and shares no state, so current OCaml doesn't need to provide such guarantees. Upcoming multicore OCaml will provide such guarantees through algebraic effects [0]. 0. http://kcsrk.info/ocaml/multicore/2015/05/20/effects-multicore/ http://kcsrk.info/ocaml/multicore/2015/05/20/effects-multico...
    - AstralStorm 10y ago
      First, Rust does not prevent data races, just makes them pain to write. Second, Rust also prevents legitimate sharing in a bunch of cases where concurrency is not involved. (and a simple scoped allocator succeeds) This would be fixed if there was an easy way to have typed memory that can be shared but cannot be accessed concurrently. There is none. You get at most full unsafe.
      - steveklabnik 10y ago
        Rust does prevent data races, as long as you don't use unsafe. If not, it's a bug. You can write arenas in Rust.
        GolDDranks 10y ago
        Just to be clear about the terminology (since I'm not sure if the grandparent knows about the difference): Rust prevents data races but not race conditions (although it makes it easier to avoid them). Here's an explanation about the differences: http://blog.regehr.org/archives/490 http://blog.regehr.org/archives/490
- sametmax 10y ago
  It depends a lot of what you code and your constraints. Believe it or not they are a huge crowd of people making a living out of code that is easy to write but crashes. And they are happy about it. E.G: one of my friend has a streaming website. He make banks with ads despite the site having problems all the time. He doesn't care the least. He is not an expert coder and just want to be able to build the features he needs, even if it's not perfect. Types are way too much for him. It took 2 years to master git basics. Another example: my current clients are geomaticians. They code in Python a lot. They produce only small codes, and don't want something complex. They are experts in maps, not code, and love Python to have the balance of cost / reward they want. HN is a bubble of expert devs, but the world is full of PHP plumbers, data manglers, sys admin and other professional that have a legitimate needs for "smooth brain to text programming".
  - kibwen 10y ago
    And I think that's fine; Rust isn't trying to be the one language to rule them all. It's intended as a foundational language: your friend's streaming website survives despite his own code crashing often, but it won't survive if his off-the-shelf HTTP server crashes often (HTTP servers being the sort of thing one would write in Rust). Likewise, your mathematicians aren't going to be very productive if their Python interpreter crashes often (likewise, interpreters are the sort of thing one would also imagine writing in Rust). Even in Rust's ideal future, very little of the code atop the stack is written in it. It's the code at the very bottom that underpins everything whose share it hopes to eat.
    - sh_tinh_hair 10y ago
      Dictatorial concepts in PL usually fail pretty badly. Rust may become the textbook example of a good idea too far. I'd certainly never use it or use anything written in it given a choice and/or time to rewrite in anything more accessible.
      - kibwen 10y ago
        > or use anything written in it As I often say on HN, I must be missing the sarcasm here...
sametmax 10y ago
Give it time. Rust is brand new and has changed considerably during the last year. The rust team listen closely to the community and will smooth things up. But they can't do it all at once.
- Bartweiss 10y ago
  This is worth remembering. I'm technically on my "second attempt" to learn Rust, but the first one wasn't abandoned because Rust is fundamentally flawed. It was just new enough that the thing I wanted to build was drowning me in nightly builds and hypothetical features. After giving it ~1 year, things are already looking much more welcoming.
Recurecur 10y ago
> I think Rust may be ideal for embedded software development, or low-level systems software, but for general application development, I think OCaml or perhaps Swift or Scala are more ideal, at least for me (or at least until I decide to try Rust again, perhaps it will stick this time). If you're not aware of it, scala-native looks very interesting... It looks to be active project. https://github.com/scala-native/scala-native https://github.com/scala-native/scala-native FWIW, I've also enjoyed Swift development quite a bit. I think Swift will go deep into the C++ sweet spot.
- pjmlp 10y ago
  A benefit that Swift has over Rust in regards to market adoption, is that an OS vendor has the power to say "My way or the highway" to developers that want to target their platform. However Rust is already picking up steam in Firefox modules, hobby OS development, university CS degrees and GNOME modules, so there might be a path there.
  - fjrieiekd 10y ago
    The tooling for Swift is certainly miles better on iOS, but I do like Rust as a language. On Android the most comprehensive solution I've seen is Xamarin, but last time I tried it (which was years ago), I wasn't a fan of the GUI and the perf was worse than Dalvik. Hopefully that has improved now.
- fjrieiekd 10y ago
  Rust seems really great as infrastructure level code, but the tooling still has a lot of rough dyes when it comes to mobile development. I think Swift could play a decent role here if it ever gets good android support as it already enjoys first-class support on iOS. I also agree in that Swift feels very nice. :)

by jnbiche 10y ago

smt88 10y ago

> smooth brain to text programming This isn't a good thing, in my opinion. Brains make mistakes. I don't want smooth, uninterrupted coding. I want the compiler to tell me when I'm making the mistake, even if it makes things choppier. It's a lot less painful to write code in fits and starts than to write a million tests or spend hours debugging.

jnbiche 10y ago
> I want the compiler to tell me when I'm making the mistake, even if it makes things choppier. You don't think the OCaml type system would do this? OCaml gives you just as much safety as Rust does, it just doesn't also give you no GC like Rust does. And the price Rust pays for the absence of GC is the lifetime concept, which adds a very significant layer of complexity to the language. Much like OCaml, Swift and Scala also provide very safe type systems. Again, if you can't have a GC, then Rust is an excellent option, and the only really safe GC-less language unless you use C with FramaC or similar static analysis (and FramaC also requires lots of training and time to use, just like Rust).
- pcwalton 10y ago
  Ownership and borrowing are also useful for avoiding data races. OCaml solves the problem by not having any shared state at all, which is obviously a huge limitation.
  - jnbiche 10y ago
    Current OCaml needn't worry about data races since no state is shared. Unfortunately, current OCaml also only exploits a single core, but it's so insanely fast that usually doesn't matter. Upcoming OCaml multicore solves the shared state and data races problem with algebraic effects[0]. It is working, it's just not yet been released in mainline OCaml. Supposedly, that will happen this year, but we'll see. 0. http://kcsrk.info/ocaml/multicore/2015/05/20/effects-multicore/ http://kcsrk.info/ocaml/multicore/2015/05/20/effects-multico...
- Bartweiss 10y ago
  OCaml seems like the argument against Rust's claim to trade usability for safety. It's not true for everything, I wouldn't write embedded OCaml, but it's an easy disproof-by-example for "Rust's difficulty is the inevitable price for trustworthy code!" Which isn't to say OCaml is trivial, or Rust is useless (GC and threading both being limitations). It just makes me skeptical of claims that Rust's difficulty is irreducible.
  - kibwen 10y ago
    Rust's difficulty relative to OCaml might be irreducible if we consider the difficulty added by not providing a pervasive GC, which is part of Rust's design goal and not part of OCaml's.
  - Ar-Curunir 10y ago
    But OCaml isn't intended for the use cases Rust is intended for: a replacement for C and C++
    - pjmlp 10y ago
jackmott 10y ago
I don't think they are any error classes that OCaml/F# will let you make that Rust won't.
- pcwalton 10y ago
  Data races.
- stonemetal 10y ago
  Rust prevents data races, OCaml/F# don't provide such guaranties. Though it isn't so much of a problem in OCaml since it doesn't have concurrent threads.
  - jnbiche 10y ago
    OCaml has GIL, is normally single core, and shares no state, so current OCaml doesn't need to provide such guarantees. Upcoming multicore OCaml will provide such guarantees through algebraic effects [0]. 0. http://kcsrk.info/ocaml/multicore/2015/05/20/effects-multicore/ http://kcsrk.info/ocaml/multicore/2015/05/20/effects-multico...
  - AstralStorm 10y ago
    First, Rust does not prevent data races, just makes them pain to write. Second, Rust also prevents legitimate sharing in a bunch of cases where concurrency is not involved. (and a simple scoped allocator succeeds) This would be fixed if there was an easy way to have typed memory that can be shared but cannot be accessed concurrently. There is none. You get at most full unsafe.
    - steveklabnik 10y ago
      Rust does prevent data races, as long as you don't use unsafe. If not, it's a bug. You can write arenas in Rust.
      - GolDDranks 10y ago
        Just to be clear about the terminology (since I'm not sure if the grandparent knows about the difference): Rust prevents data races but not race conditions (although it makes it easier to avoid them). Here's an explanation about the differences: http://blog.regehr.org/archives/490 http://blog.regehr.org/archives/490
sametmax 10y ago
It depends a lot of what you code and your constraints. Believe it or not they are a huge crowd of people making a living out of code that is easy to write but crashes. And they are happy about it. E.G: one of my friend has a streaming website. He make banks with ads despite the site having problems all the time. He doesn't care the least. He is not an expert coder and just want to be able to build the features he needs, even if it's not perfect. Types are way too much for him. It took 2 years to master git basics. Another example: my current clients are geomaticians. They code in Python a lot. They produce only small codes, and don't want something complex. They are experts in maps, not code, and love Python to have the balance of cost / reward they want. HN is a bubble of expert devs, but the world is full of PHP plumbers, data manglers, sys admin and other professional that have a legitimate needs for "smooth brain to text programming".
- kibwen 10y ago
  And I think that's fine; Rust isn't trying to be the one language to rule them all. It's intended as a foundational language: your friend's streaming website survives despite his own code crashing often, but it won't survive if his off-the-shelf HTTP server crashes often (HTTP servers being the sort of thing one would write in Rust). Likewise, your mathematicians aren't going to be very productive if their Python interpreter crashes often (likewise, interpreters are the sort of thing one would also imagine writing in Rust). Even in Rust's ideal future, very little of the code atop the stack is written in it. It's the code at the very bottom that underpins everything whose share it hopes to eat.
  - sh_tinh_hair 10y ago
    Dictatorial concepts in PL usually fail pretty badly. Rust may become the textbook example of a good idea too far. I'd certainly never use it or use anything written in it given a choice and/or time to rewrite in anything more accessible.
    - kibwen 10y ago
      > or use anything written in it As I often say on HN, I must be missing the sarcasm here...

sametmax 10y ago

Give it time. Rust is brand new and has changed considerably during the last year. The rust team listen closely to the community and will smooth things up. But they can't do it all at once.

Bartweiss 10y ago
This is worth remembering. I'm technically on my "second attempt" to learn Rust, but the first one wasn't abandoned because Rust is fundamentally flawed. It was just new enough that the thing I wanted to build was drowning me in nightly builds and hypothetical features. After giving it ~1 year, things are already looking much more welcoming.

Recurecur 10y ago

> I think Rust may be ideal for embedded software development, or low-level systems software, but for general application development, I think OCaml or perhaps Swift or Scala are more ideal, at least for me (or at least until I decide to try Rust again, perhaps it will stick this time). If you're not aware of it, scala-native looks very interesting... It looks to be active project. https://github.com/scala-native/scala-native https://github.com/scala-native/scala-native FWIW, I've also enjoyed Swift development quite a bit. I think Swift will go deep into the C++ sweet spot.

pjmlp 10y ago
A benefit that Swift has over Rust in regards to market adoption, is that an OS vendor has the power to say "My way or the highway" to developers that want to target their platform. However Rust is already picking up steam in Firefox modules, hobby OS development, university CS degrees and GNOME modules, so there might be a path there.
- fjrieiekd 10y ago
  The tooling for Swift is certainly miles better on iOS, but I do like Rust as a language. On Android the most comprehensive solution I've seen is Xamarin, but last time I tried it (which was years ago), I wasn't a fan of the GUI and the perf was worse than Dalvik. Hopefully that has improved now.
fjrieiekd 10y ago
Rust seems really great as infrastructure level code, but the tooling still has a lot of rough dyes when it comes to mobile development. I think Swift could play a decent role here if it ever gets good android support as it already enjoys first-class support on iOS. I also agree in that Swift feels very nice. :)