Hacker News Reader

Comment by superswordfish | Hacker News Reader

> ignoring years of research and good ideas

And people are falling over themselves to use Go in places that seem inappropriate. Most of Go's strengths shine in a large team of mediocre developers: Low build times, low abstraction, quick ramp-up, etc. So why do startups choose Go? You're just shooting yourself in the foot. Use OCaml, use C++, use Clojure, hell, use Swift or Rust, just use something that at least pretends to care about expressiveness and abstraction. I actively avoid working for shops that use Go heavily, it's an indicator of cargo-culting.

View on HN

I run a few side projects with a pool of about a dozen developers. Some love Java but others won't touch it, some are C developers, one of them only has experience with PHP, there are lispers, an Erlang zealot and even a Delphi refugee. I personally like Perl and OCaml but couldn't convince them to even consider them. It was a nightmare to agree and settle up with something.

Enter Go, and while we all agreed that the language kind of sucks and $FAV_LANG is better, we somehow stopped bike-shedding and started to get real work done.

Sure, it's not the most exciting language in the block and its community seems to live in the 70s, but sometimes targeting the lowest common denominator can pay off, as is the case for us.

> Sure, it's not the most exciting language in the block and its community seems to live in the 70s, but sometimes targeting the lowest common denominator can pay off, as is the case for us.

Except that even Algol 68 is more feature rich than Go, assuming a 60's powerful computer, like the Burroughs B5000. :)

But I do appreciate that every line of written Go code is one less of written C code.

Define "feature".

Go thinks fast compile time is a feature. How fast is your Algol 68 compiler on a ten million line code base?

1. How many people have 10 million line code bases?

2. How many of those people would have much smaller codebases if they used a more expressive language?

3. Of the people who have 10 million line codebases and would still have 10 million line codebases in a more expressive language, how many of those could actually compile their programs faster if they used a language that allowed partial compilation of only the parts of the code that were changed?

Very few people have Google's problems, and I'm not even completely convinced that Go is the best way to solve Google's problems.

Fast enough for a 60's computer, imagine nowadays.

But if you want numbers, Turbo Pascal 5.5 was doing 34,000 lines/minute[1] on MS-DOS back in 1989.

[1] http://edn.embarcadero.com/article/20803

Turbo Pascal isn't Algol 68. A PC in 1989 isn't a B5000. But even accepting the example, 34,000 lines/minute gets you a compile that takes 294 minutes, or just under 5 hours. That's... not very good.

Of course faster hardware is part of the answer, but I suspect that it doesn't cover nearly all the ground between Turbo Pascal's compile time and Go's.

I gave Turbo Pascal as an example, because even when compared against it, there are many features that Go lacks and Turbo Pascal had.

Besides I am comparing an 8086 with 640 KB against a i7 with 16 GB and three level caches.

Go being fast isn't that much of an achievement in 2016.

If Go compiles faster than Turbo Pascal with an 8086 CPU and 640 KB RAM, that is an achievement.

I am going to guess that Go compiles at least 10 times faster than Turbo Pascal. From the numbers you gave, I think at least a factor of ten is left even after you account for the difference in hardware speeds.

So you are stating that Go will compile 10x faster than Turbo Pascal on a 8086 with 640 KB?!

My point is that Go's compilation speed isn't nothing extraordinary, I can keep giving examples of other compiled languages that had equally fast compilers in the the mid-90's.

Oberon, Go's grand daddy could bootstrap itself and build a full working graphical workstation OS in less than one minute if I remember correctly.

Sounds like a prison for programmers.

I think it really depends on what kind of software you're writing. At my startup (around 30 engineers) most of what we do is web based, and our backends are mostly written with Java and Spring Boot now. Go is simpler, more productive, has better concurrency, and still has good static analysis. The benefits mostly seem to come from the removal of bullshit rather than the addition of nice abstractions.

You don't know what you are talking about. Have you seen any Swift backend used in production? Would you use C++ for a web API? Go was developed because C++ is a horibble language and I'm glad it didn't adopt the expressiveness and abstraction from C++.

>You don't know what you are talking about. Have you seen any Swift backend used in production?

He said "hell, use Swift" -- which didn't imply that he's considering it the first or best recourse.

That said:

1) There's far more Swift in production (on iOS devices as native apps, not as backend, but still production code) than Go.

2) Merely 4-5 years ago nobody had seen Go in backend (web/server) production either. Or at least very few.

3) There's already some support for server side Swift: http://perfect.org/

4) And more: IBM uses Swift for apps AND server side, and has open sourced a Swift web framework/server: https://github.com/ibm-swift/kitura

>Would you use C++ for a web API?

If I needed the crude speed yes, and in fact lots of web APIs delegate to C++ behind the scenes (e.g. for task queues), whereas some are in C++ directly.

In fact Facebook itself used to transpile PHP to C++ and run that (through their HipHop project).

>Go was developed because C++ is a horrible language

Go was developed because some old C/UNIX hackers didn't much like C++/Java and wanted to do their own thing, bringing some Plan 9 flavor on.

C++, warts and all, has proven itself time and again.

Most of the things we depend on and use, from the browser you're using, to JITS and compilers (LLVM for one, V8), to the Windows OS, nearly all major GUI programs (all major DAWs, NLEs, Photoshop, 3D programs, KDEetc), to 99% of AAA games, to Google's search engine core are written in C++.

And C++11/C++14 standards have made it a much better, even new, language. The automatic C++ dislike is cargo cult from people who usually don't use it and just repeat old wives tales.

