Our great sponsors
-
> Cannot make a type in a foreign package implement an interface
I would only push back on this point, and this point alone. Sure, it would be very convenient for me, an author to be able to just extend the implementation of anything that I import. However, when I am not an author and am instead a reader of code, doing this is the number-one way to causally make code totally unreadable. By allowing anyone to extend a type anywhere, it makes it impossible to just read the code. If the package that declares a type is the sole controller of that type, then reading code is easier.
"Where is the definition of this method?" Answer: It's next to everything else for that type, in package where that type is defined. However, if anyone can extend any other type, figuring out what methods even exist for a type becomes so difficult that you are forced to use a language-server (with all related dependencies installed) in order to use "go-to-definition". If someone wants to understand the code, requiring them to have a full-fledged IDE and/or development environment is pretty awful and quite onerous, and makes codebases tough to get into.
For example, take this line[0] from a tutorial[1] on creating a simple snake game using the Bevvy engine in Rust. The main() function wires up loads of entities, including a `snake_eating()` function. But it also calls a mysterious `.after()` method of the snake_eating() function. If you do a ctrl-f on the file, you won't find an .after() method defined for the function snake_eating(). Just reading the code in that file, the only file in the program, you'll never find what the `.after()` method does or where it comes from. Only by opening that code in an IDE with go-to-definition will you learn that it's set via an automatic macro in the bevvy library[2] which causes all functions of certain signatures to implement the System trait. Which... is pretty tough to get into, and means just reading code without computer aid is effectively impossible.
In your languages, please don't allow packages to extend the interfaces/traits/types of other packages.
[0] - https://github.com/marcusbuffett/bevy_snake/blob/0.7/src/mai...
-
> Cannot make a type in a foreign package implement an interface
I would only push back on this point, and this point alone. Sure, it would be very convenient for me, an author to be able to just extend the implementation of anything that I import. However, when I am not an author and am instead a reader of code, doing this is the number-one way to causally make code totally unreadable. By allowing anyone to extend a type anywhere, it makes it impossible to just read the code. If the package that declares a type is the sole controller of that type, then reading code is easier.
"Where is the definition of this method?" Answer: It's next to everything else for that type, in package where that type is defined. However, if anyone can extend any other type, figuring out what methods even exist for a type becomes so difficult that you are forced to use a language-server (with all related dependencies installed) in order to use "go-to-definition". If someone wants to understand the code, requiring them to have a full-fledged IDE and/or development environment is pretty awful and quite onerous, and makes codebases tough to get into.
For example, take this line[0] from a tutorial[1] on creating a simple snake game using the Bevvy engine in Rust. The main() function wires up loads of entities, including a `snake_eating()` function. But it also calls a mysterious `.after()` method of the snake_eating() function. If you do a ctrl-f on the file, you won't find an .after() method defined for the function snake_eating(). Just reading the code in that file, the only file in the program, you'll never find what the `.after()` method does or where it comes from. Only by opening that code in an IDE with go-to-definition will you learn that it's set via an automatic macro in the bevvy library[2] which causes all functions of certain signatures to implement the System trait. Which... is pretty tough to get into, and means just reading code without computer aid is effectively impossible.
In your languages, please don't allow packages to extend the interfaces/traits/types of other packages.
[0] - https://github.com/marcusbuffett/bevy_snake/blob/0.7/src/mai...
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
azure-sdk-for-rust
This repository is for active development of the *unofficial* Azure SDK for Rust. This repository is *not* supported by the Azure SDK team.
FWIW, AWS now have an official SDK for Rust in beta:
https://aws.amazon.com/sdk-for-rust/
There are people at Microsoft working on a Rust SDK for Azure, but it's explicitly a volunteer effort at the moment:
https://github.com/Azure/azure-sdk-for-rust
These days I probably would not look at any language that did not have SDKs for AWS and Azure, for similar reasons.
