6 ms·

Rust developers concerned about complexity, low usage

34 points by prmph 3y ago

jvanderbot 3y ago
I don't understand how Rust is being weighed. It's a systems programming language seemingly intended for critical code with baked in security and "programmer mitigation". I've heard and watched some pretty wild claims about it being the new Uber language. If it targets c, Cpp, then it might end up just out of sight for most programmers. If it reaches lots of Linux and Windows integration, then it'll become the new "foundational" language, but even that doesn't mean widespread adoption.
- prmph 3y ago
  Well, I guess the response to Rust just means people are still waiting for a language that: - has a very expressive and sound type system - provides a good mix of paradigms (functional, imperative, object oriented, etc.) - uses modern techniques to address the warts of many existing languages (nulls, exceptions, optionality, unsafe memory access, async, etc.) - is (reasonably) fast - comes with great tooling and docs - is mainstream, general, open, and not tied to any particular vendor Whether they are right to pin these hopes on Rust is one thing, but there's no denying there is still an un-addressed hunger for a next-gen open language that generally addresses many pain points with modern software development.
  - yogorenapan 3y ago
    I think Zig is a step in the right direction. The simple syntax feels as pleasant as Go and the manual management allows for very performant software. It makes it easier to write safe programs but definitely isn’t as memory safe as Rust. The day we have a language as simple as Go/Zig and as safe as Rust will be the day we have a perfect language.
    - dagmx 3y ago
      IMHO, if you stick to just unsafe rust, it’s got similar ergonomics to Zig. And the lack of safety in Zig to me is a move in the wrong direction for a language created so recently. The safety is the added complexity because so much of what we regularly do can fail in ways we don’t think about. The alternative so far has been to introduce some kind of automated memory management like reference counting or a GC. Rust in fact gets much simpler (but slightly verbose) if you wrap everything in an Arc. That’s why I say in another comment that Swift is the closest to a more accessible Rust. Granted, until Swift 6, it won’t go as far as Rust for thread safety. But for everything else, it is Rust without having to think about as much while writing.
    - deleted 3y ago
      [deleted]
  - dagmx 3y ago
    Now that Swift is on other platforms, I think it’s a good fit, especially as Foundation is being rewritten in pure Swift . Really good ergonomics, safe by default for many cases and getting more of rusts safety for others. Easy interop with C/ObjC/C++, which is a big deal for me because it’s what’s caused me to write less Rust/C++/Zig at all lately and focus on Swift.
    - jwells89 3y ago
      I really, really hope that the energy cross platform Swift has been seeing lately continues and accelerates. It’s not perfect, but I find it productive and enjoyable to write. It strikes a nice balance between being strict and getting out of your way and doesn’t come off as pedantic as some languages with similar syntax.
      - dagmx 3y ago
        I think the new C++ interop might help the momentum. Swift is now the easiest language IMHO to bind C++ automatically with. I really feel like easy interop in languages is the missing key to moving people into more safe languages.
        jwells89 3y ago
        Tooling is also a factor I think. Last time I was playing with writing Swift on Linux, the official LSP with VS Code was alright (surprisingly even supporting debugging) but I found myself wanting a proper IDE.
    - pjmlp 3y ago
      I doubt it, what makes Swift, just like Objective-C, it is the frameworks and IDE tooling. GNUStep went nowhere.
      - jwells89 3y ago
        Swift on its own is already much more usable than Obj-C is and will only become moreso with the Foundation rewrite. It has a way to go but it’s possible to write useful software with it without Cocoa/GNUStep (especially if one is willing to lean on C or C++ libraries via interop), which was never true of Obj-C.
  - The_Colonel 3y ago
    JVM and CLR tick all the boxes. Historically, there were performance complaints, but a lot of these were mitigated (AOT, heavily improved GC..., faster hardware). They are fast enough for a large majority of apps.
    - pjmlp 3y ago
      And if one feels like using a Rust like type system, there is enough to chose from between Kotlin, Scala, F#, and even Haskell dialects.
    - prmph 3y ago
      There are many people, like me, who dislike anything Java: the language, the runtime/SDK, and anything built on top of these. I even refuse to install anything that requires the JRE. Might be an irrational stance, but my early experience of JRE hogging my machine turned off it forever. The CLR is supposed to be open now, but in practice, the ecosystem around it is still basically Microsoft.
      - pjmlp 3y ago
        So more confortable with Apple practices, or happy PinePhone user?
  - satvikpendem 3y ago
    Looks like they're looking for OCaml, but sadly it's not as popular as most languages. Dart might fit as well.
