Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I Love Go; I Hate Go

dtrace.org

Post reply on HN
Print view View original

181–190 of 329 posts

Re: I Love Go; I Hate Go

#181

Post by jerf »

Someone wrote: post #50
tptacek wrote: post #29

Earlier quoted context omitted.

I used to feel this way. It was my top complaint about the language. But it, and, more importantly, the use requirement for variables, has saved me from bugs repeatedly; I more and more notice the bugs it's protecting me from as I keep coding in the language. I am rapidly coming to the conclusion that this was very, very much the right call. I get the sense that most Go programmers use "goimports" to work around the…

"But it […] has saved me from bugs repeatedly; I more and more notice the bugs it's protecting me from as I keep coding in the language […] most Go programmers use "goimports" to work around the annoyance. I have my Emacs configured to use it automatically. I never even think about imports anymore." If you don't think of imports anymore, how can they save you from bugs? (I do (somewhat) understand the "more important…

The use requirement for variables saves him from bugs, goimports fixes the problem with required use of packages. It's separate.

The requirement that packages aren't used isn't to prevent bugs, it's to prevent packages from claiming spurious dependencies that you're then too afraid to remove. Or, in the case of a static language like Go, don't want to take the time to remove one-by-one and see if the compilation breaks. I deal with this problem in Perl where, basically, in a source code base that's been developed now for over a decade you have no idea whether a given module is actually used in the code, and it could be pulling in a whole bunch of other stuff very confusingly. The problem is less acute in Go to start with, but it's still nice to be able to rely on the imports being accurate.

Re: I Love Go; I Hate Go

#182

Post by coldtea »

themihai wrote: post #134
superswordfish wrote: post #88

Earlier quoted context omitted.

> 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 prete…

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.

Re: I Love Go; I Hate Go

#183

Post by coldtea »

zaphar wrote: post #180
pjmlp wrote: post #172

Earlier quoted context omitted.

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

Re: I Love Go; I Hate Go

#184

Post by coldtea »

thwd wrote: post #128
nneonneo wrote: post #74

Earlier quoted context omitted.

That solution (append(a[:0], a[1:]...)) doesn't look remotely performant. I don't have a copy of go handy to test, but exploding most of the list into individual arguments and passing them to a variadic function, just to pack them all back into an array, seems quite circuitous to me. Is that really the _best_ way to delete from a slice in Go?

A slice is a view over a continguous array. deleting an index in a continguous array is inherently O(n). Go doesn't obscure this. The pain of writing it out reflects the complexity of the operation.

>The pain of writing it out reflects the complexity of the operation.

And why would one even remotely want that?

Unless they seriously think that if the syntax is painful, people will avoid doing it and get better performance...

Re: I Love Go; I Hate Go

#185

Post by hehheh »

zaphar wrote: post #174
wruza wrote: post #35

Earlier quoted context omitted.

Stockholm syndrome in action. There are two phases: active development and release engineering. -Wall for former, -Wextra -Werror for latter. If someone is not disciplined enough to throw out unused variables/imports/whatever from release, Go will not save him from hell.

This may work for you code. But are you sure that all the libraries you use also follow that rule? Are you going to audit all of those projects and their dependencies to validate they follow the same best practices as you? The end result of Go's opinion on warnings is that you know a certain class of bugs in not present anywhere in both your code and all of your dependencies. While it's true that people and teams tha…

This is an easy problem to solve.

The Go compiler could simply include a bit in the resulting binary/library that indicates whether or not it was built with the "disable-unused-variable-error" flag. If you're using a library that was built with that flag the compiler can simply refuse to compile your code without that flag, forcing you to acknowledge the problem head-on.

Re: I Love Go; I Hate Go

#186

Post by jerf »

Sean1708 wrote: post #125
_skel wrote: post #10

The most frustrating thing for me, by far, is that Go won't let you import unused packages. When you are commenting stuff out to debug a program, or adding debug statements and removing them later, it constantly requires you to go back to the top of the file and comment out the unused libraries, only to uncomment them later when you've solved your problem. The fact that there is not a compiler flag to disable this be…

I think that's the thing that really gets me about Go. I really like that it's opinionated and forces you to write good code, but I just can't understand why they refuse to allow you to turn them off when you need it. Also doesn't that workaround completely nullify all the arguments they made in that section? And it puts the programmer in a worse position than if they could just turn it off temporarily.

"I just can't understand why they refuse to allow you to turn them off when you need it."

The answer to this and a lot of similar such questions about Go is "scale". Things that were sorta kinda convenient for you in a couple hundred lines become nightmares when several dozen developers on several hundred thousands lines of codes had differing ideas of what was convenient for them at the time.

Just as you can't understand Erlang until you understand its emphasis on reliability, you can't understand Go until you understand its emphasis on coding at scale. Almost (but not quite) everything people can't understand about Go are things that people want to do because they work well locally, but things that have become serious problems in source code bases at scale. You also can't understand Go until you realize that the problems weren't merely hypothesized, but extracted from real already-existing source code bases.

