He obviously thinks you should learn from your mistakes and that you must be an avid and quick learner.

But learning skills is not what introspection / dwelling is.

It's spending times on thoughts like "what should I be doing with my life". "I can't believe how much of a victim of the system I am".

And he specifically contrasted it against doing stuff.

Writing code >>> walks in the woods.

Obviously reflection is necessary to recognize mistakes of the past. What Andreessen was talking about that you should spent majority of your time acting not reflecting. Not that you should spent 0 time reflecting.

It's surprising to me that you consider these equivalent.

Introspection is a process of discovery, to uncover a deeper cause why you did something.

Dwelling is when you can't let go.

Introspection is important. Dwelling is problematic.

If HN gets invaded by people who want to discuss cooking and start submitting and upvoting cooking articles and HN turns into cooking discussion website? And once they get majority, they'll change the rules to make it exclusively about cooking.

It's still people, just different people. People who like cooking vs. people who like technology and startups.

There's no philosophical conundrum.

Do you want HN to be colonized by cooking people or not? That is the question.

I don't.

We need to stand our ground and repel colonizers who want to change the character of HN. Our unity is our strength.

Do you now see that it doesn't work like this?

putflix is criminal theft. They pay nothing to people who make movies. You can drive the cost to zero by downloading torrents directly from pirate bay.

If you did want to pay the artists then you would pay for netflix of rent/buy from a number of places (amazon video, youtube, apple).

Your cryptocurrency fantasy is just a way to rationalize stealing.

It's just "rent", there's no buy option from any of these people, no matter what their site says. If they can revoke your ownership at any time, for any reason, then you don't own it. And if you don't own it, then you're not buying it.

I get the motivation to not pay these crooks, and instead pay the actual people that made the movie direct.

//go:fix is something understood by a particular implementation of Go. Another implementation could implement Go without implementing support for //go:fix and it would be a fully compliant implementation of Go, the language.

If they made it part of the syntax, that would require other implementations to implement it.

The reason it feels like a kludge is that "comments" are normally understood to be non-impactful. Is a source transformation that removes all comments valid? If comments have no impact per the spec, yes. But that's not the case here.

In practice comments in go are defined to be able to carry semantic meaning extensibly. Whether they're safe to ignore depends on what meaning is given to the directives, e.g. conditional compilation directives.

It's certainly done in many places. JsDoc is the biggest example I can think of. But they're all walking the line of "this doesn't have an impact, except when it does".

It being done by the language owners just makes them the ones walking the line.

In practice, the Go language developers carved syntax out of comments, so that a comment is "anything that starts with //, unless the next characters are go:"

If it would make you happier you can imagine this is part of the spec. It wouldn't change much if it was.

Why would millions of programs becoming out of date with the spec make me happy. There is value in the language maintainers and go programmers talking about the same object. I don't disagree that '// ' is standard Go style (and more readable), but it would break all the code that uses //comments /// ////.

I DO agree that it wouldn't change much if by 'it' you mean the go language and it's tooling, a proper spec does prevent arbitrary change. But it should have been added at least 5 years ago.

There was no such statement. "In practice" clearly indicates the contrary about it being "strict" and certainly encompasses the possibility that it only developed over time.

https://go.dev/blog/inliner#example-fixing-api-design-flaws

So these comments carry more weight than how those comment annotations might be consumed by optional tools for other languages.

For most of the listed examples, I think the corresponding C annotation would have been "[[deprecated]]", which has been added to the syntax as of C23.

That's why you find it in the comments. That is where tools have found a place to add their own syntax without breaking the Go code.

Absolutely you can do the same in Java. It exists to the exact same degree as it does in Go. I expect it isn't done as often in the Java world because it is much harder to parse Java code so the tools don't get built.

Things like "//go:embed" and "//go:build" very much do change the semantics of source code.

The comments above 'import "C"' containing C function definitions and imports change the compilation of go source code.

