←back to thread

277 points amazonhut | 1 comments | | HN request time: 0.198s | source
Show context
untrimmed ◴[] No.45248154[source]
As someone who has spent days wrestling with Python dependency hell just to get a model running, a simple cargo run feels like a dream. But I'm wondering, what was the most painful part of NOT having a framework? I'm betting my coffee money it was debugging the backpropagation logic.
replies(5): >>45248223 #>>45248315 #>>45248416 #>>45248640 #>>45248972 #
taminka ◴[] No.45248223[source]
lowkey ppl who praise cargo seem to have no idea of the tradeoffs involved in dependency management

the difficulty of including a dependency should be proportional to the risk you're taking on, meaning it shouldn't be as difficult as it in, say, C where every other library is continually reinventing the same 5 utilities, but also not as easy as it is with npm or cargo, because you get insane dependency clutter, and all the related issues like security, build times, etc

how good a build system isn't equivalent of how easy it is include a dependency, while modern languages should have a consistent build system, but having a centralised package repository that anyone freely pull to/from, and having those dependencies freely take on any number of other dependencies is a bad way to handle dependencies

replies(8): >>45248396 #>>45248405 #>>45248468 #>>45248509 #>>45248523 #>>45248580 #>>45249844 #>>45250869 #
1. hobofan ◴[] No.45249844[source]
> but having a centralised package repository that anyone freely pull to/from, and having those dependencies freely take on any number of other dependencies is a bad way to handle dependencies

So put a slim layer of enforcement to enact those policies on top? Who's stopping you from doing that?