I always thought of Docker as a "fuck it" solution. It's the epitomy of giving up. Instead of some department at a company releasing a libinference.so.3 and a libinference-3.0.0.x86_64.deb they ship some docker image that does inference and call it a microservice. They write that they launched, get a positive performance review, get promoted, and the Docker containers continue to multiply.

Python package management is a disaster. There should be ways of having multiple versions of a package coexist in /usr/lib/python, nicely organized by package name and version number, and import the exact version your script wants, without containerizing everything.

Electron applications are the other type of "fuck it" solution. There should be ways of writing good-looking native apps in JavaScript without actually embedding a full browser. JavaScript is actually a nice language to write front-ends in.

▲ catlifeonmars 13 hours ago | parent | next [-]

> Python package management is a disaster. There should be ways of having multiple versions of a package coexist in /usr/lib/python, nicely organized by package name and version number, and import the exact version your script wants, without containerizing everything.

Have you tried uv?

	▲	dheera 12 hours ago \| parent [-]
		Well sure, every language has some band-aid. The real solution should have been Python itself supporting: `import torch==2.9.1` Instead of a bunch of other useless crap additions to the language, this should have been a priority, along with the ability for multiple versions to coexist in PYTHON_PATH.

▲ soulofmischief 16 hours ago | parent | prev | next [-]

There is a vast amount of complexity involved in rolling things from scratch today in this fractured ecosystem and providing the same experience for everyone.

Sometimes, the reduction of development friction is the only reason a product ends up in your hands.

I say this as someone whose professional toolkit includes Docker, Python and Electron; Not necessarily tools of choice, but I'm one guy trying to build a lot of things and life is short. This is not a free lunch and the optimizer within me screams out whenever performance is left on the table, but everything is a tradeoff. And I'm always looking for better tools, and keep my eyes on projects such as Tauri.

▲ ahepp 14 hours ago | parent | prev | next [-]

I think there's merit to your criticisms of the way docker is used, but it also seems like it provides substantial benefits for application developers. They don't need to beg OS maintainers to update the package, and they don't need to maintain builds for different (OS, version) targets any more.

They can just say "here's the source code, here's a container where it works, the rest is the OS maintainer's job, and if Debian users running 10 year old software bug me I'm just gonna tell them to use the container"

	▲	dheera 13 hours ago \| parent [-]
		Yeah I'm not against Docker in its entirety. I think it is good for development purposes to emulate multiple different environments and test things inside them, just not as a way to ship stuff.

▲ nineteen999 16 hours ago | parent | prev | next [-]

Agree on all fronts. The advent of Dockerfiles as a poor mans packaging system and the per-language package managers has set the industry back several years in some areas IMHO.

▲

catlifeonmars 13 hours ago | parent [-]

> and the per-language package managers has set the industry back several years in some areas IMHO

Curious, can you expand on this?

	▲	nineteen999 4 hours ago \| parent [-]
		Python has what, half a dozen mostly incompatible package managers? Node? Ruby? All because they're too lazy, inexperienced or stubborn to write or automate RPM spec files, and/or Debian rules files. To be fair, the UNIX wars probably inspired this in the first place - outside of SVR4 deriviatives, most commercial UNIX systems (HP-UX, AIX, Tru64) had their own packaging format. Even the gratis BSD systems all have their own variants of the same packaging system. This was the one thing that AT&T and Sun Solaris got right. Linux distros merely followed suit at the time - Redhat with RPM, Debian with DEB, and then Slackware and half a dozen other systems - thankfully we seem to have coalesced on RPM, DEB, Flatpak, Snap, Appimage etc... but yeah that's before you get to the language specific package management. It's a right mess, carried over from 90's UNIX "NIH" syndrome.

▲ fragmede 12 hours ago | parent | prev [-]

> JavaScript is actually a nice language to write front-ends in.

I've written my fair share of GUIs, and React (and thus Javascript) is great compared to, I don't know, PHP, but CSS is the absolute devil.

	▲	11 hours ago \| parent [-]
		[deleted]