7 ms·

Ahhh the joy of the borrow checker : Me: Let's code this little vector computations BorrowChecker: "Not like that" Me: "What do you mean I have borrowed a mu

by wiz21c 4y ago

Ahhh the joy of the borrow checker : Me: Let's code this little vector computations BorrowChecker: "Not like that" Me: "What do you mean I have borrowed a mutable ? Let's try something else purely out of random" BC: "No" Me: "Let's rename things to cheat" BC: "No" Me: "Ah yeah, it's because I try to use two indices in the same vector" BC: "No" Me: "G*mn at random, let's shuffle things" BC: "No" ME: Ok, let's do it in python (but believe me, once, you understand it and it becomes a really good friend, it just takes months :-) )

cies 4y ago
> once, you understand it and it becomes a really good friend, it just takes months Same for Haskell. It seems that some great languages take some investment in order to become productive with them.
- paskozdilar 4y ago
  Same for Lisp :)
  - cies 4y ago
    Indeed. Writing assembly also needs a big up-front investment, but I'm not sure how many have every considered it to be a good friendship. :)
    - deleted 4y ago
      [deleted]
    - the_third_wave 4y ago
      When in need assembly is a friend indeed. It might not be the friend you'd want to go on a hiking trip with - that is, unless you like to eat birch bark spaghetti and drink fish blood - but it is the friend you know will be there to help you when birch bark spaghetti and fish blood are the only things available.
      - cies 4y ago
        > eat birch bark spaghetti and drink fish blood you cracked me up. tnx.
    - paskozdilar 4y ago
      To be fair, someone liked it enough to build an OS in it: http://kolibrios.org http://kolibrios.org http://menuetos.net http://menuetos.net
- rapsey 4y ago
  Low barrier to entry is great for adoption. Has nothing to do with the quality of the resulting product and often it is inverse.
- shirogane86x 4y ago
  Yeah I've had the same experience (with Haskell, and with Rust). Lisp probably counts too, and maybe even Array languages like APL? It does feel amazing though. It does take a while to learn and internalize these great languages, but once you do it feels like you have superpowers sometimes. I would never even attempt to write some of the things I've written in Haskell in other languages.
k__ 4y ago
When I run out of ideas, I copy.
Ygg2 4y ago
> it just takes months So does learning a language enough to claim to know it. As Bruce Eckel once said, programming is like learning to navigate a room blind. You won't learn till you've bumped into every wall and piece of furniture.
- dagw 4y ago
  So does learning a language enough to claim to know it. True, but many languages let you do a lot of useful things while you are still learning, without requiring you to truly understanding what you are doing. Some people manage to spend their entire career writing useful little python scripts without really "knowing" most of python. Languages like Rust and Haskell make you learn a lot more of the language up front before you can become useful. This should not be taken as a critique of the language however.
  - Ygg2 4y ago
    > True, but many languages let you do a lot of useful things while you are still learning, without requiring you to truly understanding what you are doing. Well same can be done in Rust. Hate the borrow checker? Just Box/RefCell all the things. However learning that habit can be pricey from execution POV, so most Rust books don't teach it.
    - staticassertion 4y ago
      Box/RefCell are gonna be way harder than just ".clone()" or not sharing mutable references all over the place.
      - Ygg2 4y ago
        Well it's the only way to bypass borrow checker as fas as I know. And I assume teaching you a bad habit, then un-teaching it is going to be more expensive than not. I guess another way could be by using Copy-able structs is anohther way.
  - staticassertion 4y ago
IshKebab 4y ago
Python: "Nonetype object is not subscritable"
- nivenkos 4y ago
  After it's been running for 3 hours...
  - wiz21c 4y ago
    Which you discover by reading the logs on production server :-)
- psd1 4y ago
  Triggered
tialaramex 4y ago
Sometimes, what you're doing is unsound and so it must be forbidden even if you can't intuitively see why yet. Rust's diagnostics often show you why. However, sometimes (and for an experienced Rust developer this might start to happen more often than "Oh, actually that was dumb" type situations) the problem is that the Borrow Checker doesn't understand why it's fine. The diagnostic points you at something, and you say "Er, yeah, what's the problem?" and, sometimes, there wasn't really a problem. Non-lexical lifetimes were a big improvement in Rust, improving the borrow checking analysis so that more cases which are correct were allowed by the checker. Polonius is one thing intended to further improve upon this: https://github.com/rust-lang/polonius https://github.com/rust-lang/polonius
- paskozdilar 4y ago
  It seems to me that Rust takes a very conservative approach to memory safety - the borrow checker gives you a set of things that are safe, and you figure out how to do stuff with the lego blocks that are given. Over time, as the compiler gets better and better, safe Rust will probably be as powerful and expressive as any other programming language. I'm looking forward to see how the language develops further.
  - cjg 4y ago
    I feel confident that my Rust is strong enough that I can already write any structure that is expressible in another language. It might be that I would have to add extra safety mechanisms - such as Arcs or Mutexes. But it's all possible. Some Rust developers might see such code as less idiomatic and look for a different solution, but if a different solution doesn't exist, there's always the fallback. Less experienced Rust developers, however, are more used to seeing only the easier patterns and may not appreciate how to achieve some of the more difficult ones. It's not that these patterns are harder in Rust than another language, per se. But more typing is needed to convince the compiler that you have everything lined up. Other languages will just let you introduce data races / crashes.
    - paskozdilar 4y ago
