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

"100% of our production system is now running Go"

groups.google.com

Post reply on HN
Print view View original

111–120 of 189 posts

Re: "100% of our production system is now running Go"

#111

Post by jlouis »

batista wrote: post #52
thebigshane wrote: post #19

Earlier quoted context omitted.

Straight from Rob Pike -- http://commandcenter.blogspot.com/2012/06/less-is-exponentia... Python and Ruby programmers come to Go because they don't have to surrender much expressiveness, but gain performance and get to play with concurrency. C++ programmers don't come to Go because they have fought hard to gain exquisite control of their programming domain, and don't want to surrender any of it. To them, software isn…

> The issue, then, is that Go's success would contradict their world view. I call BS. The parent explanation is much better: for a lot of the kinds of jobs C++ is good for, Go is not that good, whereas for a lot of things Python is good for, Go is as good and has better performance.

Actually, If you have invested the 15+ years it takes to become a decent C++ programmer, then you won't want to throw that out just because some new language comes by.

Most of what happens in C++ is low level maintenance of data. There are certain programs where this is important, but for the largest chunk of programs, low level maintenance provides more buggy programs with considerably worse performance.

And this is the real crux of the problem. For some C++ programmers they wont or simply can't give up the low level ability to mangle data. I have a hunch though that certain lacking constructs, generics come to mind, are used as excuses for not even wanting to take a decent look at the language. I have a feeling that sometimes it ends up being a religious tirade because "then I can't do my own containers". But you really shouldn't.

Most dynamically typed languages do not really need a generic-primitive. Does that make them unsuitable for programming? Hardly. In Go you just have to work around the problem.

Re: "100% of our production system is now running Go"

#112

Post by radiosnob »

jlouis wrote: post #111
batista wrote: post #52

Earlier quoted context omitted.

> The issue, then, is that Go's success would contradict their world view. I call BS. The parent explanation is much better: for a lot of the kinds of jobs C++ is good for, Go is not that good, whereas for a lot of things Python is good for, Go is as good and has better performance.

Actually, If you have invested the 15+ years it takes to become a decent C++ programmer, then you won't want to throw that out just because some new language comes by. Most of what happens in C++ is low level maintenance of data. There are certain programs where this is important, but for the largest chunk of programs, low level maintenance provides more buggy programs with considerably worse performance. And this is…

If you're a programmer/developer/hacker, you don't "throw out" what you already know.

Wouldn't learning a new language expand your toolset? Not replace it.

And I think most here agree that Go and C++ are solving different problem spaces. So knowing both would be a win.

Re: "100% of our production system is now running Go"

#113

Post by microtherion »

draven wrote: post #107
qznc wrote: post #95

Earlier quoted context omitted.

http://golang.org/pkg/container/list/ Casting every list element to "interface{}" is not generic.

Go does not have generics per se but that container looks pretty generic to me. What's your definition of generic programming BTW? I'm looking at several definition right now and cannot find out if, for example, a generic list container in C using void pointers to data would be considered generic programming . Wikipedia states generic programming is "a computer programming paradigm based on method/functions or classe…

To me, generic programming implies preserving all type information, which is something the above Go container does not do (when you get an element out of the container, you cannot tell statically what type it is).

Templates are generic, but so is, e.g. the type inference used in functional languages.

Re: "100% of our production system is now running Go"

#114

Post by qznc »

luriel wrote: post #104
qznc wrote: post #95

Earlier quoted context omitted.

http://golang.org/pkg/container/list/ Casting every list element to "interface{}" is not generic.

