Jacobin[0] a JVM written in entirely in go. While we still have a way to go to get to feature parity for Java 21, we can sit back and watch the bytecode instructions fly by as they execute, which is something you can't do with the JDK due to the HotSpot JVM's architecture and the fact that it's written in both Java and C++.
We just crossed 5,000 commits. Also, we take testing very seriously: our test code base is presently 160% the size of our production code.
The few times I've needed support, Fastmail has responded nearly immediately with the exact info I needed. So Moz would need to demonstrate excellence in customer service before I would consider any migration.
(I know that doesn't directly answer your question, but it does articulate a necessary pre-condition, and one that is hard for businesses entering a new line of service to deliver--although not impossible, of course.)
JMAP is a bonus (other fastmail user here) bjt if I can do custom sieve rules and or unlimited aliases created on demand at (somestring)@customdomainiown.com thst I can then use the sieve rules to put into a folder of the same name as that email address, I would rather give my money to support Thunderbird. Fastmail is fine and all but they are in australia so they live on spyware island and they dont have good native clients in the works like thunderbird does.
Unlimited aliases at custom domains are a part of the offering. Technically, Thundermail supports sieve rules, we do need to come up with UX to expose it to users for management.
That is an interesting project, which i have been following for a while. Unfortunately, progress has slowed a lot recently. I hope development picks up…and that the author chooses a different name for the language.
There are many exceptions to what you state as an ironclad rule: i bought a display case for my baseball, i bought an album for my photos, etc. “for” can go in either direction.
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.
This also does not change th code. It is an advertisement to a linter-loke tool to take some action on the source code. Its most similar to linter directives which usually are comments.
> 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.
J6 is not a strong counterexample, IMHO. Part of the problem with Epstein is "proof beyond a reasonable doubt," for which evidence is needed--and, it appears, hard to come by. Whereas with J6, there were thousands of hours of footage showing the crimes being committed (and in many cases bragged about), which made prosecutions much easier.
He studied them diligently. His book Digital Typography gives lengthy accounts of his research and includes photographs and examples of how he chose various aspects.
The use of "golang" for posts and comments is desirable IMHO because it greatly facilitates search, especially on sites such as HN that cover many languages.
Searching "site:news.ycombinator.com go" on Google didn't yield any results that weren't about the Go programming language even after going several pages deep. What kind of search problems are you having, exactly?
And why is it unique to Go? I am sure there are comments on HN about metal oxidization, making sharp changes in direction, Norse gods, and letters of the alphabet.
But if you go to the search box at the bottom of the HN page and type in 'go' the first hit is "Julian Assange has reached a plea deal with the U.S., allowing him to go free," In the top 10 results, only _two_ are about Go, the language.
Whereas the first 50 golang hits are all about the language.
You might have your preferred approach, but there are good reasons for using golang.
Such as? If you type in 'C' into HN's search box, the first result is about the F.C.C., followed by C.E.O., then USB-C. Even once we finally see one about a programming language, it is about C#.
If the earlier list was instead 'Clangclang, Golang, Odinlang and Ziglang' then I could maybe understand where you are coming from, but that is not what we saw. Clearly there was no effort put into aiding searchers universally.
Are you trying to suggest that Go is the only language worth reading about? Let me try to restate the earlier question in your tongue: Why is it unique to 'golang'?
Yowza! Lines 1566-1637 consist entirely of closing braces. That's 70 closing braces in a row. Beyond the nightmare of maintenance, it's got to be a performance drag on the compilation.
We just crossed 5,000 commits. Also, we take testing very seriously: our test code base is presently 160% the size of our production code.
[0] jacobin.org
reply