4 ms·

I've only just started learning Rust but having spent 38 years programming I largely agree with his sentiments. Typing .unwrap() forces you to acknowledge that

I've only just started learning Rust but having spent 38 years programming I largely agree with his sentiments. Typing .unwrap() forces you to acknowledge that what you have may not actually be what you expect. Explicit flow control makes what is happening clear to understand and reason about without jumping about the code via exceptions. Type conversions should also be explicit, (and automatic type conversions would needlessly complicate the Type Checker in any event). I am sure there are places where "ergonomics" can be improved, but it is far more important to avoid the many (accidental) mistakes made by other programming languages. Rust is going to be around for a long time. So any mistakes made now will also be around for a very long time.

zacmps 9y ago
I don't think type conversions need to always be explicit, there just needs to be a lot of careful thought before they are. Automatic deref would be an absolute pain to live without for example.
- ben0x539 9y ago
  Would lack of automatic deref be less painful with a "->" operator equivalent, or just postfix deref? I don't want to say automatic deref is harmful, but a lot of the time I wish I could locally deduce more about the level of indirection.
- glandium 9y ago
  Speaking of explicit conversions, it's always painful to have to do explicit conversions of integers. E.g. Have an u8 and want to use it as an index in a Vec? You have to cast as usize. That quickly becomes annoying.
  - royjacobs 9y ago
    If you need to do that a lot then arguably you'd be better off having a variable of 'usize' in the first place.
  - thinkpad20 9y ago
    On the contrary, I think that’s an argument against implicit conversions. u8 and usize have wildly different ranges, and treating them as the same could cause some maddening bugs. I can’t imagine there are that many places where you’d need to use a u8 as an index; if there were you could either wrap your data structure in a struct which accepts u8 instead, or use usize more instead... (Not that I’m claiming to know your code base or specific challenge or anything; I’m just speaking generally)
    - userbinator 9y ago
      I think implicit widening is a good idea, but not narrowing --- expanding a u8 into a usize doesn't actually lose any information, but going the opposite way does.
      - therein 9y ago
        Depends on the machine architecture really but I agree in principle.
    - Gibbon1 9y ago
      > I can’t imagine there are that many places where you’d need to use a u8 as an index I have some firmware on a small machine, there aren't any arrays with more than two dozen elements. On the eight bit machine the the code originally ran on using a 16 or 32 bit int caused a lot of code bloat. You might not think that's a problem but consider the price difference between a processor with 64k of flash and 128k might be a dollar. Times 100,000 units a year. The above is why I'm not going to use rust anytime soon, because a rust binary size is about 4 times larger than C. That would add about $2-3 to the cost of the product. Or $200-300k a year for no real benefit at all.
      - burntsushi 9y ago
        That doesn't make any sense. If `i` is a `u8` and `xs` is an array, then `xs[i as usize]` works today. The criticism isn't even specific to exotic environments. The same reasoning applies at bigger widths too. I've certainly used `u32` in places instead of `usize` to avoid doubling the size of my heap use on 64-bit systems. Implicit widening would be nice, but it isn't necessary.
- jeremyjh 9y ago
  I would argue Deref coercions are still explicit, because the trait implementations are explicit. There is not a magic mapping of types whose references can be coerced to each other, it is exactly the ones that implement Deref<Target=T>.
- zzzcpan 9y ago
  Type conversions have to be explicit when they are lossy, otherwise it's just useless noise and cognitive overhead that can lead to a bug.
  - ben0x539 9y ago
    I dunno, "newtypes" are a fairly popular patterns, and if they automatically converted between the base type and other newtypes of the base type, they'd not really be useful.
  - k__ 9y ago
    Can't they have performance impacts even if they aren't lossy?
  - Too 9y ago
    Type conversions, even non lossy ones, can teach people to use the wrong type, in c++ it's very common to see people use a int in a for loop indexing an array when you should always use size_t for that purpose. This misuse is so widespread that people hardly even know that the size_t type exists. https://www.viva64.com/en/a/0050/ https://www.viva64.com/en/a/0050/ has some nice material about why this matters and the type of bugs this can cause.
    - Gibbon1 9y ago
      Personal opinion, heavy use of int is a code smell. Ada with 'range' probably gets this right.
