The ups and downs of porting 50k lines of C++ to Go (2015)

Re:The ups and downs of porting 50k lines of C++ to Go (2015) by laumars on Thursday March 14, 2019 @05:14AM (#19387582)

In fairness, my biggest day to day pain point of using Go isn't the oft discussed lack of generics nor it's unpopular error returns. What bothers me the most when writing Go regularly is that I'm constantly having to reimplement basic functions for working with slices. The lack of a push or pop. Even selecting the last element of the slice via the following really becomes bothersome when you start dealing with multi-dimensional arrays:

  slice[len(slice)-1]

The lack of a push and pop is a small inconvenience but it still disrupts my flow - not to mention adds unnecessary burden on testing to ensure I haven't cocked up something that should be elementary (and those kinds of errors are often a pain in the arse debug too).

The latter isn't so much a productivity problem - I just think it looks ugly as sin. Which is why I sometimes add a .Last() method to any slice types I define where I need to read the last item regularly.

[ Parent | on HN ]

Re:The ups and downs of porting 50k lines of C++ to Go (2015) by janekm on Thursday March 14, 2019 @05:56AM (#19387765)

Python supports slice[-1] for the last element... Pretty reasonable. Also slice[0:-1] etc. Swift also has a lot of array slice sugar, like array.last, array.endIndex, array.removeLast ... Obviously there is a trade-off to adding a lot of sugar to a language, in terms of learning the language, but leaving too little sugar in the language just leads to developers / library designers implementing the sugar themselves which leads to a whole mess of inconsistent code.

[ Parent | on HN ]

Re:The ups and downs of porting 50k lines of C++ to Go (2015) by laumars on Thursday March 14, 2019 @06:06AM (#19387817)

> Python supports slice[-1] for the last element... Pretty reasonable.

Lots of languages offer something akin to that. If not `[-1]` then something more OO like `.last`. Even the language I wrote supports it. This is why I made the complaint about Go.

> Also slice[0:-1] etc.

In fairness, Go can do that. You just omit the value for where you want the last (or first) element of the slice or array. eg

  b := []byte("Hello, World")
  world := b[7:]

(this would work with strings too but I'm using a byte to make it clear we're working with slices)

edit: just for clarity I mean Go has the syntactic sugar for stating the start or end of a slice - rather than a negative number of elements from the end of the slice. My point being that there is already some syntactic sugar in specifying slices so it's a shame Go doesn't take that further.

[ Parent | on HN ]

Re:The ups and downs of porting 50k lines of C++ to Go (2015) by 314 on Thursday March 14, 2019 @06:22AM (#19387900)

In python slice[0:-1] drops the last element. To get the same effect in Go you need world := b[:len(b)-1]. The len() needs to be there (your example is a different case).

[ Parent | on HN ]

Re:The ups and downs of porting 50k lines of C++ to Go (2015) by laumars on Thursday March 14, 2019 @06:26AM (#19387926)

Yes, I was the one who made the comment about Go's lack of a -1 for slices in the first place. ;)

I was actually referencing the 0 part and thus saying Go does already have some syntactic sugar when dealing with slices. ie you can do:

   slice[5:]   // slice[:len(slice)]

but not

   slice[5:-1] // slice[:len(slice)-1]

Which is a great pity.

However I'll update my previous comment to make that clearer because I can totally understand how it reads confusingly.

[ Parent | on HN ]