flembat 3y ago
There is space in the world for a difficult complex language that produces low level operating system and library code, we just don't need to be writing every application using it, since ordinary people should also be able to program computers.
- dstanko 3y ago
  Do you perceive Rust programmers as extraordinary?
  - foofie 3y ago
    Rust is renowned for imposing a high cognitive load on all but the most trivial tasks. This is perhaps the worst traits a programming language can have.
    - steveklabnik 3y ago
      This is a thing people experience at the beginning, but once you get over the hump, for many, it is not descriptive of what it's like.
      - foofie 3y ago
        > This is a thing people experience at the beginning (...) This is not an onboarding problem. This is a trait of the programming language, which only gets worse as a project grows. It's high time for the Rust community to start to get honest with themselves and stop pretending problems don't exist. It's already bad enough with the clusterfuck which is async Rust, and you're doing no one any favor to pretend that the borrow checker doesn't add a heavy cognitive load.
        dwattttt 3y ago
        I can't speak for others, but it absolutely has made life easier, on both small and large scales. Actually being forced to think about how long allocations and resources need to live turned random "takes days to figure out" bugs into an instant response of "oh, that was stupid of me to try doing that huh? Guess I'll try something else"
ww520 3y ago
I have done a fair amount of Rust. The complexity is not in the borrow checker or lifetime. It’s in the combination explosion of the of generic, traits, lifetime, and constraints. When a struct takes on these, all functions and impls need to specify them. The amount of brackets becomes very distracting.
- aldanor 3y ago
  It's all relative. I've done my fair share of both C++ and Rust for over a decade and yet I can quite easily read Rust source code for both the Rust standard library and any 3rd party crate. In comparison, reading C++ std headers is complete pain, same as sources of many popular C++ libraries, due to them being overly generic in a C++ way.
  - pjmlp 3y ago
    Including Serde macros, and tokio async implementation?
