For what it’s worth, I agree with you about branches, and there are various ongoing discussions about how to make working with branches more convenient. I use an experimental feature called “advance branches” that makes it mostly fit my workflows, and the other benefits of jj are sufficient that I haven’t switched back to git.

I create log files of runs, temporary helper scripts, build output, etc. in my working copy all the time.

The solution to this is to just have a more aggressive .gitignore. But also, note that the “working copy commit” isn’t generally something you want to push or keep; think of it more like a combination of the git staging index and an automatic stash.

Apparently the JS name was selected and announced in partnership with Sun from the very beginning, and Sun had the copyright over both Java and JapaScript up until the acquisition by Oracle. I had no idea, but that makes perfect sense.

Oracle? Oracle owns Java, not JavaScript.

Edit: mea culpa! Sun owned both!

Do you mean Dan Luu, or one of the studies reviewed in the post?

Yeah, I understand that Option and Maybe aren’t new, but they’ve only recently become popular. IIRC several of the studies use Java, which is certainly safer than C++ and is technically statically typed, but in my opinion doesn’t do much to help ensure correctness compared to Rust, Swift, Kotlin, etc.

I don’t know; I haven’t caught up on the research over the past decade. But it’s worth noting that this body of evidence is from before the surge in popularity of strongly typed languages such as Swift, Rust, and TypeScript. In particular, mainstream “statically typed” languages still had null values rather than Option or Maybe.

Note that this post is from 2014.

Partly because it’s from 2014, so the modern static typing renaissance was barely starting (TypeScript was only two years old; Rust hadn’t hit 1.0; Swift was mere months old). And partly because true evidence-based software research is very difficult (how can you possibly measure the impact of a programming language on a large-scale project without having different teams write the same project in different languages?) and it’s rarely even attempted.

Notably, this article is from 2014.

Most of those comments are actually just random people arguing about the merits of the experiment, not continued discussion with the bot.

Also, the bot is supposed to be able to run builds to verify its work, but is currently prevented from doing so by a firewall rule they’re trying to fix, so its feedback is limited to what the comments provide. Humans wouldn’t do great in that scenario either. (Not to say the AI is doing “great” here, just that we’re not actually seeing the best-case scenario yet.)

You don’t have to imagine it; you can browse the Linux Kernel mailing list!

That’s called a mailing list

/s

TypeScript is a language, and traditionally languages are considered separate from their implementations. When I first saw the headline I hoped maybe it meant a non-JS runtime for compiled TS, and I’m well aware of the difference. Yes, that would be a much larger undertaking than porting the compiler to a new language, but the headline doesn’t indicate how large a project this is, and Microsoft certainly has the resources to write a new backend (even a native-code one) for the TS compiler.

In addition to not actually being correct, I don’t think the information you’ve provided is particularly helpful in answering OP’s question.

The first part is confusing what “middleware” means. Rather than “duplicating” functionality, it connects libraries (I’m guessing this is what you meant). But that has nothing to do with a language being compiled versus “directly executed”, because compilation doesn’t connect different services or libraries; it just transforms a higher-level description of execution into an executable binary. You could argue that an interpreter or managed runtime is a form of “middleware” between interpreted code and the operating system, but middleware typically doesn’t describe anything so critical to a piece of software that the software can’t run without it, so even that isn’t really a correct use of the term.

The second part is just…completely wrong. Lisp, Fortran, and other high-level languages predate terminal shells; C obviously predates the shell because most shells are written in C. “Most original code” is in an actual systems language like C.

(As a side note, Python wasn’t the first scripting language, and it didn’t become popular very quickly. Perl and Tcl preceded it; Lua, php, and R were invented later but grew in popularity much earlier.)

Pretty much all languages are middleware, and most of the original code was shell/bash.

What? I genuinely do not know what you mean by this.

Yeah, I was particularly glad to see the change in loop variable semantics become a stable part of the language. That was a terrible footgun.

There are other things I dislike about Go, but I do think it’s improving while maintaining its better qualities, which is no small feat.

It is similar to old error codes, but I feel that this makes one always have to be mindful of error handling and the non happy path

Technically you need a separate linter (errcheck) to ensure you don’t just ignore errors. This is…not great. (That should have been a compiler error.)

Yeah, consistency is good, which is why it’s good to follow the spec. I’m saying that the decision to make errors be flat strings in the spec was a bad one. A better design would be what you have, where code is nested one level below error, plus permitting extra implementation-defined fields in that object.

The spec requires errors to be a single string, and also mandates using the space character as a separator? I’m not a fan of deviating from spec, but those are…bad choices in the spec.