yakubin 4y ago
Coming from C++, it didn't take months. I got a couple lifetime errors at the start, but I understood the reason behind them all[1]. Now I don't get the errors[2]. In C++ you need to think about the lifetimes anyway or your code will break at runtime, so then coming to Rust it's not that much of a problem IMO. [1]: Except the errors about partial (non-aliasing) borrows of struct fields. That was annoying, although circumventable with some boilerplate. Luckily, it's solved now in the compiler. [2]: Although it may be to a large degree thanks to using arenas for allocation, which simplify lifetimes a lot by grouping them into large buckets instead of tracking each little object separately with its own little lifetime.
- CraigJPerry 4y ago
  >> it may be to a large degree thanks to using arenas for allocation If you're going to do that, would you not be better saving all that time and code bloat (it's code you wrote that doesn't contribute to solving your problem) by just using a garbage collector from the outset? This propensity to fall back to arenas and the other puzzling behaviour i observe is liberal use of "#[derive(Copy, Clone)]" - these seem counter productive. Why are people wasting time only to reinvent solved problems? Or to frame it more charitably, rust is allegedly a super-power for developers. Why are rust devs not pushing the boundaries of what it means to be a developer? We do we not see very large code bases on github maintained by a small number of devs? Allegedly the combination of static typing + borrow checker makes code maintainability a breeze. So where's the evidence?
  - yakubin 4y ago
    > If you're going to do that, would you not be better saving all that time and code bloat (it's code you wrote that doesn't contribute to solving your problem) by just using a garbage collector from the outset? I suspect a garbage collector would be pretty nice. However, I can't just list the features I want and get a language (unless I make it myself, which would take a lot of time). Currently, my imaginary perfect language would actually have a garbage collector, would be pretty similar to Standard ML, but would be more focused on arrays than lists, and would have value types --- in Standard ML I can't have a value array of records (structs in Rust/C++ parlance) --- they will be behind a pointer. And if I were to stick to the standard or make sure that my code compiles with other compilers than MLTon, then I can't even have a value array of 64-bit words, although I can have a value array of 63-bit words. This one bit may seem insignificant, but for certain algorithms it's a big complication. Powers of 2 simplify a lot of algorithms (and are "faster" to be a bit loose with the language). There are other features I'd like, but already this short list makes for a currently-non-existent language. OCaml and Haskell have similar problems to Standard ML. At the same time Rust has great support for arrays, is expression-oriented, has sum types. Value types are the default. It generally ticks a lot of boxes I care about. I can't just go and say "now give me all that but with a GC" and have it appear before me. Also, arenas I use are linked to logical portions of my programs. They are not contrivances that I had to think long and hard about. They don't waste my time really. I've spent 0 time thinking about how they should be organized. Now the part where a GC would be helpful is a bit of a more liberal use of closures, and eliminating code noise coming from lifetime annotations such as "for<'a>". But I can live with the current state of affairs, if I get all the other benefits. > If you're going to do that, would you not be better saving all that time and code bloat (it's code you wrote that doesn't contribute to solving your problem) by just using a garbage collector from the outset? If anything, Rust is an asset for large teams of devs. Even though you may sometimes argue that a handful of C/C++ devs can keep their whole project in their heads and not make mistakes (although I think that's a stretch), the moment you get a large C/C++ team, weird hard-to-debug bugs coming from memory- and thread-safety issues start to creep in. There are other high-level languages, but Rust is the one with a combination of performance competitive with C++ and large ecosystem of libraries you can use. Examples of Rust projects with a large number of contributors facilitated by the language taking the fear of intractable bugs away: - <https://github.com/BurntSushi/ripgrep https://github.com/BurntSushi/ripgrep> - <https://github.com/clap-rs/clap https://github.com/clap-rs/clap> - <https://github.com/rayon-rs/rayon https://github.com/rayon-rs/rayon> - <https://github.com/cloudflare/wrangler https://github.com/cloudflare/wrangler> - <https://github.com/sharkdp/fd https://github.com/sharkdp/fd>
