Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Generics can make your Go code slower

planetscale.com

Post reply on HN
Print view View original

351–360 of 418 posts

Re: Generics can make your Go code slower

#351

Post by imtringued »

dcgudeman wrote: post #120
dahfizz wrote: post #93

Earlier quoted context omitted.

You're arguing against a straw man. I could just as easily say "why not make every line of code it's own function?" C has libraries, and my comment made it clear that they are useful. Argue against my actual point: By not having a bespoke package manager, and instead relying on the system package manager, you end up with higher quality dependencies and with dramatically less bloat in C than other language ecosystems.…

I don't agree with your assessment that libraries in C are higher quality. Additionally I have yet to see a system package manager that enables developers to install dependencies at a specific version solely for a project without a lot of headaches. All the venv stuff in python is necessary python dependencies are installed system wide. The idea that the C/C++ ecosystem is better off because it doesn't have its own p…

I'm one of the few humans on the planet that installs his dependencies inside the project folder and uses PYTHONPATH.

Re: Generics can make your Go code slower

#352

Post by pornel »

pjmlp wrote: post #315
pornel wrote: post #284

Earlier quoted context omitted.

If you dig deep enough into the Turing Tarpit, you can write these in JavaScript too (in fact, some of these have already been written). It's merely a disagreement about what the label "systems programming" should mean, rather than about capabilities and performance of the Go language. Objectively and undeniably Go relies on garbage collection, and C/C++/Rust don't. Google's implementation of Go prefers fast compilat…

A disagreement indeed, https://people.inf.ethz.ch/wirth/ProjectOberon/Sources/Kerne...

I'm saying forks aren't for eating soup, and you're showing me soups eaten with a fork.

In case of languages' general capabilities/applicability, I don't think singular counterexamples are sufficient, because they prove "can", rather than "should". Turing Tarpit means you can push languages way beyond their appropriate use-cases.

There are also weird cases like Java smart cards and LISP machines, but I don't think it's useful to use these exceptions to classify Java and LISP as "assembly" or "machine" languages. Go does very well in the network services niche, but you can also write such network services in Bash (determined-enough people have written Bash HTTP servers). You can write small shell utilities in Go too. Does this mean Go and Bash are the same type of language?

The lines are blurry, but you have to draw a line somewhere, otherwise every language is a shell scripting systems programming assembly machine language.

Re: Generics can make your Go code slower

#353

Post by afiori »

chrisseaton wrote: post #309
coder543 wrote: post #283

Earlier quoted context omitted.

From a conceptual point of view, I agree, but... in practice, stacks are incredibly cheap. The entire set of local variables can be allocated with a single bump of the stack pointer upon entry into a function, and they can all be freed with another bump of the stack pointer upon exit. With heap allocations, even with the simplest bump allocator.. you still have to allocate once per object, which can easily be an orde…

> you still have to allocate once per object Why can’t you bump once to allocate enough space for multiple objects?

No, outside special code it is impossible to know at compile time how many heap allocation a function will have.

The stack has the requirement that its size must be known at compile time for each function. In oversimplified terms its size is going to be the sum of size_of of all the syntactically local variables.

So for example you cannot grow the stack with a long loop, because the same variable is reused over and over in all the iterations.

You can instead grow the heap as much as you want with a simple `while(true){malloc(...)}`.

Re: Generics can make your Go code slower

#354

Post by afiori »

ClumsyPilot wrote: post #289
throwawaylala1 wrote: post #273

Earlier quoted context omitted.

If you're needing to fight the GC to prevent crashes or whatever then you have a system design issue not a tooling/language/ecosystem issue. There are exceptions to this but they're rare and not worth mentioning in a broad discussion like this. Sadly very few people take interest in learning how to design systems properly. Instead they find comfort in tools that allow them to over-engineer the problems away. Like fal…

> Computers suck at networking. We have _a lot_ of complex layers to help make it feel somewhat reliable. I've got bad news pal: your SSD has a triple-core ARM processor and is connected to the CPU through a bus, which is basically a network, complete with error correction and exact same failure modes as your connection to the new york stock exchange. Even the connection between your CPU and it's memory can prodice e…

the difference of distributed (networked) systems is that they are expected to keep working even in the presence of partial (maybe byzantine) failures.

The communication between actor itself is not the problem, unreliable comunication between unreliable actors is.

If any of my CPU, RAM, Motherboard has a significant failure my laptop is just dead, they all can assume that all the others mostly work and simply fail if they don't.

Re: Generics can make your Go code slower

#355

Post by morelisp »

afiori wrote: post #353
chrisseaton wrote: post #309

Earlier quoted context omitted.

> you still have to allocate once per object Why can’t you bump once to allocate enough space for multiple objects?

