Like, structs, maps, and slices are things you can explain to someone in 5 minutes with no software engineering or computer science background. They map to real-life concepts that people use every day. Do you have an ordered todo list? Ever use a dictionary? Ever look at a driver's license, where every license has the same fields but different information? Congratulations, you now intuitively understand the core data structures in Go code.

There is also no way to golf down code. Want to map the elements of a slice into another slice? That's a for loop. Want to reduce over a slice? That's a for loop. People get super excited about giving each sort of operation like this its own name, map reduce foldr foldl zip... but like many things, the names hide what's actually going on, where as Go just makes you type what you're doing into your editor. This seems to annoy people greatly.

The "it's for dumb people" is riffing off a comment made when Go was first introduced; they were aiming for a language that would be easier for large teams to maintain. People new to the codebase could show up and start being productive. Fixes could be applied en masse across the entire codebase. So that's where that comes from. I guess we contrast it with C++, where one missed reference count increment here, or one stack variable returned from a function there, and you have an impossible to debug nightmare that is blowing up in production. Knowing not to make those mistakes makes you smart, and being new and having the system blow up in your face is a great learning exercise, right? Why should you get to come play with my system the day you graduate from college? You have to earn it! So I think that's where the hate comes from. If the junior engineers can start contributing, you're going to have to do something other than troll HN all day or you'll be rEpLaCeD.

