8 ms·

> You do not need a very good reason not to. Actually you do. One is a component specified by international standards, which is ideal, while the other is yet a

> You do not need a very good reason not to. Actually you do. One is a component specified by international standards, which is ideal, while the other is yet another third party component. Unless you only work on hobby projects, adding dependencies is a maintenance liability. You need very good and compelling reasons to add a dependency, and it doesn't seem you have any. > And thus far, that best tool is fmt. You gave zero reasons to support your personal assertion. It's fine if you just hack stuff together in hobby projects, but pros doing pro work have to meet professional standards, which you failed to address.

i-use-nixos-btw 3y ago
> One is a component specified by international standards That just means that vendors should provide something that matches the specification. Usually it also means backwards compatibility guarantees, which is moot with external repos when you can stick to a revision if something breaks. But hey, don’t worry, we’ve got std::format and soon we will have std::print. So you can keep to the standard library if you wish. The implementation is inferior to the fmt library itself, though. An addition to fmt is a commit away - an addition to std::format is four bikesheds, three defect reports and six revisions away before it may find itself into the standard in 3 years). It has much more exposure to a much bigger and more diverse community before it hits a major version than the standard gets. > You gave zero reasons Just to provide the full paragraph: > And thus far, that best tool is fmt. The syntax is cleaner, it’s more configurable without horrible side effects, the resulting operations are more efficient, and as a project it is still being actively improved over time. Configurability: check No horrible side effects: check Resulting operations are more efficient: check Under regular improvement: check Those are my reasons. If any “pro” work negates using good tools, then I pity it. I use a range of third party libraries in my work (no, not just hobby projects - and no, not a small project) and it is a major plus.

i-use-nixos-btw 3y ago

> One is a component specified by international standards That just means that vendors should provide something that matches the specification. Usually it also means backwards compatibility guarantees, which is moot with external repos when you can stick to a revision if something breaks. But hey, don’t worry, we’ve got std::format and soon we will have std::print. So you can keep to the standard library if you wish. The implementation is inferior to the fmt library itself, though. An addition to fmt is a commit away - an addition to std::format is four bikesheds, three defect reports and six revisions away before it may find itself into the standard in 3 years). It has much more exposure to a much bigger and more diverse community before it hits a major version than the standard gets. > You gave zero reasons Just to provide the full paragraph: > And thus far, that best tool is fmt. The syntax is cleaner, it’s more configurable without horrible side effects, the resulting operations are more efficient, and as a project it is still being actively improved over time. Configurability: check No horrible side effects: check Resulting operations are more efficient: check Under regular improvement: check Those are my reasons. If any “pro” work negates using good tools, then I pity it. I use a range of third party libraries in my work (no, not just hobby projects - and no, not a small project) and it is a major plus.