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

91–100 of 138 posts

Re: Go is boring

#91

Post by genbattle »

tomp wrote: post #68
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…

Hey, I'm really interested in exploiting the GPU for GP programming, and also in how the SIMD can help you... Would you be willing to give me some examples of the most common/useful uses?

Image processing and machine vision is a big one. Part of the skeletal tracking algorithm for Kinect is implemented as a set of shaders on the Xbox's GPU.

That's just one example, but anything that involves image processing is a prime example of something that can be optimized for GPGPU.

EDIT: To add another couple of examples:

- Digital effects; rendering, etc. Digital effects studios like Weta Digital are using GPGPU for speeding up their photo-realistic rendering [1].

- Physics simulations for games; games can now move resource-heavy activities like physics simulation from the CPU to the GPU, not only freeing up CPU resources, but also increasing the number of particles, etc. that can be simulated (look for n-body simulations as an example).

[1] http://blogs.nvidia.com/2010/01/nvidia-collaborates-with-wet...

Re: Go is boring

#92

Post by exDM69 »

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…

SIMD is really a big omission if you do a low level language these days. A modern language should really have first class vector types. I'm talking about static sized small vectors that run on SIMD, e.g. 4 x float32 or 8 x uint8. Not something matlab-esque.

Something along the lines of OpenGL shading language, OpenCL C or relevant vector extensions in modern C compilers. With GCC and Clang vector extensions, SIMD programming is fairly nice. (NOTE: GCC 4.8/git version vector extensions emit bad scalar NEON assembly so you can't really use them if you target ARM).

One particular thing about SIMD coding is the shuffling instructions which are hard to express in normal programming language terms as the order of the shuffling has to be static. GCC and Clang both have a shuffling function that requires the parameters to be compile time constants. But I prefer GLSL/OpenCL shuffle syntax, like vec.xxyy or vec.wzyx or vec.s0s0s1s1, and combinations like (vec4)(vec1.xx, vec2.yy). Too bad this syntax is not available on Clang or GCC when doing normal CPU C code.

NEON's shuffling instructions are rather odd to deal with. An odd thing about them is that Clang's ARM intrinsics actually use __builtin_shufflevector to implement NEON shuffles like vrev.

Re: Go is boring

#93

Post by icebraining »

ozataman wrote: post #53
thebigshane wrote: post #31

Earlier quoted context omitted.

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

Not at all. In fact about 95% of all Haskell I write - and I write quite a bit - is for commercial stuff, ranging all the way across large-ish (not quite google-scale, yet) scale computation, distributed systems, machine learning, modeling/simulations and web development. More academic feeling stuff like parsing and DSLs are just the cherries on top (though even those were for commercial uses). I'll admit Haskell has…

no real first class functions - you barely use map/reduce/fold/etc. in python

Can you expand on this?

Re: Go is boring

#94

Post by bru »

nimrody wrote: post #69
ozataman wrote: post #53

Earlier quoted context omitted.

Not at all. In fact about 95% of all Haskell I write - and I write quite a bit - is for commercial stuff, ranging all the way across large-ish (not quite google-scale, yet) scale computation, distributed systems, machine learning, modeling/simulations and web development. More academic feeling stuff like parsing and DSLs are just the cherries on top (though even those were for commercial uses). I'll admit Haskell has…

Can you recommend any open source project that you consider a good example of Haskell usage? (meaning both practical and well-written)

I'd say xmonad[1]! It is a very light and fast tiling WM.

There's also a couple of elegant and blazingly fast web frameworks, such as Yesod, Snap and Happstack[2].

1: http://xmonad.org/

2: http://www.haskell.org/haskellwiki/Web/Comparison_of_Happsta... http://stackoverflow.com/questions/5645168/comparing-haskell...

Re: Go is boring

#95

Post by fauigerzigerk »

ozataman wrote: post #53
thebigshane wrote: post #31

Earlier quoted context omitted.

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

Not at all. In fact about 95% of all Haskell I write - and I write quite a bit - is for commercial stuff, ranging all the way across large-ish (not quite google-scale, yet) scale computation, distributed systems, machine learning, modeling/simulations and web development. More academic feeling stuff like parsing and DSLs are just the cherries on top (though even those were for commercial uses). I'll admit Haskell has…

I guess it all depends on whether or not you think that pure functional programming makes sense as a general approach to programming. Pure functional or not is a very fundamental choice that influences all other features of a programming language. So I don't think it makes a whole lot of sense to compare Haskell to Go feature by feature.

Anyway, I agree that there is no reason why Haskell should be confined to the academic space at all. Actually I think the whole "right tool for the job" mantra is largely misplaced when it comes to Turing complete languages (apart from _very_ low level systems programming).

Re: Go is boring

#96

Post by Erwin »

trung_pham wrote: post #2

I love static typed language. With a proper IDE, code navigation, completion work like magic. I end up doing less typing than the dynamic typed language. Have you ever tried to auto complete the 'init' function in RubyMine? It will ask you which one of the 100 init functions do you mean. :) Not with static typed language. There is only one init function to choose from because the IDE knows the exact type you are work…

