16 ms·

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

by voz_ 4y ago

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 this is not a stable solution. I get wanting to solve a problem, but at what point into fighting the language, to accomplish something simple, do you take a step back and just pick a better one?

XorNot 4y ago
> pick a better one? Such as?
- innocentoldguy 4y ago
  My choices would be: - Elixir - Rust - Clojure - Crystal In that order.
  - cosmicradiance 4y ago
    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.
    - nicoburns 4y ago
      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.
    - innocentoldguy 4y ago
      I don't consider myself an expert at anything, but yes, I use these languages on a daily to weekly basis at work. We had some Go code, but replaced it with Elixir. EDIT: I'd also like to add that Elixir and Rust aren't "exotic." Crystal may be, but it's basically just compiled/typed Ruby. I've been using Elixir professionally for seven years across multiple companies: 1. Divvy. 2. GoSkip. 3. Podium. 4. Actiphy.
  - gabrielgio 4y ago
    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.
    - pjmlp 4y ago
      There are AOT options for JVM, just need to learn how to use them.
  - nine_k 4y ago
    Elixir is wonderful, but its deployment story is much more complicated than Go's or Rust's.
    - innocentoldguy 4y ago
      I don't think Elixir's deployment story is difficult. It doesn't result in a single executable, like Go compiles to, but it's easy to deploy Elixir apps and the compiled package contains everything necessary to run (meaning you don't have to install Elixir, Erlang, etc. manually in production). The biggest benefits of Elixir over Go for me are: 1. Pattern matching. 2. Easier concurrency (with less resource usage). 3. Piping. 4. Easy to hire and train Ruby or Crystal developers. 5. Phoenix is an outstanding web framework for Elixir. 6. Excellent tooling. 7. Supervision trees. 8. Actor model. 9. Elixir's concurrency is done in private memory, whereas Go uses public memory. EDIT: Fixed formatting.
- clumsysmurf 4y ago
  I'm hoping Kotlin + GraalVM Native Image can fit the niche of golang.
  - the_gipsy 4y ago
    No VM language can fit the niche of go.
    - hnra 4y ago
      Why not?
      - the_gipsy 4y ago
        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.
        masklinn 4y ago
        > 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.
        the_gipsy 4y ago
        Yea - but that's offered by all modern languages, and they're not tied to one particular IDE since LSP took off.
        masklinn 4y ago
        > 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.
anacrolix 4y ago
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.
- hnra 4y ago
  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).
  - gabrielgio 4y ago
    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#.
    - pjmlp 4y ago
      Just wait when Go gets 20 years of existence and enterprise use beyond devops.
      - gabrielgio 4y ago
        > Just wait when Go gets 20 years of existence and enterprise use beyond devops. C# is really reliable language, great tooling and documentation but it does not change the fact that is cluttered and no longer simple (which was the point of my comment). Also I can't see golang going to the same direction, by design go is a lot simpler.
  - 4y ago
the_gipsy 4y ago
> I get wanting to solve a problem, but at what point into fighting the language, to accomplish something simple, do you take a step back and just pick a better one? My guess is that they got excited at the chance of doing something mildly interesting, beyond the mind numbing "regular" go.
Cthulhu_ 4y ago
I mean it's a good exercise I guess if you want to flex your language knowledge, but it goes against the mindset of Go to actually use it in production. Said mindset being don't overcomplicate things. One doesn't need Go to not overcomplicate things either. I wanted to advocate in favor of Go for a long time, and still do recommend it, but it's the mindset that is more important.
- erik_seaberg 4y ago
  What I fear most is starting to absorb the "reserved for language designers, not for me" mindset. Stubbornly bending the language to serve you is a much healthier attitude for anyone who wants to maintain his expertise.
