←back to thread

302 points Bogdanp | 3 comments | | HN request time: 0s | source
Show context
rednafi ◴[] No.44392307[source]
I’m glad that Go went the other way around: compilation speed over optimization.

For the kind of work I do — writing servers, networking, and glue code — fast compilation is absolutely paramount. At the same time, I want some type safety, but not the overly obnoxious kind that won’t let me sloppily prototype. Also, the GC helps. So I’ll gladly pay the price. Not having to deal with sigil soup is another plus point.

I guess Google’s years of experience led to the conclusion that, for software development to scale, a simple type system, GC, and wicked fast compilation speed are more important than raw runtime throughput and semantic correctness. Given the amount of networking and large - scale infrastructure software written in Go, I think they absolutely nailed it.

But of course there are places where GC can’t be tolerated or correctness matters more than development speed. But I don’t work in that arena and am quite happy with the tradeoffs that Go made.

replies(9): >>44392470 #>>44392882 #>>44393976 #>>44394789 #>>44395314 #>>44395527 #>>44395624 #>>44398142 #>>44398420 #
mike_hearn ◴[] No.44394789[source]
> fast compilation is absolutely paramount. At the same time, I want some type safety, but not the overly obnoxious kind that won’t let me sloppily prototype. Also, the GC helps

Well, that point in the design space was already occupied by Java which also has extremely fast builds. Go exists primarily because the designers wanted to make a new programming language, as far as I can tell. It has some nice implementation aspects but it picked up its users mostly from the Python/Ruby/JS world rather than C/C++/Java, which was the original target market they had in mind (i.e. Google servers). Scripting language users were in the market for a language that had a type system but not one that was too advanced, and which kept the scripting "feel" of very fast turnaround times. But not Java because that was old and unhip, and all the interesting intellectual space like writing libs/conf talks was camped on already.

replies(5): >>44395036 #>>44396542 #>>44396960 #>>44397814 #>>44398191 #
frollogaston ◴[] No.44398191[source]
Golang having solid n:m greenthreading day 1 was its big deal. Java has had no good way to do IO-heavy multitasking, leading to all those async/promise frameworks that jack up your code. I cannot even read the Java code we have at work. Java recently got virtual threads, but even if that fixes the problem, it'll be a while before things change to that. Python had the same problem before asyncio. This isn't even a niche thing, your typical web backend needs cooperative multitasking.

I'm also not fond of any of the Golang syntax, especially not having exceptions. Or if you want explicit errors, fine, at least provide nice unwrap syntax like Rust does.

replies(2): >>44399022 #>>44399279 #
cogman10 ◴[] No.44399279[source]
Java 21 has n:m green threads, but with caveats. Java 24 removed a major source of the caveats.
replies(2): >>44400277 #>>44400464 #
computably ◴[] No.44400464[source]
I'm sure you're already aware but for those who aren't - Java 21 was released in 2023. Golang 1.0 was released in 2012.
replies(1): >>44403029 #
pjmlp ◴[] No.44403029[source]
In 2012 we could do much of the same stuff with Java 5 concurrency framework and futures (aka promises everyone raves about on JS land), with the advance that scheduling can be customised.
replies(1): >>44405691 #
1. frollogaston ◴[] No.44405691{3}[source]
That's what I meant by unreadable code. You have to twist everything to work with whatever async framework.
replies(1): >>44406651 #
2. pjmlp ◴[] No.44406651[source]
Have you ever had to write down channel sending dependencies graph?

I had to, to make sense of whatever was going on.

replies(1): >>44426393 #
3. frollogaston ◴[] No.44426393[source]
If this is an app backend, you aren't dealing with Golang channels directly. Your webserver or whatever it is spawns a new goroutine (greenthread) for each incoming request, then you use blocking calls without worrying. Looks similar in JS but the event loop handles it instead, and you async/await stuff. JS webpages and app frontends also don't worry about this.

If this is systems programming, yeah you're reasoning about channels, but that's mostly the same in any language. Golang has slightly nicer support for that if anything.