IntelliJ's Python module (Pycharm) does a as decent job as you might expect based on code and your type annotations (i.e. if your docstring says that foobar is a BlahManager, it will complete foobar methods based on that and warn you if you are calling something foobar doesn't have).

Re: Go is boring

#97

Post by StavrosK »

As a long-time Python programmer, I tried Go recently for something that needed large amounts of concurrency (a hosted version of hubot: http://instabot.stochastictechnologies.com), and I have to say, I am very pleasantly surprised.

The type system was a bit cumbersome, after coming from Python, especially having to wrangle with pointers after not using them ever, but it's nothing you don't get used to. I'm still not sure how much I gain from static typing, but I'm willing to bear it out.

Channels and goroutines, however, were an absolute dream to use. The entire IRC frontend runs off one process, which, I am led to believe, will basically never need anything more (it just proxies messages from IRC to the backend and back). Communication with the processes was fantastically easy, creating, launching and reasoning about goroutines is, again, very straightforward, and all this feel very much like a first-class citizens.

Python has gevent too, and it suited me very well, but Go feels more integrated and better done.

Re: Go is boring

#98

Post by masklinn »

pufuwozu wrote: post #84
masklinn wrote: post #79

Earlier quoted context omitted.

The haskell code is — as far as I can see anyway — nominative typing. It can be post-implemented, but you still need your type to be explicitly made into a Stream instance. Contrast OCaml, an object type is represented as a set of (method, types) tuples and type-checking is a subset check (if type A has all the methods of type B, then it's a subtype of B regardless of anything else from visibility to semantics): # le…

You're comparing ad-hoc polymorphism with subtype polymorphism . Doing so will lead you to the expression problem : http://en.wikipedia.org/wiki/Expression_problem Anyway, there's been quite a few proposals to add extensible records to Haskell, which would allow row polymorphism , similar to what you just showed in OCaml: http://hackage.haskell.org/trac/ghc/wiki/ExtensibleRecords Too bad that it has gone nowhere in a…

> You're comparing ad-hoc polymorphism with subtype polymorphism.

No, I'm comparing structural typing, which is what Go implements, to nominative typing.

But that may very well be due to me having stayed in context of an other sub-thread where this was the subject, and using that as a filter for the current one.

Re: Go is boring

#99

Post by masklinn »

hasenj wrote: post #78
masklinn wrote: post #74

Earlier quoted context omitted.

> I also never seen any language doing interfaces like Go. OCaml has used structural subtyping since the beginning for its object layer. C++'s templates also use structural subtyping on type arguments. Pierce also covers the subject in TAPL. > I find that this is pretty impressive as a feature on its own. There are advantages and inconvenients to structural subtyping (compared to nominative): it's more flexible and h…

I don't know what structural subtyping is, but I no that Go's interfaces are nothing like anything in C++

> I don't know what structural subtyping is

Which is why "you have never seen a language doing interfaces like Go", everybody else calls it what it is (structural typing/structural subtyping)

> I no that Go's interfaces are nothing like anything in C++

Well you may "know" it, but your knowledge is wrong.

Re: Go is boring

#100

Post by masklinn »

swdunlop wrote: post #72
nas wrote: post #27

Earlier quoted context omitted.

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…

It is hard to get excited about concurrency in vanilla Python while the Global Interpreter Lock still chokes everything down internally. (Vanilla, here, should be read "not Stackless.") For more effective use of lightweight processes, I'd probably reach for Erlang or Occam.

Not sure why, the GIL is not an issue to node-style concurrency (based on an event loop and async IO), though you need alternative IO layers (Gevent provides exactly that, and can — if requested — monkeypatch the stdlib to replace standard synchronous IO calls by Gevent-provided async IO).

In fact, mixing threads and an event loop with async IO is probably a good way to make everything blow up.

Post reply on HN