Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We found a bug in Go's ARM64 compiler

blog.cloudflare.com

Post reply on HN
Print view View original

61–70 of 146 posts

Re: We found a bug in Go's ARM64 compiler

#61

Post by Degorath »

moomoo11 wrote: post #53
Degorath wrote: post #30

Earlier quoted context omitted.

Unfortunately, in 95% cases location IS a factor with bigger companies. I'm in a similar position where I'd like to do something a lot more interesting, but intersection between where the interesting companies have offices and where I'd be willing to live do not really overlap enough justify rooting up my life. (Unless we're talking about "too good to ignore", that's a different story.)

I was explicitly talking about too good to ignore. Anyone who can optimize a company’s bottom line will be hired. Like I said, no random average mid react guy or dime a dozen Java developer is getting hired as a remote employee in some flyover country. But if someone can provide like 50x value then hell yeah.. I thought that was obvious in my message considering we are discussing compiler optimization

(Yeah, I'd say your messaging was reasonably clear, but in the context of the whole thread it wasn't obvious whether the poster was putting themselves in that skill bucket.)

I think there's also quite a big spectrum of skill, even when we're talking about compiler optimization and highly skilled software developers. I'd put myself up there, but still I'm no Lars Bak (for whom Google allegedly created an office in Denmark).

Re: We found a bug in Go's ARM64 compiler

#62

Post by ptsneves »

moomoo11 wrote: post #53
Degorath wrote: post #30

Earlier quoted context omitted.

Unfortunately, in 95% cases location IS a factor with bigger companies. I'm in a similar position where I'd like to do something a lot more interesting, but intersection between where the interesting companies have offices and where I'd be willing to live do not really overlap enough justify rooting up my life. (Unless we're talking about "too good to ignore", that's a different story.)

I was explicitly talking about too good to ignore. Anyone who can optimize a company’s bottom line will be hired. Like I said, no random average mid react guy or dime a dozen Java developer is getting hired as a remote employee in some flyover country. But if someone can provide like 50x value then hell yeah.. I thought that was obvious in my message considering we are discussing compiler optimization

How do you rate yourself as higher than dime a dozen? I work as a full remote dev but I am not sure I am anything special, I mean how do you know that you are objectively good.

Re: We found a bug in Go's ARM64 compiler

#63

Post by a10c »

lordnacho wrote: post #55
akerl_ wrote: post #48

Earlier quoted context omitted.

It feels like this comment was almost a purely additive anecdote of your own experience with a similar kind of issue, but you've spoiled it by deciding to tell the author that they're incorrect about how they felt during the process? Maybe different people find different things fun.

Not saying he's wrong, sometimes the word "fun" connotes something slightly different what what it literally means. "Satisfying" is something I'd use for the end state. Maybe "challenging" for the intermediate state. But while you're in a high-pressure situation that you don't understand, that is rarely "fun" in the literal sense. You wouldn't pay to be given compiler race condition bugs, right?

> Not saying he's wrong

https://heinen.dev/ - I’m Thea “Teddy” Heinen (she/her or they/them)!

Re: We found a bug in Go's ARM64 compiler

#64

Post by alfalfasprout »

lordnacho wrote: post #46

> This was a very fun problem to debug. I'm sure it was a relief to find a thorough solution that addressed the root cause. But it doesn't seem plausible that it was fun while it was unexplained. When I have this kind of bug it eats my whole attention. Something this deep is especially frustrating. Nobody suspects the standard library or the compiler. Devs have been taught from a young age that it's always you, not t…

> Devs have been taught from a young age that it's always you, not the tools you were given, and that's generally true.

That's not been my experience at all FWIW. Tools get things wrong all the time.

Simply that more mature projects with heavy use like eg; gcc or clang/llvm generally tend to have had major bugs stamped out by this point. They do still happen though.

More nascent language and compiler ecosystems are more likely to run into issues. Especially languages with runtimes.

Re: We found a bug in Go's ARM64 compiler

#65

Post by rectang »

lordnacho wrote: post #46

> This was a very fun problem to debug. I'm sure it was a relief to find a thorough solution that addressed the root cause. But it doesn't seem plausible that it was fun while it was unexplained. When I have this kind of bug it eats my whole attention. Something this deep is especially frustrating. Nobody suspects the standard library or the compiler. Devs have been taught from a young age that it's always you, not t…

Although I’m good enough at it, like you I hate this kind of debugging experience, and try hard to avoid putting myself in a position where I have to do it. It’s not fun for me at all.

