Go is about to get a whole lot faster

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • WorkOS - The modern identity platform for B2B SaaS
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • SaaSHub - Software Alternatives and Reviews
  • deque2

    Fast ring-buffer deque (double-ended queue)

    I’m also not much of a Go programmer, but looking at the benchmark code it doesn’t actually use the values after they are retrieved, so if the compiler is smart it may never have to check the runtime of the type. It does, however, have to wrap the primitive in the any type, which seems to be what’s making it slow.

    Question for Go programmers: does using the any type result in an additional memory lookup if the wrapped type is a sized primitive like an int, or is the value stored directly alongside the type information?

    https://github.com/sekoyo/deque/blob/86df0003850acaf3039c2d6...

  • FrameworkBenchmarks

    Source for the TechEmpower Framework Benchmarks project

    >> Go is known to be quite slow

    I understood it was comparable to Java or C#, both of which are extremely fast - both in terms of execution speed and more so in terms of developer productivity.

    The benchmarks I’ve seen generally back that up

    https://plummerssoftwarellc.github.io/PrimeView/report?id=da...

    9th overall - faster than c++ for example in Dave Plummers primes benchmark. I quite like that benchmark because it’s really just a bunch of memory operations, a decent view of the compilers ability to generate decent code. Although my concern with this benchmark is that not all languages got the same optimisation effort. Looking at git commits, it seems like rust got almost more optimisation effort than every other language combined.

    Also i don’t like the unfiltered view of that benchmark - lisp comes out fastest language of all but that’s because languages like c++ and Rust can only really pre calculate results at compile time (constexpr etc) - whereas that lisp implementation is doing everything before compilation. Unfair because other languages don’t have a precompilation reader phase.

    https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

    In the area of java, Swift etc i don’t like these benchmarks at all though. The c# one for example often relies on c libraries or vector intrinsics etc so it’s not really like for like.

    https://www.techempower.com/benchmarks/#section=data-r20&hw=...

    Between java and c++

  • WorkOS

    The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.

  • slice_deque

    A contiguous-in-memory double-ended queue that derefs into a slice

    There is a single contiguous memory allocation, which mirrors itself.

    One thread produces elements and pushes them at the tail (e.g. I/O bytes, in batch), and one thread consumes as many elements as possible in batch from the other end (e.g. all bytes available, in batch).

    The mirror is required to allow processing all elements in the deque as if they were adjacent in memory.

    This is the library i am using, the array contains an explanation : https://github.com/gnzlbg/slice_deque

  • go

    The Go programming language

    > It was endless arguments from Go users that generics aren't needed

    There was (and still is) a small minority of Go users that insist generics are bad, but in my observation it's nowhere near the majority view. As a concrete datapoint, the GitHub issue on this[1] has 2k upvotes and 150 downvotes. A sizeable minority, but a minority nonetheless.

    As is often the case, "the Go community" is far from heterogeneous, and it's hard to really get an idea what "the average Go programmer" thinks, and easy to criticise the most extreme elements.

    Certainly for the Go team itself the position was always that 1) generics are useful, but 2) we're not quite sure how to best implement them. People take issue with that viewpoint too, which is fair enough, but it's really quite a different one.

    [1]: https://github.com/golang/go/issues/15292

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts