3 ms·

This isn't really a Rust problem. Even Java forces you to reckon with heap vs. stack allocation with its boxed types, and you'll get annoying warnings when you

This isn't really a Rust problem. Even Java forces you to reckon with heap vs. stack allocation with its boxed types, and you'll get annoying warnings when you use Integer when int would do. This is just programming culture; given two ways of doing something, with one being harder but more performant, we gravitate to the harder one at all costs.

deleted 3y ago
[deleted]
smabie 3y ago
Considering how mind boggling slow most software is, doesn't seem we are gravitating to the more performant options..
jonhohle 3y ago
There are only two times to use boxed types in Java: when they’re in collection types that take objects (e.g. generics), or when the value needs to be nullable. The first is a language design flaw (imho) that can’t be easily fixed due to backwards compatibility desires. The second is almost always a boundary (DB to app, app to API, etc.) issue that should be resolved quickly, imho. In existing codebases I’ve worked with, often 90% or more boxed primitives are unnecessary, introduce unnecessary errors (assumed non-null refs vs. guaranteed non-null values) and performance penalties. They have a purpose, but there are libraries that address the first concern and Optional${Type} that are more expressive for the second.
- xxs 3y ago
  >or when the value needs to be nullable. I'd discount this part entirely. Using a boxes/non-primitive type for nullability is likely a design mistake. I can go in a full rant mode, in practical terms I tend to reject pull requests that do that.
  - wredue 3y ago
    I mean. They gave example of where it might be commonplace, which is at API boundaries. Especially at DB boundaries, there’s decisions to make. If you put yourself in a position of your db having entirely non-nullable fields, you end up in one of two situations: 1) your whole db is key/value 2) you have magic values Making all key/value doesn’t solve the nullability issue at the code boundary if you’re representing as an object, so you’re left with magic values. I think we all know how nice magic values are. Ideology is the enemy of practicality.
lmm 3y ago
> you'll get annoying warnings when you use Integer when int would do. You can turn them off though, and most of the culture will support you in ignoring them if that's appropriate to your use case.

deleted 3y ago

[deleted]

smabie 3y ago

Considering how mind boggling slow most software is, doesn't seem we are gravitating to the more performant options..

jonhohle 3y ago

There are only two times to use boxed types in Java: when they’re in collection types that take objects (e.g. generics), or when the value needs to be nullable. The first is a language design flaw (imho) that can’t be easily fixed due to backwards compatibility desires. The second is almost always a boundary (DB to app, app to API, etc.) issue that should be resolved quickly, imho. In existing codebases I’ve worked with, often 90% or more boxed primitives are unnecessary, introduce unnecessary errors (assumed non-null refs vs. guaranteed non-null values) and performance penalties. They have a purpose, but there are libraries that address the first concern and Optional${Type} that are more expressive for the second.

xxs 3y ago
>or when the value needs to be nullable. I'd discount this part entirely. Using a boxes/non-primitive type for nullability is likely a design mistake. I can go in a full rant mode, in practical terms I tend to reject pull requests that do that.
- wredue 3y ago
  I mean. They gave example of where it might be commonplace, which is at API boundaries. Especially at DB boundaries, there’s decisions to make. If you put yourself in a position of your db having entirely non-nullable fields, you end up in one of two situations: 1) your whole db is key/value 2) you have magic values Making all key/value doesn’t solve the nullability issue at the code boundary if you’re representing as an object, so you’re left with magic values. I think we all know how nice magic values are. Ideology is the enemy of practicality.

lmm 3y ago

> you'll get annoying warnings when you use Integer when int would do. You can turn them off though, and most of the culture will support you in ignoring them if that's appropriate to your use case.