6 ms·

> but the ergonomic is really bad. Every time I write some rust I feel limited. > But I do not think it is a good general purpose language. Remember that this

by goku12 3y ago

> but the ergonomic is really bad. Every time I write some rust I feel limited. > But I do not think it is a good general purpose language. Remember that this is not a sentiment that's shared by everyone. I use Rust for tasks that need anything more complicated than a shell script. Even my window manager is controlled from a Rust program. I say this as someone who has been programming in Python for nearly two decades now. At this point, I'm about as fast in Rust as I am in Python.

lumost 3y ago
I tried to get into rust for many years, I'm now in a C/CPP job (after Java/Python/Ruby and other gigs). What I've come to understand is that Rust's lifetime model is very difficult to work with whenever you have a cyclic reference. In C/CPP the same holds, but you deal with it through clever coding - or ignoring the problem and cleaning up memory later. Java, and other GC'd languages just work for these structures. While the Rust devs believe such cyclic references are rare - I think this speaks mostly to the problem domain they are focused on. Relational models are everywhere in Apps, they are often common in complex systems software like databases, and they are fairly rare in firmware/drivers/system code code. There are a few patterns for dealing with cyclic references, but they all end up requiring either unsafe or a main "owner" object which you clean up occassionally (effectively arena allocation). Having now worked in C/CPP - the idea of having unsafe blocks sprinkled around the code doesn't bother me, and many C/CPP components have some form of arena allocation built-in. I just wish Rust learning resources would be more upfront about this.
- goku12 3y ago
  > I just wish Rust learning resources would be more upfront about this. While beginner resources don't dwell too much upon cyclic references, they don't consider unsafe blocks as unusual. All the material I've seen say that there are certain domains where Rust's compile-time safety model simply won't work. What Rust allows you to do instead, is to limit the scope of unsafe blocks. However, the beginner material often won't give you too much details on how to analyze and decide on these compromises. Anyway, compile-time safety checks (using borrow checker) and manual safety checks (using unsafe) aren't the only way to deal with safety. Cyclic references can be dealt with runtime safety checks too - like Rc and Weak.
  - mtsr 3y ago
    > Cyclic references can be dealt with runtime safety checks too - like Rc and Weak. Indeed. Starting out with code sprinkled with Rc, Weak, RefCell, etc is perfectly fine and performance will probably not be worse than in any other safe languages. And if you do this, Rust is pretty close to those languages in ease of use for what are otherwise complex topics in Rust. A good reference for different approaches is Learn Rust With Entirely Too Many Linked Lists https://rust-unofficial.github.io/too-many-lists/ https://rust-unofficial.github.io/too-many-lists/
    - lumost 3y ago
      You still need a main owner in those patterns, that owner must be part of a DAG of owners - you cannot have cyclic ownership.
    - pncnmnp 3y ago
      Also, take a look at GhostCell (https://plv.mpi-sws.org/rustbelt/ghostcell/ https://plv.mpi-sws.org/rustbelt/ghostcell/ and https://www.youtube.com/watch?v=jIbubw86p0M https://www.youtube.com/watch?v=jIbubw86p0M). If anyone's used this in a project or production environment, I'd love to hear your firsthand experiences and insights.
    - pjmlp 3y ago
      Except in those other languages the compiler types .clone() for me.
      - chalsprhebaodu 3y ago
        Sometimes the compiler types clone for you even you don’t actually want it to.
        pjmlp 3y ago
        It is easier to tell it, "don't do it this time" than all the time. It is no accident that while Val/Hylo, Chapel and Swift have taken inspiration from Rust, they have decided to not inflict the affine types directly into the language users, rather let the compiler do part of the work itself.
- lifthrasiir 3y ago
  > Relational models are everywhere in Apps, they are often common in complex systems software like databases, and they are fairly rare in firmware/drivers/system code code. It's not like that you can't write relational models in the safe Rust. The only forbidden thing is a reference pointing arbitrary memory, which is typically worked around via indices and often more performant in that way. It is much rarer to find applications that need an absolutely random pointer that can't be hidden in abstractions in my opinion.
- mjevans 3y ago
  What's a frequently encountered case for such cyclic loops? Without details I'm drawn to trying to break the cycle, either by promoting the shared state to a container object for the set, or by breaking it out into it's own object that multiple things can point at.
  - solomonb 3y ago
    ASTs
    - lifthrasiir 3y ago
      ASTs are one of "nicely behaving" data structures. It is like a archetype of abstract data types pervasive in functional programming languages.
    - mjevans 3y ago
      An Abstract Syntax Tree / or Double-Linked List both qualify, but they're also a lower level implementation detail than I'd expect to frequently interact with in a reference safety focused language. I've still been meaning to write something in / learn Rust's ways of thinking; is there not an intended replacement for these data structures? Or do they expect it all to go under Unsafe?
      - littlestymaar 3y ago
        > is there not an intended replacement for these data structures? Or do they expect it all to go under Unsafe? For linked-lists, there's one in std and the majority of people should never have to write their own as it's error prone and requires unsafe. For graph use-case then you can either use ECS, arena, ref counting or unsafe, but you're probably better off using/developing a dedicated crate that optimizes it and abstract it away behind an easy to use (and safe) interface.
        lumost 3y ago
        The one in std uses unsafe. My main concern with learning rust is that you can spend ages trying to learn “the right way” of doing things in rust, when the right way really is to use unsafe.
- worik 3y ago
  > While the Rust devs believe such cyclic references are rare - They are. I have not had to use cyclic references ever, except once doing experiments with fully connected graphs, that was very unusual If you're doing a lot cyclic references Rust is not the right choice. Horses for courses But are you sure you're using the best algorithm?
  - jcelerier 3y ago
    Maybe for you it's unusual - in my previous work all the apps contained graphs, and I just joined a company where almost all the apps also contain graphs
    - underdeserver 3y ago
      I don't write Rust, but I never understood why graphs meant you need circular references. Doesn't it just come down to the question of who owns the node? If it's a tree, and parents are never removed before children, just make the child owned by the parent and keep a weak reference to the parent. If it's a general graph, and vertices can exist or not exist regardless of edges, keep a list of them independent of the edges, and keep weak references in the edges. If it's a graph where a one or a few roots exist, and nodes exist as long as there's a path from a root node to them, that sounds like a classic use case for Rc<>. Is there a common use case I'm missing?
      - lumost 3y ago
        Things get tricky when you have a valid triangular relationship amongst equal objects. This comes up far more often than you’d expect.
        underdeserver 3y ago
        Can you give an example?
- zabzonk 3y ago
  to be a bit pedantic, i assume the language you a referring to as CPP is actualy C++? cpp to me means the c (and c++) preprocessor.
- oconnor663 3y ago
  Oh I just put up a blog post about this on Monday :) https://jacko.io/object_soup.html https://jacko.io/object_soup.html Agreed that I wish more beginner Rust books had a section about this. The pattern is quite simple, but it's hard for beginners who get stuck to realize that they need it.
  - strokirk 3y ago
    I would have needed this when I started learning Rust! All my early programs were object soups.
hiAndrewQuinn 3y ago
I've finally set my mind to properly learning a new language after Python, Haskell, and typescript. I'm looking into Rust especially because of how I've heard it interoperates with Python (and also because it's maybe being used in the Linux kernel? Is that correct?).
- PartiallyTyped 3y ago
  Linux kernel has support for rust userland drivers, and rust interops with python with pyo3.
  - maccam94 3y ago
    Not sure what you mean by "userland" drivers here, but support for kernel modules written in rust is actively being developed. It's already being used for kernel drivers like the Asahi Linux GPU driver for M1 Macs.
    - PartiallyTyped 3y ago
      I am referring to userspace / userland drivers. https://www.kernel.org/doc/html/v4.18/driver-api/uio-howto.html#writing-a-driver-in-userspace https://www.kernel.org/doc/html/v4.18/driver-api/uio-howto.h...
      - tremon 3y ago
        But you can write userspace drivers in any language, as long as that language has basic file I/O and mmap() support. There's nothing special about using Rust for userspace drivers.
        TylerE 3y ago
        Isn't this false? Don't certain languages basically need, say, a libc that isn't nessesarily available in kernel space?
- tinco 3y ago
PartiallyTyped 3y ago
Surprisingly, I am faster in Rust than any other language. Something about my prior experiences just made it click just the right way. I don't want to program in anything else anymore. I don't want to deal with obscure C++ error messages, C footguns and lack of ergonomics, I don't want to deal with abstraction hell of Java, or the poor person's typing that python has. I have been programming in Python for the past 6 years, I know all sorts of obscure details, and with rust, I just don't need to think about all of those issues.
- goku12 3y ago
  > Surprisingly, I am faster in Rust than any other language. Not really surprising, given that you have C and C++ background. That's what I was trying to highlight. Rust isn't a confusing or unproductive language as many project it to be - if you have the conceptual understanding of what happens on the hardware. Especially about stack frames and RAII. If you know those, the borrow checker complaints will immediately make sense and you will know how to resolve them. Add rust-analyzer (Rust's language server) to it, you get real-time type annotations and a way to match types correctly in the first attempt. In my experience Rust also helps structure your program correctly and saves a ton of time in debugging. All in all, Rust is a fast way to write correct programs.
  - mcronce 3y ago
    My background is PHP, Python, and Go, and I have the same experience as GP
  - PartiallyTyped 3y ago
    I'd add that if you have some understanding of how memory ownership should be such that you don't end up with memory leaks, you are fine. The borrow checker just verifies that your mental model is correct, and removes some of the cognitive load from you.
    - ayewo 3y ago
      > if you have some understanding of how memory ownership What reading materials will help me level up my understanding of this?
pizza234 3y ago
> At this point, I'm about as fast in Rust as I am in Python. This is factually impossible. For anything larger than (very) small programs, Rust requires an upfront design stage, due to ownership, that it's not required when developing in GC'ed languages. This is not even considering more local complexities, like data structures with cyclical references.
- goku12 3y ago
  > This is factually impossible. How do you outright deny something as subjective as my personal experience? Besides, I'm not the only one in this discussion that made the same opinion. > For anything larger than (very) small programs, Rust requires an upfront design stage, due to ownership, that it's not required when developing in GC'ed languages. While GC'ed languages allow you to skip a proper initial design stage, it's a stretch to claim that it's not required at all. In my experience using Python, while the initial stages are smooth, such design oversights come back and bite at a later stage - leading to a lot of debugging and refactoring. This is one aspect where Rust saves you time. > This is not even considering more local complexities, like data structures with cyclical references. I'm not going to dwell on cyclical references, since there's another thread that addresses it. They point out a way to make it as easy in Rust as it is in GC'ed languages. Meanwhile, the upfront architecture and data structure design isn't as complicated as you project it. Rust is mostly transparent about those - even compared Python. How well do you understand how Python manages Lists, dictionaries or even objects in general? I often find myself thinking about it a lot when programming in Python. While you need to think upfront about these in Rust, there's actually less cognitive overhead as to what is happening behind the scenes.
  - Ylmaz 3y ago
    This is possible if you are really slow in python
    - ParetoOptimal 3y ago
      Or maybe they mean "fast to 1.0" rather than "fast to 0.1"? They didn't specify.
Liskni_si 3y ago
What window manager is that, may I ask out of curiousity?
- goku12 3y ago
  Sway. And river, sooner or later. A single Rust program is used for setting up services (using s6-rc on Gentoo), shutdown, reboot, idle inhibit, etc.
JohnFen 3y ago
It's interesting that you bring up Python. I find Rust unpleasant to program in -- and I also find Python unpleasant to program in. Now I'm wondering about demographics. Are people who love Python more likely to love Rust as well?

by goku12 3y ago

lumost 3y ago

I tried to get into rust for many years, I'm now in a C/CPP job (after Java/Python/Ruby and other gigs). What I've come to understand is that Rust's lifetime model is very difficult to work with whenever you have a cyclic reference. In C/CPP the same holds, but you deal with it through clever coding - or ignoring the problem and cleaning up memory later. Java, and other GC'd languages just work for these structures. While the Rust devs believe such cyclic references are rare - I think this speaks mostly to the problem domain they are focused on. Relational models are everywhere in Apps, they are often common in complex systems software like databases, and they are fairly rare in firmware/drivers/system code code. There are a few patterns for dealing with cyclic references, but they all end up requiring either unsafe or a main "owner" object which you clean up occassionally (effectively arena allocation). Having now worked in C/CPP - the idea of having unsafe blocks sprinkled around the code doesn't bother me, and many C/CPP components have some form of arena allocation built-in. I just wish Rust learning resources would be more upfront about this.

goku12 3y ago
> I just wish Rust learning resources would be more upfront about this. While beginner resources don't dwell too much upon cyclic references, they don't consider unsafe blocks as unusual. All the material I've seen say that there are certain domains where Rust's compile-time safety model simply won't work. What Rust allows you to do instead, is to limit the scope of unsafe blocks. However, the beginner material often won't give you too much details on how to analyze and decide on these compromises. Anyway, compile-time safety checks (using borrow checker) and manual safety checks (using unsafe) aren't the only way to deal with safety. Cyclic references can be dealt with runtime safety checks too - like Rc and Weak.
- mtsr 3y ago
  > Cyclic references can be dealt with runtime safety checks too - like Rc and Weak. Indeed. Starting out with code sprinkled with Rc, Weak, RefCell, etc is perfectly fine and performance will probably not be worse than in any other safe languages. And if you do this, Rust is pretty close to those languages in ease of use for what are otherwise complex topics in Rust. A good reference for different approaches is Learn Rust With Entirely Too Many Linked Lists https://rust-unofficial.github.io/too-many-lists/ https://rust-unofficial.github.io/too-many-lists/
  - lumost 3y ago
    You still need a main owner in those patterns, that owner must be part of a DAG of owners - you cannot have cyclic ownership.
  - pncnmnp 3y ago
    Also, take a look at GhostCell (https://plv.mpi-sws.org/rustbelt/ghostcell/ https://plv.mpi-sws.org/rustbelt/ghostcell/ and https://www.youtube.com/watch?v=jIbubw86p0M https://www.youtube.com/watch?v=jIbubw86p0M). If anyone's used this in a project or production environment, I'd love to hear your firsthand experiences and insights.
  - pjmlp 3y ago
    Except in those other languages the compiler types .clone() for me.
    - chalsprhebaodu 3y ago
      Sometimes the compiler types clone for you even you don’t actually want it to.
      - pjmlp 3y ago
        It is easier to tell it, "don't do it this time" than all the time. It is no accident that while Val/Hylo, Chapel and Swift have taken inspiration from Rust, they have decided to not inflict the affine types directly into the language users, rather let the compiler do part of the work itself.
lifthrasiir 3y ago
> Relational models are everywhere in Apps, they are often common in complex systems software like databases, and they are fairly rare in firmware/drivers/system code code. It's not like that you can't write relational models in the safe Rust. The only forbidden thing is a reference pointing arbitrary memory, which is typically worked around via indices and often more performant in that way. It is much rarer to find applications that need an absolutely random pointer that can't be hidden in abstractions in my opinion.
mjevans 3y ago
What's a frequently encountered case for such cyclic loops? Without details I'm drawn to trying to break the cycle, either by promoting the shared state to a container object for the set, or by breaking it out into it's own object that multiple things can point at.
- solomonb 3y ago
  ASTs
  - lifthrasiir 3y ago
    ASTs are one of "nicely behaving" data structures. It is like a archetype of abstract data types pervasive in functional programming languages.
  - mjevans 3y ago
    An Abstract Syntax Tree / or Double-Linked List both qualify, but they're also a lower level implementation detail than I'd expect to frequently interact with in a reference safety focused language. I've still been meaning to write something in / learn Rust's ways of thinking; is there not an intended replacement for these data structures? Or do they expect it all to go under Unsafe?
    - littlestymaar 3y ago
      > is there not an intended replacement for these data structures? Or do they expect it all to go under Unsafe? For linked-lists, there's one in std and the majority of people should never have to write their own as it's error prone and requires unsafe. For graph use-case then you can either use ECS, arena, ref counting or unsafe, but you're probably better off using/developing a dedicated crate that optimizes it and abstract it away behind an easy to use (and safe) interface.
      - lumost 3y ago
        The one in std uses unsafe. My main concern with learning rust is that you can spend ages trying to learn “the right way” of doing things in rust, when the right way really is to use unsafe.
worik 3y ago
> While the Rust devs believe such cyclic references are rare - They are. I have not had to use cyclic references ever, except once doing experiments with fully connected graphs, that was very unusual If you're doing a lot cyclic references Rust is not the right choice. Horses for courses But are you sure you're using the best algorithm?
- jcelerier 3y ago
  Maybe for you it's unusual - in my previous work all the apps contained graphs, and I just joined a company where almost all the apps also contain graphs
  - underdeserver 3y ago
    I don't write Rust, but I never understood why graphs meant you need circular references. Doesn't it just come down to the question of who owns the node? If it's a tree, and parents are never removed before children, just make the child owned by the parent and keep a weak reference to the parent. If it's a general graph, and vertices can exist or not exist regardless of edges, keep a list of them independent of the edges, and keep weak references in the edges. If it's a graph where a one or a few roots exist, and nodes exist as long as there's a path from a root node to them, that sounds like a classic use case for Rc<>. Is there a common use case I'm missing?
    - lumost 3y ago
      Things get tricky when you have a valid triangular relationship amongst equal objects. This comes up far more often than you’d expect.
      - underdeserver 3y ago
        Can you give an example?
zabzonk 3y ago
to be a bit pedantic, i assume the language you a referring to as CPP is actualy C++? cpp to me means the c (and c++) preprocessor.
oconnor663 3y ago
Oh I just put up a blog post about this on Monday :) https://jacko.io/object_soup.html https://jacko.io/object_soup.html Agreed that I wish more beginner Rust books had a section about this. The pattern is quite simple, but it's hard for beginners who get stuck to realize that they need it.
- strokirk 3y ago
  I would have needed this when I started learning Rust! All my early programs were object soups.

hiAndrewQuinn 3y ago

I've finally set my mind to properly learning a new language after Python, Haskell, and typescript. I'm looking into Rust especially because of how I've heard it interoperates with Python (and also because it's maybe being used in the Linux kernel? Is that correct?).

