The biggest problem with Typescript in the modern era is that LLMs are pretty bad at it, at least as compared to some other languages that are more well suited to LLM generation. What you say may have been a boon in the olden days, but it is hard to justify now. It is difficult to avoid Typescript/Javascript in the browser, sure, but now it's just as fast to duplicate everything in another language for the backend and at least gain the advantages on that end.
> hell its better than Go for industry purposes. [...] the drawback with Java will always be the CULTURE
The industry purpose for Go is that all codebases look more or less the same, so workers can jump into any project they've never seen before and instantly feel like they wrote it themselves. Google talked about that a lot around the time Go was released. It is why they created it instead of just adopting Haskell or something.
Some of that simply comes down to the language not allowing much creativity, but without the culture developers would still find a way to mess with outcomes. You can still write crazy Go code if you want to. The culture is the piece that matters. If Java doesn't have the culture, how does it fit in industry?
That doesn't really make sense, though, as rice — one of the main ingredients in the aforementioned product — receives the highest subsidy rate in the USA. A Beyond Meat burger should be cheaper than a meat burger thanks to subsidies.
> I feel like the anti-MCP push is coming from people who don't need to work in a large org.
Any kind of social push like that is always understood to be something to ignore if you understand why you need to ignore it. Do you agree that a typical solo dev caught in the MCP hype should run the other way, even if it is beneficial to your unique situation?
He is talking about the same thing as you, no? As you point out, the more AI exposure (red), the more likely to have higher wages (green). Which suggests that those who are embracing AI are those who are thriving the most. Same as what he suggested.
Whether people are adopting AI or not, everybody doing the same kind of job gets the same number for exposure to AI.
You can claim that AI is creating a Jevons paradox situation and making companies hire as crazy the people it nominally replaces. But then you would have to point any instance of that happening, because it's clearly not there either.
The BLS classifies them as different roles. In essence: Software developers plan, computer programmers implement. Which in many cases might be the same person, but it has always been true that one person can hold multiple jobs.
That's not a distinction that actually exists in the real world. This makes me wonder what other made-up distinctions they are claiming in industries I'm less familiar with.
I've seen it. I personally think it is ill-conceived and I am not sure why any business would actually want to function that way, but it definitely exists. Of software developers and computer programmers combined, only around 5% are considered to be computer programmers, so it is already recognized in the data as something fairly unusual.
> Things like "//go:embed" and "//go:build" very much do change the semantics of source code.
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.
> What you are looking at is another programming language that has been added by a particular tool
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.
> So the go stdlib also isn't "the go programming language"?
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.
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.
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).
The best time to move your docs to your repo was 30 years ago. But now that they are written by LLMs, tomorrow's LLM will be able to write an even better doc than today's LLM. Nothing is gained in caching them now.
Unless you're doing something wrong, the "why" is already captured in your test suite/type system. While you can fairly call that documentation (that is the point of it!), the linked story is about natural language documentation. That can be extracted from your tests/types at will, and as models keep getting better extracting later will be better than extracting now.
Don't get me wrong, I'm sure future historians appreciate when you document that John, when trying to determine how to figure out how to exchange data in your application, took a drink from his Diet Coke that happened to have a fly in it and as he spit it out eureka struck: Data can be pushed to the client like a firehose.
But let's be real, that's never going to happen. No matter what format you give someone, they're not going to write that kind of thing down. They will, however, encode why a firehose approach is necessary to both document it for future readers and to ensure that the program doesn't accidentally (or possibly on purpose by an eager junior dev) move to, say, a pull method that won't meet the business/technical requirements. Which LLMs can extract a natural language version from.
And, really, that's the only "why" that actually matters to other developers trying to get their job done. The forest, while perhaps full of fun stories that I am sure are entertaining to read, doesn't matter all that much.
reply