JamesSwift 4y ago
This mirrors my initial experience as well : ) It really took a while for it to "click" in my head about how it wanted me to structure things. Once that occurred it was smoother sailing, though still difficult. Then I never touched it again. I should give it another try to see if anything stuck with me.

by wiz21c 4y ago

cies 4y ago

> once, you understand it and it becomes a really good friend, it just takes months Same for Haskell. It seems that some great languages take some investment in order to become productive with them.

paskozdilar 4y ago
Same for Lisp :)
- cies 4y ago
  Indeed. Writing assembly also needs a big up-front investment, but I'm not sure how many have every considered it to be a good friendship. :)
  - deleted 4y ago
    [deleted]
  - the_third_wave 4y ago
    When in need assembly is a friend indeed. It might not be the friend you'd want to go on a hiking trip with - that is, unless you like to eat birch bark spaghetti and drink fish blood - but it is the friend you know will be there to help you when birch bark spaghetti and fish blood are the only things available.
    - cies 4y ago
      > eat birch bark spaghetti and drink fish blood you cracked me up. tnx.
  - paskozdilar 4y ago
    To be fair, someone liked it enough to build an OS in it: http://kolibrios.org http://kolibrios.org http://menuetos.net http://menuetos.net
rapsey 4y ago
Low barrier to entry is great for adoption. Has nothing to do with the quality of the resulting product and often it is inverse.
shirogane86x 4y ago
Yeah I've had the same experience (with Haskell, and with Rust). Lisp probably counts too, and maybe even Array languages like APL? It does feel amazing though. It does take a while to learn and internalize these great languages, but once you do it feels like you have superpowers sometimes. I would never even attempt to write some of the things I've written in Haskell in other languages.

k__ 4y ago

When I run out of ideas, I copy.

Ygg2 4y ago

> it just takes months So does learning a language enough to claim to know it. As Bruce Eckel once said, programming is like learning to navigate a room blind. You won't learn till you've bumped into every wall and piece of furniture.

dagw 4y ago
So does learning a language enough to claim to know it. True, but many languages let you do a lot of useful things while you are still learning, without requiring you to truly understanding what you are doing. Some people manage to spend their entire career writing useful little python scripts without really "knowing" most of python. Languages like Rust and Haskell make you learn a lot more of the language up front before you can become useful. This should not be taken as a critique of the language however.
- Ygg2 4y ago
  > True, but many languages let you do a lot of useful things while you are still learning, without requiring you to truly understanding what you are doing. Well same can be done in Rust. Hate the borrow checker? Just Box/RefCell all the things. However learning that habit can be pricey from execution POV, so most Rust books don't teach it.
  - staticassertion 4y ago
    Box/RefCell are gonna be way harder than just ".clone()" or not sharing mutable references all over the place.
    - Ygg2 4y ago
      Well it's the only way to bypass borrow checker as fas as I know. And I assume teaching you a bad habit, then un-teaching it is going to be more expensive than not. I guess another way could be by using Copy-able structs is anohther way.
- staticassertion 4y ago

IshKebab 4y ago

Python: "Nonetype object is not subscritable"

nivenkos 4y ago
After it's been running for 3 hours...
- wiz21c 4y ago
  Which you discover by reading the logs on production server :-)
psd1 4y ago
Triggered

tialaramex 4y ago

Sometimes, what you're doing is unsound and so it must be forbidden even if you can't intuitively see why yet. Rust's diagnostics often show you why. However, sometimes (and for an experienced Rust developer this might start to happen more often than "Oh, actually that was dumb" type situations) the problem is that the Borrow Checker doesn't understand why it's fine. The diagnostic points you at something, and you say "Er, yeah, what's the problem?" and, sometimes, there wasn't really a problem. Non-lexical lifetimes were a big improvement in Rust, improving the borrow checking analysis so that more cases which are correct were allowed by the checker. Polonius is one thing intended to further improve upon this: https://github.com/rust-lang/polonius https://github.com/rust-lang/polonius

paskozdilar 4y ago
It seems to me that Rust takes a very conservative approach to memory safety - the borrow checker gives you a set of things that are safe, and you figure out how to do stuff with the lego blocks that are given. Over time, as the compiler gets better and better, safe Rust will probably be as powerful and expressive as any other programming language. I'm looking forward to see how the language develops further.
- cjg 4y ago
  I feel confident that my Rust is strong enough that I can already write any structure that is expressible in another language. It might be that I would have to add extra safety mechanisms - such as Arcs or Mutexes. But it's all possible. Some Rust developers might see such code as less idiomatic and look for a different solution, but if a different solution doesn't exist, there's always the fallback. Less experienced Rust developers, however, are more used to seeing only the easier patterns and may not appreciate how to achieve some of the more difficult ones. It's not that these patterns are harder in Rust than another language, per se. But more typing is needed to convince the compiler that you have everything lined up. Other languages will just let you introduce data races / crashes.
  - paskozdilar 4y ago

