tail_exchange

A few reasons for me:

- Rude and antagonistic moderation.

- Closing topics too aggressively. Very often in favour of topics that are too old, no longer relevant, or don't fully address the question.

- Ignoring the constraints of the asker. For example, asking how do I do X with Y framework, and having someone telling you to switch to B framework instead. Even worse when it's a mod hellbent on shutting you down for not being able to change your constraints.

Reddit, in all its chaos, seems to be faring better at being a support community than SO.

Signal is also a lot smaller. Telegram has over 1B users, while Signal has 40M. These optics could just be a product of the size of the user base.

This would imply that just E2EEing everything would give you a free pass not to moderate anything, which seems very naive. I doubt the judges would care about their self-imposed technological limitations.

E2EE is optional. Telegram does have it, but you don't need to use it.

I'm genuinely curious to what would happen with Signal if the same bad actors moved to their platform. Would France also be arresting its creators for not properly moderating and giving backdoors?

IntelliJ is also supported. If you want to use something else, like VIM, then you need to ssh into the remote devbox machine. They have support for custom dotfiles, so you can set up your cool VIM environment for all your remote devboxes.

If you don't want remote devboxes, the regular devboxes still work. You just need to deal with the additional pain for syncing the files.

That's a good read. Thanks for sharing.

> took almost 15minutes to correctly switch branches on intel machines

This can probably be fixed with trivial tuning. Just configuring Git to fetch only your branches would speed up the branch switching significantly.

> build and test are soul sucking experiences

Why? It doesn't have to be. If you are going to build the entire monorepo, then yes, but this should only happen when you are running CI, and even then you can break down the builds into smaller components.

> the whole MR becomes a nightmare to correctly review

Not if you set up code ownership properly. You also need to think what happens in case of emergencies, so having a selected list of "super users" and users with permissions to bypass reviews is important.

It sounds like this company wanted a monorepo, but nobody invested any money or time to actually think about developer productivity. When this happens, yes, of course it won't be good, because no project succeeds like this. The nice thing about a monorepo is that instead of 1,000 repos with tooling all over the place and no specialist to take care of them, you can have one repo with really good tooling and a team dedicated to just keep it running smoothly. But if nobody is actually taking care of the monorepo, it will rot just like any other codebase.

Why is that?

Not the full story. You are omitting the fact that Bolsonaro made several allegations of voter fraud on social media, and Brazil had their own version of January 6th after he lost (what you called "at best rioters"). These decisions are a response to those events, but your post paints him as a blameless victim.

> politics won't change a single thing about my life which couldn't be changed through more hard work

Maybe that is true for you, but this is not true for minorities and people who are fighting for a cause (abortion and trans rights, for example). Not being willing to cast a vote because it doesn't change anything for you doesn't seem like a virtue.

But how else would they stamp an AI label to their product? Bolt a chatbot onto it, say you are AI-powered, and profit!

Because you are attributing things that are common in enterprise environments (Bazel, monorepos, and Protobufs) to Go. It's fine if you hate these things, but saying that these are the defaults of Go isn't right, and I bet that's why people are hating on you. There's nothing default about them in Go. If you work with enterprise-y code, it shouldn't be surprising that a lot of them are going to follow Google's steps.

Bazel is not a Go default either. You can get very far just by using the default Go Modules, and this is much more common than repos using Bazel.

Throw some Makefiles and shell scripts in the mix, if that's your thing, and that's perfectly fine.

You may be right, but I think this is a mistake that native speakers are more likely to make. This is just anecdotal, so don't take me too seriously...

Mistakes like "your" instead of "you're" and "should of" instead of "should have" seem to be very common for people who learned english by listening instead of reding (native speakers). The words sound the same, so they get switched.

On the other hand, as a non-native, I struggle with phrasal verbs, such as "get in" vs "get on", "get out" vs "get off", and so on. These may be very different concepts in English, but not for my native language, so I don't always choose the correct one.

I didn't consider the usage of ResourceBundle. It does make a lot more sense now!

This is interesting. I had no idea MessageFormat even existed. It seems very powerful, but I'm not sure I like the example for pluralization.

  String pattern = "There {0,choice,0#are no files|1#is one file|1<are {0,number,integer} files} on your desktop.";

Maybe I'm just not used to it, but this seems pretty error prone.

Looks cleaner and simpler. I like this pattern!

Jokes aside, the level of discourse on HN is miles ahead places like Reddit and Twitter. HN's comment section is fantastic compared to them.

How is this relevant? I didn't say we should allow smoking everywhere, or that smokers don't need to exercise basic courtesy when they are around non-smokers. I said it's not my business whether someone else decides to be a smoker or not.

I don't really care what people do with their lungs, so whether they want to smoke or not, that's their problem. That being said, I definitely have an issue with smokers who think it's ok to throw cigarette butts on the ground. It's crazy how we still allow non-biodegradable cigarette filters to exist.

Another commenter said that this change was a malformed configuration that crashed the application. If this is the case, you wouldn't need days to see this problem manifest, but only a few minutes. If they had rolled it out to 1% of their customers and waited for a couple hours before releasing it everywhere, they probably would have caught it.

Can someone who actually understands what CrowdStrike does explain to me why on earth they don't have some kind of gradual rollout for changes? It seems like their updates go out everywhere all at once, and this sounds absolutely insane for a company at this scale.

Real estate is about 13% of Canada's GDP[1]. It's considerable, but hardly "wholly dependant". This number is very similar to the US.

[1] https://en.wikipedia.org/wiki/Economy_of_Canada

If you use short-lived branches and every PR is one indivisible unit that represents a change, then it will always end up as a single commit anyways. When this is the case, there's no point enforcing a high commig quality - just squashing them will produce the same end-result.

Other people will suggest SQLite and Postgres, so I'll go for something less conventional...

If you are using GCP or AWS, take a look at Firestore and Dynamo. They are fully managed (no maintenance for you), reliable, fast, cheap, scalable, and easy to use. Despite being designed for heavy-duty usage, they work perfectly as a simple key-value store.

I use Firestore for all my personal projects, and I only pay a couple dollars per month.

My experience has been the opposite. Every organization I worked at used Trunk based development (feature branch->master). Because branches are short lived and usually small, they are the atomic representation of a change, and not the commits in the pull request. Pull requests usually have lots of "linting", "fixing test", "fixing typo" commits that I absolutely do not want in my master branch.

I understand that not all organizations work like this, but that is my point: there is nuance. Blanket statements like these are not productive. The author seems frustrated that people still use squash merge, and just assumes that it's because people just don't understand how git works.

Just yesterday I went to a coffee shop that had a big sign saying they didn't accept cash. Seems to become more common as time passes.

Oh, but how I miss those days... The repeating gif background, using transparent images to separate table cells, the MS FrontPage or Flash menu buttons, the comic sans, the colored scrollbars, the marquees, scrolling status on the bottom of IE, the image links on the bottom of the page for "home" and "contact, the page view counter, JS alerts with welcome messages, and of course the huge collection of fugly gifs with the dancing banana... So nostalgic.

Another thing that we didn't have back in the day was platforms. Nowadays, if you want a page, you either make an account on facebook, squarespace, shopify, etc. Back then there was no such thing, so you needed to learn html and build your website yourself.

Indeed, I mentioned it in my comment. Thanks.