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

Go is boring

aeronotix.pl

Post reply on HN
Print view View original

31–40 of 138 posts

Re: Go is boring

#31

Post by thebigshane »

ozataman wrote: post #29

I've tried giving Go a try a bunch of times now. My primary choice of language is Haskell and I just can't seem to get excited about Go.

Would you say your interest in programming languages is largely academic in nature? I get the impression that Haskell mostly (for now at least) fits best with academia, Java/C# for enterprise, python/ruby for smallish web apps, Go/C/C++/Java for industrial applications (like servers, etc).

There is a very real possibility that Go is just not the right fit for you with your current requirements. No language is the right fit for every application.

Re: Go is boring

#32

Post by genbattle »

onan_barbarian wrote: post #30

I reached the same conclusion ("Go is boring") myself, but with a different flavor. After having spent a great deal of time in recent years doing things like GPGPU and a _whole_ lot of SIMD programming (not to mention a lot of use of the STL, BGL, etc), I have to say I'm less impressed by the boringness (aka taking good, solid choices from existing languages) of Go. I understand that not everyone is excited about SIM…

To be fair, no programming language has really taken a first-party approach to those specific problems.

SIMD and GPGPU both fairly difficult low-level concepts as they stand: I think there would definitely be some valuable postgrad research in looking at how to create higher-level interfaces to graphics acceleration and GPGPU/SIMD that are as simple and effective as Go's goroutines.

The main problem is that SIMD and GPGPU (even hardware accelerated graphics, to a lesser extent) are bolt-ons; they're not a core part of every computer, which is why they don't usually form a core part of any programming language. At best languages might choose to integrate this functionality into the standard library, but i don't think it will ever come built-in for a general-purpose language (maybe for a domain-specific language?).

I've actually been attempting to write a GPGPU interface between Go and OpenCL[1], so it's certainly not impossible to do GPGPU or SIMD in Go (via cgo), but it would require writing your own 3rd-party libraries or making additions to the go runtime/compiler to develop a novel interface to this functionality like goroutines that can run on the GPU (a dream many people in the Go community share).

[1] https://bitbucket.org/genbattle/go-opencl

Re: Go is boring

#33

Post by ak217 »

This sounds really interesting and compelling.

As someone new to Go... What would be the advantages of using Go over Python (taking into account the emergence and future ascendancy of pypy)?

Re: Go is boring

#34

Post by lazyjones »

The author makes valid points and some of the reasons why I tested Go recently are named, but when it was ~15x slower than Perl and 10x slower than Java on some simple regexp matching, I gave up on it.

Re: Go is boring

#35

Post by ww520 »

hasenj wrote: post #8

I'd like to point out that I never heard of coroutines before Go. Not even in computer science; and I did take an Operating Systems course. I also never seen any language doing interfaces like Go. Go does it just right. I find that this is pretty impressive as a feature on its own.

coroutine is an old concept before threading became popular. It was usually implemented as a green-thread library. For C, setjmp/longjmp was used to implement it. Some libraries messed around with the stack register to implement it.

GO puts it as a first class citizen in the language. Other languages might call it Actor, light weight thread, fiber, task, etc. It's popular in embedded systems to implement cooperative threading using coroutine due to its simplicity and low overhead in resource utilization.

Re: Go is boring

#36

Post by dhconnelly »

ak217 wrote: post #33

This sounds really interesting and compelling. As someone new to Go... What would be the advantages of using Go over Python (taking into account the emergence and future ascendancy of pypy)?

A few:

- Go has language-level support, in the form of goroutines, for multithreaded concurrency. Python is single-OS-thread-only, and PyPy doesn't change that.

- Go has enough static typing to help you write safer code, without the verbosity of "bigger" languages like C++ or Java. If you write a lot of tests for your Python app, you might not have variable typos or function argument type mismatches, but in Go the compiler catches these things.

