Ethan

What I mean is, from the perspective of performance they are very different. In a language like C where (p)threads are kernel threads, creating a new thread is only marginally less expensive than creating a new process (in Linux, not sure about Windows). In comparison creating a new ‘user thread’ in Go is exceedingly cheap. Creating 10s of thousands of goroutines is feasible. Creating 10s of thousands of threads is a problem.

Also, it still uses kernel threads, just not for every single goroutine.

This touches on the other major difference. There is zero connection between the number of goroutines a program spawns and the number of kernel threads it spawns. A program using kernel threads is relying on the kernel’s scheduler which adds a lot of complexity and non-determinism. But a Go program uses the same number of kernel threads (assuming the same hardware and you don’t mess with GOMAXPROCS) regardless of the number of goroutines it uses, and the goroutines are cooperatively scheduled by the runtime instead of preemptively scheduled by the kernel.

Key point: they’re not threads, at least not in the traditional sense. That makes a huge difference under the hood.

Really? Huh, TIL. I guess I’ve just never run into a situation where that was the bottleneck.

Definitely not a guarantee, bad devs will still write bad code (and junior devs might want to let their seniors handle concurrency).

It’s safe to assume that any non-trivial program written in Go is multithreaded

You can also just tell GitHub to not do that.

Unless I have an external monitor, keyboard, and mouse, using an external keyboard with a laptop is a shitty experience for me. And if I’m at home and trying to get work done, I’m using my desktop PC.

Why are you memeing about me? I don’t appreciate being made fun of.

If your job is to make websites and you make sites that don’t work on a browser that has over 100 million users you’re not doing your job.

That’s an artifact of JavaScript, not JSON. The JSON spec states that numbers are a sequence of digits with up to one decimal point. Implementations are not obligated to decode numbers as floating point. Go will happily decode into a 64-bit int, or into an arbitrary precision number.

hackthebox is essentially a puzzle solving platform where the puzzles are designed to teach you hacking. You’re not supposed to hack the platform.

I was trying to make a point without starting a flamewar that was beside the point. Personally I’d never choose a dynamically typed language for a production system. That being said, Python and Ruby complain if you try to add an array, dict/hashmap, string, or number to another (of a different type) so they’re certainly more sane than JavaScript.

I thought it was clear I was saying JavaScript is not a sane language for this very reason

Sure. But in a sane language doing something totally nonsensical like that is an error, and in a statically typed language it’s a compiler error. It doesn’t just silently do weird shit.

I used GitLab’s version of Copilot when it was free and that was net helpful. It predicted for loops and stuff and was close enough, enough of the time that it was net positive. Not enough that I’d actually pay for it…

As someone whose first language was C, I plan to never use C++ for anything more than programming an Arduino precisely because of the multitude of pointer types. A pointer should just be a pointer. Having five hundred different flavors of pointers is confusing as fuck.

Ananace and the article they linked are using their dislike of Go to conclude that it’s a bad language*. It is not a bad language. Every language has hidden complexity and foot guns. They don’t like Go. Maybe you won’t like Go. That’s ok. But that doesn’t make Go a bad language. The language designers are very opinionated and you might dislike them and their decisions.

I haven’t used Rust but from what I’ve seen, it’s a lot less readable than Go. And the only thing more important than readability is whether or not the code does what it’s supposed to do. For that reason I doubt I’ll ever use Rust outside of specific circumstances.

*I’m using “a bad language” as shorthand for “a language you shouldn’t use”. Maybe they don’t think it’s bad but amounts to the same thing.

I think it’s a joke about the song being copyrighted

Agreed. Even self-reviewing a few days after I wrote the code helps me see mistakes.

Ah, yeah that makes a lot more sense