githut VS go

This is the best measure I've found:

https://madnight.github.io/githut/#/pushes/2023/4

Unfortunately it doesn't have new projects, but it does seem like C++ peaked a couple of years ago and is starting to trend down. "Plummeting" is clearly an exaggeration though.

>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.

fad - an intense and widely shared enthusiasm for something, especially one that is short-lived and without basis in the object's qualities; a craze.

---

I don't think Ruby is a fad. The drop off Ruby had since early 2010s is dramatic, but it stabilized around 5% of all PRs on GH in the last few years:

https://madnight.github.io/githut/#/pull_requests/2023/2

It's still one of the most popular languages for web development.

I would beg to differ.

On Github[0], Go currently sits at #3 for pull request volume (C# is at 10), #3 for stars (C# is at 8), #6 for pushes (C# is at 10) and #6 for stars (C# is at 9). By each of those metrics, Go has a much more vibrant ecosystem than C#.

[0]: https://madnight.github.io/githut/#/pull_requests/2023/2

One measure is git pushes on GitHub. By that measure[0], in Q1 2023, we have Emacs Lisp (2995 pushes) > Clojure (2135) > Scheme (1350) > Common Lisp (236) > Racket (below detection; latest in Q1 2022: 102).

[0]: https://madnight.github.io/githut/

> 20 years ago I might've agreed with you. But I do not think that PHP, BASIC and shell scripting are popular beginner languages in 2023.