That said, I still feel they missed some steps. I'd like non-nil-able pointers. (Optional, like C#, because the way Go methods work means that if you're careful nil pointers of a certain type are perfectly legal and can have sensible methods on them, but that's not always the case.) Packaging is another obvious case where Google had an answer that worked for them so they didn't see a problem, though that's being worked on. (I'm struggling through this because I consider it a non-negotiable feature that my packaging solution allows me to locally mirror everything I use, which all packaging systems (not just Go!) seem to consider some bizarre use case. Strange, I consider it a basic requirement for truly professional development.) So bear in mind I don't mean this necessarily as a defense of Go, I'm talking about what it takes to understand it.

(Edit: also, yes, I consider it a bit sad that Go doesn't have iterator support, per my comment at https://news.ycombinator.com/item?id=12210351 You can sort of bash some stuff together, and io.Writer and io.Reader cover a common case for Go programs and can be composed, but it's still a bummer.)

It is completely the case that some people will come to a greater understanding of Go, and realize it's the wrong choice for their problems. But perhaps it will, at the very least, be less threatening that other people do consider it a good choice for their problems.

Re: I Love Go; I Hate Go

#187

Post by scott_s »

_skel wrote: post #10

The most frustrating thing for me, by far, is that Go won't let you import unused packages. When you are commenting stuff out to debug a program, or adding debug statements and removing them later, it constantly requires you to go back to the top of the file and comment out the unused libraries, only to uncomment them later when you've solved your problem. The fact that there is not a compiler flag to disable this be…

Not allowing the import of unused packages was an explicit design goal intended to reduce compile times. Cribbing from a comment I made years ago:

Take a look at this adaptation of a keynote talk on the design of Go, with the title "Language Design in the Service of Software Engineering": http://talks.golang.org/2012/splash.article Section 7, "Dependencies in Go" addresses this issue: http://talks.golang.org/2012/splash.article#TOC_7. The relevant paragraph states,

The first step to making Go scale, dependency-wise, is that the language defines that unused dependencies are a compile-time error (not a warning, an error). If the source file imports a package it does not use, the program will not compile. This guarantees by construction that the dependency tree for any Go program is precise, that it has no extraneous edges. That, in turn, guarantees that no extra code will be compiled when building the program, which minimizes compilation time.

Further, the talk justifies this approach through their analysis of how their C++ codebase was compiled:

The construction of a single C++ binary at Google can open and read hundreds of individual header files tens of thousands of times. In 2007, build engineers at Google instrumented the compilation of a major Google binary. The file contained about two thousand files that, if simply concatenated together, totaled 4.2 megabytes. By the time the #includes had been expanded, over 8 gigabytes were being delivered to the input of the compiler, a blow-up of 2000 bytes for every C++ source byte.

As another data point, in 2003 Google's build system was moved from a single Makefile to a per-directory design with better-managed, more explicit dependencies. A typical binary shrank about 40% in file size, just from having more accurate dependencies recorded. Even so, the properties of C++ (or C for that matter) make it impractical to verify those dependencies automatically, and today we still do not have an accurate understanding of the dependency requirements of large Google C++ binaries.

Re: I Love Go; I Hate Go

#188

Post by mtanski »

fauigerzigerk wrote: post #152
ckastner wrote: post #97

Earlier quoted context omitted.

>> Stockholm syndrome in action. >That's a very negative way of saying "that's not my personal behavioral preference" In my experience, Stockholm syndrome is not used to describe personal behavioral preferences, but rather (unexpected) transitions between such preferences from the negative to the positive. In the grandparent's own words: >>> i was shocked by that at first too. Then I came to love it.

Yes, but it requires that the victim has no way out. Stockholm syndrome is not just any unexpected change of preferences.

The victim has no way out short of switching languages which may or may not be under their control.

Re: I Love Go; I Hate Go

#189

Post by devishard »

_ph_ wrote: post #160

I like Go quite a lot. Mainly I am a Lisp programmer, so I am not looking for the next most high level programming language. I am looking for a language which gets things done, where Lisp doesn't quite fit. For jobs, which traditionally would have been done in C. Programs that run fast and have a reasonable complexity. It brings back the virtues of the Wirth computer language family back into modern times, as with st…

This post is yet another reinforcement of my assertion that the people who like Go only like it because they have no idea what has happened in programming languages for the last few decades. Case in point:

> It brings back the virtues of the Wirth computer language family back into modern times, as with strict type checking and the module system.

Strict type checking? Have you used any other languages besides C? Go's type system is a joke.

Like literally, it's a joke. If you get a bunch of people who know about types languages in a room discussing types, "What about Go?" is guaranteed to get a laugh.

Re: I Love Go; I Hate Go

#190

Post by devishard »

_ph_ wrote: post #171
junke wrote: post #163

Earlier quoted context omitted.

I am really curious about the kind of tasks that are easily done in Go but for which Lisp doesn't quite fit.

Sometimes I like to have a fully statically typechecked program. You can do that in Lisp, its easier in Go. Also, it directly produces statically linked executables. You can do a lot of this in SBCL, it also produces executables, has type checking etc. But for some of this, you have to wrestle a bit with the Lisp system. The Common Lisp numeric tower is great - until you want to write low level programs where you jus…

> Sometimes I like to have a fully statically typechecked program.

Wait, I thought we were talking about situations where Go was appropriate. What do you use when you want a fully statically typechecked program?

Post reply on HN