Hacker Newsnew | past | comments | ask | show | jobs | submit | wizhi's commentslogin

Servers taking advantage of the tendency for Americans to tip shouldn't be conflated with anyone else traveling to the US.


Python package documentation is abysmal. It tends to read like a novel and yet still only covers surface layer details with simplistic examples. It's next to impossible to just "get an overview" of what's available: just show me the modules, classes, functions, etc. Don't make me spend 30 minutes trying to find an explanation for that one function which just takes a kwargs, which ends up only being covered in thr footnote of some random page in the documentation on something otherwise completely unrelated.

It's madness.


Man, if anything you sound like a pretty shit coworker.


What's a concrete example of "concurrency power" here?


You can make a list of guarantees that concurrency primitives provide. You have to get down into the details, ranging from "memory barriers that guarantee all previous operations have completed", which is really quite a weak guarantee, up through things like "no more than one thing can have this lock at a time", which is the sort of thing that a moderately experienced person might already have considered to be one of the weakest guarantees but there's quite a few "memory barriers" that are significantly weaker, up through things like the channel's guarantee of "if you pass the send operation you are guaranteed that some other goroutine has already picked this up", and finally, proceeding upwards to something like a distributed lock's "you are guaranteed to be the only thing holding this lock across the entire cluster", which is very expensive. And this is still only a very-coarse-grained summary of the sorts of concurrency primitives there are.

The easiest one to see is the distributed versus non-distributed versions of locks as they are so dramatically different and so obviously different in expense, but the principle extends all the way down to even different sorts of memory barriers with different guarantees having different costs.

When each of these are optimized to within an inch of their life, as they typically are, including all the way down to the hardware level, stepping up to a higher guarantee level is never free.


I've been there, being forced to use it for work..

I tried both Yabai and Amethyst and, frankly, neither provide a clean experience.

Yabai requires disabling some OS security feature iirc, which may or may not be an issue for you. I seem to recall having issues with it, and switching to Amethyst pretty soon after. It might also only support BSP layout, which I dislike - stacks all the way.

Amethyst feels a little half baked. It works well enough, but configuration is through a GUI and saved in some non text format, making it not difficult friendly. It also doesn't support things like moving windows between workspaces, meaning you need to have additional bindings for that through the MacOS command center or whatever it's called.

Overall, I managed with Amethyst for close to 2 years, so that's the one I'd recommend of the two. Luckily I'm back on a Linux machine and can use river now. :)

Good luck!


> It also doesn't support things like moving windows between workspaces

It's been a while since I used Amethyst as the Mac is now on complete corporate lockdown, but I remember that being the biggest feature I used on Amethyst. MacOS doesn't support it, but Amethyst did.


I lost my Amethyst due to corporate lockdown rebuild a few weeks ago. MacOS window management is obnoxious without it and I'm much less productive due to losing my tools.


I am likely misremembering, and mixing it was something else! There definitely was something vital I wasn't able to do through just Amethyst though.


I can recommend Runbox. It's a paid service, but I really think that's for the better.


The exact same as if npm did it.


But this can literally just be done in a simple shell script as well. The makefile ends up just being a redundant way to run a shell script.


> But this can literally just be done in a simple shell script as well.

Only if there's no dependencies. It's unusual that GP's type of usage has no dependencies.


When my shell scripts depend on another script ... they run the other script. Make definitely has its place, especially when dependencies get complex and parallel, but it's hardly necessary for simple cases. Once Make is needed, it's trivial to drop in and have it wrap the standalone scripts.


> When my shell scripts depend on another script ... they run the other script.

I hear you, but you're running the other script unconditionally. If it downloads something, it will download it every time you run the first script.

In this simple case, make runs the other script conditionally, so it need not run every time.


I build .tf files from parameters for each host in the Makefile (and script which knows the vSphere topology) for one-shot execution (it only creates the VM, it doesn’t manage the lifecycle) and also template config that needs to be done before deployment - there are plenty of dependencies


Vendor support.

Shipping with Linux is a good indicator that it's Linux compatible. Buying computers with Linux is also a way of voting for Linux compatibility - even if you reinstall your preferred distro afterwards.


How would me answering how I once "reacted to xyz" make me any more likely to "put the extra neurons in"?


Those types of questions are likely to engage "problem solvers", aka people who don't just wait to be told what to do, but who actually demonstrated proactive critical thinking by reacting to a challenge. Those types of people are more likely to put extra neurons in for future problems (contrary to stock markets, past performance is actually a strong indicator of future success, when it comes to hiring).

If you don't have any scenarios from your work experience where you can demonstrate being a "problem solver" who reacts to stuff, then you probably aren't someone to likes to fire up the extra neurons, and hence wouldn't be a fit for the parent comment's desired team/org profile.


Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: