3 ms·

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 t

by jerf 5y ago

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 package of all this stuff with the original API of C++; I want the same capabilities, but for them to be idiomatic in the new language. It is quite common that the resulting port will both be missing some things no longer necessary in the new language, but may also require things that weren't necessary in the host language. As a nice little bite-sized example, consider some of the vector methods. PushBack takes a single element. It really ought to take a slice, probably via the "..." notation to make it a variable-argument function. That's idiomatic in Go. It is also idiomatic to offer that functionality and not worry too much about the fact it will be ever so slightly slower than not taking a slice. Go is generally fast, but if you care that much about speed to the n'th degree, you picked the wrong language. "Reserve" is in the original C++ API because C++ is not a garbage collected language. Go has the ability to specify sizes up front with slices, and that's generally enough. ShrinkToFit is generally again for a non-GC'd language... it's not useless in Go but again, if you're really paranoid about that being available you probably picked the wrong language. Examples of this sort are pervasively shot throughout this API, from what a scan of it shows me. A non-trivial amount of the complexity of the STL interface is related to manual memory management. In Go it results in APIs where even if you can't quite point at what the problem is, they're just generally overcomplicated in a GC language. I expect something much simpler to implement, much simpler to use, and probably also faster to execute could be written if one wrote a list of the desirable capabilities down, and then ignored the C++ API and implemented the capabilities directly in idiomatic Go. Probably after crossing off a couple of things in the capabilities related to C++ being manually-memory-managed, and perhaps after adding some capabilities related to cheap threads being available, e.g., a parallel map operation that works across these data structures or something. Idiomatic, not just blindly copied. (I comment on this because I do see this a lot. Since these sorts of libraries rarely take off it can be a fatal mistake made on a lot of effort.)

tialaramex 5y ago
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 and C++ agree that a "string" might be just any bunch of bytes, who knows how they're encoded, that's somebody else's problem so APIs which do care need to be very explicit, maybe even mentioning it in method names. In Python that's very strange, the strings are always Unicode and so a function name_in_cp1252() is awkward to use, probably just offer name() and cope with the encoding. There are some subtle but important affordances which a non-native user may not even consider adding because their preferred language just omits the necessary feature. For example Rust's From/ Into/ TryFrom/ TryInto cascade or C++ 20 spaceship operator are things native speakers of those languages expect in a good library but aren't going to fall out naturally from converting a Python API.
- synergy20 5y ago
  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.
layer8 5y ago
> 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.
turminal 5y ago
> 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++ ;)
- jerf 5y ago
  Point taken.

by jerf 5y ago

tialaramex 5y ago

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 and C++ agree that a "string" might be just any bunch of bytes, who knows how they're encoded, that's somebody else's problem so APIs which do care need to be very explicit, maybe even mentioning it in method names. In Python that's very strange, the strings are always Unicode and so a function name_in_cp1252() is awkward to use, probably just offer name() and cope with the encoding. There are some subtle but important affordances which a non-native user may not even consider adding because their preferred language just omits the necessary feature. For example Rust's From/ Into/ TryFrom/ TryInto cascade or C++ 20 spaceship operator are things native speakers of those languages expect in a good library but aren't going to fall out naturally from converting a Python API.

synergy20 5y ago
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.

layer8 5y ago

> 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.

turminal 5y ago

> 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++ ;)

jerf 5y ago
Point taken.