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

231–240 of 241 posts

Re: Go is amazing, period.

#231

Post by drivebyacct2 »

lusr wrote: post #99
j45 wrote: post #8

A lot of great and capable languages are overlooked. The question is how do they overcome the opinion, hearsay and preferences that are louder than the truth? Too few devs: - truly give something 5 minutes before jumping to their foregone conclusion. - admit that most languages with a decent capable and decent programmer are all, pretty equally equipped. - every language + framework has it's pros and cons.

5 minutes isn't fair. I took a look at http://shootout.alioth.debian.org/u64q/benchmark.php?test=al... first. OK so Go is about on par with Mono's C# performance and uses up to a 1/3 of the memory with code that is more concise. That's cool because it means I'm not sacrificing anything over the platform I specialize in (C#; although the last time I looked at the Alioth C# code I thought I saw some obvious improvement…

>Already feeling a sense of dread having been through this game 10s of times before with other languages.

What? I'm a student still learning new languages and it took me no time to look up and quickly grok duck typing. If that prevents you from learning a language...

Seriously... it's an hour to skim and read through. Hour or two to put together a decent non-trivial server demonstrating channels. I really don't know what your big long rant is about. It's not hard to find reasons Go was designed the way it was, find what it's goal is and read enough intro docs to get up and coding with it easily.

Re: Go is amazing, period.

#232

Post by scott_w »

Luyt wrote: post #198
scott_w wrote: post #181

Earlier quoted context omitted.

One time we worked on some code, and one of the developers had the same habit: "It works, so why do I need to format it?" We decided to make our build system run PEP over the code, resulting in a failure if PEP didn't pass. It annoyed the hell out of him, but we quickly got the formatting up to a better standard.

PEP8? http://www.python.org/dev/peps/pep-0008/

My apologies, yes. Don't know why I missed the 8 off there.

Re: Go is amazing, period.

#233

Post by jwr »

unlogic wrote: post #209
jff wrote: post #205

Earlier quoted context omitted.

So much for Lisp as the ultra-expressive, compact language, I guess... Impressive speeds, though.

Well, the link to the shootout statistics is probably not the best demonstration for Lisp speed/memory consumption/SLOC count relation. If you look into the Lisp sources there you will see that there are lot of things precompiled for the sake of reducing the execution time. Here's where the extensive memory usage and source size come from. I intended to say that Lisp's and Go's both performance and succinctness in th…

This discussion is increasingly weird and non-technical, mostly because there is no such thing as "Lisp". There are implementations of Common Lisp, implementations of Scheme, there is Clojure on the JVM, all of those are in the "Lisp" family. So comparing a particular language to "Lisp" makes no sense.

And I don't understand the comment about things being "precompiled". So what? Compilation is a natural step. Note that with most lisps "compilation" is not something you wait for while your server farm keeps crunching .c files, it's a natural step, sometimes happening behind the scenes.

Re: Go is amazing, period.

#234

Post by luriel »

jbarham wrote: post #16
zemo wrote: post #13

Earlier quoted context omitted.

to be honest, I've used both gevent and Go and concurrency is far more natural in Go. Sure, you can do most of what you want with gevent, and if you're using stackless or pypy you can even have channels, but implementing concurrency at the library level is a mistake. It feels bolted on. It's like how some programming languages weren't object oriented from the start, but then they bolted an object system on top of it…

I've done concurrent programming in both Python and Go, and to be fair to Python, its standard library queue class ( http://docs.python.org/library/queue.html ) is very close to Go's channels so it does CSP style concurrency quite nicely. However, Go's goroutines are IMHO superior to Python threads since they're much more lightweight and can run in parallel on multi-core CPUs and you can have a lot more of them. Go g…

I agree with most of your comment. But I'm sorry, this part is not even close:

