Our great sponsors
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
> It communicates hostility and disbelief rather than curiosity.
I don't share that opinion.
> https://github.com/golang/go/issues/60078 is where this is discussed.
We can discuss semantics here, but a breaking change, to me, is one that that breaks well-crafted existing code. Well, what kind of code relies on the fact that closures over the iteration target examine a value that depends on runtime behavior?
I have stumbled upon this issue myself when I first learned Go. I have used Go professionally and in private projects and since long before modfiles became a thing. I have NEVER seen code that relies on this unintuitive, behavior of loop variables. This is not a change that breaks something good, this is a fix that removes a footgun from the language.
Further down, rsc writes this (https://github.com/golang/go/issues/60078#issuecomment-15424...)
That's some of the real-world evidence in favor of changing 3-clause loops.
> I'm not sure here how you differentiate minimalist from restrictive.
The flexibility of the language and its syntax. The more constructs are syntactic, the less minimalistic it is, and Go is a very syntactic language.
> I've always considered Go to be minimalist in terms of available tokens to the programmer: https://github.com/e3b0c442/keywords/blob/main/chart.png
No language on this chart has even a passing resemblance to minimalistic. I don't think anything does when it reaches double digit keywords.
For reference, I believe Smalltalk has 6.
And forth is more complicated because it doesn't really have keywords at all, and barely any syntax, instead it has assembly-coded / runtime-provided words (~functions) and variables. SectorForth (https://github.com/cesarblum/sectorforth/) is down to 8 builtin words, 2 IO words, and 5 variables (milliforth packs those behind a word instead). And so far 2 of the words have been found unnecessary / redundant.
> I'm not sure here how you differentiate minimalist from restrictive.
The flexibility of the language and its syntax. The more constructs are syntactic, the less minimalistic it is, and Go is a very syntactic language.
> I've always considered Go to be minimalist in terms of available tokens to the programmer: https://github.com/e3b0c442/keywords/blob/main/chart.png
No language on this chart has even a passing resemblance to minimalistic. I don't think anything does when it reaches double digit keywords.
For reference, I believe Smalltalk has 6.
And forth is more complicated because it doesn't really have keywords at all, and barely any syntax, instead it has assembly-coded / runtime-provided words (~functions) and variables. SectorForth (https://github.com/cesarblum/sectorforth/) is down to 8 builtin words, 2 IO words, and 5 variables (milliforth packs those behind a word instead). And so far 2 of the words have been found unnecessary / redundant.
>There's a lot of misinformation, bad arguments and bad conclusions in this post. Let's pick it apart.
No, there really isn't, but I had fun answering :-)
> But, past isn't a guarantee of the future. It was stable before, but who's to say it will be in the future?
Whos to say C will be stable tomorrow? Well, the fact that the C compiler is a standard, and has an official document outlining what a C compiler does. And go is the same.
If anyone was to change that, all I have to do is check out an earlier version of this open source language, and use that. And since tons of code rely on this, that is what would happen.
Languages don't become unstable because they suddenly change trajectory, they are unstable if feature upon feature is heaved upon them, along with codebases relying on these features, necessitating constantly keeping up to date with the language version.
Go, explicitly, has a completely different design trajectory. And as a result, Go code that was written in Go 1.8 will still compile today.
> Go has no standard
Here is the official spec of the language: https://go.dev/ref/spec
Which is a de-facto standard, even according to this listing: https://en.wikipedia.org/wiki/Comparison_of_programming_lang...
Btw. if you look at the listing, MOST languages, including commonly used ones, don't have an international or national standard. Many don't even have a de-facto standard. Among them are many tried and battle tested languages.
> and nobody will hold them responsible for the discrepancy.
Anyone unhappy with the implementation is free to fork the project and take it in a different direction. He who writes the code makes the rules. If people are unhappy with that, they can fork, or use another language. And people seem to be very happy with the language: https://madnight.github.io/githut/#/pull_requests/2023/3
> By who? How did you come to this conclusion? There's only evidence to the contrary of your argument.
What evidence is there for the assumption that Go would vanish if Google lost interest?
> This is demonstrably false.
No, it is not, as demonstrated by the example I gave regarding C. The language didn't change much from C99, which itself wasn't that big a step away from ANSI-C. C99 was a quarter century ago, and C remains one of the most used languages in existence.
> To further illustrate this point: today, versions of Python
I am pretty sure I never used Python as an example for this. If you disagree, quote where I did.
> In more broader terms, I have no idea why did you bring C into this argument.
For a very simple reason: To show that languages that a language that is mostly feature-freezed, and so stable that I can run a modern compiler on decades-old unchanged code, and still get a runnable executable, can be, and are, incredibly successful. Go has been called "C for the 21st century", and for everything other than System-Programming, that statement holds true.
This is a lot more possible now that Go has generics (as of 1.18).
I would probably never use these, as I find such libraries are a whole new domain-specific language to learn, and often don't make things much simpler anyway, but here are some libraries where people have done something like this:
* https://github.com/ahmetb/go-linq: modelled after LINQ, but created pre-generics so only recently added some generics features
* https://github.com/asynkron/gofun: simple library with stand-alone functions to filter, map, and so on