rob74 4y ago
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.
- pjmlp 4y ago
  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.
  - jackosdev 4y ago
    I hopped jobs to go from using Go to Rust, I was sad and bored, now I'm happy and energized. Always going to be things you dislike for sure, but life's to short to be using a language that's making you miserable.
    - pjmlp 4y ago
      Which is true, assuming the job market is great on the area, which even on IT isn't the case. Thankfully I seldom have to deal with Go anyway.
  - rob74 4y ago
    True, but can you really work day by day in a language and still not understand its appeal? I mean, not like it, but at least understand why others might choose to use it? And, if you really can't bring yourself to see the positive sides of a language you have to use (and any mainstream language has to have positive sides, otherwise it wouldn't be mainstream), maybe it's really time to consider switching jobs...
    - pjmlp 4y ago
      I see Go's appeal as a better C for userspace code, and the language is quite nice had it been released during the days Oberon and Limbo mattered in the mid-1990's. As post 2000 language, its design isn't that appealing. The language would have been as mainstream as Oberon and Limbo were, if the authors weren't working at Google.
silisili 4y ago
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.
- pjmlp 4y ago
  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.
- shakow 4y ago
  > 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)?
  - rad_gruchalski 4y ago
    I have, maybe a couple of times. Never missed generics.
  - ilyt 4y ago
    Those are not show-stoppers, just annoyances. Generics make it oh so much nicer to do some stuff but lack of them wasn't exactly something that I missed, just that I wished some libraries had for the cases you mentioned (generic map/reduce/math/etc.)
- ilyt 4y ago
  Generics were never required, just their lack was annoying and their presence makes some things just cleaner and easier For example I deal in ops stuff so pretty common task is "here are desired and current set, generate list of add/delete operations to get from one state to another". I wrote iteration of that function a bunch of times pre-generics, eventually being just copy-paste-change-types but now I can just write [1] one that compares a slice of types and returns the elements present in left or right and [2] another that can do similar difference on disparate types via conversion function. Then there is a whole slew of map/reduce and math stuff that now can just have `Map` or `Max` function without worrying about types. Hell I can "just" write "parse all the slice elements in parallel, keeping order [3] once and never worry about it. That's also code that I wrote more than once before generics * [1] https://github.com/XANi/goneric/blob/master/slice.go#L77 https://github.com/XANi/goneric/blob/master/slice.go#L77 * [2] https://github.com/XANi/goneric/blob/master/slice.go#L106 https://github.com/XANi/goneric/blob/master/slice.go#L106 * [3] https://github.com/XANi/goneric/blob/master/parallel.go#L15 https://github.com/XANi/goneric/blob/master/parallel.go#L15
