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

Go is amazing, period.

poincare101.blogspot.com

Post reply on HN
Print view View original

101–110 of 241 posts

Re: Go is amazing, period.

#101

Post by Peaker »

dhaivatpandya wrote: post #20
tpsreport wrote: post #17

Here's a summary of the article: * author cannot write portable C sockets code * author cannot handle C/C++ * author believes his app would be too slow in Python, later abandons App, but retains his bias against Python * Go has no parens for if/for * Go has unicode support * Go has closures "like salt shakers" * Go is cohesively designed * Go has nice libraries Go may or may not be a good language, but this kind of a…

I usually wouldn't respond to mean comments, but, this one really throws me off (I'm the OP). There is a very strong difference between "cannot write" and the need for something to be simple. I can definitely handle C/C++, and I don't think writing something in a higher-level language changes that. If something is doing processing with 4000 threads with around 10 years worth of by-the-minute data, it sure as hell wil…

Did you try Haskell?

Knowing Haskell makes reading about Go a very underwhelming experience.

Re: Go is amazing, period.

#102

Post by alok-g »

FreakLegion wrote: post #81
CamperBob wrote: post #78

Earlier quoted context omitted.

I'm historically a braces-on-their-own-line guy, so getting used to the strict enforcement of the other style was a pain for me Wait, what?

void func() { } vs. void func() { } Does Go really enforce the latter? That would be incredibly silly.

I see the line of reasoning behind this as explained by various comments here. But why can't this just be an user/editor preference while the file saved may use whatever convention?

Re: Go is amazing, period.

#103

Post by enneff »

ootachi wrote: post #94
enneff wrote: post #86

Earlier quoted context omitted.

"...not an optimizing compiler." ? The gc compiler does perform some optimizations, including inlining across package boundaries. There is also the gccgo compiler which takes full advantage of gcc's many optimizations. Both compilers will be equally supported in Go 1.

I'm referring to the Plan 9-based compilers, which do not perform the optimizations necessary to make it competitive with modern C and C++ compilers. Here I'm referring to stuff like SSA-based global value numbering, scalar replacement of aggregates, loop-invariant code motion, etc., as well as lower-level stuff like instruction scheduling. gccgo is better here, of course. Unfortunately, the Plan 9-based compilers ar…

It doesn't matter what "most people use". Both compilers are equally accessible with the new go command (http://weekly.golang.org/cmd/go/). People who find their programs faster with gccgo will use gccgo, and vice versa.

Not competitive with "modern C and C++ compilers"? There are few real world programs that are improved by code generation micro-optimizations, and even for those that are Go is still competitive. http://blog.golang.org/2011/06/profiling-go-programs.html

Re: Go is amazing, period.

#104

Post by ootachi »

chmike wrote: post #100
ek wrote: post #84

I really like most things about Go, and was even going to use it for a bytecode interpreter project I was working on. A problem that I ran into, however, was that in interpreting a dynamic language with a stack machine, we needed a way to be able to store arbitrary data in stack values, which in C/C++ would be done using a struct with a type flag and then a union of various types. Go doesn't have unions, though, and…

Unions is a problem for garbage collectors. It is difficult to know if it contains a reference or a value. Though Go should have a solution for your use case. The only one I see is polymorphism. Thus a stack of references to different instances of the same class.

Discriminated (type-safe) unions like ML and Haskell have are no problem for garbage collectors: you simply assign one ID to each variant of the union, and prefix the data with the ID corresponding to the variant in use.

You can simulate ML-style unions in Go with interfaces and downcasts, or the reflect package (basically like case classes in Scala, but without the exhaustiveness checking). Unfortunately, downcasts in Go (and interfaces generally) are slow.

Re: Go is amazing, period.

#105

Post by pjmlp »

shadowsun7 wrote: post #75
rian wrote: post #51

Earlier quoted context omitted.

people who program actually have a lot to learn from the fashion industry. trends are fine as long as trends are iterated on quickly. in comparison, it's taken programmers 15 years to make the half-assed-jump from java to go. and even then, the conceptual differences between java and go are minimal , superficial at best. the fact is that go touts itself as a C++/java alternative but i see no significant/non-superfici…

Two things. 1) Have you used Go? Your comments indicate to me that you have little Go experience - thinking in Go is quite different from thinking in C. 2) One line counter-example to disprove your negative-work argument: goroutines. Also known as: CSP-style concurrency in a procedural language. I urge you to read up on goroutines. There are quite a few examples on the golang site of how you can use this feature to g…

Go routines + CSP are easily done in all mainstream languages.

Java: java.util.concurrent

.NET Task Parallel Library

C++ Parallel Patterns Library Threading Building Blocks Click Cilk Plus

D Actors + std.concurrency

Erlang Actors

Scala Actors

Haskell STM

Clojure STM

There are good things about Go, but people should learn other programming languages properly, before doing comparisons.

Re: Go is amazing, period.

#106

Post by stock_toaster »

enneff wrote: post #72
firefoxman1 wrote: post #47

Earlier quoted context omitted.

What's it like to use a compiled language for a web server?