PartiallyTyped 3y ago
Linux kernel has support for rust userland drivers, and rust interops with python with pyo3.
- maccam94 3y ago
  Not sure what you mean by "userland" drivers here, but support for kernel modules written in rust is actively being developed. It's already being used for kernel drivers like the Asahi Linux GPU driver for M1 Macs.
  - PartiallyTyped 3y ago
    I am referring to userspace / userland drivers. https://www.kernel.org/doc/html/v4.18/driver-api/uio-howto.html#writing-a-driver-in-userspace https://www.kernel.org/doc/html/v4.18/driver-api/uio-howto.h...
    - tremon 3y ago
      But you can write userspace drivers in any language, as long as that language has basic file I/O and mmap() support. There's nothing special about using Rust for userspace drivers.
      - TylerE 3y ago
        Isn't this false? Don't certain languages basically need, say, a libc that isn't nessesarily available in kernel space?
tinco 3y ago

PartiallyTyped 3y ago

Surprisingly, I am faster in Rust than any other language. Something about my prior experiences just made it click just the right way. I don't want to program in anything else anymore. I don't want to deal with obscure C++ error messages, C footguns and lack of ergonomics, I don't want to deal with abstraction hell of Java, or the poor person's typing that python has. I have been programming in Python for the past 6 years, I know all sorts of obscure details, and with rust, I just don't need to think about all of those issues.

