Thing is, cleaning up slop, AI or otherwise, is miserable, slow, difficult work. It’s why we get caught in rewrite traps.

I gained a lot of understanding noodling with extreme low-level memory access etc, but in reality almost all the coding I ever did early on was in C with stdlib etc, which is shaped more by low-level realities of the CPU, but is still full of abstractions. Abstractions that were often opaque to us as well, because this was before Linux and ubiquitous open source.

Sure everything is a few more layers removed from the simple hardware these days, but once it’s a black box, it’s a black box. A lot of the feeling of being closer to the hardware is pretty meaningless.

Sure a variable in C is really just a way of referring to a piece of memory, while in Python it’s some sort of data structure in a mapping most of us don’t really know the exact nature of, but in the end the difference is rarely is of any significance and most of us only have a similarly vague idea of how the compiler works it out for us in C.

It’s so much better! Tooling is many orders of magnitude better and so many libraries give you deep power from an easy API. What used to be a team and 18 months is a library install and a day so you’re free to do much bigger things.

Christ even version control. The shit I put up with over the years.

Compose minus minus for me. I use it frequently.

Fair point

I f’ing love emacs, but don’t get cocky. It’s a security disaster.

Well, if you use any packages fetched from the net anyway.

I’m pretty sure I’ve heard effectively the same core joke but better composed. Can’t remember it though because at best it’s middling funny.

Things is you don’t crunch numbers in Python code, you do that in libraries called from Python.

It’s a few statements of orchestration and any heavy lifting is encapsulated compiled code.

You don’t do tight loops on Python, or if you do you’re using it wrong.

Master’s degrees though — racist as fuck.

Golang is technical debt in language form. A language that gained limited and now sagging popularity, for good reason. I hate to work in Java but hate golang more. It’s the lightsaber of programming languages. I’ve got shit to do, give me blasters and all the rest. And I’m not interested in wanking myself off about how I did it all with channels. [edited for typo/clarity]

Hmm, I’m not taking about hacking defaults, I’m talking about hacking functionality. I’m talking about making capabilities that didn’t exist, all seamlessly part of my typical integrated text manipulation environment (that’s way broader than editing)

The unique power of emacs is it doesn’t have typical boundaries, so integrated personal unique functionality is possible. May well be a huge downfall, security wise - it rides a lot on security through obscurity.

Frankly it’s taken me decades to properly appreciate how my computer experience can be so fungible. Most computer systems don’t allow it.

Lazy about tooling? The biggest point people make is that IDEs tend to work out of the box while the likes of vim or emacs need configuration and have an initially steep learning curve.

Well, as in this discussion, some people sometimes also tend to raise a lot of features as if only IDEs have them, but that’s frequently just ignorance.

Hackability not on your list? It’s the ability to extend and adapt it to my particular needs that, above many other things, means I am too deep into Emacs to even imagine leaving.

Plugins are a very weak substitute that cannot provide that utility, and I notice Helix doesn’t even offer plugins. That sword does have the horrendous opposite edge of almost total lack of security, so perhaps I’ll regret that one day. There are so many ways I value Emacs that isn’t matched by any other text environment that none of the others are even on my radar as possible replacements.

Out-of-the-box experience is very weak on Emacs, but I’m decades past that being a concern to me directly, though it does inhibit newcomer uptake.

Other than that, for me it ticks your boxes while barely scratching the surface of its merits. At least its speed and latency is not something I notice any meaningful benefit when working with something that people praise, like vim. Come to that most of the time like now, typing into a browser text box, I’m not even bothered by latency, and that’s way worse than Emacs.

It’s biggest failing to me is working remotely when there’s significant network latency, where VSCode is clearly superior, but I have neither the time, nor probably the ability, to fix it.

Dude, your þey business immediately turns 80% of readers against any message you may be trying to convey while the rest will be saying “Okay, they may be an insufferable dweeb, but that doesn’t mean they’re wrong, so let’s try to give it a fair read”…

I swear some of you people think some of the most talented and productive experienced devs use vim and emacs because of some snobbery or because they haven’t noticed vscode etc exist.

It really is unique.

Well j = i + 1, and drop the equality test.

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.

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