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

21–30 of 113 posts

Re: Hacking Go's runtime with generics

#21

Post by gabrielgio »

innocentoldguy wrote: post #8
XorNot wrote: post #6

Earlier quoted context omitted.

> pick a better one? Such as?

My choices would be: - Elixir - Rust - Clojure - Crystal In that order.

If you allow me, my take on the list:

* Clojure is a really nice and simple language, but the tooling and documentation comes nowhere near go, also it uses JVM, which would already disquilify as go replacement.

* Rust is nice (or even better in a lot points) but a lot harder. Concurrency in go is just lot easier.

* Elixir, I agree, although I don't have much experience of the language.

* Crystal, not clue about this lang xD.

Re: Hacking Go's runtime with generics

#22

Post by nicoburns »

cosmicradiance wrote: post #20
innocentoldguy wrote: post #8

Earlier quoted context omitted.

My choices would be: - Elixir - Rust - Clojure - Crystal In that order.

Are you an expert in all those languages? To me these are the exotic languages which one gets inspired from when reading the stackoverflow survey, but there is hardly any one person I know who has mastered even half of those.

Once you’ve learnt a few languages, learning more becomes easy. Elixir, Rust and Clojure are all reasonably widely used. And I would note: somewhat similar to each other.

Re: Hacking Go's runtime with generics

#23

Post by masklinn »

the_gipsy wrote: post #18
hnra wrote: post #16

Earlier quoted context omitted.

Why not?

Kotlin might fit the Java niche, if you trust someone that sells IDEs to make a language. Go's niche includes being native. If you discard that, then virtually anything that is "easy" could fit it.

> Kotlin might fit the Java niche, if you trust someone that sells IDEs to make a language.

They would at least know how to make a language that's not a pain in the ass to analyse, which is probably in its favour.

Re: Hacking Go's runtime with generics

#25

Post by pjmlp »

rob74 wrote: post #15
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…

What I do not understand is why on every article about Go someone needs to extol their dislike of Go. If you don't understand its appeal, then either you should give it a (serious) try and see if you like it, or if you are unable to bring yourself to do that, just use those better (according to your opinion) languages.

Unfortunely that isn't always a choice that we can influence, project => language, and in some cases that implies using a language that we dislike, regardless of how we feel about it.

One can go job hoping as alternative, but then good luck jumping jobs everytime one has to deal with stuff we dislike.

Re: Hacking Go's runtime with generics

#26

Post by pjmlp »

gabrielgio wrote: post #19
hnra wrote: post #14

Earlier quoted context omitted.

C# may fit your needs, depending on what you consider a simple language and easy concurrency. The language doesn’t feature any hard to understand concepts. Concurrency is very good, but only async has built in syntax sugar (I believe go has syntax sugar for channels or something?). The executables may be a bit larger (I’m guessing).

C# is far from simple. It used to be be but lately (in that last ~5 year) they have been adding a lot to a point it has become hard to follow the changes, and hard to read modern C#. When I was C# developer I welcome the addition of FP like feature, but now imho the lang have become very cluttered. GO lang is in another level of simplicity and it is not comparable with C#.

Just wait when Go gets 20 years of existence and enterprise use beyond devops.

Re: Hacking Go's runtime with generics

#27

Post by pjmlp »

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.

Plenty of software has been written on languages without generics, but they have the excuse of coming up before generics were a common feature in mainstream languages.

At least that has been finally fixed.

Re: Hacking Go's runtime with generics

#28

Post by pjmlp »

the_gipsy wrote: post #18
hnra wrote: post #16

Earlier quoted context omitted.

Why not?

Kotlin might fit the Java niche, if you trust someone that sells IDEs to make a language. Go's niche includes being native. If you discard that, then virtually anything that is "easy" could fit it.

Then use an AOT compiler, plenty of those for JVM since 2000.

While one can excuse themselves that they were commercial, GraalVM native image, and OpenJ9 offer free beer alternatives.

Re: Hacking Go's runtime with generics

#29

Post by pjmlp »

gabrielgio wrote: post #21
innocentoldguy wrote: post #8

Earlier quoted context omitted.

My choices would be: - Elixir - Rust - Clojure - Crystal In that order.

If you allow me, my take on the list: * Clojure is a really nice and simple language, but the tooling and documentation comes nowhere near go, also it uses JVM, which would already disquilify as go replacement. * Rust is nice (or even better in a lot points) but a lot harder. Concurrency in go is just lot easier. * Elixir, I agree, although I don't have much experience of the language. * Crystal, not clue about this…

There are AOT options for JVM, just need to learn how to use them.
Post reply on HN