yakubin 4y ago

Coming from C++, it didn't take months. I got a couple lifetime errors at the start, but I understood the reason behind them all[1]. Now I don't get the errors[2]. In C++ you need to think about the lifetimes anyway or your code will break at runtime, so then coming to Rust it's not that much of a problem IMO. [1]: Except the errors about partial (non-aliasing) borrows of struct fields. That was annoying, although circumventable with some boilerplate. Luckily, it's solved now in the compiler. [2]: Although it may be to a large degree thanks to using arenas for allocation, which simplify lifetimes a lot by grouping them into large buckets instead of tracking each little object separately with its own little lifetime.

CraigJPerry 4y ago
>> it may be to a large degree thanks to using arenas for allocation If you're going to do that, would you not be better saving all that time and code bloat (it's code you wrote that doesn't contribute to solving your problem) by just using a garbage collector from the outset? This propensity to fall back to arenas and the other puzzling behaviour i observe is liberal use of "#[derive(Copy, Clone)]" - these seem counter productive. Why are people wasting time only to reinvent solved problems? Or to frame it more charitably, rust is allegedly a super-power for developers. Why are rust devs not pushing the boundaries of what it means to be a developer? We do we not see very large code bases on github maintained by a small number of devs? Allegedly the combination of static typing + borrow checker makes code maintainability a breeze. So where's the evidence?
- yakubin 4y ago
  > If you're going to do that, would you not be better saving all that time and code bloat (it's code you wrote that doesn't contribute to solving your problem) by just using a garbage collector from the outset? I suspect a garbage collector would be pretty nice. However, I can't just list the features I want and get a language (unless I make it myself, which would take a lot of time). Currently, my imaginary perfect language would actually have a garbage collector, would be pretty similar to Standard ML, but would be more focused on arrays than lists, and would have value types --- in Standard ML I can't have a value array of records (structs in Rust/C++ parlance) --- they will be behind a pointer. And if I were to stick to the standard or make sure that my code compiles with other compilers than MLTon, then I can't even have a value array of 64-bit words, although I can have a value array of 63-bit words. This one bit may seem insignificant, but for certain algorithms it's a big complication. Powers of 2 simplify a lot of algorithms (and are "faster" to be a bit loose with the language). There are other features I'd like, but already this short list makes for a currently-non-existent language. OCaml and Haskell have similar problems to Standard ML. At the same time Rust has great support for arrays, is expression-oriented, has sum types. Value types are the default. It generally ticks a lot of boxes I care about. I can't just go and say "now give me all that but with a GC" and have it appear before me. Also, arenas I use are linked to logical portions of my programs. They are not contrivances that I had to think long and hard about. They don't waste my time really. I've spent 0 time thinking about how they should be organized. Now the part where a GC would be helpful is a bit of a more liberal use of closures, and eliminating code noise coming from lifetime annotations such as "for<'a>". But I can live with the current state of affairs, if I get all the other benefits. > If you're going to do that, would you not be better saving all that time and code bloat (it's code you wrote that doesn't contribute to solving your problem) by just using a garbage collector from the outset? If anything, Rust is an asset for large teams of devs. Even though you may sometimes argue that a handful of C/C++ devs can keep their whole project in their heads and not make mistakes (although I think that's a stretch), the moment you get a large C/C++ team, weird hard-to-debug bugs coming from memory- and thread-safety issues start to creep in. There are other high-level languages, but Rust is the one with a combination of performance competitive with C++ and large ecosystem of libraries you can use. Examples of Rust projects with a large number of contributors facilitated by the language taking the fear of intractable bugs away: - <https://github.com/BurntSushi/ripgrep https://github.com/BurntSushi/ripgrep> - <https://github.com/clap-rs/clap https://github.com/clap-rs/clap> - <https://github.com/rayon-rs/rayon https://github.com/rayon-rs/rayon> - <https://github.com/cloudflare/wrangler https://github.com/cloudflare/wrangler> - <https://github.com/sharkdp/fd https://github.com/sharkdp/fd>

JamesSwift 4y ago

This mirrors my initial experience as well : ) It really took a while for it to "click" in my head about how it wanted me to structure things. Once that occurred it was smoother sailing, though still difficult. Then I never touched it again. I should give it another try to see if anything stuck with me.