Hacker News new | past | comments | ask | show | jobs | submit | uyt's comments login

As a tech worker with little knowledge about china, the most interesting section for me starts at "A summer storm" where he talks about why/how the government is cracking down on big consumer tech.


Seems like he didn't have time to finish Advent of Code this year. I was looking forward to seeing his code for some of the puzzles I struggled with!

While there are plenty of other solutions and discussions in the megathreads for each day: https://www.reddit.com/r/adventofcode/wiki/solution_megathre...

It is mostly dominated by competitive programmers who value speed over readability. When it comes to presenting a solution, Peter Norvig's style, clarity and craftsmanship is unmatched.


Same, and it made me feel less guilty about myself for abandoning AoC for a second year (after 17 days in 2019 and 19 days this year). It becomes just too time consuming after around 17-18 days since I am not a genius.


Beware that many masters programs from top schools are degree mills and the undergrads who went there know this and actively loathe them (based on their experience sharing classes with them). At least for my particular school. I remember helping out with resume screening at a job fair and we would sort everyone who went to that masters program to the bottom of the pile. A handful of them turned out to be good candidates on second pass, but it sucks that they probably would've had a better chance just leaving off their masters.


> Beware that many masters programs from top schools are degree mills and the undergrads who went there know this and actively loathe them (based on their experience sharing classes with them).

Thank you for mentioning this. So many people don’t realize that masters programs can be fairly worthless even from elite schools.



I think people who are graduating now will have a hard time replicating this. My cohort (now in our early 30s, cs majors from a top school) were incredibly lucky because we were in a permanent bull run so as long as we were invested in almost any tech stock, we did well. Almost all of us hit one million mark before early 2020 and that became 2 million at the end of 2021.

I would love for this to continue forever but can it really? For example the author (and my friends) are in similar situation where their compensation are now in the ~500k range but that number is based on the stock value at the time of offer. It is now essentially double that. So we're in a situation where your everyday senior FAANG engineers are locked in a golden handcuff unless they are offered million dollar packages to jump ship.

We're in weird times.


Golden handcuffs are a good thing. It's such a first world problem to complain about golden handcuffs. "Oh no, I'm making $300k/yr over my nominal market value!"


The golden handcuffs are only handcuffs if you’re in a terrible environment. I’ve walked away from a 7-figure TC. Handcuffs be damned. I wasn’t going to take the abuse anymore.

Some people don’t have the strength to walk away and instead will obsess over money for anything. It’s funny how I’m sure people would require much bigger numbers if they were given an offering where they’d have to go to a terrible prison for 2-3 years in their prime years.


There's no question that equity valuations are due for a massive collapse, the federal reserve has even admitted this. But there are a few things that make me thing that software engineer compensation has nowhere to go but up:

- The world is becoming increasingly computerized. The demand for software is skyrocketing.

- Software engineering is extremely economically efficient. You can produce infinite quantities of a piece of software with no marginal cost.

- Outside of the HN / CS bubble, most regular people still think coding is either boring, stupid, or too hard.

I really think it would be tough to do this job without some major interest in computers that most people simply don't have. And you can't really fake this. This puts a cap on the supply of engineers.


> I would love for this to continue forever but can it really?

well, we've pretty much got the world chained down it's essentially unlimited money for us forever

if things go downhill we will still be on top anyway so who cares


>renamed Streamlabs OBS to Streamlabs Studio

Ah that is a good outcome. I pessimistically thought this post was implying that OBS decided to "collaborate" by relenting to huge wads of money and giving up their name. Which would've been a huge shame to open source software. Glad stuff worked out.



Wow - this was a really good read! Thanks for sharing.


Since I don't use Find My Phone often enough, my Pixel 3 helpfully decided to remove location permissions from it. Would've been in for a surprise the next time I lose my phone had I not caught the notification.


I believe that permission is only needed for the Find My App itself (so that it can display the map correctly centered w.r.t where you are).

I don't think it affects finding that device from other devices.


Oh wow, this is true for me as well. Need to check if the app permission is required or if the location tracking works separately through some system service.


If you mean the Find My Device app it only asks for foreground location permission so I would assume the actual device "beacon" is part of the system not that app.


I've lost a phone with location tracking turned off. You can still disable the phone remotely and assign a lock screen message for the findee to contact you.


> Kernel developers obsess about speed and performance. The Linux kernel is built using -mregparm=3, which is sometimes called fastcall.

I've never messed with calling convention for the sake of performance before so I found this bit interesting. I found more info about it at: https://en.wikipedia.org/wiki/X86_calling_conventions#Borlan...

Does anyone have benchmarks? Assuming I don't care about ABI stability, what's the fastest calling convention?


> Assuming I don't care about ABI stability, what's the fastest calling convention?

I'd assume a modern optimizing compiler will, in situations where it's permitted, create completely novel calling conventions depending on the situation. Whole program optimization is one area you might see this.


The compiler tends to be limited in how it can change calling conventions by external visibility of the functions. Generally if you compile a function down to an object file the compiler will want to make that object file linkable with any other object files importing that symbol properly.

Whole program optimization gives the compiler some ways around that. I am not sure how much freedom it gives the compiler.


With LTO the compiler should be free to fudge the calling convention for most calls even between translation units.

Here is GCC doing that optimization for a static noinline function: https://godbolt.org/z/cn6Wz9Kvn

Similarly, compilers can also clone functions if it makes sense to propagate constants from call sites into the function. Example: https://godbolt.org/z/59z6xT75n

I'm sure there is more room for improvement. A perfect compiler would always optimized programs as a whole and only regard function boundaries as hints at best. In practice, you have to keep complexity in check somehow.


On Linux with GCC and Clang you can use -fvisibility=internal to tell the compiler to not care at all about this and go wild with ABI. Of course it needs to be done carefully...


Compilers can clone functions (so there are two variants with different calling conventions) or even create alternate entry points.


> Regardless, we decided weeks ago we’re removing the clause during the next ToS refresh

I've seen you reply about ToS issues before (specifically over caching of non-html assets): https://news.ycombinator.com/item?id=20791605

You verbally allowed it in that thread but have you considered officially adding that into the next revision of your ToS too?


Consider applying for YC's W25 batch! Applications are open till Nov 12.

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

Search: