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

Hacking Go's runtime with generics

dolthub.com

Post reply on HN
Print view View original

71–80 of 113 posts

Re: Hacking Go's runtime with generics

#71

Post by flagsrule »

notwokeno wrote: post #64
czx4f4bd wrote: post #62

Earlier quoted context omitted.

You can allocate memory manually in Go and manage it yourself using Go's `unsafe` package, so there's an escape route once Go's GC became a limiting factor. Here's a blog post about it in the context of Dgraph: https://dgraph.io/blog/post/manual-memory-management-golang-...

The real issue with go is (or was, I haven't messed with it for a few years) its un-optimized goroutine scheduler that makes channels slow if you start using them a lot.

Yes, refactoring from channels to atomic package can easily give 10x speedup. Sometimes we have to communicate by sharing memory :)

Re: Hacking Go's runtime with generics

#72

Post by rad_gruchalski »

shakow wrote: post #61
silisili wrote: post #17

Earlier quoted context omitted.

I've been writing software for 20 years. About half that in Go. Whenever I see someone say it's a bad language because X, I seriously wonder if the asker just writes terrible code, or if there's whole swaths of domains I've not encountered. Or maybe a little of both. I've never once been stumped by a lack of generics, for example, despite how many people claim it's unusable without them.

> I've never once been stumped by a lack of generics Heve you never written a stack structure (since Go doesn't include one)? Never used a min/max function between numbers (go doesn't either)?

I have, maybe a couple of times. Never missed generics.

Re: Hacking Go's runtime with generics

#74

Post by Ingaz »

anacrolix wrote: post #10
voz_ wrote: post #5

I do not understand the appeal of go. > The proposal argues that Golang developers are forced to work around language when writing hash-based data structures like Tries or concurrent hash maps. Developers who want an efficient hash-based data structure have only the builtin map to choose from. When this issue was originally created in 2017, Golang didn't have generics And then the author goes to tell us about how thi…

I hate Go, but there is no solid alternative for what I do. Documentation quality. Compiler performance. Library support. Easy packaging. Easy language. Consistent cross platform tooling. Easy concurrency. Good for web apps and CLI tools. Reasonably refactorable. Note I say easy and not good, or simple. Rust, Haskell, JavaScript, all get caught up on some aspect or another for me.

You obviously don't hate go.

Everything you listed help programmer to keep own sanity.

It's all compromises but they're mostly reasonable compromises.

Re: Hacking Go's runtime with generics

#75

Post by shakow »

konart wrote: post #69
shakow wrote: post #54

Earlier quoted context omitted.

> True, but can you really work day by day in a language and still not understand its appeal? Yes. I have been working with Go for close to a year now, and I still don't get why we use it, if not for the inertia of times past – and I still don't get why it was chosen in the first place. If we wanted a fast, down to the metal language, Rust would IMHO be better. If we preferred a higher-level language with a Gc, Java/…

>If we preferred a higher-level language with a Gc, Java/Kotlin/C# would be, IMHO, much better. Writing code in Java\Kotlin requires quite some investment into the language and tooling (at least that's my Java impression). With Go - you can start getting the job done from day one most of the time. Some parts of Go may be harder than the others, even challenging maybe, but not as hard as Java. Lack of OOP (at least in…

To be honest, I think that go packaging is ghastly (just accessing dependencies in private repos requires changing global git settings, which is an abomination), but I can see how Java can be very heavy on that.

However, I would not weight too much the time-to-first-makefile of a language if a project is supposed to live for years.

Re: Hacking Go's runtime with generics

#76

Post by shakow »

the_gipsy wrote: post #41
masklinn wrote: post #34

Earlier quoted context omitted.

> that's offered by all modern languages I see you've yet to meet Scala. > they're not tied to one particular IDE since LSP took off. There's at least one language server for Kotlin. I'm not even a interested in (let alone a user of) Kotlin, but you seem to have a very not-objective view of it for some reason.

Are you saying Scala has bad code analysis? I recall it being as good as Java's. Anyway, that's just a matter of defining "modern languages" then. > There's at least one language server for Kotlin. I didn't say there is none, I said that any modern language has one. An IDE is not a selling point anymore, in my humble opinion. > you seem to have a very not-objective view of it for some reason I just think that shoehor…

> I just think that shoehorning Kotlin into "the go niche" is absurd

That's what you say, but you don't really tell us why.

Re: Hacking Go's runtime with generics

#77

Post by valenterry »

silisili wrote: post #17
voz_ wrote: post #5

I do not understand the appeal of go. > The proposal argues that Golang developers are forced to work around language when writing hash-based data structures like Tries or concurrent hash maps. Developers who want an efficient hash-based data structure have only the builtin map to choose from. When this issue was originally created in 2017, Golang didn't have generics And then the author goes to tell us about how thi…

I've been writing software for 20 years. About half that in Go. Whenever I see someone say it's a bad language because X, I seriously wonder if the asker just writes terrible code, or if there's whole swaths of domains I've not encountered. Or maybe a little of both. I've never once been stumped by a lack of generics, for example, despite how many people claim it's unusable without them.

No it's mostly just the blub paradox. You don't feel the pain because you didn't use some features/techniques of other languages that don't exist in Go.

It's the same everyone. I, for example, never felt I was missing something until I learned about type providers. Now that I don't work in a language that supports them, I hate it. If I had never learned about them, I would probably never miss em.

Re: Hacking Go's runtime with generics

#78

Post by somethingreen »

silisili wrote: post #17
voz_ wrote: post #5

I do not understand the appeal of go. > The proposal argues that Golang developers are forced to work around language when writing hash-based data structures like Tries or concurrent hash maps. Developers who want an efficient hash-based data structure have only the builtin map to choose from. When this issue was originally created in 2017, Golang didn't have generics And then the author goes to tell us about how thi…

I've been writing software for 20 years. About half that in Go. Whenever I see someone say it's a bad language because X, I seriously wonder if the asker just writes terrible code, or if there's whole swaths of domains I've not encountered. Or maybe a little of both. I've never once been stumped by a lack of generics, for example, despite how many people claim it's unusable without them.

On one hand, the bar for things to be called bad has now dropped pretty low. Being not as excellent as other thing, or not being excellent throughout is enough.

But I think the actual hate isn't coming from Go technical shortcomings. It's language authors and community attitude towards people asking for obvious QoL improvements.

Generics are a bad enough example of community for years tactfully flipping off everyone asking for them and then, hey, here they are and the sky doesn't seem to be falling. But it's not the only example. Just a couple days ago I was researching if there's a way to somehow build struct tags from constants or use interpolation and sure enough, there's an old bug tracker suggestion entry that got a two sentence "won't do" reply with zero reasoning and a bunch of following entries just marked as duplicate and closed without reply at all. This happens a lot. And people don't appreciate it.

Re: Hacking Go's runtime with generics

#79

Post by the_gipsy »

shakow wrote: post #76
the_gipsy wrote: post #41

Earlier quoted context omitted.

Are you saying Scala has bad code analysis? I recall it being as good as Java's. Anyway, that's just a matter of defining "modern languages" then. > There's at least one language server for Kotlin. I didn't say there is none, I said that any modern language has one. An IDE is not a selling point anymore, in my humble opinion. > you seem to have a very not-objective view of it for some reason I just think that shoehor…

> I just think that shoehorning Kotlin into "the go niche" is absurd That's what you say, but you don't really tell us why.

It's not my burden of proof. If you think something like compiling kotlin instead of running a JVM is akin to compiling with go tooling, then at this point anything that somehow compiles to native (and beyond) is in the "go niche".

Re: Hacking Go's runtime with generics

#80

Post by [deleted] »

nine_k wrote: post #53
voz_ wrote: post #5

I do not understand the appeal of go. > The proposal argues that Golang developers are forced to work around language when writing hash-based data structures like Tries or concurrent hash maps. Developers who want an efficient hash-based data structure have only the builtin map to choose from. When this issue was originally created in 2017, Golang didn't have generics And then the author goes to tell us about how thi…

The appeal of Go: - A pretty simple, if not very expressive, language (it's anti-Perl, and seems simpler than JS); you can learn it down to a reasonably productive level in a weekend. (I did.) - A memory-safe language (like Java) with good performance (like Java) without the need to install any runtime, and the ability to ship as a single binary (unlike Java). - A reasonably good and ergonomic concurrency approach (l…

[deleted]
Post reply on HN