BrandoElFollito 4y ago
> I do not understand the appeal of go. I am an amateur dev developer and used to use untyped languages (Python and JS, mostly). At some point Python was annoying in docker environments (especially for APIs) and I gave a try to Go. Initially I hated it, then learned to like it more and now I kinda like it. - typed (this is a game changer) - compiles to a single self-contained binary (easy with Docker) - great for APIs without the worries of gunicorn and whatnot I also discovered TypeScript to help with JS. So the forst one would be "typed language". I have Python for the rest ("the 2nd best language for any task") and since I am an amateur dev, I do not have the time to dig into many languages to find the pearl.
nine_k 4y ago
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 (like JS, unlike Java), based around channels, not futures, and able to embrace multicore parallelism (unlike JS, like Java, and somehow like Erlang). - Highly opinionated, well-crafted built-in data structures (like Python), and a general approach discouraging you from rolling your own. - Good cross-platform support; fast compilation. That is, it's a language that works well in a case where most of your team is junior devs, and you write some kind of a network server. The devs are forced to follow simple, if repetitive and wordy, patterns, and are limited in their ability to raise creative mayhem in the code base, all while writing reasonably performant, concurrency-friendly code that's a piece of cake to deploy. Combined with some overview from more senior folks, this should work reasonably well (and apparently that's what how it works at Google). No. it's not a joy to use, it has warts (or, rather, deliberate compromises) in many areas, it requires boilerplate which pushes the user towards copy-paste programming, etc. If you can afford to not use it, don't, but sometimes it's the easiest tool for a job, much like, well, PHP.
- deleted 4y ago
  [deleted]
- zachmu 4y ago
  I actually find go a joy to use, I dunno. I like statically typed languages, and go makes defining and using types so simple and straightforward that it feels like you get a lot of the benefits of dynamic typing without the headaches.
  - nine_k 4y ago
    I love statically-typed languages! What bothers me in Go is mostly the control flow around `result, err := foo(); if err != nil { return err };`, and still non-genericized standard library. But after 1.18 I started to look at Go as a potentially good language, in areas where using Rust is too cumbersome, and using Typescript or Java or Kotlin is also inappropriate.
ilyt 4y ago
>I get wanting to solve a problem, but at what point into fighting the language, to accomplish something simple, do you take a step back and just pick a better one? ..coz they already have code in it ? Coz they are happy with remaining 99% of the language ? It's not hard to figure out cmon. If people dropped language at slight inconvenience we'd be out of languages
tptacek 4y ago
This is an article about an idiosyncratic and fairly interesting approach to writing a fast generic striped map in Golang. Responding to it with a language war appeal is arson; maybe not the "pouring gasoline onto the building" kind of arson, but certainly the "tossing your lit cigarette into the dried up pile of brush" kind. Almost the entire thread on this story has been consumed by a litigation of whether Go is good or not. If you don't like Go (or Rust or Haskell or Elixir or Ruby), that's fine. Just don't comment.
aatd86 4y ago
I think he didn't mean tries which don't generally need hashing but was trying to implement a lock-free map based on Concurrent Hash-Array Mapped Tries. I had done that myself as an exercise a few years back and had to extract the hash function from the runtime that is used for maps. In any case, the performance was terrible and code brittle. (lack of sumtypes). Since then, I've learnt to not bother too much and just use the builtin maps. Never had an issue for my use-cases.
- awmarthur 4y ago
  (OP) I'm mostly interesting in a fast hash for writing a generic, concurrent hash map. The reference to Tries came from the original issue in the Golang repo about possible uses for a standard library hash function: https://github.com/golang/go/issues/21195 https://github.com/golang/go/issues/21195 And you're right, the Trie implementation linked there was indeed a Hash-Array Mapped Tried: https://pkg.go.dev/github.com/lleo/go-hamt-key#Key https://pkg.go.dev/github.com/lleo/go-hamt-key#Key
coldtea 4y ago
>I get wanting to solve a problem, but at what point into fighting the language, to accomplish something simple, do you take a step back and just pick a better one? What makes you think they haven't tried what you think are "better ones" and moved away because they had more problems to fight the language/ecosystem about with those?

by voz_ 4y ago

XorNot 4y ago

> pick a better one? Such as?

innocentoldguy 4y ago
My choices would be: - Elixir - Rust - Clojure - Crystal In that order.
- cosmicradiance 4y ago
  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.
  - nicoburns 4y ago
    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.
  - innocentoldguy 4y ago
    I don't consider myself an expert at anything, but yes, I use these languages on a daily to weekly basis at work. We had some Go code, but replaced it with Elixir. EDIT: I'd also like to add that Elixir and Rust aren't "exotic." Crystal may be, but it's basically just compiled/typed Ruby. I've been using Elixir professionally for seven years across multiple companies: 1. Divvy. 2. GoSkip. 3. Podium. 4. Actiphy.
- gabrielgio 4y ago
  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.
  - pjmlp 4y ago
    There are AOT options for JVM, just need to learn how to use them.
- nine_k 4y ago
  Elixir is wonderful, but its deployment story is much more complicated than Go's or Rust's.
  - innocentoldguy 4y ago
    I don't think Elixir's deployment story is difficult. It doesn't result in a single executable, like Go compiles to, but it's easy to deploy Elixir apps and the compiled package contains everything necessary to run (meaning you don't have to install Elixir, Erlang, etc. manually in production). The biggest benefits of Elixir over Go for me are: 1. Pattern matching. 2. Easier concurrency (with less resource usage). 3. Piping. 4. Easy to hire and train Ruby or Crystal developers. 5. Phoenix is an outstanding web framework for Elixir. 6. Excellent tooling. 7. Supervision trees. 8. Actor model. 9. Elixir's concurrency is done in private memory, whereas Go uses public memory. EDIT: Fixed formatting.
clumsysmurf 4y ago
I'm hoping Kotlin + GraalVM Native Image can fit the niche of golang.
- the_gipsy 4y ago
  No VM language can fit the niche of go.
  - hnra 4y ago
    Why not?
    - the_gipsy 4y ago
      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.
      - masklinn 4y ago
        > 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.
        the_gipsy 4y ago
        Yea - but that's offered by all modern languages, and they're not tied to one particular IDE since LSP took off.
        masklinn 4y ago
        > 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.

anacrolix 4y ago

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.

hnra 4y ago
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).
- gabrielgio 4y ago
  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#.
  - pjmlp 4y ago
    Just wait when Go gets 20 years of existence and enterprise use beyond devops.
    - gabrielgio 4y ago
      > Just wait when Go gets 20 years of existence and enterprise use beyond devops. C# is really reliable language, great tooling and documentation but it does not change the fact that is cluttered and no longer simple (which was the point of my comment). Also I can't see golang going to the same direction, by design go is a lot simpler.
- 4y ago

the_gipsy 4y ago

> I get wanting to solve a problem, but at what point into fighting the language, to accomplish something simple, do you take a step back and just pick a better one? My guess is that they got excited at the chance of doing something mildly interesting, beyond the mind numbing "regular" go.

Cthulhu_ 4y ago

I mean it's a good exercise I guess if you want to flex your language knowledge, but it goes against the mindset of Go to actually use it in production. Said mindset being don't overcomplicate things. One doesn't need Go to not overcomplicate things either. I wanted to advocate in favor of Go for a long time, and still do recommend it, but it's the mindset that is more important.

erik_seaberg 4y ago
What I fear most is starting to absorb the "reserved for language designers, not for me" mindset. Stubbornly bending the language to serve you is a much healthier attitude for anyone who wants to maintain his expertise.

rob74 4y ago

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.

pjmlp 4y ago
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.
- jackosdev 4y ago
  I hopped jobs to go from using Go to Rust, I was sad and bored, now I'm happy and energized. Always going to be things you dislike for sure, but life's to short to be using a language that's making you miserable.
  - pjmlp 4y ago
    Which is true, assuming the job market is great on the area, which even on IT isn't the case. Thankfully I seldom have to deal with Go anyway.
- rob74 4y ago
  True, but can you really work day by day in a language and still not understand its appeal? I mean, not like it, but at least understand why others might choose to use it? And, if you really can't bring yourself to see the positive sides of a language you have to use (and any mainstream language has to have positive sides, otherwise it wouldn't be mainstream), maybe it's really time to consider switching jobs...
  - pjmlp 4y ago
    I see Go's appeal as a better C for userspace code, and the language is quite nice had it been released during the days Oberon and Limbo mattered in the mid-1990's. As post 2000 language, its design isn't that appealing. The language would have been as mainstream as Oberon and Limbo were, if the authors weren't working at Google.

