←back to thread

302 points Bogdanp | 5 comments | | HN request time: 1.269s | 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 #
k__ ◴[] No.44396960[source]
"it picked up its users mostly from the Python/Ruby/JS world rather than C/C++/Java"

And with the increasing performance of Bun, it seems that Go is about to get a whooping by JS.

(Which isn't really true, as most of the Bun perf comes from Zig, but they are targeting JS Devs.)

replies(1): >>44397867 #
rednafi ◴[] No.44397867[source]
Runtimes like Bun, Deno, or type systems like TypeScript don’t change the fact it’s still JS underneath — a crappily designed language that should’ve never left throwable frontend code.

None of these runtimes make JS anywhere even close to single-threaded Go perf, let alone multithreaded (goroutine) perf.

replies(1): >>44398255 #
1. frollogaston ◴[] No.44398255[source]
JS is perfectly designed for what it does, frontend and non-CPU-intensive backend code. It's never going to reach singlethreaded Golang perf.
replies(1): >>44398983 #
2. rednafi ◴[] No.44398983[source]
JavaScript was never designed for non-browser usage. It’s the community’s unquenchable thirst to use the same language everywhere that brought us here.
replies(1): >>44399087 #
3. frollogaston ◴[] No.44399087[source]
NodeJS about page makes its case pretty succinctly, JS was a good fit for IO-bound concurrent backends because of the event loop. This was at a time when no other major language/runtime had a good answer for this unless you count Erlang. Plenty of people using it didn't even come from the web frontend side, myself included.

npm was also maybe the first default package manager that "just works," unlike Python or browser JS.

replies(1): >>44399889 #
4. AgentME ◴[] No.44399889{3}[source]
A lot of people don't realize NodeJS was made because the creator wanted to make a runtime dedicated to asynchronous IO, didn't want to use a language with a pre-existing standard library and ecosystem built around synchronous IO, and realized that JS almost uniquely fit the bill. It was not built for the purpose of letting people who only knew JS use JS on the server.
replies(1): >>44400205 #
5. frollogaston ◴[] No.44400205{4}[source]
This tracks, cause the NodeJS website also doesn't mention anything about people already knowing JS. And imports worked completely differently between browser and Node, so they were pretty separate things at least at the start.