>He said "hell, use Swift" -- which didn't imply that he's considering it the first or best recourse.

I've got that but it was too late... the comment was already posted. I've up-voted his response.

The rest of your points are invalid. Development is not only about a http server(which I'm sure is subpar compared with Go). You will burry your time and energy in making basic things work. As developer that's great because you can use your experience on your "next" project but as a start-up you are very likely to fail. There may be some IBM developers that played around with the language but I'm sure IBM has no swift powered service in production. Swift is still a language in flux with many changes pending in the next 2 -3 versions. Big corporations don't really like to invest in unstable environments. Maybe in 3-4 years from now Swift will be able to compete with Go but today there is really no reason to use Swift over Go for a backend service.

> Go was developed because some old C/UNIX hackers didn't much like C++/Java and wanted to do their own thing

I must say it again: C++ is a horrible language. It may perform well and it may be widely spread but that doesn't change much as far as its design is concerned. C++ competes mostly on its reach not on its merits. Hopefully that will change as new platforms emerge(i.e Rust).

> In fact Facebook itself used to transpile PHP to C++ and run that (through their HipHop project).

Yeah, that's a pretty picture for what C++ is really good for. I rest my case.

Edit: I would also say "experienced hackers" instead of "old hackers". The C++ or Swift hackers are not younger anyway.

C++ is horrible in many ways, but Go never really tried hard to replace it (although it claimed to do that in the beginning, before it was refocused as a language for backend and tools).

The are many reasons for that, but most importantly, Go doesn't support deterministic memory management (like C++, Rust and Swift) and opts for GC instead, which makes life easier for at least 95% of its use cases, but not for some of the use cases C++ used to shine on.

I think that the Plan 9 Googlers dislike of C++ (and in truth, Modern C and UNIX as well) is closer to be the real reason for creating Go. It really was never designed to be a proper system language.

>The rest of your points are invalid. Development is not only about a http server(which I'm sure is subpar compared with Go). You will burry your time and energy in making basic things work.

The same could be said, and was said for Go compared to Java C#, etc just a few years ago. And it probably can still be said, as older languages have much more stable, richer ecosystems, support, tooling, and use bases.

>I must say it again: C++ is a horrible language. It may perform well and it may be widely spread but that doesn't change much as far as its design is concerned. C++ competes mostly on its reach not on its merits. Hopefully that will change as new platforms emerge(i.e Rust).

Well, it gets a lot of things right. Compatibility with C. Great performance. Enough abstractions to be usable. Enough batteries built-in compared to C. Great ecosystem and tooling, first class vendor support, etc. A language is not just its syntax -- not even just its semantics.

>>The same could be said, and was said for Go compared to Java C#, etc just a few years ago. And it probably can still be said, as older languages have much more stable, richer ecosystems, support, tooling, and use bases.

I don't say that you should never use C++. Sometimes it's a necessary evil but that doesn't make it a great/pleasant choice(at least for me).

>> Great ecosystem and tooling

I think it could be considered GREAT 20 years ago but now it is miserable compared with the new languages. For example it has no kind of distribution model(i.e package manager). Cross platform compiling is no fun... C++ parsing is no fun either so you could say that its syntax is quite important if you were to develop new tools.

It really depends on the project. I'd prefer Clojure or Erlang for most frontends, a Lisp for the backend of an expert system, and C++ or OCaml for any heavy lifting. Python still can be a great choice for all sorts of systems too. Swift and Rust aren't quite there yet but for a startup might be worth a look in time. We're not talking about "nobody ever got fired for choosing IBM" business here and being risk-averse is itself risky.

I find swift the worst choice for a start-up right now. Why would you use a language that's only half baked? Don't you have more important things to do than porting the standard library to linux? Not to mention the lack of concurrency. Go can be a grat choice for all sort of systems too and in many cases better than any of the languages you listed. It's about using the right tool for the job and I think your comments about Go are plain ignorant.

You're going after my hyperbolic recommendation (it follows "hell,") and calling me ignorant when we merely disagree. This is a waste of time.

> Have you seen any Swift backend used in production?

Lots of iOS applications use it already.

> Would you use C++ for a web API?

Facebook and Google apparently do use it.

And Google is actively replacing a lot of those with Go because using C++ for a web api is painful.

That's a myth. Google is not actively replacing anything with Go. Some new stuff is written in Go, and a few small parts here and there were rewritten in Go during a major refactor.

There's no active program to rewrite things in Go, and most things are not meant to be written in Go from now on or anything -- it's just one of the supported languages.

Fair enough. I used poor wording there.

The only ones that Google has officially replaced has been on YouTube and downloads server.

> Most of Go's strengths shine in a large team of mediocre developers: Low build times, low abstraction, quick ramp-up, etc.

I find some of those strengths and others shine in a small team of strong developers too, if they "get" Go.

But to your point: some people expect their startups to eventually employ a large number of programmers, at which point they will inevitably have some mediocre ones, that being a side effect of "hiring only the best."

Planning for that day is not shooting yourself in the foot.

You've hit the nail on the head for me at my current place of work. The only alternative I have here is Scala, which I wouldn't choose, but higher quality ecosystem and community, and closer to Rust which I'm enjoying at home, so am thinking of doing the switch.

I cannot imagine a scenario where Go would be a better fit for a team of skilled engineers (compared to scala). Maybe ramp up time would be the only thing, but even still the dividends you can reap from scala's more complex abstraction are worth the initial investment as they are applicable to multiple projects (as opposed to learning a complex framework or whatnot).

Reply on news.ycombinator.com