
The ups and downs of porting 50k lines of C++ to Go (2015) - aparashk
https://togototo.wordpress.com/
======
chewxy
> Readability. I always found the Go code I encountered quite easy to read and
> understand, both our code and external code. Some of the C++ I encountered,
> in contrast, took hours to fully comprehend. Go also forced me to write
> readable code: the language makes it impossible to think something like
> “hey, the >8=3 operator in this obscure paper on ouroboromorphic
> sapphotriplets could save me 10 lines of code, I’d better include it. My
> coworkers won’t have trouble understanding it as the meaning is clearly
> expressed in the type signature: (PrimMonad W, PoshFunctor Y, ReichsLens S)
> => W Y S ((I -> W) -> Y) -> G -> Bool”.

This sentence is gold J

~~~
millstone
I don't get the "Go is easy to read" notion. Here's the recommended way to
work with slices: [1]:

Delete from a slice: `a = append(a[:i], a[i+1:]...)`

Copy a slice: `b = append([]T(nil), a...)`

Pop from a slice: `x, a = a[len(a)-1], a[:len(a)-1]`

And some of these are discouraged because they leave you vulnerable to memory
leaks (?)

These are fundamental building blocks and they're really quite bad. I mean
when you're using `append` to delete...

1:
[https://github.com/golang/go/wiki/SliceTricks](https://github.com/golang/go/wiki/SliceTricks)

~~~
joshuak
That is not the recommended way to work with slices. These are novelties, aka
tricks. The following is more representative.

Delete:

    
    
        copy(a[i:],a[i+1:])
        a = a[:len(a)-1]
    

Copy:

    
    
        b := make([]T, len(a))
        copy(b,a)
    

Push:

    
    
        a = append(a, x)
    

Pop:

    
    
        x := a[len(a)-1]
        a = a[:len(a)-1]
    

Enqueue:

    
    
        a = append([]T{x}, a...)
    

Dequeue:

    
    
        x := a[0]
        a = a[1:]
    

Idiomatic Go would have you not put on one line what is more clear on two.

~~~
jonahx
> Idiomatic Go would have you not put on one line what is more clear on two.

This is the kind of silly aphorism that sounds enlightened until you think
about it, and is emblematic of the bad parts of Go dogma.

The problem is that excessive LOC actually correlates strongly with poor
readability, and all the cleverness in the world won't change that.

~~~
Arnavion
It's also not even true, given that `if foo, err := bar(); err != nil {` is
considered idiomatic over writing that over two lines.

~~~
joshuak
Both are idiomatic. I use the two line version.

I don't like this form both for legibility, and the fact that it closes over
the return value.

------
RhodesianHunter
Coming from JVM languages, it drives me nuts that I can't
.map/.filter/.foreach/.reduce etc. my collections, especially with something
like streams/sequences. That's where you really notice the lack of generics if
you're used to this sort of programming.

~~~
ilovecaching
Go isn’t Java. It’s easy to bring our biases in from other languages, but when
you use a language you should be buying into the philosophy, conventions, and
style of the language as much as the rules of the language.

Go focuses on code, not data and concrete solutions, not generic ones. It’s a
language designed for the 90%. If that doesnt fit your requirements, it’s ok
to use C++, Haskell, or Java, or some other equally good language. But Go is
really, really good when you give it a fair chance.

~~~
smadurange
This is a cheap way out. I don't think most people are putting down Go as an
outright terrible language.

So, when so many engineers with lots of experience say that, for instance, no-
generics is a problem with Go, it's worth considering that may be it really is
a problem.

I wonder what you will say if Golang introduces generics in a future release.

~~~
sacado2
Well, they _are_ about to introduce generics, so...

~~~
cy_hauser
No, not quite. Rob Pike said in a video about a year or so ago that now they
have enough experience to start thinking about generics. That the process is
now just starting and you shouldn't expect them any time soon.

The Go core team has to decide if there's a way to add them to the language in
a "Go way." If they can't they won't be added to Go at all, despite what other
people want or don't want.

~~~
sacado2
They started making early proposals, with syntax and the associated semantics.
It will take a long time, but I'd be very surprised if they changed their mind
now.

------
ilovecaching
I personally love Rust and think Rust is the future for C and C++, and use it
professionally. But Go is simple, fun, fast, and easy to read and frankly more
approachable by the people many companies can afford to hire.

I view language choice as a line. If I need to build big, or build niche, or
build fast, I use Rust. But if it’s general purpose I use Go. I can write Go
faster than I can write Python because the type system gives me a fast
feedback loop and the language is simple and builds in the common case
building blocks. I can get better performance and understand my app better
than with the JVM because it’s compiled ahead of time and I already know the
ins and outs of Linux. There is no black box JVM that consumes resources while
idling.

Go has advanced the state of formatting, documentation, and revitalized the
Unix philosophy of building small, focused pieces without getting caught in
the clouds over abstracting.

If you are currently using a Python, Java, C#, or JavaScript, Go is better.
Just don’t post angrily to your blog until you’ve written Go while also
embracing its philisophy and taking the time to understand the authors
intentions.

~~~
SeanDav
Where does Windows development fit into the Go way of doing things? Is Windows
a first class citizen for Go?

Python, Java, C#, C, C++ are all very well supported in Windows.

P.S. I don't have any hidden agenda with this comment - genuinely curious.

~~~
laumars
Windows is very much a first class citizen - just so long as you're writing
CLI tools or web services.

Unfortunately writing native GUIs in Go is something that isn't well supported
- irrespective of the host platform you're targeting.

------
tschellenbach
Switched from Python to Go about 2 years ago. If you need to build performant
APIs with a small team there is nothing that comes close. You get the
productivity of something like Python with the performance of C++. Or at least
very close to it in both cases. ([https://getstream.io/blog/switched-python-
go/](https://getstream.io/blog/switched-python-go/))

The lack of generics hasn't bothered me so far. You just find different
solutions to the problem. Composition, interfaces, or if all else fails an
empty interface{}. It's rare to really not be able to work around it. It does
make it near impossible to build reusable and performant data structures in Go
though. (say that you want to build your own heap or list, hashtable etc.) So
that's annoying, but something that you rarely run into.

Bigger issue is that GO modules are still not ready for production since the
ecosystem didn't catch up:
[https://github.com/golang/go/issues/24661](https://github.com/golang/go/issues/24661)

~~~
whateveracct
It's just a shame that you could EASILY bolt on basic parametric polymorphism
to Go with 0 cost and huge benefit. And it'll never happen.

The power of a universally quantified interface cannot be underestimated!

~~~
joeblubaugh
Never? This is one of the basic proposals in the Go 2 roadmap.

~~~
pjmlp
Rob Pike is against the current proposal and clearly states it comes from the
community.

[https://www.youtube.com/watch?v=RIvL2ONhFBI](https://www.youtube.com/watch?v=RIvL2ONhFBI)

------
nayuki
This HN item links to the blog's front page. The actual article is at
[https://togototo.wordpress.com/2015/03/07/fulfilling-a-
piked...](https://togototo.wordpress.com/2015/03/07/fulfilling-a-pikedream-
the-ups-of-downs-of-porting-50k-lines-of-c-to-go/)

------
networkimprov
For anyone bothered by Go's simplistic error handling, a menu of _Requirements
to Consider for Go 2 Error Handling_ :

[https://gist.github.com/networkimprov/961c9caa2631ad3b95413f...](https://gist.github.com/networkimprov/961c9caa2631ad3b95413f7d44a2c98a)

See also the Go 2 Draft Design feedback wiki:

[https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback](https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback)

------
rienbdj
After switching to ML languages for most development tasks, I don’t think I
could face using a language with so few features.

Is most of the hype from a dev ops perspective? Go looks tiresome to program
in.

~~~
coldtea
Well, there's some blub paradox (PG) at play.

As Go team found out, it's not like people go from C++, OcamL or other full
featured languages to Go.

For Python/Ruby etc programmings coming to Go, the lack of features feels
exciting, because it makes them think they're programming closer to the metal
(what with types, and static compilation, and contiguous arrays, and
pointers).

~~~
laumars
I've written stuff in C++ as well as Python. The simplicity of Go appeals to
me because it means the code is generally more readable (eg people aren't
abusing advanced features quite so much).

Anecdotally I've found reading other peoples Go code far easy than I've found
reading other peoples code in pretty much any other language. YMMV though

~~~
coldtea
> _Anecdotally I 've found reading other peoples Go code far easy than I've
> found reading other peoples code in pretty much any other language_

At the micro level yes. At the macro level though, it's easier to understand
10 lines of dense code than the 200 lines Go forces you to write for the same
thing. At least you can see them in your screen all at once (and usually
express the intent more directly).

~~~
laumars
For _you_ , perhaps. However for me I completely disagree.

What you're failing to understand is that this is an entirely subjective
rather than objective matter. What works for you isn't proof that it's the
same for everyone else.

This is why I've said " _The simplicity of Go appeals to me_ ", " _Anecdotally
I 've found_" and " _YMMV_ " to made it clear in my post that the subject
you're discussing is actually a matter of personal taste.

~~~
coldtea
> _What you 're failing to understand is that this is an entirely subjective
> rather than objective matter._

I don't think it is subjective.

It's just that as an industry we don't have large scale research into such
things.

> _What works for you isn 't proof that it's the same for everyone else._

No, but our brains co-developed evolutionary for millions of years for some of
us to be widely different than others in how they work.

~~~
laumars
> _I don 't think it is subjective._

The very fact that we disagree on what we find readable should be evidence
enough that it's subjective.

> _It 's just that as an industry we don't have large scale research into such
> things._

I don't need large scale research to tell me what I, _personally_ , find
easier or harder to read.

Research would tell us what the _general_ rule of thumb is but that's very
different to saying there's a definitive rule that applies to everyone
uniformly.

> _No, but our brains co-developed evolutionary for millions of years for some
> of us to be widely different than others in how they work._

Forgive me if I'm missing your point here but some people like fast cars and
some people like to cycle. Some people want kids while others do not. Some
people enjoy working in IT while others want to be gardeners, carpenters,
mechanics, doctors, lawyers, etc.

Even specifically to HN, we have enough arguments on here about emacs vs vi;
CLI vs GUI; and tiled window managers vs dynamic / overlapping windows to
demonstrate that personal preference is alive and well in the field of IT. Yet
it's strange how you consider it not to be applicable when it comes to
language preferences. I suggest that's failing of imagination on your part.

~~~
coldtea
> _I don 't need large scale research to tell me what I, personally, find
> easier or harder to read._

I think we do.

Your phrasing implies that everybody (or at least just you) already and always
knows and uses the optimal code styles that make it "easier" for them to read
code.

I very much doubt that's the case.

People are deluded about what's "best for them" all the time.

Not to mention "what's best" might change with familiarity with other styles,
training, etc, and people could be stuck in a shallow local optimum.

> _Forgive me if I 'm missing your point here but some people like fast cars
> and some people like to cycle. Some people want kids while others do not.
> Some people enjoy working in IT while others want to be gardeners,
> carpenters, mechanics, doctors, lawyers, etc._

Those are matters of taste. Not matters of cognitive skills and how people
read best, learn best, etc.

In fact, the popular myth of personal "learning styles" (X training style
being best for some people, Y style best for others, etc) has been demolished.

And yet tons of people confused their "preferences" with some objective
reality of their preferred style being better for them.

[https://blog.mindresearch.org/blog/learning-styles-
myth](https://blog.mindresearch.org/blog/learning-styles-myth)

[https://www.theatlantic.com/science/archive/2018/04/the-
myth...](https://www.theatlantic.com/science/archive/2018/04/the-myth-of-
learning-styles/557687/)

~~~
laumars
> _Your phrasing implies that everybody (or at least just you) already and
> always knows and uses the optimal code styles that make it "easier" for them
> to read code._

No it doesn't. All I've been saying is I find Go - in general - more readable
than other languages. Everything else thereafter is you badgering your
language snobbishness onto others and me having to say, repeatedly, "I like
what I like"

> _Those are matters of taste. Not matters of cognitive skills and how people
> read best, learn best, etc._

"Read best" != "learn best". Anyone who has dyslexia will tell you that they
struggle with layouts that others wouldn't take issue with. People who aren't
native English speakers also often have different preferences for writing
styles to native English speakers.

------
johnvega
I'm a C++ programmer for over 10 years and looking forward to becoming a Go
programmer, professionally.

------
dang
Discussed at the time:
[https://news.ycombinator.com/item?id=9161366](https://news.ycombinator.com/item?id=9161366)

------
agentofoblivion
I wonder how Dlang would have compared.

~~~
zerr
D is superior in every aspect except the BigCo support.

~~~
agentofoblivion
Why do you think that is (the lack of BigCo support)?

~~~
zerr
Because Walter Bright is/was not working at Google, Oracle or Microsoft? :)

------
herf
> he expected the language to be adopted by C++ programmers, a prediction that
> hasn’t been realised

I respect go (and its runtime) a lot, but one little thing keeps me from using
it: the reverse "argument type" ordering (backwards from C++) makes me avoid
it. If this were the only language I used, it would be easy, but when
switching back and forth, does anyone else find it hard to do?

~~~
abvdasker
My job requires switching between Go and Java occasionally. While I think Go
is slightly more natural, it definitely adds cognitive overhead when going
back to Java. But that additional overhead is nothing compared to the rampant
and indecipherable stringing together of Guava futures in my company's Java
codebases.

~~~
fiddlerwoaroof
The newer jvm languages (particularly thinking of Kotlin and Scala) though,
generally are type-second languages.

------
stesch
Link to the article instead of the blog:
[https://togototo.wordpress.com/2015/03/07/fulfilling-a-
piked...](https://togototo.wordpress.com/2015/03/07/fulfilling-a-pikedream-
the-ups-of-downs-of-porting-50k-lines-of-c-to-go/)

------
kristianp
"one of my reasons for getting into programming was the opportunity to get
paid to use Emacs".

Not a reason for getting into programming that many have, I expect!

------
alfalfasprout
Wow, I'm surprised to see the typical "Well, why didn't you just use Rust"
comment hasn't been posted.

At the end of the day, it sounds like they just had some clunky C++ code that
was due for a rewrite anyways (and the author admits as much). If you don't
need it to be ultra low latency, some nice abstraction and modularity can
already do wonders.

I've found Go to be an excellent Java replacement when all is said and done.
Great for the vast majority of services you might write. But if you need to do
anything lower level or that involves complex type logic you always end up
with a clunky solution (and I'm not going to sing any praises for C++ having
an elegant solution either).

That said, modern C++ (especially 17) can be made to look decently clean and
without weird behavior in most cases. Yes, there's always the person that
shows up and points out weird edge cases that you can run into but the
situation is far, far better than it was years ago. With some good engineering
practices in encapsulating low level optimized code you can largely limit the
"danger surface" of your codebase.

~~~
pjmlp
When Go gets around supporting Java generics, dynamic loading, JDBC, PDF
generation libraries, Office/LibreOffice manipulation libraries, Akka, CMS
platforms, BluRay/SIM CPUs, a phone OS, a GUI library comparable to AWT
(lowering the level as Swing/JavaFX/Android aren't even around), JMX
instrumentation, hot code replacement.... then maybe just maybe, it is an
excelent replacement for Java.

~~~
laumars
I can't tell if it's intentional but your post borders on fanboyism given
about 80% of what you listed there is either already available for / possible
in Go or is a Java specific term so naturally Go would have it's own mature
libraries out there under a different name. For example

* JDBC, Akka, etc

There as all Java specific technologies but that doesn't mean that Go (nor any
other language) doesn't have their own libraries to do the same. I mean you're
not going to call Go's database libraries " _Java_ Database Connectivity" are
you

* PDF generation libraries, Office/LibreOffice manipulation libraries, CMS platforms,

Go already has all that

* a phone OS,

There isn't any phone OS's written in Java either. There are phone OS's that
use Java as their preferred application runtime environment - such as Android
- and many of them can and do support running Go binaries as well. There is in
fact a lot of documentation online regarding running Go on Android.

\---

I'll grant you that Go doesn't have hot code replacement nor generics but the
former is a pretty niche case for Java development that wouldn't really
improve Go's current workflow anyway - and the latter is such an tired old
argument that you're not going to win any debates by pointing it out.

Disclaimer: I've programmed in both Java and Go (as well as more than a dozen
other languages too). So I'm about as agnostic as they come when it comes to
evaluating programming languages.

~~~
pjmlp
So where are the Go drivers offering 1:1 feature parity with JDBC for Oracle,
DB2, SQL Server, Informix....?

An example for cluster based distributed framework similar to Akka in
features?

What Go libraries provide feature parity to PDFJava, iText or POI?

Which Go CMS is comparable in features to Literay, Adobe Experience Manager?

Where is Go listed here?

[https://developer.android.com/guide/platform](https://developer.android.com/guide/platform)

~~~
laumars
> _So where are the Go drivers offering 1:1 feature parity with JDBC for
> Oracle, DB2, SQL Server, Informix....?_ > > _An example for cluster based
> distributed framework similar to Akka in features?_

> _What Go libraries provide feature parity to PDFJava, iText or POI?_

> _Which Go CMS is comparable in features to Literay, Adobe Experience
> Manager?_

Clearly I'm not going to waste my entire afternoon doing research for you just
to win some internet points. Particularly when you're just going to find some
other "irrefutable fact" to lord over Go thus making any sensible discussion
pointless.

Actually I'm going to agree with you on one thing: while Go does support all
of the above I'm sure there will be some specific edge cases that are
available in a Java library - eg PDFJava - that isn't available in an
equivalent Go library. However I'm also confident I could list of some edge
cases that are covered by Go and not Java. Anyone with the slightest bit of
level headedness would agree that you're not going to get 1:1 feature parity
with every competing library in competing languages because different
developers will prioritise different features. So you accomplish nothing by
making such an argument in the first place.

> _Where is Go listed here?_

>
> _[https://developer.android.com/guide/platform](https://developer.android.com/guide/platform)
> _

Why would it be listed there when Go doesn't target libc nor the JVM? That
page also doesn't list about dozen other languages nor frameworks that also
support Android.

~~~
pjmlp
The point was that Go is supposedly an excellent Java replacement, yet it's
ecosystem is found lacking in comparable libraries.

As for Android, the whole userspace and a big part of Treble drivers are
written in Java, which was exactly the point of being a phone OS written in
Java.

So excellent replacement for Java? Not really.

~~~
laumars
A sane person would have read that as " _excellent replacement for Java for
many typical use cases_ " rather than " _a drop in replacement for Java for
any and all use cases_ "

Sure the GP didn't categorically set a context boundary but it's a pretty
reasonable to assume he intended it to be read that way given we're all
supposed to be intelligent people.

> _As for Android, the whole userspace and a big part of Treble drivers are
> written in Java, which was exactly the point of being a phone OS written in
> Java._

The whole userspace isn't written in Java. Yes there is _also_ an accompanying
Java userspace but your exaggerated argument is ignoring the GNU components as
well as native C++ parts too (which, as it happens, are also represented in
the very link you posted).

~~~
pjmlp
> The entire feature-set of the Android OS is available to you through APIs
> written in the Java language.

Ah so Linux is not written in C, because there are some Assembly components
there I guess.

What GNU components? The only GPL stuff surviving on Android is the Linux
kernel.

~~~
laumars
> Ah so Linux is not written in C, because there are some Assembly components
> there I guess.

Oh do please stop exaggerating things. It's abundantly clear that I wasn't
arguing the irrelevance of Java in Android. You simply said " _phone OS
written in Java_ " and I was making the point that Android wasn't exclusively
written in Java, thus Go (amongst other languages) can and do still run on
Android. Given the context was about whether x can run on y, it's very
relevant if y was written exclusively in x, w or v.

Also I don't understand why you've taken such a personal offence to Go but
this entire argument of yours has been really petty. You have your tools you
like and the GP has theirs. Does the GPs tools really need "death by a
thousand paper cuts" to make yours tools look more important? Clearly it
doesn't because Java is proven technology. So why waste your time criticising
everyone else's tools?

> What GNU components? The only GPL stuff surviving on Android is the Linux
> kernel.

Quick Google suggests you might be right there however that wasn't the case
last time I did dev work on Android.

Even so, the NDK still exists.

------
wglb
Article from 2015.

------
arthurcolle
Ups and downs?

------
atomical
Occasional pauses of 400-500 milliseconds? How would one mitigate that when
coding a restful API server?

~~~
Rapzid
This article is pretty old. If this is from garbage collection, Go has more
than addressed this with <100 microsecond stop the world in "typical worse
case" scenarios. I believe it also tries to spread out the work to provide
consistent latency.

~~~
easytiger
My, possibly incorrect understanding, is that it had implemented hard time max
pause durations, which will only lead to an infinite amount of garbage under
some use patterns. Given the point if gc is you doubt think about it that's
bad.

Giving go a gc was a total design failure

~~~
majewsky
Go's GC is the best GC I've seen in practice. It's just silently working in
the background without causing visible interruptions. And contrary to what you
imply, I've never seen the GC cause memory leaks.

~~~
easytiger
> "visible interruptions"

Humans can see things only longer than 200milliseconds. A small eternity.

The point is there are entire classes of application which have latency
targets in the handful of microseconds. A 1ms STW isn't acceptable in this
scenario.

------
PudgePacket
> Posted on March 7, 2015

~~~
dang
Added. Thanks!

~~~
PudgePacket
No worries.

------
visviva
Four years old and the typo in the title still hasn't been fixed?

~~~
013a
You mean "Pikedream"? Its a play on words. One of Go's core developers is Rob
Pike.

~~~
fwip
I think they meant the ups "of" downs.

~~~
dang
Wow, I looked at that repeatedly and closely, yet didn't see it until I read
your comment. Paris in the the spring...

Fixed now. Thanks!

------
jondubois
>> The worse the abstraction that you and your colleagues are likely to use,
the better a language is Go

I feel the same way about most statically typed languages. They're designed
for developers who aren't good at coming up with abstractions. Basically,
they're great for junior developers. For senior developers, they just give you
more work and slow down progress.

On my last project (statically typed language), we had to do a refactoring of
a decent portion of the code just because it allowed us to use one
interface/type instead of two related interfaces/types (one inheriting from
the other). It didn't fix any bugs, make it more maintainable or even change
the external behaviour at all.

~~~
networkimprov
Another gent who asserts that languages he likes to use are better for "senior
developers" while those he doesn't are better for "junior people".

Don't hire anyone who makes such insulting remarks.

~~~
jondubois
Why is it insulting? I didn't say that using the language means that you're a
junior. I just said that it was designed for juniors.

Just like there are adults who wear diapers, it doesn't mean that they're
juniors. In fact, most of them are very senior. They just like to be on the
safe side.

~~~
GenericsMotors
Gents, this ^ is what "full retard" looks like.

~~~
jondubois
Sorry for the confusion, next time I will try to dumb it down further... Maybe
I need to start using static type annotations to indicate sarcasm.