silisili 4y ago

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.

pjmlp 4y ago
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.
shakow 4y ago
> 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)?
- rad_gruchalski 4y ago
  I have, maybe a couple of times. Never missed generics.
- ilyt 4y ago
  Those are not show-stoppers, just annoyances. Generics make it oh so much nicer to do some stuff but lack of them wasn't exactly something that I missed, just that I wished some libraries had for the cases you mentioned (generic map/reduce/math/etc.)
ilyt 4y ago
Generics were never required, just their lack was annoying and their presence makes some things just cleaner and easier For example I deal in ops stuff so pretty common task is "here are desired and current set, generate list of add/delete operations to get from one state to another". I wrote iteration of that function a bunch of times pre-generics, eventually being just copy-paste-change-types but now I can just write [1] one that compares a slice of types and returns the elements present in left or right and [2] another that can do similar difference on disparate types via conversion function. Then there is a whole slew of map/reduce and math stuff that now can just have `Map` or `Max` function without worrying about types. Hell I can "just" write "parse all the slice elements in parallel, keeping order [3] once and never worry about it. That's also code that I wrote more than once before generics * [1] https://github.com/XANi/goneric/blob/master/slice.go#L77 https://github.com/XANi/goneric/blob/master/slice.go#L77 * [2] https://github.com/XANi/goneric/blob/master/slice.go#L106 https://github.com/XANi/goneric/blob/master/slice.go#L106 * [3] https://github.com/XANi/goneric/blob/master/parallel.go#L15 https://github.com/XANi/goneric/blob/master/parallel.go#L15