It's really nice. You can build your Go program, deploy it as a single binary and it just runs. No need to hide it behind nginx or some other dedicated web server. The Go http package is DoS hardened and very fast. It's refreshing how little mechanism there is.

How are the database libraries (postgres/mysql) these days? Last time I poked around (been a while) it seemed like most of them were pretty beta yet.

Re: Go is amazing, period.

#107

Post by rian »

shadowsun7 wrote: post #75
rian wrote: post #51

Earlier quoted context omitted.

people who program actually have a lot to learn from the fashion industry. trends are fine as long as trends are iterated on quickly. in comparison, it's taken programmers 15 years to make the half-assed-jump from java to go. and even then, the conceptual differences between java and go are minimal , superficial at best. the fact is that go touts itself as a C++/java alternative but i see no significant/non-superfici…

Two things. 1) Have you used Go? Your comments indicate to me that you have little Go experience - thinking in Go is quite different from thinking in C. 2) One line counter-example to disprove your negative-work argument: goroutines. Also known as: CSP-style concurrency in a procedural language. I urge you to read up on goroutines. There are quite a few examples on the golang site of how you can use this feature to g…

goroutines = (poorly implemented) cheap threads

threading (or CSP) is nothing new conceptually. yes, i agree, the go language has popularized a cheap threading implementation but the same design concepts we've applied to unix processes and posix threads apply to goroutines.

btw, blocks in ruby and generators in python have existed for many years prior to go.

Re: Go is amazing, period.

#108

Post by chmike »

I looked at its serializing documentation and I was surprized to see that every floating point value is serialized to a double precision value. There are now four types of foating point values and this simplification is downgrading the capabilities of data tranfer. Extended is needed in some scientific computations. Appart from this, the base type encoding is great. The other weird choice is the structure encoding with field numbers and omitting null value fields. My impression is that this is less efficient than coding the null fields. Is this choice based on measurements ?

Re: Go is amazing, period.

#109

Post by enneff »

ootachi wrote: post #95
dsymonds wrote: post #79

Earlier quoted context omitted.

Have you found the GC to be an actual problem? Or are you assuming it is? It's a very different situation to other GC-based languages.

Why is it so different? I'd be curious to know. In my experience, a stop-the-world collector that must be threadsafe ends up being a disaster. You hit a brick wall in terms of real-time performance quickly (look at iOS versus Android for an easy example, and Dalvik's GC is much more sophisticated than that of Go these days). I predict that Go is going to have to put a lot of effort into making the GC fast in order to…

Java requires a powerful, sophisticated garbage collector because it is extremely difficult (and in many cases impossible) to write Java programs that don't generate a lot of garbage. Even many of the core APIs are allocation heavy. It's a pain.

Go data structures tend to be much smaller than the Java equivalents, and it is much easier to track down and eliminate unnecessary allocations in Go code. When you have better control over allocations you don't need to lean so hard on the garbage collector. (Some of this is touched on here http://loadcode.blogspot.com.au/2009/12/go-vs-java.html)

You seem to have a lot of strong opinions (and predictions!) about Go, when you clearly don't have much experience with it.

Re: Go is amazing, period.

#110

Post by ootachi »

enneff wrote: post #103
ootachi wrote: post #94

Earlier quoted context omitted.

I'm referring to the Plan 9-based compilers, which do not perform the optimizations necessary to make it competitive with modern C and C++ compilers. Here I'm referring to stuff like SSA-based global value numbering, scalar replacement of aggregates, loop-invariant code motion, etc., as well as lower-level stuff like instruction scheduling. gccgo is better here, of course. Unfortunately, the Plan 9-based compilers ar…

It doesn't matter what "most people use". Both compilers are equally accessible with the new go command ( http://weekly.golang.org/cmd/go/ ). People who find their programs faster with gccgo will use gccgo, and vice versa. Not competitive with "modern C and C++ compilers"? There are few real world programs that are improved by code generation micro-optimizations, and even for those that are Go is still competitive. h…

"There are few real world programs that are improved by code generation micro-optimizations"

I don't know how to convince you of the fact that this statement just isn't true. Consider the rasterization software you're using right now in your web browser. Micro-optimizations hugely matter for blitting and tessellation. Consider video decoding (or encoding!). Using SSE instructions instead of going word-by-word or byte-by-byte makes an enormous difference. Read Dark Shikari's blog posts about x264 if you want to see how much good use of SSE matters for video encoding.

To name just one example: Modern x86 processors have an optimization that allows the fetch-and-decode step to be skipped for the second and subsequent iterations of small loops. By "small" I mean "really really small" -- something like 16 bytes is the number I've heard. By shaving a byte or two off the instruction encoding to fit a loop from 18 bytes into 16 bytes, the loop performance can double or triple. When that loop is the loop that drives alpha blending on your touch-sensitive mobile app, that can be the difference between an app that feels solid and fluid and an app that feels slow and pokey.

People use systems languages for performance. Folks for whom performance is irrelevant are all on dynamic languages, and that's not changing. Systems programmers need a compiler that knows about these micro-optimizations.

Post reply on HN