PHP and shell scripting are still massively used in 2023 (eg https://madnight.github.io/githut/#/pull_requests/2023/1). You have a point about BASIC but it was the de facto standard for computers at a time when people didn't have the web to quickly look up problems and thus learning to code was much harder. Yet we (in fact I) managed just fine.

> Quotation marks and especially parentheses after function calls don't fit TFA's definition of a sigil because they aren't at the beginning of the word and (arguably only in the latter case) don't communicate meta-information about the word.

I didn't say they are sigils. I said they're tokens. My point was that removing sigils doesn't remove meta-information encoded in magic characters:

- You have `foobar()` where the braces denote (call the function rather than pass the function reference

- "" == string which allows escaping and/or infixing vs '' which doesn't (other languages have different tokens for denoting string literals, like `` in Go)

- # in C and C++ is a marco

- // is a line comment in some languages. Others use #, or --

- Some languages use any of the following for multi-line comments: ```, /* /, and even {} is used. Whereas it's an execution block in some other languages

My point is you have to learn what all of these tokens mean regardless of whether they sit as a prefix or not. The that that they're a sigil doesn't change anything.

The real complaint people are making here is about specific languages, like Perl, overloading sigils to do magical things. That is a valid complaint but, in my opinion, it's a complaint against overloading tokens rather than sigils specifically. Much like a complaint about operator overloading doesn't lead to the natural conclusion that all operators are bad.

> don't communicate meta-information about the word.

We need to be careful about our assumption about whether a token effectively communicates meta-information because while I do agree that some tokens are more intuitive than others, there is also a hell of a lot of learned behaviour involved as well. And it's really* hard to separate what is easier to understand from what we've just gotten so use to that we no longer give a second thought about.

This is a massive problem whenever topics about code readability comes up :)

> I'll agree with you that the line between sigils and general syntax/punctuation is a bit of a blurry one - where do you stop?

shrugs...somewhere...? You can't really say there should be a hard line that a language designer shouldn't cross because it really depends on the purpose of that language. For example the language I'm currently working on makes heavy use of sigils but it also makes heavy use of barewords because it's primary use is in interactive shells. So stricter C-like strings and function braces would be painful in a read once write many environment (and I know this because that was my original language design -- and I hated using the shell with those constraints).

In a REPL environment with heavy use of barewords, sigils add a lot to the readability of the code (and hence why Perl originally adopted sigils. Why AWK, Bash, Powershell, etc all use them, etc).

However in lower level languages, those tokens can add noise. So they're generally only used to differentiate between passing values vs references.

But this is a decision each language needs to make on a case by case basis and for each sigil.

There also needs to be care not to overload sigils (like Perl does) because that can get super confusing super quick. If you cannot describe a sigil in one sentence, then it is probably worth reconsidering whether that sigil is adding more noise than legibility.

> sing my definition above, I think wrapping strings in quotation marks is a clear win because it fits our widely-held shared understanding that quotation marks demarcate and group a sequence of words. Single and double quotes behaving differently is unintuitive for the same reason while not conferring a corresponding benefit on experts.

Here lies the next problem for programming languages. For them to be useful, they need to be flexible. And as languages grow in age, experts in those languages keep asking for more and more features. Python is a great example of this:

- ''

- ""

- ''' '''

- """ """

- f""

...and lots of Python developers cannot even agree on when to use single and double quotes!

I tried to keep quoting simple in my own language but I ended up with three different ways to quote:

- '' (string literals)

- "" (strings with support for escaping and infixing)

- %() (string nesting. For when you need a string within a string within a string. Doesn't come up often but useful for dynamic code. A contrived example might look like: `tmux -c %(sh -c %(echo %(hello world)))` (there are certainly better ways you could write that specific code but you get the kind of edge case I'm hinting at).

As much as languages do need to be easy to learn, they shouldn't sacrifice usability in the process. So it is a constant balancing act trying to make something easy to learn, yet also powerful enough to actually have a practical use. Not to mention the constant push and pull between verbosity where some claim fewer characters (eg `fn` as a function keyword) improves readability because it declutters the screen from boilerplate, while others say terms like `function` are more readable because it is closer to executable pseudo-code. Ultimately you cannot please all of the people all of the time.

The official julia user developer survey for 2022 lists GitHub as the largest platform of people using julia which intuitively also seems fitting to me as it seems like the community is very pro "open code, open science". But checking the GitHub language trends (via https://madnight.github.io/githut/ and https://tjpalmer.github.io/languish/) you can see that Julia has been rather stagnant since 2019 w.r.t. some measures and only slowly growing w.r.t. others.

It seems to me they made the same mistake that I did in my GitHub archive queries, they do not filter bot accounts. JavaScript, without filter, is on top 1 because of dependabot. If you filter all bots then Python is number 1, see: https://madnight.github.io/githut/#/pull_requests/2023/1

Make sure you have Go installed https://go.dev/.

The Go Programming Language

When Go first shipped, it was already well-documented that the only stable ABI on some platforms was via dynamic libraries (such as libc) provided by said platforms. Go knowingly and deliberately ignored this on the assumption that they can get away with it. And then this happened:

https://github.com/golang/go/issues/16606

If that's not "getting burned", I don't know what is. "Trying to provide a nice feature" is an excuse, and it can be argued that it is a valid one, but nevertheless they knew that they were using an unstable ABI that could be pulled out from under them at any moment, and decided that it's worth the risk. I don't see what that has to do with "not being as broadly compatible as they had hoped", since it was all known well in advance.

Sadly, I think that is indeed radically different from Go’s design. Go lacks anything like sum types, and proposals to add them to the language have revealed deep issues that have stalled any development. See https://github.com/golang/go/issues/57644

I've been writing a lot about Go and gRPC lately:

I have a mountain of respect for Bell Labs and its contributions to the public welfare, and a lot of respect for the current group of alumni, mostly at Google, and mostly affiliated to a greater or lesser degree with golang. I have my differences with one or two of them (Pike telegraphs a wildly overcompensated imposter syndrome, but he’s almost as much of a genius as he acts like he is and who am I to judge on an overcompensated imposter syndrome, moreover when the guy in at the next desk over is Ken Thompson, who wouldn’t be a little intimidated by the legend).

With that said, golang is too opinionated for its level of adoption, too out-of-touch with emerging consensus (and I’m being generous with “emerging” here, the Either monad is more than an emerging consensus around the right default for error handling), and too insular a leadership to be, in my personal opinion, a key contender outside some narrow niches.

I’m aware that there are avid advocates for golang on HN, and that I’m liable to upset some of them by saying so, so I’m going to use some examples to illustrate my point and to illustrate that I’ve done my homework before being critical.

Many, including myself, became aware of what is now called golang via this presentation at Google in 2007 (https://youtu.be/hB05UFqOtFA) introducing Newsqueak, a language Pike was pushing back in the mid-90s with what seems to be limited enthusiasm no greater than the enthusiasm for its predecessor Squeak. Any golang hacker will immediately recognize the language taking shape on the slides.

I’ve been dabbling with golang for something like a decade now, because I really want to like it. But like a lot of the late labs stuff it seems to have suffered from the dangerous combination of the implications of Richard Gabriel’s Worse is Better observation: it was simpler, faster, cheaper, and ultimately more successful to incrementally adapt innovations from Plan9 into Linux (and other Unices), to adapt innovations from sam and acme into nvim/emacs (and now VSCode), and to adapt channel-based and other principled concurrency from Newsqueak/golang (not to mention Erlang and other more full-throated endorsements of that region of the design space) into now countless other languages ranging from things like TypeScript and Rust at the high end of adoption all the way to things like Haskell at more moderate levels of adoption. Ironically enough, the success of UTF-8 (a compromise for the non-ASCII world but the compromise that made it happen at all) is this same principle in action via the same folks!

And golang would be fine as yet another interesting language serving as a testbed for more pragmatic applications of radical ideas: but it’s got corporate sponsorship that puts Sun Microsystems and Java to shame in scale and scope, but done quietly enough to not set off the same alarm bells.

The best example of this is probably this GitHub issue: https://github.com/golang/go/issues/19991 (though there are countless like it). I’ve worked with Tony Arcieri, he’s brilliant and humble and hard-working and while we haven’t kept in touch, I keep an eye out, and he’s clearly passionate about the success of golang. But proposal after proposal for some variation of the Either monad has died on procedural grounds for nearly a decade, all while being about the only thing that everyone else agrees on in modern industrial PLT: TypeScript supports it, Rust supports it, C++ de-facto supports it via things like abseil and folly, and of course the hard-core functional community never even bothered with something worse in the modern era. You can even kind of do it, but there are intentional limitations in the way generics get handled across compilation units to ensure it never gets adopted as a community-driven initiative. Try if you don’t believe me (my golang code has a Result type via emacs lisp I wrote).

Another example is the really weird compilation chain: countless serious people have weighed in here, I’ll elide all the classics because most people making these arguments have their own favorite language and they’ve all been on HN dozens of times, but a custom assembly language is a weird thing to have done, almost no one outside the hardcore golang community thinks it’s sane, the problems is creates for build systems and FFI and just everything about actually running the stuff are completely unnecessary: there are other IRs, not all of them are LLVM IR if you’ve got some beef with LLVM IR, and given that go doesn’t seriously target FFI as more than a weird black sheep (cgo) there’s, ya know, assembly language. It’s a parting shot from the Plan9 diehards with the industrial clout to make it stick.

The garbage collection story is getting better but it’s an acknowledged handicap in a MxN threading model context, it’s not a secret or controversial even among the maintainers. See the famous “Two Knobs” talk.

Raw pointers, sum types, dependency management, build, generics that never get there, FFI: solved problem after solved problem killed by pocket veto, explained away, minimized, all with mega-bucks, quiet as a gopher corporate sponsorship fighting a Cold War against Sun and the JVM that doesn’t exist anymore marketed by appealing to the worst instincts of otherwise unimpeachable luminaries of computing.

There is great software written in golang by engineers I aspire to as role models (TailScale and Brad respectively as maybe the best example). I had to get serious about learning golang and how to work around its ideologically-motivated own-goals because I got serious about WebRTC and Pion (another great piece of software). But it sucks. I dread working on that part of the stack.

Go enums do suck, but that’s because we pay a very heavy price for golang being mainstream at all: we’ve thrown away ZooKeeper and engineer-millennia of garbage-collector work and countless other treasures, it sucks oxygen out of the room on more plausible C successors like D and Jai and Nim and Zig and V and (it pains me to admit but it’s true) Rust.

Yes there is great software in golang, tons of it. Yes there are iconic legends who are passionate about it, yes it brought new stuff to the party and the mainstream.

But the cost was too high.

It seems to be userspace accessible: https://github.com/golang/go/issues/66450

Something you should keep in mind regarding maps in Go. They don't shrink after elements are deleted runtime: shrink map as elements are deleted #20135