I’d say it’s even worse than that. The examples from the post are quite responsible usages of the feature.
For serde, as noted in the footnote, the actual public API are functions like serde_json::to_string or bincode::serialize. You only interact with the trait directly when you implement new instances: the trait is an interface for extension, not an interface for usage.
rayon, and, to a lesser extent, byteorder want to augment standard library types, and they count as ubiquitous crates one just knows about. They add to ecosystem’s learning curve, but generally are not a hindrance during day-to-day development. byteorder also has this cute trick where you spell LittleEndian explicitly at the call site, so I’d even argue it’s still greppable.
But I often (more often?) see less defensible usages of extension traits:
a library exposes interface to its own types via traits
a library extends std types, but it isn’t quite as ubiquitous as rayon
an application uses extensions traits for internal types simply because some types aligned somewhere, and something could be pulled into a trait.
Would ‘grepability’ be solved by having the source code of direct dependencies downloaded to a subfolder of the project. Almost a decade ago when I used to code in Java, maven would download the source code of all the dependencies and it was trivial to search through them if I needed to. I have not messed with Rust yet and so I am wondering if crate has similar capabilities?
As a C# programmer who’s dealt with extension methods for years - my experience has been that they are on balance a useful feature.
I wouldn’t write any language without an IDE these days. VS Code if I’m broke or JetBrains if I’m rich. It’s great that all the language servers exist now, happy days.
I like articles like this one that make one think, and I think greppability is a useful and valid metric when considering code, but one that can be considered as a trade-off with other aspects and considered in the perspective of real developer workflows for the code at hand.
I’d actually like to know how their workflow is. I understand that extension traits may be annoying and that being able to grep for stuff can be nice very nice when being mobile, looking through some code (though github already has IDE lookup integration for many languages). But ultimately hovering over functions and structs, clicking on “go to definition” and “show source” using rust analyzer, or displaying the docs for that struct/type/function isn’t a thing of convenience, it’s a must have which saves a ton of time. It’s like hyperlinks in html, hover summaries in wikipedia or timestamps in videos. Sure you can just google for that word or go to the footnote that contains the actual link. But why do that if you can actually use direct links, have it all in one place and save a ton of time.
I’d say it’s even worse than that. The examples from the post are quite responsible usages of the feature.
For serde, as noted in the footnote, the actual public API are functions like
serde_json::to_stringorbincode::serialize. You only interact with the trait directly when you implement new instances: the trait is an interface for extension, not an interface for usage.rayon, and, to a lesser extent,byteorderwant to augment standard library types, and they count as ubiquitous crates one just knows about. They add to ecosystem’s learning curve, but generally are not a hindrance during day-to-day development.byteorderalso has this cute trick where you spellLittleEndianexplicitly at the call site, so I’d even argue it’s still greppable.But I often (more often?) see less defensible usages of extension traits:
My go-to tool for searching for defs without any IDE tools, is
cargo doc --open, for two reasons:Works a lot better than googling.
Would ‘grepability’ be solved by having the source code of direct dependencies downloaded to a subfolder of the project. Almost a decade ago when I used to code in Java, maven would download the source code of all the dependencies and it was trivial to search through them if I needed to. I have not messed with Rust yet and so I am wondering if crate has similar capabilities?
cargo vendoris what you want for downloading dependency sources.As a C# programmer who’s dealt with extension methods for years - my experience has been that they are on balance a useful feature.
I wouldn’t write any language without an IDE these days. VS Code if I’m broke or JetBrains if I’m rich. It’s great that all the language servers exist now, happy days.
I like articles like this one that make one think, and I think greppability is a useful and valid metric when considering code, but one that can be considered as a trade-off with other aspects and considered in the perspective of real developer workflows for the code at hand.
Eli is indeed stuck in the past.
I’d actually like to know how their workflow is. I understand that extension traits may be annoying and that being able to grep for stuff can be nice very nice when being mobile, looking through some code (though github already has IDE lookup integration for many languages). But ultimately hovering over functions and structs, clicking on “go to definition” and “show source” using rust analyzer, or displaying the docs for that struct/type/function isn’t a thing of convenience, it’s a must have which saves a ton of time. It’s like hyperlinks in html, hover summaries in wikipedia or timestamps in videos. Sure you can just google for that word or go to the footnote that contains the actual link. But why do that if you can actually use direct links, have it all in one place and save a ton of time.