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

401–410 of 418 posts

Re: Generics can make your Go code slower

#401

Post by throwaway894345 »

tekknik wrote: post #385
pjmlp wrote: post #362

Earlier quoted context omitted.

If you say so, "HERO: On the Chaos When PATH Meets Modules" https://cs.nju.edu.cn/changxu/1_publications/21/ICSE21_02.pd...

I’ve been writing go since it basically came out. Every single one of you’re comments is anecdotal so here we go. I’ve never, ever, encountered an issue compiling / building go code using modules. You also said in your first argument that you get no access to raw threads then a comment later said you do. It seems like you’re just advocating for people to use java because it’s what you’re comfortable with.

Pretty sure it was a different commenter who claimed no access to raw threads, but yes, the parent user can be a bit abrasive on the subject of programming languages.

Re: Generics can make your Go code slower

#402

Post by cy_hauser »

azth wrote: post #390
cy_hauser wrote: post #366

Earlier quoted context omitted.

Enums in Go are inferior but that doesn't stop you from using them in the same way. Of course you can code gen using Go's tags. It's done all the time. As already pointed out, Go has the JFR it needs, not what Java has. Go doesn't need a JITter. Go isn't perfect, but neither is Java or C#. Go code is known for being maintainable and easy for newcomers to read so your last line applies to Java more than Go. But it see…

> Enums in Go are inferior but that doesn't stop you from using them in the same way. It does, I have to think twice because I know I'm not getting the compile time features that Java offers, and may end up just using strings in an awkward manner. > Go has the JFR it needs, not what Java has That doesn't make sense. All programs need the JFR that Java has, otherwise you wouldn't see companies like Datadog doing well.…

I've coded Java, C#, and now Go and have spent years doing each. My experience differs from yours. Clearly our experiences differ and that's okay. I occasionally support Go and occasionally bash Go but really I don't have the passion to dislike any language as much as you seem to. Be well.

Re: Generics can make your Go code slower

#403

Post by zepolen »

EdwardDiego wrote: post #370
zepolen wrote: post #332

Earlier quoted context omitted.

> After 14 years in JVM dev in areas where latency and reliability are business critical What sort of industry/use cases are we talking here? There is business critical and mission critical and if your experience is in network applications as your next paragraph seems to imply then no offence, but you have never worked with critical systems where an nondeterministic GC pause can send billions worth of metal into the…

Um, how did you derive from this conversation that the "outages" in question were about space missions failing? Curious, and a tad confused.

The parent of this thread being is about systems languages and how GC languages are rarely the right tool.

Then your comment about having experience that the GC doesn't really matter in critical environments, which I personally find not to be true at all but am interested in which domain your comment is based on.

So please answer the original question.

Re: Generics can make your Go code slower

#404

Post by bschwindHN »

svnpenn wrote: post #276
TheDong wrote: post #274

Earlier quoted context omitted.

As I said above: > In this case, the abstraction available in rust is cleaner and requires less code for me, the user of the package, so I don't think the lines of code used to build that abstraction matter. > Why do you see this as something that matters? It's true that the abstraction in rust has more code underlying it, but why does that matter? If you de-facto never have to implement the rust error trait by hand…

Thats a good outlook. Dont worry about any problem, just import something an its fixed! More imports the better! Hopefully we can do away with all code, and just import everything.

Don't you think that's a little disingenuous?

You're absolutely right about implementing the `Error` trait yourself in Rust, it's a pain! And with many things, the Rust team felt it was better to leave error experimentation to an external library, as the community can iterate more quickly and settle on a favorite. At the moment, that favorite is `thiserror` (for defining errors in a library) and `anyhow` (for working with errors in application code)

That's been a pretty common pattern in Rust - leave some less clear parts of the standard library out for external crates to implement and experiment on. So you'll see almost all big Rust projects use one of those error handling libraries. You _could_ implement it with just the standard library, but you're just giving yourself more work for little to no gain.

Here's an example without using external libraries:

https://play.rust-lang.org/?version=stable&mode=debug&editio...