The "//go" comments contain a mix of ones that must be respected to compile, to being optional, to being entirely ignorable (like generate and fix).

When you take the source code as a whole they do, but the Go parts are unchanged. The Go spec says nothing about //go:embed, or //go:build. These are not Go features. What you are looking at is another programming language that has been added by a particular tool, using Go comments as the gateway to supporting non-standard syntax inline.

> The "//go" comments contain a mix of ones that must be respected to compile

That is true, but in using it you've accepted that you are no longer writing Go. In fact, with respect to your talk of C, "Cgo is not Go" is one of the most oft-repeated lines seen in the Go community. It's not just a silly catchphrase. It is the technical reality. Cgo is literally a different programming language, much like how Objective-C is not C despite supporting everything C does.

So the go stdlib also isn't "the go programming language"? The 'golang.org/x' repositories aren't standard go?

I feel like you're no-true-scottsmanning this into a meaningless definition where the spec defines Go, but all Go code in existence is not actually Go code, it's a different programming language which everyone happens to call Go and think of as Go.

Like, sure, redefine Go like that if you want, but I don't think anyone else in practice thinks "Ah, yes, the go stdlib isn't actually written in Go", so you'll be off by yourself with that definition.

Which standard library? There isn't just one. tinygo's standard library, for example, isn't the same as gc's. They are, in most cases, API compatible, but there are some packages not shared and they are completely different codebases. A standard library is a distribution concern, not a language concern.

Maybe you're caught up thinking in some other kind of language that only has one distribution and trying to apply that misaligned logic to programming at large?

> I feel like you're no-true-scottsmanning this into a meaningless definition

It's not, though. It is actually something you have to think about in the real world. A 100% spec-complaint Go compiler can be completely unable to use gc's standard library code as it contains additional language constructs that are bound to gc specifically.

> I don't think anyone else in practice thinks "Ah, yes, the go stdlib isn't actually written in Go"

Again, its not clear which standard library you are referring to, but if we assume gc's it is mostly written in Go, but it contains extensions that are not Go. If you say that it was written in Go casually, people will know what you mean, but technically, no, it isn't written in Go. At least no more than an Objective-C program is written in C.

But, unlike Objective-C, the extensions are added in such a way that they remain valid Go syntactically. That means you can use, say, a Go language server on gc's standard library without it blowing up on the extensions. It gives the advantage of a new language, but without having to build new language tools.

This is not inlining in the compiler. It's a directive to a source transformation (refactoring) tool. So yes, this has no impact on the code. It will do things if you run `go fix` on your codebase, otherwise it won't.

I keep being impressed at subtle but meaningful things that Go does right.

It was: "With sufficiently advanced vibe coding the need for certain type of product just vanishes."

If a product has 100 thousand users and 1% of them vibe codes an alternative for themselves, the product / business doesn't vanish. They still have 99 thousand of users.

That was the rebuttal, even if not presented as persuasively and intelligently as I just did.

So no, it's not the case of "both things being true". It's a case of: he was wrong.

Which begs the question: do you think it's more "moral" to wage wars and lie to public that you're in the business of defense OR say things that are truthful?

Spending trillion+ dollars on military is about the only thing that both political party agree on. Obama bombed more countries that most presidents.

Since we're talking about adults thinking like children: your simplistic ideas about what military should be have no effect on what it is.

If Iran had the firepower superiority over Israel and U.S. they would level both countries. This is no me saying. "Death to America" is a literal quote from now-dead ayatollah.

When you actually listen why they renamed DoD to DoW it's way more nuanced that you apparently believe.

One of the reasons is that political correctness is destructive in military. If you're actually at war, winning should be objective not PR optics.

And it seems to be working. See disaster of Afghanistan withdrawal compared to astonishing success of snatching Maduro and destroying Iran's capability to wage future wars.

As far as I can see, the US has managed to replace an older Ayatollah Khomeini with a younger Ayatollah Khomeini with even more reasons to seek vengeance against the US and obtain nuclear weapons.