- Go is compiled to machine code. This means that, barring a miracle in JIT/VM research, Go will probably always be faster than PyPy for most tasks.

These, together with the fact that many of the niceties of Python are available in Go (lightweight syntax, first-class functions, iterators and list slicing, etc), make it, in my opinion, a compelling alternative to Python.

Re: Go is boring

#37

Post by mattgreenrocks »

nas wrote: post #27
MaxGabriel wrote: post #21

Earlier quoted context omitted.

I also heard of it in a programming languages course, and also in Udacity CS 212 I think. To add to the list, they're implemented in Python using yield statements

Python's yield was originally a limited co-routine, something we coined as a "generator" (borrowing the word from Icon, which Tim was quite fond of). It was limited to one frame on the stack and could only return values. Recent enhancements have allowed values to be passed back into the suspended function. That's still not a full co-routine though since Python only lets you go one level down on the stack. As someone…

All of the node.js kids get really defensive when you point this out; as if async was supposed to be heinously ugly despite the fact that the entire raison d'etre of node.js is to be async.

Programming advances so slowly because all of the training required to become familiar with it eventually becomes a blind spot.

Re: Go is boring

#38

Post by dhconnelly »

lazyjones wrote: post #34

The author makes valid points and some of the reasons why I tested Go recently are named, but when it was ~15x slower than Perl and 10x slower than Java on some simple regexp matching, I gave up on it.

There's some history behind this. You can read some of it from Russ Cox, one of the Go authors.

https://groups.google.com/forum/?fromgroups#!topic/golang-nu... http://swtch.com/~rsc/regexp/regexp1.html

Edit: missed another good one. There's a lot of discussion about this on the mailing list. https://groups.google.com/forum/?fromgroups#!topic/golang-nu...

Re: Go is boring

#39

Post by beagle3 »

genbattle wrote: post #32
onan_barbarian wrote: post #30

I reached the same conclusion ("Go is boring") myself, but with a different flavor. After having spent a great deal of time in recent years doing things like GPGPU and a _whole_ lot of SIMD programming (not to mention a lot of use of the STL, BGL, etc), I have to say I'm less impressed by the boringness (aka taking good, solid choices from existing languages) of Go. I understand that not everyone is excited about SIM…

To be fair, no programming language has really taken a first-party approach to those specific problems. SIMD and GPGPU both fairly difficult low-level concepts as they stand: I think there would definitely be some valuable postgrad research in looking at how to create higher-level interfaces to graphics acceleration and GPGPU/SIMD that are as simple and effective as Go's goroutines. The main problem is that SIMD and…

> To be fair, no programming language has really taken a first-party approach to those specific problems.

APL (and it's descendants J and K) has everything needed to do justice to SIMD/GPGPU. And it had them since the early 60s. I am not aware of an APL compiler that actually uses GPU or SIMD instructions, but one is possible, and wouldn't require any change to the base language.

Not surprisingly, this is because the idiomatic model is closer to the SIMD mindset than to the "standard" (algol/pascal/c/java/python/go) mindset, which is why it is unlikely to ever become popular.

Re: Go is boring

#40

Post by ak217 »

dhconnelly wrote: post #36
ak217 wrote: post #33

This sounds really interesting and compelling. As someone new to Go... What would be the advantages of using Go over Python (taking into account the emergence and future ascendancy of pypy)?

A few: - Go has language-level support, in the form of goroutines, for multithreaded concurrency. Python is single-OS-thread-only, and PyPy doesn't change that. - Go has enough static typing to help you write safer code, without the verbosity of "bigger" languages like C++ or Java. If you write a lot of tests for your Python app, you might not have variable typos or function argument type mismatches, but in Go the co…

> Python is single-OS-thread-only, and PyPy doesn't change that.

Neither statement is really the whole truth, and Python does have some nice ways to do coroutines and futures now, but I see how Go is better here (those 2 features do need to be in the core of the language) and with your other points, thanks.

Post reply on HN