goku12 3y ago
> Surprisingly, I am faster in Rust than any other language. Not really surprising, given that you have C and C++ background. That's what I was trying to highlight. Rust isn't a confusing or unproductive language as many project it to be - if you have the conceptual understanding of what happens on the hardware. Especially about stack frames and RAII. If you know those, the borrow checker complaints will immediately make sense and you will know how to resolve them. Add rust-analyzer (Rust's language server) to it, you get real-time type annotations and a way to match types correctly in the first attempt. In my experience Rust also helps structure your program correctly and saves a ton of time in debugging. All in all, Rust is a fast way to write correct programs.
- mcronce 3y ago
  My background is PHP, Python, and Go, and I have the same experience as GP
- PartiallyTyped 3y ago
  I'd add that if you have some understanding of how memory ownership should be such that you don't end up with memory leaks, you are fine. The borrow checker just verifies that your mental model is correct, and removes some of the cognitive load from you.
  - ayewo 3y ago
    > if you have some understanding of how memory ownership What reading materials will help me level up my understanding of this?

pizza234 3y ago

> At this point, I'm about as fast in Rust as I am in Python. This is factually impossible. For anything larger than (very) small programs, Rust requires an upfront design stage, due to ownership, that it's not required when developing in GC'ed languages. This is not even considering more local complexities, like data structures with cyclical references.

goku12 3y ago
> This is factually impossible. How do you outright deny something as subjective as my personal experience? Besides, I'm not the only one in this discussion that made the same opinion. > For anything larger than (very) small programs, Rust requires an upfront design stage, due to ownership, that it's not required when developing in GC'ed languages. While GC'ed languages allow you to skip a proper initial design stage, it's a stretch to claim that it's not required at all. In my experience using Python, while the initial stages are smooth, such design oversights come back and bite at a later stage - leading to a lot of debugging and refactoring. This is one aspect where Rust saves you time. > This is not even considering more local complexities, like data structures with cyclical references. I'm not going to dwell on cyclical references, since there's another thread that addresses it. They point out a way to make it as easy in Rust as it is in GC'ed languages. Meanwhile, the upfront architecture and data structure design isn't as complicated as you project it. Rust is mostly transparent about those - even compared Python. How well do you understand how Python manages Lists, dictionaries or even objects in general? I often find myself thinking about it a lot when programming in Python. While you need to think upfront about these in Rust, there's actually less cognitive overhead as to what is happening behind the scenes.
- Ylmaz 3y ago
  This is possible if you are really slow in python
  - ParetoOptimal 3y ago
    Or maybe they mean "fast to 1.0" rather than "fast to 0.1"? They didn't specify.

Liskni_si 3y ago

What window manager is that, may I ask out of curiousity?

goku12 3y ago
Sway. And river, sooner or later. A single Rust program is used for setting up services (using s6-rc on Gentoo), shutdown, reboot, idle inhibit, etc.

JohnFen 3y ago

It's interesting that you bring up Python. I find Rust unpleasant to program in -- and I also find Python unpleasant to program in. Now I'm wondering about demographics. Are people who love Python more likely to love Rust as well?