Use slices. Really, maybe we should remove container/* completely, so we don't have to answer this stuff over and over again.

Slice still restricts you to an array data structure (a continuous block of memory). How would you implement a sorted set in Go? It should be generic and type safe and efficient, please. Compare with the C++ solution.

Re: "100% of our production system is now running Go"

#115

Post by qznc »

draven wrote: post #107
qznc wrote: post #95

Earlier quoted context omitted.

http://golang.org/pkg/container/list/ Casting every list element to "interface{}" is not generic.

Go does not have generics per se but that container looks pretty generic to me. What's your definition of generic programming BTW? I'm looking at several definition right now and cannot find out if, for example, a generic list container in C using void pointers to data would be considered generic programming . Wikipedia states generic programming is "a computer programming paradigm based on method/functions or classe…

In some sense, you can do generic programming with C by using void*, but this throws out type safety.

Re: "100% of our production system is now running Go"

#116

Post by qznc »

pcwalton wrote: post #32
jonathansizz wrote: post #28

Earlier quoted context omitted.

I think that Mozilla's Rust is aiming squarely at C++ developers, whereas Go is more of a Java replacement. And it's interesting to see Python and Ruby being squeezed lately, from various directions; Clojure, Go, other languages. Since Python went mainstream and started being picked up for serious projects, it naturally came under the spotlight a lot more than it had previously, and I think many people have started t…

"I think that Mozilla's Rust is aiming squarely at C++ developers, whereas Go is more of a Java replacement." I basically agree with this as a Rust developer (although I'm not sure about Go being in Java's niche; I think of it more as in node.js's niche -- highly scalable web apps). Early on, I think both Rust and Go were thought to be targeting the same segment, but it turned out that we really weren't. Personally,…

The funny thing is Go and Rust compete with C++, but in different niches. C++ manages to cover a lot of ground from high-level to low-level programming.

With C++11 it now has a foot in the concurrency niche. The question is, whether C++ can keep its niches or if lots of different languages will chew away its market share on various levels.

Re: "100% of our production system is now running Go"

#117

Post by nathan_long »

pilif wrote: post #81
Evbn wrote: post #59

Earlier quoted context omitted.

Just put a session id in the URLs.

keeping a session id in the URLs is way less secure as it is susceptible to XSS attacks, it can leak in referer headers, it can be accidentally shared by people copy & pasting the URL and by extension, the session ID might even end up in a search engine and depending on your bad luck, the bots might visit the page just often enough so the session doesn't expire on the server at which point an authenticated session is…

I agree, but:

>> session cookies (which go away when you close the browser)

They should, but often don't anymore.

http://dalevisser.wordpress.com/2012/07/18/how-to-fix-firefo...

Re: "100% of our production system is now running Go"

#118

Post by eckyptang »

tjoff wrote: post #93
thebigshane wrote: post #19

Earlier quoted context omitted.

Straight from Rob Pike -- http://commandcenter.blogspot.com/2012/06/less-is-exponentia... Python and Ruby programmers come to Go because they don't have to surrender much expressiveness, but gain performance and get to play with concurrency. C++ programmers don't come to Go because they have fought hard to gain exquisite control of their programming domain, and don't want to surrender any of it. To them, software isn…

I have such a hard time believing how anyone could have believed that C/C++ programmers would switch to a GC-only language just like that. I just can't see Go as an alternative to C or C++, and I'm quite surprised that anyone (especially someone such as Rob Pike) could. Sure there are situations where a program that typically would have been written in C/C++ could benefit from Go (so there is a place for it), but the…

I think C/C++ programmers have had their reign long enough and have shown us through the amount of utterly horrible security issues that managing memory yourself is a bad idea.

Go fits an important niche: stuff that doesn't have to play with the hardware directly, which is pretty much everything but the OS.

I controversially consider there to be no other use for C bsaed languages these days other than at the kernel level.

It's better to centralise the memory management and optimisation either into a VM or compiler. It's easier and safer to verify a compiler (mathematically or otherwise) than every memory access that you do.

Due to my engineering background, I would always sacrifice performance for less risk and more reliability.

I've also spent 20 years writing C and C++ so I know how horrible it is.

Re: "100% of our production system is now running Go"

#119

Post by stonemetal »

jlouis wrote: post #111
batista wrote: post #52

Earlier quoted context omitted.

> The issue, then, is that Go's success would contradict their world view. I call BS. The parent explanation is much better: for a lot of the kinds of jobs C++ is good for, Go is not that good, whereas for a lot of things Python is good for, Go is as good and has better performance.

Actually, If you have invested the 15+ years it takes to become a decent C++ programmer, then you won't want to throw that out just because some new language comes by. Most of what happens in C++ is low level maintenance of data. There are certain programs where this is important, but for the largest chunk of programs, low level maintenance provides more buggy programs with considerably worse performance. And this is…

If you have invested the 15+ years it takes to become a decent C++ programmer

I have been programming in C++ for the past 14 years. Other than fast compile times, and a little less work to wire up interfaces, what exactly I am I supposed to be drooling over Go for? Between RAII and other modern C++ practices I don't really feel the need for a garbage collector. I already have a library that gives me Channel like functionality. I am sure if I really wanted green threads I could find an implementation that was similar to goroutines. Basically when I get excited about new programming languages it is about languages different enough from C++ that they actually have a shot at being better, Clojure, Scala, and Haskell come to mind.

A language that doesn't affect the way you think about programming, is not worth knowing.

Edit: I am fully aware that I may be blind. I do plan on exploring Go at some point, but exploring other more exotic languages take priority for me.

Re: "100% of our production system is now running Go"

#120

Post by cageface »

StavrosK wrote: post #100
cageface wrote: post #12

Earlier quoted context omitted.

In hindsight it doesn't seem so surprising. Go really isn't a good alternative to C++ for the kinds of things that really need the low-level control and direct memory access C++ provides. And if you don't really need those things you probably should have moved on to Java or Ruby/Python/etc already. And since a lot of Java shops are fantastically risk averse I'm not at all surprised that the same kind of people that w…

> In hindsight it doesn't seem so surprising. Most things don't seem surprising in hindsight. That's why you don't judge surprises by it. If C++ programmers did flock to Go, would you then say that that was surprising? If not, you've just fallen victim to hindsight bias (because a model that predicts everything is useless).

Most things don't seem surprising in hindsight. That's why you don't judge surprises by it.

Surprising was GP's original term, not mine.

I don't expect Go or any other language to displace C++ any time soon. But I do think the "scripting" languages are very vulnerable to challenges from languages with static typing systems less primitive than Java's.

Post reply on HN