hn_acc_2's comments

I prefer this to having app.use / router.use scattered anywhere throughout the app init (i.e. Express)

Success is a lousy teacher. Mr. Musk has been dreaming about his "everything app" i.e. X.com for a very long time. The fact that he thinks the sinking Twitter ship will bring it to fruition is laughable.

Looks like the top comment was spot on. Were HN users the "Avengers" mentioned in OP?

There are a limited number of people willing to spend a limited amount of time fuzzing, reviewing, and scrutinizing crypto libraries. The more libraries exist, the more their efforts are divided, and the total scrutiny each library receives decreases. How would this help the problem?

Actually, among the MAGMA companies I've found the _least_ bias for leetcode-memorization at Amazon.

My interview with Meta was exactly as you described (a CS riddle taken from a textbook, to be solved without running the code or receiving hints). But in my interview with Amazon, each coding interview also included a couple leadership questions. If you want you can look up the exact questions that they'll give you to test what they call their "Leadership Principles"

Also the Amazon coding questions were not taken directly from Leetcode, and were easily reasoned out without prior knowledge of a special algorithm.

Obviously this is true but CK doesn't sell dollar bills for 90 cents.

Yes..... and the only way a $444M quarterly revenue company "aren't profitable at all" is if their costs are >$444M / quarter. That's what my comment was getting at. Does GP really think a business like CK costs that much to run?

Your guess is wrong, their Q2 revenue this year was reported $444M

Having seen several projects written by people who "happen to know some code," I can tell you there's a good reason this hasn't caught on.

These sort of people can work the very foundations of the company into an ungodly quagmire that would send you screaming back to the fad-chaser dev in a heartbeat.

Also despite the meme, most mid-senior devs are actually keen on making their contributions valuable to the business, having gotten over this phase of fascination with new tools

The difference will be painfully clear once you try to walk a junior developer through installing and linking new files to a large project in Visual Studio, vs "copy this .h file here and include it".

Whether or not a "good build system" should handle it, the fact that single-file libraries are much preferred these days should demonstrate most people don't have such a build system

1) Include it wherever it's used. The convention is to use the preprocessor[1] so it only appears once in the final binary

2) Most developers just want to compile to a single binary. Any developer who for some reason needs separately compiled objects should be able to quickly achieve that from a single-file library

[1] https://github.com/phoboslab/qoi/blob/324c2243b2fb35f741a88d...

There is a stigma amongst "real programmers" against "web developers". So a "real programmer" will never become adept at CSS because it doesn't appeal to their ego

Sure, high salaries are justified for this minority.

The people mentioned specifically in the comment are of more concern; sales, admin, etc. salaries in this field are also inflated compared to other industries.

What other packages have you seen abusing import side effects?

Shopify is the first one I've seen, so I don't think it's quite as common as you are implying, but I'm curious to know what other bad behavior you have found

What "moat" does Bitcoin have protecting it from other crypto which may have more attractive features?

It seems to me that it's just the first one that everyone's grandma has heard the name of.

Some journalists will say BTC is just the "most stable" but the fact that it has the most miners is just a consequence of the high price, not the other way around.

As for the technology, what is actually maintaining BTC dominance in the crypto world other than general first mover sentiment?

Unfortunately the Python package ecosystem is enough of a headache.

Now we add additional complication "OK, these pip package authors have upstreamed Alpine packages, and these other ones are only on PyPi".

Maybe this approach would work if you can keep your Python dependencies to a small list of well-maintained packages

If you ask me, installing glibc / compat layers defeats the purpose of using Alpine, especially since Alpine ultimately only saved me ~50 MB on image size versus a similarly configured debian:slim-buster image

I did settle on Debian, using i.e. python:3.9-slim-buster (though you can just as easily start from debian and install your python version)

Another "I want to love Alpine but can't" user here.

Their use of musl libc makes it a very poor choice for running python in a container, because it forces a lot of manual rebuilding since the PyPi wheels don't work on Alpine, among other issues [1]

[1] https://pythonspeed.com/articles/alpine-docker-python/

Thanks, that makes sense. The computer terms helped :)