devaiops9001 3y ago
https://austral-lang.org/ https://austral-lang.org/
harimau777 3y ago
For what it's worth, I'm currently learning Rust. My primary motivation is that it offers the opportunity to get a job where I can use functional programming techniques (even if it isn't necessarily a "functional language" in the way something like Haskel is).

34 points by prmph 3y ago

I don't understand how Rust is being weighed. It's a systems programming language seemingly intended for critical code with baked in security and "programmer mitigation". I've heard and watched some pretty wild claims about it being the new Uber language. If it targets c, Cpp, then it might end up just out of sight for most programmers. If it reaches lots of Linux and Windows integration, then it'll become the new "foundational" language, but even that doesn't mean widespread adoption.

prmph 3y ago
Well, I guess the response to Rust just means people are still waiting for a language that: - has a very expressive and sound type system - provides a good mix of paradigms (functional, imperative, object oriented, etc.) - uses modern techniques to address the warts of many existing languages (nulls, exceptions, optionality, unsafe memory access, async, etc.) - is (reasonably) fast - comes with great tooling and docs - is mainstream, general, open, and not tied to any particular vendor Whether they are right to pin these hopes on Rust is one thing, but there's no denying there is still an un-addressed hunger for a next-gen open language that generally addresses many pain points with modern software development.
- yogorenapan 3y ago
  I think Zig is a step in the right direction. The simple syntax feels as pleasant as Go and the manual management allows for very performant software. It makes it easier to write safe programs but definitely isn’t as memory safe as Rust. The day we have a language as simple as Go/Zig and as safe as Rust will be the day we have a perfect language.
  - dagmx 3y ago
    IMHO, if you stick to just unsafe rust, it’s got similar ergonomics to Zig. And the lack of safety in Zig to me is a move in the wrong direction for a language created so recently. The safety is the added complexity because so much of what we regularly do can fail in ways we don’t think about. The alternative so far has been to introduce some kind of automated memory management like reference counting or a GC. Rust in fact gets much simpler (but slightly verbose) if you wrap everything in an Arc. That’s why I say in another comment that Swift is the closest to a more accessible Rust. Granted, until Swift 6, it won’t go as far as Rust for thread safety. But for everything else, it is Rust without having to think about as much while writing.
  - deleted 3y ago
    [deleted]
- dagmx 3y ago
  Now that Swift is on other platforms, I think it’s a good fit, especially as Foundation is being rewritten in pure Swift . Really good ergonomics, safe by default for many cases and getting more of rusts safety for others. Easy interop with C/ObjC/C++, which is a big deal for me because it’s what’s caused me to write less Rust/C++/Zig at all lately and focus on Swift.
  - jwells89 3y ago
    I really, really hope that the energy cross platform Swift has been seeing lately continues and accelerates. It’s not perfect, but I find it productive and enjoyable to write. It strikes a nice balance between being strict and getting out of your way and doesn’t come off as pedantic as some languages with similar syntax.
    - dagmx 3y ago
      I think the new C++ interop might help the momentum. Swift is now the easiest language IMHO to bind C++ automatically with. I really feel like easy interop in languages is the missing key to moving people into more safe languages.
      - jwells89 3y ago
        Tooling is also a factor I think. Last time I was playing with writing Swift on Linux, the official LSP with VS Code was alright (surprisingly even supporting debugging) but I found myself wanting a proper IDE.
  - pjmlp 3y ago
    I doubt it, what makes Swift, just like Objective-C, it is the frameworks and IDE tooling. GNUStep went nowhere.
    - jwells89 3y ago
      Swift on its own is already much more usable than Obj-C is and will only become moreso with the Foundation rewrite. It has a way to go but it’s possible to write useful software with it without Cocoa/GNUStep (especially if one is willing to lean on C or C++ libraries via interop), which was never true of Obj-C.
- The_Colonel 3y ago
  JVM and CLR tick all the boxes. Historically, there were performance complaints, but a lot of these were mitigated (AOT, heavily improved GC..., faster hardware). They are fast enough for a large majority of apps.
  - pjmlp 3y ago
    And if one feels like using a Rust like type system, there is enough to chose from between Kotlin, Scala, F#, and even Haskell dialects.
  - prmph 3y ago
    There are many people, like me, who dislike anything Java: the language, the runtime/SDK, and anything built on top of these. I even refuse to install anything that requires the JRE. Might be an irrational stance, but my early experience of JRE hogging my machine turned off it forever. The CLR is supposed to be open now, but in practice, the ecosystem around it is still basically Microsoft.
    - pjmlp 3y ago
      So more confortable with Apple practices, or happy PinePhone user?
- satvikpendem 3y ago
  Looks like they're looking for OCaml, but sadly it's not as popular as most languages. Dart might fit as well.

flembat 3y ago

There is space in the world for a difficult complex language that produces low level operating system and library code, we just don't need to be writing every application using it, since ordinary people should also be able to program computers.

dstanko 3y ago
Do you perceive Rust programmers as extraordinary?
- foofie 3y ago
  Rust is renowned for imposing a high cognitive load on all but the most trivial tasks. This is perhaps the worst traits a programming language can have.
  - steveklabnik 3y ago
    This is a thing people experience at the beginning, but once you get over the hump, for many, it is not descriptive of what it's like.
    - foofie 3y ago
      > This is a thing people experience at the beginning (...) This is not an onboarding problem. This is a trait of the programming language, which only gets worse as a project grows. It's high time for the Rust community to start to get honest with themselves and stop pretending problems don't exist. It's already bad enough with the clusterfuck which is async Rust, and you're doing no one any favor to pretend that the borrow checker doesn't add a heavy cognitive load.
      - dwattttt 3y ago
        I can't speak for others, but it absolutely has made life easier, on both small and large scales. Actually being forced to think about how long allocations and resources need to live turned random "takes days to figure out" bugs into an instant response of "oh, that was stupid of me to try doing that huh? Guess I'll try something else"

ww520 3y ago

I have done a fair amount of Rust. The complexity is not in the borrow checker or lifetime. It’s in the combination explosion of the of generic, traits, lifetime, and constraints. When a struct takes on these, all functions and impls need to specify them. The amount of brackets becomes very distracting.

aldanor 3y ago
It's all relative. I've done my fair share of both C++ and Rust for over a decade and yet I can quite easily read Rust source code for both the Rust standard library and any 3rd party crate. In comparison, reading C++ std headers is complete pain, same as sources of many popular C++ libraries, due to them being overly generic in a C++ way.
- pjmlp 3y ago
  Including Serde macros, and tokio async implementation?

devaiops9001 3y ago

https://austral-lang.org/ https://austral-lang.org/

harimau777 3y ago

For what it's worth, I'm currently learning Rust. My primary motivation is that it offers the opportunity to get a job where I can use functional programming techniques (even if it isn't necessarily a "functional language" in the way something like Haskel is).