Honest question: isn't Go a bit of a weird choice for a database given the GC? Why not C/C++/Rust?
If you like/trust dbdb.io, most databases are written in C++ or Java. C# and Go are also high on the list.
Hacking Go's runtime with generics
51–60 of 113 posts
Re: Hacking Go's runtime with generics
#52Earlier quoted context omitted.
Why can't a database be written in a garbage collected language?
I believe you usually want as much control of memory management as possible as it can be a great place for finding performance improvements and also help in delivering very consistent performance. Automatic memory management is a great aid in reduction of the complexity you have to deal with, but you presumably want to deal with that completely in the context of a database. Seems like this: https://www.cockroachlabs.…
> I believe you usually want as much control of memory management as possible as it can be a great place for finding performance improvements and also help in delivering very consistent performance.
Sure, but premature optimization is the root of all evil right? Get something functional, then make it performant by handling the problematic cases. GC doesn't prevent this progression, it's just a significant help to getting something functional.
GC can sometimes lead you into designs that can't be optimized without a change in abstraction, but it's not at all obvious that you would have landed on the right abstraction if you didn't have the GC to begin with anyway. I think getting something working as fast as possible lets you gather the data you need to make a performant design, and having to handle all of that complexity up front without a GC just delays the data gathering stage.
Re: Hacking Go's runtime with generics
#53I 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 (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.
Re: Hacking Go's runtime with generics
#54Earlier quoted context omitted.
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.
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...
> 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/Kotlin/C# would be, IMHO, much better.
And both paths offer the same level of tooling, so it's still a mystery to me.
Re: Hacking Go's runtime with generics
#55I 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 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
Re: Hacking Go's runtime with generics
#56I 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.
Hell, just scroll down in this thread to see the clowns. Maybe envy that their favourite toy/niche language didn't get popular instead ?
Like, there is plenty of flaws clear to see in Go but it does some jobs well and that's all that's needed to be useful language.
Re: Hacking Go's runtime with generics
#57Earlier quoted context omitted.
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.
Huh, the one reason that I'd wish most languages would die and we picked like... 5 is that seemingly every time I hit a project I'd want to hack upon it's in language I don't know...
Re: Hacking Go's runtime with generics
#58I 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…
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.
Re: Hacking Go's runtime with generics
#59I 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 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.
Re: Hacking Go's runtime with generics
#60Earlier quoted context omitted.
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.
I looked into using Graal one time. Many of the dependencies I used were not compatible. I also encounter weird bugs with any of the OpenJ* alternatives. In Go, everything just works.