> If you're actually at war, winning should be objective not PR optics.

Which of course is why a former TV host is clearly the most qualified person to be Secretary of Defense, sorry War.

You didn’t actually justify most of what you said and when you did the reasoning seems circular. Most of what you say just has the premise that what’s being done now is good and necessary, and that’s not something I agree with.

I did listen to the justifications for the ‘rename’ (Congress named the department and has not actually changed the name - but that’s a digression…), and disagree with much of the reasoning.

I think it would be ‘more moral’ to have a Department of Defense that operates and has the goals I described. I neither think it’s ‘moral’ to strive for war nor to lie to the public about it.

I agree the military should be well funded.

You invoke Obama, I can’t tell if you agree with what he did or not, and it’s anyway not relevant to what we’re discussing.

Since we're talking about adults thinking like children: your simplistic ideas about what military should be have no effect on what it is.

This sounds deep but is actually nonsense. Our society absolutely gets to choose everything about what our military is and how it’s used. Indeed, you even seem to be arguing that it isn’t (wasn’t) what you think it should be!

Iran and our response to it is a different thing than I was discussing (the name of the department, remember), but I think it would be both ‘more moral’ and probably more effective to actually think and plan deeply than whatever this is. The current administration seems to be all tactics, no strategy.

And I find it ironic that you list a bunch of conflicts that have had, at best, mixed results, then just assert that what’s currently underway, which seems to have less long term planning behind it than any of those, is just obviously going to have a great outcome.

It was supposed to solve the problem of: some computers run x86, some arm, we need something that is equivalent, but portable across different cpus

What business is it for WebAssembly to know about complex types? What x86 instructions is there for `(type $t (struct i32))` ? Or doing garbage collection.

We would be better off standardizing on a subset of x86 and writing translators to arm etc. Or standardize on arm and translate to x86.

We know it can work. Apple did it with rosetta. Microsoft did it with Prism. I don't think WebAssembly implementation generate faster code than rosetta or prism.

QEMU did it simply (albeit slowly).

WebAssembly is becoming another JVM. It's not simple. It's not fast. It's not easy to use.

But now we're stuck with it and the only path is to add and add and add.

My emulators here have roughly the same performance as the same code compiled as native executable (e.g. within around 5%) - this is mostly integer bit twiddling code. Unless you hand-optimize your code beyond what portable C provides (like manually tuned SIMD intrinsics), WASM code pretty much runs at native speed these days:

https://floooh.github.io/tiny8bit/

Also, don't forget that WASM is designed to replace JavaScript, thus it must interoperate with it to smooth the transition. Rosetta and Prism also work to smooth the transition from x86 -> ARM, and much of the difficult work that they do actually involves translating between the calling conventions of the different architectures, and making them work across binaries compiled both for and not for ARM, not with the bytecode translation. WebAssembly is designed to not have that limitation: it's much more closely aligned to JS. That's why it wouldn't make sense to use a subset of x86 or similar, as it would simply produce more work trying to get it to interface with JavaScript.

Not disagreeing with you, but here’s an article from Akamai about how using WASM can minimize cold startup time for serverless functions.

https://www.akamai.com/blog/developers/build-serverless-func...

This is basically what Native Client (NaCl) was, and it was really hard to work with! We don't use it anymore and developed WASM instead.

> Friends, as I am sure is abundantly clear, this is a troll post :)

I strongly call BS on that.

Strong claim and evidence seems to be a hallucination in your own head.

There are several writeups of large backends ported from node/python/ruby to Go which resulted in dramatic speedups, including drop in P99 and P99.9 latencies by 10x

That's empirical evidence your claim is BS.

What exactly is so unfair about Go scheduler and what do you compare it to?

Node's lack of multi-threading?

Python's and Ruby's GIL?

Just leaving this to OS thread scheduler which, unlike Go, has no idea about i/o and therefore cannot optimize for it?

