Earlier quoted context omitted.
golang's priority is "works inside of google" and everything else tends to be a bit of a fight
This is definitely not true. "Inside of Google" would have been just linux/amd64 for a very long time. Now it includes linux/arm64 too, but that port happened before Google needed it. And all the other ports are not used inside of Google, except maybe the Mac port if you count developers laptops.
Russ Cox is stepping down as the Go tech lead
341–350 of 396 posts
Re: Russ Cox is stepping down as the Go tech lead
#342Earlier quoted context omitted.
> Adding generics was too much I strongly disagree. Sure, like anything in programming, generics can be misused. But even comments can be misused! OTOH I am able to build things in Go with generics that I would not be very happy building without them.
> But even comments can be misused! And arguably are in Go, where they are used for all kinds of things that are not inline documentation!
examples of that? code generation? been away from go for a while, after using it some earlier, so not up to date
Re: Russ Cox is stepping down as the Go tech lead
#343Out of interest, why are people so confident in Google when it comes to Go, yet every other day there's articles about how Google can't be trusted in related to Dart/Flutter which are soon to be abandoned?
I get an early-UNIX / Bell-Labs vibe from the entire Go project. New Jersey all the way. The ecosystem is too sleek and practical to abandon. My 0.02€, ymmv.
>New Jersey all the way
New Jersey vs. what? I read about that phrase sometime earlier but forgot the rest of it. Is it vs. MIT / Stanford / West Coast / other? implying worse is better vs. other?
is it also related to neat vs. scruffy approaches in AI?
too much in tech to keep track of it all.
but asking out of interest.
Re: Russ Cox is stepping down as the Go tech lead
#344Earlier quoted context omitted.
If you cant name 3 projects/app that use Dart/Flutter that just shows your bias. Can you name 3 apps/projects that use COBOL? -- This is akin to asking, "Quick, name 3 books written in Persian. Huh, you cant name them? Must be a dead language"
> Can you name 3 apps/projects that use COBOL? Does this imply that you see COBOL as having a trustworthy future, making it a great choice for a new greenfield application?
the part of your sentence before the comma is not fully related to the part after it.
iow, the first part does not imply the second part.
a lang could have a trustworthy future for maintenance of existing apps, like in terms of support from vendors, while not being a very good choice for greenfield applications, due to not having modern language features and libraries.
but there is so much cobol in critical infrastructure in the world that I don't think it is going away anytime soon. Google for some relevant threads on hn about it.
there is a good chance that some services critically important to you and your family rely on software written in COBOL running on mainframes. just like for everyone else in the developed world and some of the developing world.
Re: Russ Cox is stepping down as the Go tech lead
#345Earlier quoted context omitted.
Interestingly enough, I hate autoformatters (and use spaces instead of tabs) in every other language , but in Go you just get used to the way gofmt formats your code from the beginning, and then start to appreciate that you don't spend as much time on it anymore, so it's not a problem (at least for most people).
I've seen a number of autoformats for other languages be way too obsessive about formatting every little detail and edge case, to the point where it just becomes silly. 100% consistency is a fool's errand, and also contributes very very little Once you deal with some major issues (braces, spacing) you very quickly get diminishing returns.
One thing that I've found works kinda well: if you use a linter with "autofix" options, then the policy can be: complaint about formatting? Add the lint that can be autofixed. Then your formatter is just "run the lint autofixes"
Re: Russ Cox is stepping down as the Go tech lead
#346Does Google actually consider Go to be a success? I get the impression that it failed in what it set out to be: a successor to C/C++. Or put differently, Rust has eaten Go‘s lunch.
It was not supposed to /universally/ replace C++.
It was supposed to replace C++ in projects where the developers would’ve otherwise reached for C++ simply because it was the default language choice.
Re: Russ Cox is stepping down as the Go tech lead
#347Earlier quoted context omitted.
> usually have lots of layers for organizational reasons The ridiculous number of layers in Java or C# are more of a skill and guidance issue than anything else. Older languages don’t always mean over-attempted-abstraction (think C, for example).
Never seen CORBA and COM written in C, I guess. Enterprise Architects will do their beloved architectures with whatever languages are the tool of the day.
Ohhhh boy have I seen that. Like I say, it’s a skill issue, but those people tend to be in Java and C#, not Go and Rust.
Re: Russ Cox is stepping down as the Go tech lead
#348Earlier quoted context omitted.
> pointless features are added because maintainers are afraid I wouldn't have described language designers' feelings that way, but you're absolutely right. For example, witness the recent features added to Python with little more justification than "other languages have it". It's pure FOMO - fear of missing out.
Would you expand on the Python issue? I find recent Python additions either useful or non-intrusive, I wonder which ones you think are born out of FOMO.
The `match` statement is the most obvious - its motivation [0] is "pattern matching syntax is found in many languages" and "[it will] enable Python users to write cleaner, more readable code for [`if isinstance`]". But `if isinstance` is bad Python! [1]
`match` also breaks fundamental Python principles [2] and interacts badly with the language's lack of block scope:
>>> a, b = 1, 2
>>> match a:
... case b: pass
...
>>> a, b
(1, 1)
Another example is async-await - while the concept is fine (although I think stackful coroutines are a better fit for a high-level language), the syntax is just copy-pasted from other languages [4]. There seems to have been little thought as to why C# etc chose that syntax (to allow `async` and `await` to be contextual keywords), nor how `async def` contradicts existing Python syntax for generators.
[0] https://peps.python.org/pep-0635/#motivation
[1] http://canonical.org/%7Ekragen/isinstance/
[2] https://x.com/brandon_rhodes/status/1360226108399099909
[3] https://github.com/micropython/micropython/issues/8507
[4] https://peps.python.org/pep-0492/#why-async-and-await-keywor...
Re: Russ Cox is stepping down as the Go tech lead
#349Earlier quoted context omitted.
Don't forget that the semantic change of traditional 3-clause "for" loops: https://go101.org/blog/2024-03-01-for-loop-semantic-changes-... Because of this change, Go 1.22 is actually the first Go version which seriously breaks Go 1 compatibility, even if the Go official doesn't admit the fact.
Are there cases where people actually rely on the previous behavior? I always assumed that it was considered faulty to do so.
No convincing evidences to prove there are not such cases. In my honest opinion, if there are such cases in theory, there will be ones in practice. It is a bad expectation to hope such cases never happen in practice.
The authors of the change did try to prove such cases don't happen in practice, but their proving process is totally breaking.
It is my prediction that multiple instances of broken cases will be uncovered in coming years, in addition to the new foot-gun issues created by the altered semantics of transitional 'for' loops.
Re: Russ Cox is stepping down as the Go tech lead
#350Earlier quoted context omitted.
Don't forget that the semantic change of traditional 3-clause "for" loops: https://go101.org/blog/2024-03-01-for-loop-semantic-changes-... Because of this change, Go 1.22 is actually the first Go version which seriously breaks Go 1 compatibility, even if the Go official doesn't admit the fact.
> since Go 1.22, every freshly-declared loop variable used in a for loop will be instantiated as a distinctive instance at the start of each iteration. In other words, it is per-iteration scoped now. So the values of the i and v loop variables used in the two new created goroutines are 1 2 and 3 4, respectively. (1+2) + (3+4) gives 10. I think you are assuming more guarantees than are actually guaranteed. You have a…
:D
It looks you don't understand the change at all.
The statement "since Go 1.22, you should try to specify a Go language version for every Go source file" is made officially, not by me.
> You have a well-documented history of making incorrect claims about Go compiler and runtime behaviors, so this isn't surprising.
The claim is totally baseless.
All my opinions and articles are based on facts. If you have found ones which are incorrect or which are not based on facts, please let me know: https://x.com/zigo_101.