BrandoElFollito 4y ago

> I do not understand the appeal of go. I am an amateur dev developer and used to use untyped languages (Python and JS, mostly). At some point Python was annoying in docker environments (especially for APIs) and I gave a try to Go. Initially I hated it, then learned to like it more and now I kinda like it. - typed (this is a game changer) - compiles to a single self-contained binary (easy with Docker) - great for APIs without the worries of gunicorn and whatnot I also discovered TypeScript to help with JS. So the forst one would be "typed language". I have Python for the rest ("the 2nd best language for any task") and since I am an amateur dev, I do not have the time to dig into many languages to find the pearl.

nine_k 4y ago

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 (like JS, unlike Java), based around channels, not futures, and able to embrace multicore parallelism (unlike JS, like Java, and somehow like Erlang). - Highly opinionated, well-crafted built-in data structures (like Python), and a general approach discouraging you from rolling your own. - Good cross-platform support; fast compilation. That is, it's a language that works well in a case where most of your team is junior devs, and you write some kind of a network server. The devs are forced to follow simple, if repetitive and wordy, patterns, and are limited in their ability to raise creative mayhem in the code base, all while writing reasonably performant, concurrency-friendly code that's a piece of cake to deploy. Combined with some overview from more senior folks, this should work reasonably well (and apparently that's what how it works at Google). No. it's not a joy to use, it has warts (or, rather, deliberate compromises) in many areas, it requires boilerplate which pushes the user towards copy-paste programming, etc. If you can afford to not use it, don't, but sometimes it's the easiest tool for a job, much like, well, PHP.

deleted 4y ago
[deleted]
zachmu 4y ago
I actually find go a joy to use, I dunno. I like statically typed languages, and go makes defining and using types so simple and straightforward that it feels like you get a lot of the benefits of dynamic typing without the headaches.
- nine_k 4y ago
  I love statically-typed languages! What bothers me in Go is mostly the control flow around `result, err := foo(); if err != nil { return err };`, and still non-genericized standard library. But after 1.18 I started to look at Go as a potentially good language, in areas where using Rust is too cumbersome, and using Typescript or Java or Kotlin is also inappropriate.

ilyt 4y ago

>I get wanting to solve a problem, but at what point into fighting the language, to accomplish something simple, do you take a step back and just pick a better one? ..coz they already have code in it ? Coz they are happy with remaining 99% of the language ? It's not hard to figure out cmon. If people dropped language at slight inconvenience we'd be out of languages

tptacek 4y ago

This is an article about an idiosyncratic and fairly interesting approach to writing a fast generic striped map in Golang. Responding to it with a language war appeal is arson; maybe not the "pouring gasoline onto the building" kind of arson, but certainly the "tossing your lit cigarette into the dried up pile of brush" kind. Almost the entire thread on this story has been consumed by a litigation of whether Go is good or not. If you don't like Go (or Rust or Haskell or Elixir or Ruby), that's fine. Just don't comment.

aatd86 4y ago

I think he didn't mean tries which don't generally need hashing but was trying to implement a lock-free map based on Concurrent Hash-Array Mapped Tries. I had done that myself as an exercise a few years back and had to extract the hash function from the runtime that is used for maps. In any case, the performance was terrible and code brittle. (lack of sumtypes). Since then, I've learnt to not bother too much and just use the builtin maps. Never had an issue for my use-cases.

awmarthur 4y ago
(OP) I'm mostly interesting in a fast hash for writing a generic, concurrent hash map. The reference to Tries came from the original issue in the Golang repo about possible uses for a standard library hash function: https://github.com/golang/go/issues/21195 https://github.com/golang/go/issues/21195 And you're right, the Trie implementation linked there was indeed a Hash-Array Mapped Tried: https://pkg.go.dev/github.com/lleo/go-hamt-key#Key https://pkg.go.dev/github.com/lleo/go-hamt-key#Key

coldtea 4y ago

>I get wanting to solve a problem, but at what point into fighting the language, to accomplish something simple, do you take a step back and just pick a better one? What makes you think they haven't tried what you think are "better ones" and moved away because they had more problems to fight the language/ecosystem about with those?