I’m now 1 year in to working in Go having been mostly C++ and then mostly large-scale Python dev (with full type annotation).

Frankly, I bristle now at people giving Python a hard time, having worked with Go and I now hate Go and the de-facto ethos that surrounds it. Python may be slow, but for a lot of use cases not in any way that matters and modern computers are very fast. Many problem areas are not performance-limited, and many performance problems are algorithmic, not from raw statement execution. I even rewrote an entire system in Python and made it use 20% of the CPU the former C++ solution used, while having much more functionality.

The error returns drive me nuts. I looked around for explanations of the reasoning as I wasn’t seeing it, and only found bald assertions that exceptions get out of control and somehow error returns don’t. Meanwhile standard Go code is very awkward to read because almost every little trivial function calls becomes 4 lines of code, often to do nothing but propagate the error (and errors are just ignored if you forget…). With heavy use of context managers, my error and cancellation handling in Python was always clean, clear, and simple, with code that almost read like whiteboard pseudo-code.

The select statement can be cool in Go, but then you realize that literally 98% of the times it’s used, it’s simply boilerplate code to (verbosely) handle cancellation semantics via the context object you have to pass everywhere. Again, literally code you just don’t need in exception-based languages with good structures to manage it like Python context managers.

And every time you think “this is stupidly awkward and verbose, surely there’s a cleaner way to do this” you find people online advocating writing the same boilerplate code and passing it off as a virtue. e.g. get a value from a map and fall back to a default if it’s not there? Nope, not offering that, so everyone must write their own if foo, ok := m[k]; !ok {...} crap. Over and over and over again the answer is “just copy this chunk of code” rather than “standard libraries should provide these commonly needed utilities”. Of course we can do anything we want ourselves, it’s Turing Complete, but why would we want to perpetually reinvent these wheels?

It’s an unpopular language, becoming less popular (at least by Google trends) and for good reason. I can see it working well for a narrow set of low level activities with extreme concurrency performance needs, but it’s not the only language that could handle that, and for everything else, I think it’s the wrong choice.

Go code is always an abomination.

I know about window managers and how using them will reduce the memory usage by system a lot because they are less bloated etc.

Ehhhh… I think it’s more “not using a curated general-purpose DE”, rather than “using a WM”. All graphical systems include a WM, and a DE in some senses is more of a concept or category than a concrete thing. The choice is whether it’s one you cobble a DE together yourself, or use a pre-configured, curated one.

Many people use stand-alone WMs and then create their own DE, but quite a few of us put the WM of our choice within existing DE because we want the WM but have no interest in re-inventing all those DE wheels (and/or have >4Gb memory so the “bloat” is not an issue). In my case it’s i3 on Gnome via gnome-flashback.

Curated DEs do tend to use more resources - typically mostly memory - partly because they tend to be comprehensive for diverse users. Rolling your own minimal DE for your personal needs can often be lighter weight. If you have a very constrained system then it can be beneficial, though that circumstance is more and more unusual these days when 8Gb of memory is often considered “minimal”.

The main reasons for making your own DE is to do things exactly the way you want, at the expense of having to do it. Beware though, there will be various helpful features of DEs you may not realize you appreciate until you have realize you don’t have them. E.g. what happens when you plug in a USB drive? Nothing, by default - a DE usually manages that. SSHing into servers a lot - a credentials agent is nice - better add one of those…

A lot of rolling your own DE is months or years of “oh yeah, that is a useful thing to have; I need to find tools and configure them to do that”. Conversely, dropping your WM of choice into another DE is often a case of “huh, that happens automagically; nice!”.

Dynamic typing is shit. But type annotation plus CI checkers can give you the same benefits in most cases.

Once you need performance

If you need more performance. Many things just don’t.

Pretty bizarre if people do this. I’ve never heard it to mean anything but linoleum.

But a lot of people in the US use the word “turf” to specify not turf (i.e. artificial turf), so there’s no reason for words to mean things.

What? One of linoleum’s benefits is not off gassing and not being made from fossil fuels. Are you thinking of vinyl?

Not at all. It allows you to install and use whole suites of tools and libraries without any pollution of or dependencies on your host system. It also allows you to define the whole setup in a file so it’s trivial to recreate on another machine

Well aerosols are tiny particles, but often created and propelled using pressurized glasses.

Funniest is when a vim user says that, since emacs includes a vim.

All that is not in a text editor. A text editor is in all that. A few text editors actually.

But most of the world did not have the US education system. I’d say only some Americans have heard of Oregon City, and very few non Americans.

Hilarious to have to look this low for it, but who want to stand up and declare themselves mainstream.

Polished, reliable, and solid, and snaps are not a big deal or an insidious evil, and neither is Canonical. They make missteps for sure. But with containers etc stability is more important than immediate updates and it’s excellent about kernel updates for new hardware. It’s slick Debian, and if the fuckery ever gets real switching to Debian is easy.

floppy drive, hard drive, sechs drive — we got building blocks. Crowd sourcing a joke could work.

Avoid categories where a lot of items have fake specs (storage devices, LED bulbs, anything that claims a runtime on a Li-Ion battery)

I’d say be aware rather than avoid. E.g I bought a $10 camping lantern that claimed 2.5 times its true capacity, but it still runs for hours and is a great, well designed, if flimsy, product for the price.

The sort option by “orders” is good for this. Far from infallible but still useful.

Excellent, the punchline is sorted, now we just need the rest of the joke.

That’s a much broader term.

deleted by creator

Although I came from vi (pre-vim and pre-evil) and still have the muscle memory, I don’t and haven’t used it myself.

I hear it described as a “nearly complete” and “very comprehensive”. There is definitely a solid community of people using and enjoying it, but on the other hand there are always some reports of getting tired of having to work through, and sometimes extend, an additional interface layer, so in the long run being happier to just adopt the default bindings.

I know there are a few areas where trying to follow common vim workflows doesn’t work as well. Historically the performance of line number display been weak in Emacs, though I believe it’s recently much improved. A lot of people seem to make heavy and constant use of it in vim but conversely for me (and I think it’s more common in Emacs) it’s only an occasional, transient need when some external log or error quotes a line number, so I have them only displayed when I hit the go-to-line binding.

Overall, I think the most frustrating issues people have trying to adopt Emacs from vim are due to trying to impose their specific familiar vim workflows. The most obvious example is people concerned with startup time, but for more typical Emacs workflows it’s a non-issue. Users typically stay in Emacs rather than jumping in and out of it from a terminal (and if you really want that workflow, you run one instance as a daemon and pop up a new client to it instantly). My Emacs instance’s uptime usually matches my computer’s uptime.

The draw of Emacs is not about it only being an editor so much as a comprehensive and programmable text environment. It is a lisp-based text-processing engine that can run numerous applications, the primary being an editor (the default, or evil, or others…) but also countless other applications like file managers, VC clients, subprocess management and many others. It 95% replaces the terminal for me, and many other tools. So it’s the environment through which you view and manipulate all things text that is very accessible to modify and extend to fit your needs. Hence the joke about it being an OS is pretty apt, though to believe it needs a good editor implies vim isn’t a good editor ;).