I also don’t like many puzzle games, like Sudoku, because to me they feel like this kind of work. Many colleagues of mine have expressed bafflement that I don’t find such puzzles fun and give me all kinds of grief about how I ought to enjoy them, since they do.

It’s the same thing here, just flipped around: this person seems to enjoy the debugging experience; just let them be. Or recruit them, because that temperament is valuable.

Re: We found a bug in Go's ARM64 compiler

#66

Post by commandersaki »

lordnacho wrote: post #46

> This was a very fun problem to debug. I'm sure it was a relief to find a thorough solution that addressed the root cause. But it doesn't seem plausible that it was fun while it was unexplained. When I have this kind of bug it eats my whole attention. Something this deep is especially frustrating. Nobody suspects the standard library or the compiler. Devs have been taught from a young age that it's always you, not t…

Probably just meant satisfying instead of fun. I found a bug in sscanf for the gcc arm toolchain that ships with Ubuntu (and Debian), and it wasn't fun since I had deadlines to deal with. Workaround was to use the official ARM one. But after 2 days, it was satisfying to nail the exact problem and write a regression test.

Re: We found a bug in Go's ARM64 compiler

#67

Post by btbuilder »

lordnacho wrote: post #46

> This was a very fun problem to debug. I'm sure it was a relief to find a thorough solution that addressed the root cause. But it doesn't seem plausible that it was fun while it was unexplained. When I have this kind of bug it eats my whole attention. Something this deep is especially frustrating. Nobody suspects the standard library or the compiler. Devs have been taught from a young age that it's always you, not t…

Segfaults with no use of “Unsafe” equivalents in managed languages can give immediate indication it’s not a code problem.

Re: We found a bug in Go's ARM64 compiler

#68

Post by wat10000 »

lordnacho wrote: post #46

> This was a very fun problem to debug. I'm sure it was a relief to find a thorough solution that addressed the root cause. But it doesn't seem plausible that it was fun while it was unexplained. When I have this kind of bug it eats my whole attention. Something this deep is especially frustrating. Nobody suspects the standard library or the compiler. Devs have been taught from a young age that it's always you, not t…

I find this sort of thing to be tremendously fun. It can be frustrating as well, but overall it’s my favorite part of my job. I don’t see why this would be implausible. Different people enjoy different things.

Re: We found a bug in Go's ARM64 compiler

#69

Post by moomoo11 »

ptsneves wrote: post #62
moomoo11 wrote: post #53

Earlier quoted context omitted.

I was explicitly talking about too good to ignore. Anyone who can optimize a company’s bottom line will be hired. Like I said, no random average mid react guy or dime a dozen Java developer is getting hired as a remote employee in some flyover country. But if someone can provide like 50x value then hell yeah.. I thought that was obvious in my message considering we are discussing compiler optimization

How do you rate yourself as higher than dime a dozen? I work as a full remote dev but I am not sure I am anything special, I mean how do you know that you are objectively good.

Where did I say anything about myself? Sounds like projection or some deep insecurities if you meant it _that_ way.

If you're asking what would constitute someone being special, it would depend on the role and skillset. As I said in my earlier comment, someone who is a beast and can find and fix bugs in compilers is a rare person. Especially if that skillset can help the company save boatloads of money that can be deployed elsewhere.

There are probably only a handful of people in the world who understand and can push the AI landscape forward. A lot of them are Chinese immigrants, and yet OpenAI/Meta/etc are paying them boatloads of money.

As for remote roles, I once worked on a project where we hired some dude for like $500/hr as a contractor because he was one of the few people who knew the inside/out of postgres and oracle rdbms because we were doing some very important migration.

Re: We found a bug in Go's ARM64 compiler

#70

Post by anyfoo »

lordnacho wrote: post #46

> This was a very fun problem to debug. I'm sure it was a relief to find a thorough solution that addressed the root cause. But it doesn't seem plausible that it was fun while it was unexplained. When I have this kind of bug it eats my whole attention. Something this deep is especially frustrating. Nobody suspects the standard library or the compiler. Devs have been taught from a young age that it's always you, not t…

> I'm sure it was a relief to find a thorough solution that addressed the root cause. But it doesn't seem plausible that it was fun while it was unexplained. When I have this kind of bug it eats my whole attention.

Yeah, and that's fun for me. Some of my most fun bugs to debug have been compiler, or even CPU issues.

Post reply on HN