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

GoSTL: Algorithm and datastructure library for Go similar to C++ STL

github.com

Post reply on HN
Print view View original

41–48 of 48 posts

Re: GoSTL: Algorithm and datastructure library for Go similar to C++ STL

#41

Post by pjmlp »

scheme271 wrote: post #36
pjmlp wrote: post #24

Earlier quoted context omitted.

It was good enough for ATLAS experiments, but what does CERN understand about HPC anyway.

CERN and HEP (high energy physics) in general care more about HTC (high throughput computing). In general, event processing is pleasantly parallel since each event can be processed independently of others. A lot of the computing is really similar to a world wide distributed map reduce cluster. This significantly reduces a lot of the complexity that comes up when working with a workflow that might have thousands of th…

So much words and nothing about iostreams or STL.

I know how ATLAS HLT TDAQ works, you will find my name on 2003 - 2004 papers.

Re: GoSTL: Algorithm and datastructure library for Go similar to C++ STL

#42

Post by pjmlp »

lpapez wrote: post #35
_wldu wrote: post #31

Earlier quoted context omitted.

unordered_map is hash based. It's as fast as any other hash backed data structure. Hash performance is well defined and widely understood.

There are dozens of hash map implementations for C++, and while they all have O(1) asymptotic complexity, the runtime performance can be vastly different depending on the implementation choices. The design space of a hash based data structure is immense, but std::unordered_map is generally always avoided unless your main goal is either ease-of-use or beginner-friendliness or you simply don't care about performance. B…

In many cases C++ is the only tool for the job, unless one wants to have fun doing their own toolchain on top of the platform SDKs, or drop down to C, even worse.

Re: GoSTL: Algorithm and datastructure library for Go similar to C++ STL

#43

Post by throwaway894345 »

DontGiveTwoFlux wrote: post #3

I hope that iterations can get some language level treatment via a mechanism to hook into the ‘range’ operator on custom containers.

I care less about hooking into range and more about the performance. I would really like for iterators to be zero-cost abstractions, but right now a SliceIter is waaaayyy slower than looping over a slice (with range or otherwise). The Go compiler isn’t smart enough to realize that a loop over a SliceIter can be reduced to a loop over a slice, perhaps because it can’t know for certain that the loop counter variable (e.g. the `counter` field in `type SliceIter[T any] struct { slice []T; counter int }`) is only being accessed by the loop itself (this might be where Rust’s ownership semantics would be useful in Go?).

Re: GoSTL: Algorithm and datastructure library for Go similar to C++ STL

#44

Post by pjmlp »

cyber_kinetist wrote: post #16
turminal wrote: post #12

Earlier quoted context omitted.

> It has precisely copied the original API, despite the fact the original API is quite unidiomatic in the new language. STL isn't even idiomatic in C++ ;)

I really wish someone takes the work of ditching the STL as a whole and make an unofficial “version 2” of the same standard library. I mean, IO sucks ass, std::string really sucks, containers like unordered_map are really slow (because of the pointer stability requirements), custom allocators are cumbersome, the regex library is a mess, why are string_view and span different things, yada yada. (And darn those long co…

“This Videogame Programmer Used the STL and You Will Never Guess What Happened Next” - CppCon 2019

https://www.youtube.com/watch?v=6hC9IxqdDDw

Ergo, not everyone agrees with that opinion.

Re: GoSTL: Algorithm and datastructure library for Go similar to C++ STL

#45

Post by kortex »

stackedinserter wrote: post #9
maerF0x0 wrote: post #4

Earlier quoted context omitted.

what do you mean by "random urls"?

Having `import "github.com/liyue201/gostl/ds/array"` in codebase looks weird and unsafe. Like, who's liyue201 and what exactly I'm importing? Vendoring helps a bit, but it's still ugly. Same problems exist in other languages, although "import numpy as np" doesn't explicitly say that you're importing a random head from someone's master.

> Same problems exist in other languages, although "import numpy as np" doesn't explicitly say that you're importing a random head from someone's master.

Sure, python is just implicitly doing so, is that any better? Lets say you know nothing about python or numpy. You see "import numpy". What/who is numpy? How is it provisioned? Is there only one thing called numpy? How do you know it's installed locally/site-packages/editable/PYTHONPATH? You can answer these questions, but not immediately. Numpy is a poor example because it's so well know, but the other day I was trying to sort out "from pylab import *". Can't "pip install pylab". Turns out, matplotlib provides it, but for weird legacy reasons, pylab is a top level namespace.

The whole point is, if you don't trust "liyue201", then you can immediately know not to import that package. It's completely explicit in what it's doing, and no one is making you install libs from github.

Re: GoSTL: Algorithm and datastructure library for Go similar to C++ STL

#46

Post by icholy »

tsimionescu wrote: post #32
evanmoran wrote: post #18

Earlier quoted context omitted.

This is how imports work in go. You make it look like a url, but then can choose in the mod (the module) file if it is local or to keep the url. This makes it quite clean because files have the same import url even as relative paths change, so you can move files all around and the import statements can stay the same. It also has the added advantage that there is no single module repository like in npm. So any url / G…

> This makes it quite clean because files have the same import url even as relative paths change, so you can move files all around and the import statements can stay the same. That only works if no one is using your module as a dependency. > So any url / GitHub repo works so no module can permanently own a name. Only if go mod understands the source control mechanism, and only if the HTTP server in front of that spea…

Why do you have such strong opinions on things you clearly don't use or understand?

Re: GoSTL: Algorithm and datastructure library for Go similar to C++ STL

#47

Post by tsimionescu »

icholy wrote: post #46
tsimionescu wrote: post #32

Earlier quoted context omitted.

> This makes it quite clean because files have the same import url even as relative paths change, so you can move files all around and the import statements can stay the same. That only works if no one is using your module as a dependency. > So any url / GitHub repo works so no module can permanently own a name. Only if go mod understands the source control mechanism, and only if the HTTP server in front of that spea…

Why do you have such strong opinions on things you clearly don't use or understand?

I do use and understand these things. I have fought several times with go mod and know a few of its quirks.

Go mod works by cloning the remote repository you import (unless the module it is working on has a replace directive). It does this via HTTPS or Git ssh or other source control mechanisms, based on the form of the import link and your GOPROXY and GOPRIVATE environment variables and their various flags and options. For each source control mechanism, it has some specific way to decide exactly what version to sync to (such as git tags to chose a specific commit).

It also depends on how you have configured your source control in your local environment, as that is what will ultimately download the code - if you want to download modules from repos that require various forms of authentication, it's up to every dev to configure credentials for each of these (or theoretically someone could mirror them to a single repo with common auth).

It's still important to note that replace directives are only used when building that particular module. Say module A depends on module B. Module B has a dependency on module github.com/proj/C, but locally adds a replace directive to replace github.com/proj/C with bitbucket.com/proj/C. When running go mod in B's folder, it will download the version of C from BitBucket. But, when building module A, it will download module C from GitHub. Replace directives are just for local builds, your dependents don't look at them.

Re: GoSTL: Algorithm and datastructure library for Go similar to C++ STL

#48

Post by jerf »

turminal wrote: post #12
jerf wrote: post #7

There's a lot of good work put into this. If it is intended as a tool to help port C++ code out of C++ into Go, it looks very useful. If it is intended as a tool to help Go programmers, it has made a common, but regrettably very serious mistake, that programmers make when porting code: It has precisely copied the original API, despite the fact the original API is quite unidiomatic in the new language. I don't want a…

> It has precisely copied the original API, despite the fact the original API is quite unidiomatic in the new language. STL isn't even idiomatic in C++ ;)

Point taken.
Post reply on HN