4 ms·

> I also find it difficult to rationalize third-party dependencies these days I would love a deeper insight into what you mean by this. I can't imagine you're

> I also find it difficult to rationalize third-party dependencies these days I would love a deeper insight into what you mean by this. I can't imagine you're rolling your own http server, database communication layer (as in like, postgresql's jdbc driver), json parsing engine, etc.

throwaway290 2y ago
JSON parser, http server are provided by many runtimes and if a runtime does not provide something it provides primitives that make it often trivial to build
- lmz 2y ago
  I'm not saying it's impossible, but writing your own HTTP server ("trivial to build"?) to avoid bugs in other implementations doesn't sound like a good idea to me.
  - throwaway290 2y ago
    Read more carefully. We talk about "third-party dependencies" not about "other implementations". Using HTTP server from your runtime is not against the recommendation of avoiding third-party dependencies. Your runtime is usually not counted as "third-party dependency", normal runtimes don't have breaking changes every other moon (Even if you need to implement something like that from scratch it may be OK, your requirements don't need all of the functionality a third package includes because someone else needed it)
    - lmz 2y ago
      It's the "trivial to build" thing I have issues with - especially for the HTTP server. Not runtime vs third party.
  - rurban 2y ago
    I had to write one recently. One third page of code, multi-threaded. Really trivial, and no security nightmares as with overblown 3rdparty deps.
pdhborges 2y ago
Web dev context here. Just from the top of my head: django-constace breaks storage format with no built-in no downtime transition, django-modeltranslations, want to add translations to a heavily used field and you are using a database without transactional ddl good luck with that, django-importexport used a savepoint per row making it useless if you want to import csvs with a few thousand rows, requests doesn't officialy declare thread safety, I could go on and on ...
- graemep 2y ago
  Most of my work is Django and I think its fairly easy to keep dependencies low because Django is very batteries included. A good case where people use an unnecessary dependency is calling REST (or other http) APIs. If there is a wrapper, people tend to use the wrapper, which is not really needed if the in many/most cases. AT the most use something like requests which is what a lot of things use anyway. > django-importexport used a savepoint per row making it useless That is pretty crazy. It is also another example of something that is easily avoided.
perlgeek 2y ago
The original piece was on developing with a long-scale time horizon (10 years), so you could go with software that has been very stable over comparable time scales. For example, there are corners of the Perl ecosystem that have been really stable for a long time. Perl itself is very conservative with backwards-incompatible changes, and DBI, the module that abstracts away database interactions, has been around for a long time (the oldest changelog entry is from 1995, but that was for version 0.58, I'd be surprised if it weren't even older). Of course, then you don't get the fancy, modern libraries, but going with DBI plus DBD::Pg is probably more efficient than coding your own, and stable enough for a ten-year horizon. Another approach might be to move the really critical pieces of your software to a much simpler interface. For example, HTTP/2 looks much more complicated than HTTP/1.1, so your software might only implement (a subset of) a HTTP/1.1 server, and then you can use an off-the-shelf reverse proxy to expose it to the "modern" internet. This reverse proxy then is easier to replace, because it doesn't handle the core logic of your application. Or you go really old-school and use CGI, which is an even simpler interface than writing a HTTP server, and any HTTP server that implements CGI would do as a frontend.
- paulryanrogers 2y ago
  > Perl itself is very conservative with backwards-incompatible changes So much so that Perl 6 became a whole separate (doomed?) language after trying to change too much.

throwaway290 2y ago

JSON parser, http server are provided by many runtimes and if a runtime does not provide something it provides primitives that make it often trivial to build

lmz 2y ago
I'm not saying it's impossible, but writing your own HTTP server ("trivial to build"?) to avoid bugs in other implementations doesn't sound like a good idea to me.
- throwaway290 2y ago
  Read more carefully. We talk about "third-party dependencies" not about "other implementations". Using HTTP server from your runtime is not against the recommendation of avoiding third-party dependencies. Your runtime is usually not counted as "third-party dependency", normal runtimes don't have breaking changes every other moon (Even if you need to implement something like that from scratch it may be OK, your requirements don't need all of the functionality a third package includes because someone else needed it)
  - lmz 2y ago
    It's the "trivial to build" thing I have issues with - especially for the HTTP server. Not runtime vs third party.
- rurban 2y ago
  I had to write one recently. One third page of code, multi-threaded. Really trivial, and no security nightmares as with overblown 3rdparty deps.

pdhborges 2y ago

Web dev context here. Just from the top of my head: django-constace breaks storage format with no built-in no downtime transition, django-modeltranslations, want to add translations to a heavily used field and you are using a database without transactional ddl good luck with that, django-importexport used a savepoint per row making it useless if you want to import csvs with a few thousand rows, requests doesn't officialy declare thread safety, I could go on and on ...

graemep 2y ago
Most of my work is Django and I think its fairly easy to keep dependencies low because Django is very batteries included. A good case where people use an unnecessary dependency is calling REST (or other http) APIs. If there is a wrapper, people tend to use the wrapper, which is not really needed if the in many/most cases. AT the most use something like requests which is what a lot of things use anyway. > django-importexport used a savepoint per row making it useless That is pretty crazy. It is also another example of something that is easily avoided.

perlgeek 2y ago

The original piece was on developing with a long-scale time horizon (10 years), so you could go with software that has been very stable over comparable time scales. For example, there are corners of the Perl ecosystem that have been really stable for a long time. Perl itself is very conservative with backwards-incompatible changes, and DBI, the module that abstracts away database interactions, has been around for a long time (the oldest changelog entry is from 1995, but that was for version 0.58, I'd be surprised if it weren't even older). Of course, then you don't get the fancy, modern libraries, but going with DBI plus DBD::Pg is probably more efficient than coding your own, and stable enough for a ten-year horizon. Another approach might be to move the really critical pieces of your software to a much simpler interface. For example, HTTP/2 looks much more complicated than HTTP/1.1, so your software might only implement (a subset of) a HTTP/1.1 server, and then you can use an off-the-shelf reverse proxy to expose it to the "modern" internet. This reverse proxy then is easier to replace, because it doesn't handle the core logic of your application. Or you go really old-school and use CGI, which is an even simpler interface than writing a HTTP server, and any HTTP server that implements CGI would do as a frontend.

paulryanrogers 2y ago
> Perl itself is very conservative with backwards-incompatible changes So much so that Perl 6 became a whole separate (doomed?) language after trying to change too much.