A lot of criticisms of Go are right. You can absolutely type in the most dogshit broken programs imaginable. (Most of them start by overusing the keyword "interface", BTW.) There are lots and lots of traps for the newcomers and even the unwary ("invalid memory address or nil pointer dereference"! what's a nil interface value? why is every goroutine you started in that loop see the same value of the loop variable? your goroutine has no way of exiting, so after 100,000 web requests your app gets OOM killed.) Tons of stuff you have to learn to truly be fluent.

It's missing a lot of input from computer science. Structured concurrency? Software transactional memory? Algebraic data types? Classes? Metaclasses? And, it makes a lot of mistakes whose harm is well-documented. ("Nil in 2023!?") While Go tries to be a simple model of the computer, the simplicity is not free. There is no claim that abstractions are zero-cost. Garbage collection WILL use your CPU. Looking up an element in an array or slice has a bounds check added! That memory you got from the OS wasn't zeroed, so guess who set that variable you just declared to the zero value. You just used a resource and you didn't get to decide. That sort of thing can make a certain type of person furious.

There is also a lot of good. The standard library is actually useful. Using third-party modules is easy, and requires no registration with some intermediary to publish one. (Also fetching modules can't print advertisements. I have no idea if any Go developers drunkenly drove their motorcycle into some pedestrians and now need a job, whereas with Javascript, it tells me that every time I build my app! Frankly, my dear, I don't give a damn. I am in the middle of my workday!) You are only nagged about security vulnerabilities if you actually call into the vulnerable code. The speedy compiler outputs a binary that can run on pretty much any computer of the right OS and architecture. You can trivially cross-compile. Everything that is tedious about the mechanics of making something that people can use largely Go away with Go. You can open up your editor, type in a program, and send it to other people to use. That's really nifty.

At the end of the day, Go isn't the last programming language society will ever develop. But you can make a lot of stuff with it. If you've ever been to an art museum, you might notice that you rarely see an example of some famous artist's pencil. You see their work. That's how programming languages should be; get out of the way, and let your work speak for itself. A lot of people really don't want their work to be front and center, and those people really don't like Go.

I think it, I type it, it works and it works fast, with minimal cognitive overload.

One really good example though is error handling - they've pretty much looked at C and decided that that was the best we can do, so now every Go program is full of nilchecking boilerplate.

The whole design of the language generally feels like as if it was made for unthinking drones.

Sorry but this is unacceptable. You post a generic comment hating on a popular language and then when asked for the specifics you bail out because you can't answer in detail for whatever reason. On top of that you then insult the language authors.

That's classic troll behavior, another commenter here asked you to stop, I'm going to do the same and flag your comments in this thread because they're strictly speaking completely off topic.

I've said it another comment but I'll directly include it here: "I have picked 20 years specifically since it was around 2003-2005 when Java and C# got generics. Obviously, they were also more than 20 years late but I compared it to mainstream languages people are more likely to know about or more likely to compare it with." Generics are a feature Go has lacked for a very long time, and I think it's a bit misleading to claim that including them is some revolutionary thing which the article suggests. ("There are many reasons to be excited about generics in Go" or "The future of Go generics is bright")

Also, I don't see how it is insulting the language authors if I point out (what I think is) a bad design decision they made. They are not horrible human beings or anything for so, I am not attacking them.

I'd like to disagree with the trolling and off-topic assessments. I would understand if it was a tangential comment about some other problems of Go (like nilchecking for example), but I replied directly to the point the article was addressing. I see the argument that it could potentially invite hostile behaviour, but I'd like to believe in the civility of the forum.

Finally, to expand a bit on the "what features Go needs" question of GP, for example it doesn't support most unicode characters deliberately (only letters and digits), proper exceptions, unions, sum types, enums, and the language doesn't care about correctness at all, only about the "common use case" (see the nanotime/time.Time issue for example, they implemented it the worst possible way)

---

It does endlessly fascinate me how 20 years after the definitive wisdom against exceptions appeared [1], programmers still keep insisting that seeing all code paths laid out bare on the page is somehow worse than keeping them implicit and hidden.

[1] https://www.joelonsoftware.com/2003/10/13/13/

"I think the reason programmers in C/C++/Java style languages have been attracted to exceptions is simply because the syntax does not have a concise way to call a function that returns multiple values, so it’s hard to write a function that either produces a return value or returns an error."

Effortlessly predicting the direction of future languages like Go/Rust/Zig decades ahead of their time. Excellent taste.

The try/throw/catch model is painful and Go opted for errors as values. It makes code more verbose but also much more predictable. Pick your pain.

No problem, we can wait. When will you be able?

Bare bones and just getting started, but I’ll hopefully be writing more about the Go projects I’ve been getting into on the side. Everything around the theme of plain technology, simple as can be.

That said, if any of you oldheads have links to such things, do share - always curious to learn more about the beige age. Nostalgia is a hell of a drug and I’m here for that secondhand.

https://www.goodreads.com/book/show/984598.Masters_of_Decept...

(even though it's not 'real vim', it's good enough for using both cmdline vim and vscode without the brain having to switch in and out of 'vim mode')

Combine that with the fact that all the UI elements are not vim-ified. In vim, since everything is a pane and a buffer, you just think "I want to select the panel to the left". Regardless of if it's a plugin view or a file or whatever.

In vim emulator's, that's never the case. It's really not the same, but better than nothing. The vscode plugin and the IntelliJ one are both pretty good compared to previous ones that I tried. But the IDEs are just incompatible with the vim ideology, in my opinion.

Just a little counterpoint basically - I don’t think you need Vim’s entire editor model to get a lot of value out of it!

My comment wasn't meant to dissuade anyone from trying the vim plugins. I was just trying to explain why someone would consider the vim emulation plugins not as good as the real thing.

If nothing else, the performance characteristics of vim are predictable (to me, after all these years) and there are various ways to work around any problems that occur (disabling plug-ins, etc).

Not once in the past eight years have I had to use tabs for something. The buffer list, yes. The argument list, yes. Tabs, no.

If all you care about is buffers, what do you miss about them in vscode or IntelliJ? Their idea of buffers is the same as vim, as far as I can tell.

Or is the problem that the IDE functionality is not implemented as buffers? So you can't use your normal keys in non-text places? That was what I was referring in the second part of the comment.

[0] https://github.com/helix-editor/helix/issues/2295#issuecomme...

The workflow he is describing works with :bufdo, :argdo, :bn, :n, etc.

He is also not describing what is special about tabs. Tabs in vim are groups of windows.

I’m not sure if you were asking me, but no, buffers are not the reason why I exclusively use vim.

> The workflow he is describing works with :bufdo, :argdo, :bn, :n, etc.

It's different because you are losing context. It's not about finding the right buffer, I understand buffers, I have no problem switching between them and finding them. It's about organizing windows in a way that makes sense and then quickly switching between them.

> He is also not describing what is special about tabs. Tabs in vim are groups of windows.

Exactly! And no other editor implements it that way. It's about context switching quickly. I setup my tabs per context and then I can quickly switch back and forth between them, and have all my windows like I left them.

No other editor does it like that (maybe emacs?), because it does not have the concept of vim tabs. Other editors use "tab" to mean "vim window". I'm constantly wasting time recreating window layouts in other editors depending on what I'm working on.

> I’m not sure if you were asking me, but no, buffers are not the reason why I exclusively use vim.

I'm asking what is missing from the IntelliJ vim plugin when it comes to buffers. The concept of buffers is not unique, most modern IDEs implement them the same way. It's why I'm surprised that you mention that buffers are the killer feature of vim, since I don't see anything unique about them compared to other editors.

I'm sorry, I think we have our wires crossed :)

I didn't say that buffers are the killer feature of vim — quite the opposite.

I was replying to the opening sentence of your comment, in which you said:

> The problem with every fake vim plugin is that the underlying editor does not implement tabs the way vim does.

My argument is that problems with vim-like plugins in IDEs like VSC run deeper than just the one you pointed out, especially given — in my opinion — neither tabs nor buffers nor windows are the killer feature of vim. But I can see how my comment can be misinterpreted given I said "vim is all about buffers", which in hindsight I think I worded poorly.

there are almost always quirks, but the biggest issue tends to be when bridging the gap between vim and the GUI itself, particularly around the modality of vim vs graphical autocomplete.

If you're less experienced as a vim user these emulators are probably perfectly fine, but as someone who has been using vim for something like 20+ years, they _always_ feel just off enough that I either just go back to vim or edit the way the editor originally intended.

I've actually had this with HN in the last days; I've ditched Reddit for HN because it contained a lot more worthwile content and valuable discussions [0], but with the Twitter shitshow I've come to enjoy a lot of snarky, unproductive discussions again. Maybe it's time to enable noprocast.

[0] Actually, it was mostly ideological reasons, but having HN as a "drop-in" replacement/upgrade helped a lot.

Wrote this script today, that just stops me seeing submissions from sites I know won't have good technical discussions. Might be useful for others.

    const boringDomains = ["twitter.com", "newyorker.com", "nytimes.com"]

    Array.from(document.querySelectorAll(".titleline > a"))
        .filter(elem => boringDomains.some(domain => elem.href.includes(domain)))
        .map(elem => elem.parentElement.parentElement.parentElement)
        .flatMap(elem => [
            elem,
            elem.nextElementSibling,
            elem.nextElementSibling.nextElementSibling]
        )
        .forEach(elem => elem.remove())

I found that at least for myself, this was just a lie I kept telling myself. HN contains almost zero actionable content, and I've not been an epsilon better off for reading it. I come to see it as infotainment.

Now it’s more a news aggregator. It’s my fault too, I don’t blog about the company I’ve created, and people can learn how to create proper startups in many places.

I feel like this is the case for a lot of productivity tools; every once in a while I find myself browsing the status-quo of the next generation of todo apps that have had far too much design work spent on their website for what it does. 9 times out of 10 it's a grift to sell a $15 / month subscription for syncing across devices and its added value is tiny compared to just using a text editor, lol.

30 minutes later... well got to keep my regex skills up to date else i'll lose them

I don’t have social media on my work computer except LinkedIn. I can’t tell you how many times a day I quickly open a new tab and head to LinkedIn (where I’m not even that personally active, mind you) to just get a quick hit of a distraction.

But the tricky part is remembering to nudge myself into starting tidying etc..

I feel sorry for my kidneys.

In retrospect, I’m amazed I made it through high school without snapping, what with such mornings and going home when it was already completely dark out. Teenagers are a different breed.

Since then, I’ve been getting so excited about people just writing their own solutions for things that might already be doable on existing platforms. Like there are plenty of sophisticated, full-featured blog platforms out there, but I love seeing somebody write and host their own because they can and want to.

I’m excited by people writing their own stuff, and the possibility to do so myself as well. Reinventing the wheel can probably go too far in a professional context, but if it’s your free time and something you want to make and learn about and curate to your own specifications and the simplicity of your individual situation, that’s awesome.

Be well, stranger!