> its standard library queue class (http://docs.python.org/library/queue.html) is very close to Go's channels so it does CSP style concurrency quite nicely.

Among other things, it lacks any construct similar to Go's `select`, without which channels are nowhere nearly as useful.

And then there are issues like what you point out about how incredibly cheap goroutines are.

Re: Go is amazing, period.

#235

Post by luriel »

jkn wrote: post #136
fdb wrote: post #118

How would you call foreign functions in C or C++ from Go? Is there something like a foreign function interface?

From http://blog.golang.org/2011/03/c-go-cgo.html : package rand /* #include */ import "C" func Random() int { return int(C.random()) } func Seed(i int) { C.srandom(C.uint(i)) } So calling C functions from Go is very easy. However the other way is not supported, AFAIK.

Calling Go from C is supported, but is not quite as straightforward. You can also use SWIG.

Re: Go is amazing, period.

#236

Post by BarkMore »

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.

No need to hide it behind nginx or some other dedicated web server.

A contributor to Go says otherwise if SSL is involved: https://groups.google.com/d/msg/golang-nuts/yohrNK8lFhc/L1d6...

Re: Go is amazing, period.

#237

Post by nfriedly »

georgemcbay wrote: post #218
jff wrote: post #204

Earlier quoted context omitted.

Just think about how much more you'd have to type if you were programming C, and you'll be ok :) My main gripe with := vs = is that as I change my code, an existing := may suddenly become invalid, meaning I have to go back and change it when compilation fails, or vice versa.

Yes, but thankfully compilation fails rather than succeed and then fail in some mysterious way at runtime. As someone who has been stuck writing JavaScript for Yahoo Widgets (Vizio Connected TV) over the past month, my appreciation for the compiler errors you get in static languages has grown tremendously. Previously I had taken them too much for granted.

You might appreciate jslint or closure-compiler - both have their quirks, but they can be tremendously helpful at finding certain errors.

Re: Go is amazing, period.

#238

Post by Radzell »

brnstz wrote: post #27
ootachi wrote: post #7

Earlier quoted context omitted.

Er, JavaScript is a structured language (meaning it doesn't mandate labels and goto for control flow).

Many programmers educated in the OOP days don't know the term "structured programming". I once interviewed someone who called a Pascal-like language "functional". We hired him anyway.

From what I here there not enough programmers around so you might of not had a choice.

Re: Go is amazing, period.

#239

Post by davvid »

Symmetry wrote: post #190
4ad wrote: post #182

Earlier quoted context omitted.

Fantastically dumb comment. FWIW int in C is also 32 bit on all mainstream 64 bit operating systems, and Go has int64.

Why on Earth would you want 64 bit ints by default, though? I'm not sure why they are thinking about changing it.

ints are used in the definition of some of the core interfaces. This has implications on how many entries a collection (that implements these interfaces) can contain.

For example, sort.Interface:

  package sort

  // A type, typically a collection, that satisfies sort.Interface can be
  // sorted by the routines in this package.  The methods require that the
  // elements of the collection be enumerated by an integer index.
  type Interface interface {
  	// Len is the number of elements in the collection.
  	Len() int
  	// Less returns whether the element with index i should sort
  	// before the element with index j.
  	Less(i, j int) bool
  	// Swap swaps the elements with indexes i and j.
  	Swap(i, j int)
  }
It would have implications on array indices as well, since they are also int.

Re: Go is amazing, period.

#240

Post by unlogic »

jwr wrote: post #233
unlogic wrote: post #209

Earlier quoted context omitted.

Well, the link to the shootout statistics is probably not the best demonstration for Lisp speed/memory consumption/SLOC count relation. If you look into the Lisp sources there you will see that there are lot of things precompiled for the sake of reducing the execution time. Here's where the extensive memory usage and source size come from. I intended to say that Lisp's and Go's both performance and succinctness in th…

This discussion is increasingly weird and non-technical, mostly because there is no such thing as "Lisp". There are implementations of Common Lisp, implementations of Scheme, there is Clojure on the JVM, all of those are in the "Lisp" family. So comparing a particular language to "Lisp" makes no sense. And I don't understand the comment about things being "precompiled". So what? Compilation is a natural step. Note th…

> This discussion is increasingly weird and non-technical, mostly because there is no such thing as "Lisp". There are implementations of Common Lisp, implementations of Scheme, there is Clojure on the JVM, all of those are in the "Lisp" family. So comparing a particular language to "Lisp" makes no sense.

Since I've posted a link to Shootout comparison of Go and Common Lisp I thought I made it clear which Lisp I was talking about.

> And I don't understand the comment about things being "precompiled". So what?

It means that a descent part of the computation was done in the compile (macroexpansion) time and this time was not measured and included into the total result. This may be great for cheating Shootout benchmarks but does not fairly demonstrate the performance of the language.

Post reply on HN