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

31–40 of 48 posts

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

#31

Post by _wldu »

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…

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

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

#32

Post by tsimionescu »

evanmoran wrote: post #18
zerr wrote: post #2

Off topic: is there still no alternative for putting random URLs directly in a source code in order to use some libs?

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 speaks the survival go mod protocol. It's a horrible system that the go team doesn't use internally.

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

#33

Post by layer8 »

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…

> As a nice little bite-sized example, consider some of the vector methods. PushBack takes a single element.

Also, push_back has always been an awkward name choice. Porting would be a good opportunity to rename it to append.

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

#34

Post by jupp0r »

The design decision of providing thread safe operations on data structures by default is a pretty poor one. In my experience this is the wrong level of abstraction on which to perform mutual exclusion of certain operations. Normally you want locks around a transaction-like operation that might involve multiple operations on a data structure (or multiple data structures). When just using concurrency safe containers on their own, subtle consistency bugs can be introduced and you end up writing a second layer of locks around the higher level code anyways, now paying the performance overhead of locking twice, once for your logic and then for the container.

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

#35

Post by lpapez »

_wldu wrote: post #31
cyber_kinetist wrote: post #16

Earlier quoted context omitted.

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…

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. But if any of these is true for your context, then C++ is probably not the right tool for the job anyway.

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

#36

Post by scheme271 »

pjmlp wrote: post #24
cyber_kinetist wrote: post #16

Earlier quoted context omitted.

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…

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 threads interacting with each other.

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

#37

Post by Someone »

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…

> 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

Nitpick: the STL (https://en.wikipedia.org/wiki/Standard_Template_Library#Cont...) contains neither of these.

> and make an unofficial “version 2” of the same standard library.

Part of the C++ standard library in some sense _is_ version 2 of the STL.

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

#38

Post by synergy20 »

jupp0r wrote: post #34

The design decision of providing thread safe operations on data structures by default is a pretty poor one. In my experience this is the wrong level of abstraction on which to perform mutual exclusion of certain operations. Normally you want locks around a transaction-like operation that might involve multiple operations on a data structure (or multiple data structures). When just using concurrency safe containers on…

I agree, while 'lock data not code' sounds good(that's what Rust does I think), container is a different story, it's by design mutable and unfit to lock as a data structure, container is not a pure data structure, it's a ADT that really works with data structure and its methods(algorithms) hands in hands, hard to split by any lock.

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

#39

Post by synergy20 »

tialaramex wrote: post #27
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…

The whole point of the Standard Template Library was generics. That's the good idea behind the STL, and as I understand it this doesn't support generics, so it's missing this crucial concept. But yes I generally agree with your point. The X language version of a Y language library ought to work the way somebody who has never used the Y language but is familiar with X expects it to work. That's across the board. Go an…

Indeed. Might be easier after go1.18 with generics is out to create a STL for Go. STL could be so useful for Go if done right.
Post reply on HN