▲ | BobbyTables2 6 days ago | ||||||||||||||||
Fully agree. So many people are so drunk on the kool aid, I often wonder if I’m the weirdo for not wanting dozens of third party libraries just to build a simple HTTP client for a simple internal REST api. (No I don’t want tokio, Unicode, multipart forms, SSL, web sockets, …). At least Rust has “features”. With pip and such, avoiding the kitchen sink is not an option. I also find anything not extensively used has bugs or missing features I need. It’s easier to fork/replace a lot of simple dependencies than hope the maintainer merges my PR on a timeline convenient for my work. | |||||||||||||||||
▲ | WD-42 5 days ago | parent | next [-] | ||||||||||||||||
If you don’t want Tokio I have bad news for you. Rust doesn’t ship an asynchronous runtime. So you’ll need something if you want to run async. | |||||||||||||||||
▲ | chasd00 5 days ago | parent | prev | next [-] | ||||||||||||||||
For this specific case an llm may be a good option. You know what you want and could do it yourself but who wants to type it all out? An llm could generate an http client from the socket level on up and it would be straightforward to verify. "Create an http client in $language with basic support for GET and POST requests and outputs the response to STDOUT without any third party libraries. after processing command line arguments the first step should be opening a TCP socket". That should get you pretty far. | |||||||||||||||||
| |||||||||||||||||
▲ | bethekidyouwant 5 days ago | parent | prev | next [-] | ||||||||||||||||
Just use your fork until they merge your MR? | |||||||||||||||||
▲ | 3036e4 5 days ago | parent | prev [-] | ||||||||||||||||
There is only one Rust application (server) I use enough that I try to keep up and rebuild it from the latest release every now and then. Most of the time new releases mostly bump versions of some of the 200 or so dependencies. I have no idea how I, or the server code's maintainers, can have any clue what exactly is brought in with each release. How many upgrades times 200 projects before there is a near 100% chance of something bad being included? The ideal number of both dependencies and releases are zero. That is the only way to know nothing bad was added. Sadly much software seems to push for MORE, not fewer, of both. Languages and libraries keep changing their APIs , forcing cascades of unnecessary changes to everything. It's like we want supply chain attacks to hurt as much as possible. | |||||||||||||||||
|