mastax 9y ago
Thing is, nobody was arguing for any of those things. This would be a much more useful article if it argued against a specfic real ergonomic proposal.
- emn13 9y ago
  Nothing wrong with being cautious, especially with something as foundational as a language feature. It's quite hard to remove a feature that turns out to have unforeseen indirect consequences.

zacmps 9y ago

I don't think type conversions need to always be explicit, there just needs to be a lot of careful thought before they are. Automatic deref would be an absolute pain to live without for example.

ben0x539 9y ago
Would lack of automatic deref be less painful with a "->" operator equivalent, or just postfix deref? I don't want to say automatic deref is harmful, but a lot of the time I wish I could locally deduce more about the level of indirection.
glandium 9y ago
Speaking of explicit conversions, it's always painful to have to do explicit conversions of integers. E.g. Have an u8 and want to use it as an index in a Vec? You have to cast as usize. That quickly becomes annoying.
- royjacobs 9y ago
  If you need to do that a lot then arguably you'd be better off having a variable of 'usize' in the first place.
- thinkpad20 9y ago
  On the contrary, I think that’s an argument against implicit conversions. u8 and usize have wildly different ranges, and treating them as the same could cause some maddening bugs. I can’t imagine there are that many places where you’d need to use a u8 as an index; if there were you could either wrap your data structure in a struct which accepts u8 instead, or use usize more instead... (Not that I’m claiming to know your code base or specific challenge or anything; I’m just speaking generally)
  - userbinator 9y ago
    I think implicit widening is a good idea, but not narrowing --- expanding a u8 into a usize doesn't actually lose any information, but going the opposite way does.
    - therein 9y ago
      Depends on the machine architecture really but I agree in principle.
  - Gibbon1 9y ago
    > I can’t imagine there are that many places where you’d need to use a u8 as an index I have some firmware on a small machine, there aren't any arrays with more than two dozen elements. On the eight bit machine the the code originally ran on using a 16 or 32 bit int caused a lot of code bloat. You might not think that's a problem but consider the price difference between a processor with 64k of flash and 128k might be a dollar. Times 100,000 units a year. The above is why I'm not going to use rust anytime soon, because a rust binary size is about 4 times larger than C. That would add about $2-3 to the cost of the product. Or $200-300k a year for no real benefit at all.
    - burntsushi 9y ago
      That doesn't make any sense. If `i` is a `u8` and `xs` is an array, then `xs[i as usize]` works today. The criticism isn't even specific to exotic environments. The same reasoning applies at bigger widths too. I've certainly used `u32` in places instead of `usize` to avoid doubling the size of my heap use on 64-bit systems. Implicit widening would be nice, but it isn't necessary.
jeremyjh 9y ago
I would argue Deref coercions are still explicit, because the trait implementations are explicit. There is not a magic mapping of types whose references can be coerced to each other, it is exactly the ones that implement Deref<Target=T>.
zzzcpan 9y ago
Type conversions have to be explicit when they are lossy, otherwise it's just useless noise and cognitive overhead that can lead to a bug.
- ben0x539 9y ago
  I dunno, "newtypes" are a fairly popular patterns, and if they automatically converted between the base type and other newtypes of the base type, they'd not really be useful.
- k__ 9y ago
  Can't they have performance impacts even if they aren't lossy?
- Too 9y ago
  Type conversions, even non lossy ones, can teach people to use the wrong type, in c++ it's very common to see people use a int in a for loop indexing an array when you should always use size_t for that purpose. This misuse is so widespread that people hardly even know that the size_t type exists. https://www.viva64.com/en/a/0050/ https://www.viva64.com/en/a/0050/ has some nice material about why this matters and the type of bugs this can cause.
  - Gibbon1 9y ago
    Personal opinion, heavy use of int is a code smell. Ada with 'range' probably gets this right.

mastax 9y ago

Thing is, nobody was arguing for any of those things. This would be a much more useful article if it argued against a specfic real ergonomic proposal.

emn13 9y ago
Nothing wrong with being cautious, especially with something as foundational as a language feature. It's quite hard to remove a feature that turns out to have unforeseen indirect consequences.