Not particularly good or bad (and I didn't even replicate all the functionality that `thiserror` gives you).

So yeah, Go and Rust have different philosophies for their standard library, and you can argue about which is better, but I don't think one can be proved objectively better than the other.

Re: Generics can make your Go code slower

#405

Post by blindmute »

alephnan wrote: post #319
blindmute wrote: post #292

Earlier quoted context omitted.

Honest question, what is golang a good choice for? It seems to inhabit the nether realm between high level productivity and low level performance, not being good at either.

> It seems to inhabit the nether realm between high level productivity This is where you're wrong. What would you consider "high level productivity" then? Java? Ruby? Ruby on Rails?

Yes, among others. Not golang though. I've used it and it feels lower level than those and less productive

Re: Generics can make your Go code slower

#406

Post by azth »

shadowgovt wrote: post #364
azth wrote: post #328

Earlier quoted context omitted.

> They're just built for features of Go They're inferior, and do not cover the same grounds (e.g. "enums" in golang are just integer constants, you can't code gen using golang tags, JFR is way way more comprehensive than anything that golang has etc.) The GC selection, JIT, and hot swapping/reloading are features that do not exist in golang, and we've seen what hoops people have to jump through when they face issues…

Why does golang need JIT when it already statically compiles to a non-virtual machine target? It could probably use some performance optimizations, but JIT would be redundant when it's already compiled.

JIT makes things like the JFR possible.

Re: Generics can make your Go code slower

#407

Post by IshKebab »

gmfawcett wrote: post #63
SomeCallMeTim wrote: post #51

Earlier quoted context omitted.

In C++, generics (templates) are zero-cost abstractions. So no, generics do not de facto make code slower.

That's only 99% of the story. :) Having too many specializations of a C++ template can lead to code bloat, which can degrade cache locality, which can degrade performance.

It's still zero cost compared to what you would have done without them - copy and paste the code.

That's what zero cost abstraction means - it doesn't mean that whatever you're writing has no cost, it means the abstraction has no extra costs compared to what you would have to do manually without it.

Re: Generics can make your Go code slower

#408

Post by native_samples »

delian66 wrote: post #361
native_samples wrote: post #340

Earlier quoted context omitted.

That's the Go party line but not really true. Counter-example: The Go GC is tuned for HTTP servers at latency sensitive companies like Google. It therefore prioritizes latency over throughput to an astonishing degree, which means it is extremely bad at batch jobs - like compilers. What language is the Go compiler written in? Go. This isn't fixable by simply writing the code differently. What you're talking about is i…

> it is extremely bad at batch jobs - like compilers. > What language is the Go compiler written in? Go. I do not see what are you trying to say? The Go compiler is plenty fast in my experience, especially compared to say `javac`. The startup time of `javac` (and most java programs) is atrocious.

You can't compare throughput of two totally different programs to decide whether an individual subsystem is faster. The Go compiler is "fast" because it doesn't do much optimization, and because the language is designed to be simple to compile at the cost of worse ergonomics. Why can't it do much optimization? Partly due to their marketing pitch around fast compilers and partly because Go code runs slowly, because it's using a GC designed to minimize pause times at the cost of having lots of them.

The algorithmic tradeoffs here are really well known and there are throughput comparisons of similar programs written in similar styles that show Go falling well behind. As it should, given the choices made in its implementation, in particular the "only one GC knob" choice.

Re: Generics can make your Go code slower

#409

Post by pjmlp »

tekknik wrote: post #385
pjmlp wrote: post #362

Earlier quoted context omitted.

If you say so, "HERO: On the Chaos When PATH Meets Modules" https://cs.nju.edu.cn/changxu/1_publications/21/ICSE21_02.pd...

I’ve been writing go since it basically came out. Every single one of you’re comments is anecdotal so here we go. I’ve never, ever, encountered an issue compiling / building go code using modules. You also said in your first argument that you get no access to raw threads then a comment later said you do. It seems like you’re just advocating for people to use java because it’s what you’re comfortable with.

I am confortable with plenty of stuff, which makes me not the target audience for Go.

"The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt."

The threads comment wasn't from me.

Re: Generics can make your Go code slower

#410

Post by jokoon »

bborud wrote: post #399
jokoon wrote: post #391

Earlier quoted context omitted.

Something that is used to write an OS, low level programming, low memory footprint, high performance/optimized.

When you say OS, do you mean kernel or kernel and the daemons?

Both.

Also everything that has low memory, like embedded systems.

Anything that is real time cannot have a GC, because GC are unpredictable. So everything in aircraft, space, when it has time sensitive machinery...

Post reply on HN