t8sr

I’m really not a fan of the therapy speak and everyone trying to diagnose everyone. Historically, this kinda medicalization of everyone you disagree with has not led to good things.

Emphasis on global blocks. Meaning everywhere in the world.

I read the tweet twice and I don’t see any mention of free speech. What he’s describing, when you look past the rhetoric, sounds ridiculous: a single medium sized country is demanding power to institute global blocks of content on the internet? If that’s an accurate description, that’s deeply concerning for the long term viability of the internet.

Something about the way the author expresses himself (big words, “I am so smart”, flowery filler) makes me unsurprised he finds it hard to have satisfying conversations with people. If he talked to me like this IRL I wouldn’t be trying to have a deep conversation either, I’d just be looking for the exit.

Lacking a theory of mind for other people is not a sign of superiority.

Two things:

1. I basically agree with everything you say, I only think the limit should be ~50-100% higher. Not 10x, but 1.5-2x.

2. For some reason, concise writing is the hardest thing to teach and demand consistently. I think a part of is that people try to hide incompetence behind a word salad, but also I think non-native speakers use more words than they need. It gets to a point where you either have to become everyone's English teacher or accept some amount of word salad.

No, I think a reasonable limit is around 100 with the mode being around 80. 50 is not a reasonable limit for a commit message in English.

Yeah, I specifically think 50 is too short. I am a big fan of brevity, but I think the sweet spot is somewhere around 100. Consider that all of these messages exceed the 50-character limit:

  [startup] Don't drop uid until all controller fds are open
  [bpf] Fix the exec exchange hitting verifier limit on Fedora
  [controller] Optimize partial policy updates with delta

I agree on the value of concise writing and dislike word salads, but if you're a junior engineer, then I have maybe 1 hour with you per week and I probably shouldn't spend that time being your English teacher.

I've worked with 5 different SCMs and I'm convinced that the reason why git repos often have such poor commit messages is because of the git commit style guide. So much of it only makes sense once you realize it's been optimized for like 5 of its original users reading it on 72 character terminal screens.

Asking people to fit a meaningful description of the change into 50 characters is silly, and it's IMO the reason why so many of them just write "fix bug" and call it a day.

Someone else has posted the Google guide for CL (change list) messages, but let me boost the signal: https://google.github.io/eng-practices/review/developer/cl-d...

This is, I believe, still the best guide out there. When I'm coaching juniors, I recommend this guide, over the opinionated and outdated git "best practices" and I think the results are much better.

It surprises me how many people working as software engineers absolutely despise programming. Consider that if you must “grind” through leetcode questions, maybe you will be unhappy in the job itself. There are other roles, technical roles even, that don’t require algorithms. Why not pursue those?

My friend, it renders at 15 fps on a literal supercomputer. It takes 30 seconds to load. The time between clicking a button and something happening is measured in seconds. It may be successful, but it is not good.

The problem is that you’ve (and we all have) learned to accept absolute garbage. It’s clearly possible to do better, because smaller companies have managed to build well functioning software that exceeds the performance of Google’s slop by a factor of 50.

I’m not saying RETVRN to plain JS, but clearly the horrid performance of modern web apps has /something/ to do with the 2 frameworks they’re all built on.

Abstraction for its own sake, especially with js frameworks, doesn't make anything more readable or maintainable. React apps are some of the most spaghetti style software I've ever seen, and it takes like 10 steps to find the code actually implementing business logic.

The problem with React apologetics is that you need to only take a cursory look at literally every production app written in React to see it's terrible and must be abandoned in the long-term.

To see how fast a properly engineered app can be if it avoids using shitty js frameworks just look at fastmail. The comparison with gmail is almost comical: every UI element responds immediately, where gmail renders at 5 fps.

1. Your argument is about the grammar of a sentence about black holes on Wikipedia? This isn’t some kind of gotcha.

2. I missed the dwarf part, but think about what you’re arguing: the mass range of a loosely defined category (the lower bound of a few thousands is not one I’ve ever heard, btw) that has nothing to do with the paper in question. Collections of stars of any kind produce light. This doesn’t. What are you saying?

What do you think physicists do all day?

I’m admittedly a few years out of date in this, but weren’t those already kinda ruled out? I’ve never met anyone who took MOND seriously - it looks like it’s a pet project of a small number of people who cite each other, and people in different subfields have always been saying it doesn’t work for them (diffuse galaxies, etc.).

I know the current models favor cold DM, I thought the hot DM model was abandoned already when it became clear that clusters of any size exist?

Berlin’s tech industry is to Zurich and London as Berlin’s art scene is to New York or Paris.

And yes, Switzerland, but especially Zurich, is on another level compared to the rest of Europe. (Except maybe London.) I’ve been a hiring manager at multiple large tech companies: Europe in general has less tech talent than the US, but in London and Zurich you can fill any role, from kernel, through ML, computer vision, hardware, manufacturing, robots, quantum computing, etc.

I’ve done hiring in tech, and the availability of broad spectrum talent in Europe really only exists in London and Zurich. There are hubs for different fields, but only those two places have everything, IME.

Definitionally, yes. It’s inert but lenses light around it.

The paper is more about the technical achievement of detecting it, IIUC. It’s not the first dark matter inference we’ve had, and doesn’t really tell us anything new about the stuff.

(I’m an astrophysics undergrad.) Black holes aren’t composed of anything, they’re just defined by their charge, spin and mass equivalent.