No, outside special code it is impossible to know at compile time how many heap allocation a function will have. The stack has the requirement that its size must be known at compile time for each function. In oversimplified terms its size is going to be the sum of size_of of all the syntactically local variables. So for example you cannot grow the stack with a long loop, because the same variable is reused over and o…

> The stack has the requirement that its size must be known at compile time for each function.

Not really. You can bump your stack pointer at any time. Even C has alloca and VLAs. In lots of languages it's dangerous and not done because you can stack overflow with horrible results, and some (but not all) performance is lost because you need to offset some loads relative to another variable value, but you can do it.

What the stack really has a requirement that any values on it will go full nasal demon after the function returns, so you'd better be absolutely certain the value can't escape - and detecting that is hard.

Re: Generics can make your Go code slower

#356

Post by bigbizisverywyz »

throwawaylala1 wrote: post #273
no_circuit wrote: post #256

Earlier quoted context omitted.

No worries. It is not meant to be quantitative. For a few years of my career that has been my experience. For this type of software, if I'm making the decision on what technology to use, it won't be any GC-based language. I'd rather not rely on promises that GC works great, or is very tunable. One could argue that I could just tune my services from time to time. But I'd just reduce the surface area for problems by no…

If you're needing to fight the GC to prevent crashes or whatever then you have a system design issue not a tooling/language/ecosystem issue. There are exceptions to this but they're rare and not worth mentioning in a broad discussion like this. Sadly very few people take interest in learning how to design systems properly. Instead they find comfort in tools that allow them to over-engineer the problems away. Like fal…

>Computers suck at networking. ... The day you network two computers together is the day you've opened yourself up to a world of hurt.

This is actually a pretty insightful comment, and something I haven't thought about in a number of years since networking disparate machines together to create a system in now so second nature to any modern software that we don't think twice about the massive amount of complexity we've suddenly introduced.

Maybe the mainframe concept wasn't such a bad idea, where you just build a massive box that runs everything together so you never get http timeouts or connection failed to your DB since they're always on.

Re: Generics can make your Go code slower

#357

Post by chrisseaton »

afiori wrote: post #353
chrisseaton wrote: post #309

Earlier quoted context omitted.

> you still have to allocate once per object Why can’t you bump once to allocate enough space for multiple objects?

No, outside special code it is impossible to know at compile time how many heap allocation a function will have. The stack has the requirement that its size must be known at compile time for each function. In oversimplified terms its size is going to be the sum of size_of of all the syntactically local variables. So for example you cannot grow the stack with a long loop, because the same variable is reused over and o…

> No, outside special code it is impossible to know at compile time how many heap allocation a function will have.

Huh?

    def foo:
      return [new Object, new Object]
That'll always bump the TLAB three times. Why not bump it one time for all objects?

> The stack has the requirement that its size must be known at compile time for each function.

Also huh?

For example a local array that has a dynamic size.

Re: Generics can make your Go code slower

#358

Post by merely-unlikely »

slrz wrote: post #119
randomdata wrote: post #96

Earlier quoted context omitted.

> I'd argue that golang is inherently not a systems language First you'd have to establish what "systems" means. That, you'll find, is all over the place. Some people see systems as low level components like the kernel, others the userland that allows the user to operate the computer (the set of Unix utilizes, for example), you're suggesting databases and things like that. The middle one, the small command line utili…

What is it that Go supposedly calls casting? The term (or its variations) does not show up in the language specification. People sometimes use it for type conversions but that's in line with usage elsewhere, no?

Are you talking about type assertions? It's right there in the Go Tour. But that's a different thing than a type conversion.

Re: Generics can make your Go code slower

#359

Post by Thaxll »

pjmlp wrote: post #344
Thaxll wrote: post #251

Earlier quoted context omitted.

> Build systems in Java by and large fall into only 3 camps, Maven, Gradle and a very small (but loud/dedicated) Bazel camp. Contrast that to Go which is almost always a huge pile of horrible Makefiles, CMake, Bazel or some other crazy homebrewed bash build system. Well Go does not need a book of 400+ pages to understand Maven.

It needs one to understand Go modules and how they change across language versions.

Go module are easy to use, compiling is even more simpler: go build .

Re: Generics can make your Go code slower

#360

Post by randomdata »

morelisp wrote: post #333
randomdata wrote: post #308

Earlier quoted context omitted.

Sucrase, written in Typescript, claims to be 2x faster than esbuild. I'll leave you to your own benchmarks.

Sucrase does this by removing some things you might expect to be table stakes, like detecting invalid parse trees and complete JS syntax. Pragmatically, esbuild can also start faster and parallelize, which means shorter wall-clock builds.

Sure, but esbuild also drops features found in the compared tools to gain a performance edge. The language may bring some marginal difference, but it's clear that the algorithm is the most significant piece.
Post reply on HN