Apparently the source of your claim is https://github.com/php/frankenphp/pull/2016

Which is optimizing for a very specific micro-benchmark of hammering std-lib http server with concurrent request. Which is not what 99% of go servers need to handle. And is exercising way more than a scheduler. And is not benchmarking against any other language, so the sweeping statement about "higher than any other language" is literally baseless.

And you were able to make a change that trades throughput for P99 latency without changing the scheduler, which kind of shows it wasn't the scheduler but an interaction between a specific implementation of HTTP server and Go scheduler.

And there are other HTTP servers in Go that focus on speed. It's just 99.9% of Go servers don't need any of that because the baseline is 10x faster than python/ruby/javascript and on-par with Java or C#.

But that's not comparing apples to apples. When you get a dramatic speedup, you will also see big drops in the P99 and P99.9 latencies because what stressed out the scripting language is a yawn to a compiled language. Just going from stressed->yawning will do wonders for all your latencies, tail latencies included.

That doesn't say anything about what will happen when the load increases enough to start stressing the compiled language.

Of course, expecting you to provide the link would be incredibly onerous. We can look it up ourselves just as easy as you can. Well, in theory we can. The only trouble is that I cannot find the issue you are talking about. I cannot find any issues in the Go issue tracker from your account.

So, in the interest of good faith, perhaps you can help us out this one time and point us in the right direction?

That being said, I love studying go and learning how to use it to the best of my ability because I work on sub-ųs networking in go.

When I get home, I’ll dig it up. But if you think it’s a fair scheduler, I invite you to just think about it on a whiteboard for a few minutes. It’s nowhere near fair and should be self-evident from first principles alone.

There are also multiple issues about this on GitHub.

And an open issue that is basically been ignored. golang/go#51071

Like I said. Go won’t fix this because they’ve optimized for throughput at the expense of everything else, which means higher tail latencies. They’d have to give up throughput for lower latency.

It doesn't look ignored to me. It explains that the test coverage is currently poor, so they are in a terrible position of not being able to make changes until that is rectified.

The first step is to improve the test coverage. Are you volunteering? AI isn't at a point where it is going to magically do it on its own, so it is going to take a willing human hand. You do certainly appear to be the perfect candidate, both having the technical understanding and the need for it.

There is unlikely anyone on the Go team with more political clout in this particular area than the one who has already reached out to you. You obviously didn't respond to him publicly, but did he reject your offer in private? Or are you just imaging some kind of hypothetical scenario where they are refusing to talk to you, despite evidence to the contrary?

I literally have no idea what you're talking about here.

5% of people create 90% of the crime. Double 5% to 10% and you double the crime. Make it 50% and and you 10x the crime.

You still have 50% of non-criminals but society with 50% criminals has way more crime than society with 5% criminals.

You might say high-crime society is much worse than low-crime society even though they both have individuals that are criminals and non-criminals.

Replace "crime" with "trust" and you understand high-trust vs. low-trust society. They both have individuals with various levels of trust, but emergent behavior driven by statistics creates a very different society.

> there's no difference between "truly creative work" and "truly creative and profitable work"

To state the obvious, the difference is "profit".

Also I don't see you're bringing the "true scottsman" judgement here. What's the difference between "creative" and "truly creative" work. Who gets to decide what is "truly creative" vs. merely "creative".

We already have "high-crime society" and "low-crime society." What this has to do with overall levels of trust in different parts of the system, say, education, is not immediately clear to me. Do all high crime societies have untrustworthy education systems as well?

> To state the obvious, the difference is "profit".

To make my intention clear, the other difference is "popularity," which exemplifies the precise confusion I was reacting to.

> What's the difference between "creative" and "truly creative" work.

I didn't invoke it. The GP did. I'm willing to admit to whatever their subjective judgement is. I wonder if their connection between trust and "true creativity" is valid regardless of any possible definition. My gambit above was to openly suppose a good faith reason for the difference in my point of view.