Dust clouds have those mass ranges. It’s not a galaxy-scale mass by any measure.

This thread has a lot of CS people being confident about physics.

Name one other place on the continent that has:

1) At least token engineering presence by every major tech company

2) Tech-savvy VC, legal, audit and tax services you can get on a short notice

3) A pool of talent to fill any engineering position

4) A funnel from a big engineering university to the industry that generates startups

5) Tax authorities willing to work through complicated situations like acquihires, IP riders in contracts for a consideration in the form of stock, etc.

It’s much smaller than the Bay Area, of course, but it’s the only place in Europe that has everything you need in one spot. (Except maybe London, but that’s more like the New York of Europe, minus the high salaries.)

Also, “IT hub” is a place where salaries are low and you plop down a call center. IT are the support roles that install antivirus, not a profit center. There’s a huge difference between that and a “tech industry.”

Zurich and its environs are basically the Bay Area of Europe. Probably explains the huge concentration of HN users.

That’s a good point. I remember that in the earlier days of Go, there was a lot more optimism about the compiler’s future ability to statically decide more about the program than it currently does. It’s unfortunate that the language never got there.

Sadly, given Google’s new culture and all the people who have left, it seems unlikely it’ll ever get there.

I've taught programming to some people who had no previous experience with it, and I can tell you that the list of concepts you have to learn at once is basically as long for Python, the quintessential "beginner" language.

The author's argument feels intellectually dishonest for that reason. Especially glaring is the comparison to JavaScript. The latter has an insane amount of concepts to deal with to do anything, including some truly bizarre ones, like prototypes.

Rust is hard to learn, IMO, for precisely two reasons:

1) The borrow checker is in an uncomfortable place, where it's dumb enough that it rejects perfectly valid code, but smart enough that it's hard to understand how it works.

2) As the author points out, there are a lot of levers available for low-level control, precise allocation, etc.

With respect to the second point, the author describes a language he'd like to see: green threads, compiler deciding on allocation, fewer choices and easy thread safety.

This language already exists (minus algebraic types). It's called Go. It's perfectly fine, well-designed and good for beginners. Some people don't like its aesthetics, but that's not reason enough to invent it again, only with Rust-inspired syntax.

Yes, but there’s nuance. We each assume a version of events and nobody really knows. In my experience, big tech companies attract a certain type of person (among others) who will not only think of stuff like this, but actively fight for it and consequences to the long term be damned. VPs who actually approve this stuff will have limited time to think about it and a lot depends on the proposal.

This looks like a group PM level decision. Bluntly, at that level we get paid enough to exercise good judgement.

I have never said and rarely thought this before, but I really hope the person who came up with / approved this idea got fired for it. It’s rare that you see something so unbelievably stupid and destructive of the shared pool of trust, which Apple spent 30 years building, only for one self-interested PM to blow a chunk of it up for no gain.

If the person who came up with this reads this site, I hope they see this comment and think about how screwed the industry would be if everyone acted the way they did.

Any evidence you'd care to offer, or are you just being racist on the internet?

Would you rather work with (hire for your startup) someone who:

1) Always pleased middle management in a large bureaucracy by moving metrics, then bailed out just before the project collapsed

2) Ignored the noise, fixed real problems and left the project better than they found it?

After 20 years of tech career and 3 FAANGs, I know my answer. This article is decent enough advice for the first 5 years of your career, so you get some seniority and money.

Once you have those two things, what they give you is the agency and the safety to walk away from bullshit.

After that the game changes: it's about credibility and being sought after by your peers, who, at this point, should also hold senior IC positions at companies whose help you need, sit on standards committees, have maintainer rights in the Kernel, etc.

Your long-term professional success will come from being an excellent technical peer, rather than pleasing random middle managers you will never work with again. Your personal job satisfaction will come from honing your craft and solving real problems for real customers, not from hitting some arbitrary business milestones. (Obviously those two things sometimes align, but if you're forced to make a choice.)

I don't like mechanistic explanations of particle physics - they're an attempt to relate what's going on to our macroscopic experience, but they usually fall apart when you look too closely.

I find it much easier to understand the stability of hydrogen by thinking about ground states. If the electron in H could merge with the proton, they'd make a neutron. But a free neutron is not stable and decays in a few minutes back into a proton, electron and an antineutrino.

With very large, proton-rich nuclei, eventually you get to the opposite situation where the ground state is one less proton, one less electron and one more neutron and the atom decays into that state by, you guessed it, an electron "falling into" the nucleus.

Yes and my yoga teacher has an even better theory where the electrons are stopped from falling in by spirits of their time-traveling ancestors.

Directly imaging an exoplanet has been done about 20 times (maybe more, by now). If you're asking how far are we from resolving an exoplanet to more than a single point of light, the answer is we will never be able to do that from this distance.

When I did my 20% on Go at Google, about 10 years ago, we already had a semi-formal rule that channels must not appear in exported function signatures. It turns out that using CSP in any large, complex codebase is asking for trouble, and that this is true even about projects where members of the core Go team did the CSP.

If you take enough steps back and really think about it, the only synchronization primitive that exists is a futex (and maybe atomics). Everything else is an abstraction of some kind. If you're really determined, you can build anything out of anything. That doesn't mean it's always a good idea.

Looking back, I'd say channels are far superior to condition variables as a synchronized cross-thread communication mechanism - when I use them these days, it's mostly for that. Locks (mutexes) are really performant and easy to understand and generally better for mutual exclusion. (It's in the name!)