Can't golang devs prioritize something like annotations or other attribute/metadata system instead of writing these in comments? I'm pretty sure this must have been raised a lot of times before, so just wanted to ask if there is/are any specific reason(s)?
> Go designers distinguish between Go language as defined by Go spec and implementation details.
> //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.
I'd buy it. AFAIK the goal of Go is to have as little breaking changes as possible between versions.
Although they introduced backwards compat breaking features such as generics have they not ?
That does seem a strange argument, it could simply be `%%` (or whatever) to introduce a 'metadata comment', and then a Go implementation that doesn't support metadata would simply lex both `%%` and `//` as comments and treat them identically.
"If they made it part of the syntax, that would require other implementations to implement it." ... I mean, so what? Has golang stopped ading new features to the spec? If not (which I guess so), then how is this any different? Unless you have freezed the language, this reasoning doesn't make sense to me.
You are right that there could be new syntax, like, say, `@tool:name args` or `#tool.name args`, but is that any different than `//tool:name args`? They all read the same to me.
The upside of that particular syntax is that only the parser used by tools needs to understand directives. All other parser implementations can be blissfully unaware, negating the need for special no-ops. The downside is...?
I mean, technically you could write your entire business logic inside comments and have some tool parse it successfully. But we don't do that, because intuitively we know that's not the right place for it.
The issue isn't that this approach is incorrect, it's that it feels out of place. A comment should be a comment, nothing more. When comments start carrying executable meaning or structured directives, they stop serving their primary purpose.
It also becomes difficult to represent anything moderately complex in a clear way. Once the structure grows beyond something trivial, readability suffers quickly.
To me, it ends up feeling like command-line arguments.. technically workable, but messy and hard to reason about. Just look at something like "ffmpeg" arguments.. and then compare that to defining the same configuration through a structured format like Yaml or Json. The latter is simply clearer and easier to maintain.
> I mean, technically you could write your entire business logic inside comments and have some tool parse it successfully.
It sounds like you are talking about cgo. I think you have a stronger case there, but it is much the same situation: It's conceptually a third-party add-on that the Go language doesn't know anything about. "Cgo is not Go"[1]
I mean, if you really did have your own business logic language that you needed to include in Go code, where else would you put it if not in the "comments"? You, a random third-party, won't be able to add syntax to Go, so you cannot reasonably consider that to be an option. What syntax could Go add that is flexible enough to allow anyone to add anything they need, but that doesn't end up being comments by another token?
> A comment should be a comment, nothing more.
It's not really a comment, though. It is a directive. A comment is structured like `// Who the hell wrote this crap?`, while this is structured like `//tool:name args`.
I think what you are saying is that you don't like overloaded syntax, which is fair, but Go overloads syntax in several places so this is not a unique case. Besides, most languages end up with overloaded syntax in practice, so it isn't even something unique to Go.
To be clear, this isn't a feature of Go. There is nothing in the spec about it. It is what outside tools have hacked on top of Go because it doesn't offer that infinitely flexible feature mentioned above. However, it remains to be seen how you add infinitely flexible syntax without it turning into just being comments again.
I think your latest comment clarifies a lot of things for me here... primary being that it's something language designer did not wanted... just that tool developers went ahead with because there wasn't somethinf else (or something better) they could use.
If that is indeed the case, I believe it's fair. Im not into language/compiler design etc., but if I have to take a guess, this is where metaprogramming would have helped, right? Like the ones provided by zig or rust?
> this is where metaprogramming would have helped, right?
It is infinitely flexible for any kind of tool you can imagine, so it is quite likely that someone has created a tool to use in a place where metaprogramming could have been used instead. But I am not sure if it helps globally. The very directive in question, `//go:fix inline`, is a directive for a tool that refactors code — changing the files stored on disk to meet modern idioms. I don't think you would want to use metaprogramming for that, would you? It is not something you want to happen at compile time or run time. It is something you run only when you are ready to modernize your codebase (which, in some cases, might be never).
This is typical Go design, other languages do it worse, it isn't really needed, and then it gets added half way as it was supposed to be if done early on, and everyone cheers how Go is a "simple" language.
Just like some other famous languages of the authors.
It's abject hackery because such "comment" directives don't even necessarily have to be a comment to be active:
const x = `This whole thing is
a
//go:generate worse-is-better
multiline
string literal`
A lot of people in this discussion are beating up Go for using syntactical comments for directives, but in reality the implementation is even less principled than that!
I mean most of us knew from day 1 this would get militarized as soon as possibly can... the same goes for spacehip (large payloads delivery to battlefields) as well and neuralink (during interrogations).
I was early at Planet (and fresh out of college) and the transition internally towards govt money was very painful for the bright eyed save-the-world hackers internally.
The initial technical architecture was aligned with broad good (low res, global, daily, openly available), but the shift towards selling high res satellite capabilities directly to governments has been tough to see.
Their role of providing a public ledger is still a net good thing IMO, and i doubt Planet is adding much increased capability to the US war fighter (they have way better stuff). Harder to say for their deals with other governments that have fewer native space capabilities.
this is very difficult to address with intellectual honesty.
It seems obvious to me that people of conscience and standing have built plenty of the most cutting edge tech of this age. Yet those people are structurally embedded within business and government. Far-reaching technology is one thing, but satellite networks are especially impactful in many ways for both real time intelligence gathering and also building a record of analytic data over time.
So, PlanetLabs.. without a doubt, completely sincere in Doves reading save-the-whales data over the entire Earth. And also, connected "at the hip" to the US Federal Government. Does the US Federal Government work diligently to save-the-whales? You be the judge.
PlanetLabs is business, with investors. That is the horse that brought the endeavor to its current state. Larry Ellison seems to run a very stable business, in the same locales, and that seems to be just fine with investors. Is there any way that PlanetLabs would not be subject to the same investor pressures and direction, lawsuits and governance letters, that Oracle is subject to? seems likely that lots of the same actors are close at hand, from the beginning.
SO there is tragedy and comedy, stock price and hiring practices, technical capacity and brilliance. The mission is the message ? feedback here seems likely to escalate, so let's set a tone of informed debate, and recall that after the typing, almost nothing will actually change in practice.. just an educated guess.
The current administration is openly extractive without the fig leaves of old.
I don’t think we can look forward to nature - whether it’s national parks or marine parks or just being a non polluting neighbor - getting any priority or protection from now onwards.
I have tried theirs... they are NOT proxies.. that means majority of the popular sites actually block scraping... even if they are protected by cloudflare itself.
Nothing special happens. µJS doesn't change anything for direct URL access. The server renders the full page as usual. µJS only intercepts navigation once it's initialized on the page. This is actually one of the advantages of this approach over a true SPA: every URL is a fully server-rendered page, so direct access, bookmarks, and sharing links all work out of the box.
Let's take an example. Say we have a website with 3 pages:
- Homepage "website.com/"
- Products "website.com/products"
- About "website.com/about"
Your browser can load any of these pages directly, as usual. But when you are on the homepage (for example) and you click on the "About" link, µJS load the "/about" URL, and replace the current page's `<body>` tag with the fetched page's one.
Would it make this exercise even more interesting if we add that for every 25%+ improvement in val_bpb, existing limits (5 minute and VRAM usage) are also increased (by certain percentages)? This can simuate human-like dev iterations much more closely. Infra can be auto-scaled using a platform like Modal.
reply