Maybe the website wouldn't be down right now if it'd run on Go.
Go is boring
101–110 of 138 posts
Re: Go is boring
#102Earlier 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…
And C/C++ is by developers to implement Java, C#, Python, Ruby, Go, C, and C++. :)
Actually there are Java and C# compilers implemented on the own language.
Re: Go is boring
#103I 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…
I think "Go is boring" is a too simplistic conclusion.
Go creates a genuinly unique programming environment. If you come from a C++ background (like me) you might think the C++ solution will always be structurally superior.
But this is not true. It has a really radical take on OOP, actually realizing some of the most extreme takes on OO from the C++ community: no class inheritance, only interface inheritance. Using the inheritance syntax for non-interfaces ("classes") does inheritance by composition.
Regarding templates: C++ has the best (imperative) language support for templates. But it also shows where it can lead... (typedef typename...) Boost has actually become a playground for clean template implementations that look like nothing but a mess.
Re: Go is boring
#104Earlier quoted context omitted.
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…
reasonable SIMD support (let's limit it to SSE2 and above for "reasonable") has been in every Intel processor since what, Pentium 4? it's not much of a bolt-on anymore. one of the causes of the lack of good programming models for SIMD is that autovectorization was supposed to generate SIMD code for every application, but autovectorization isn't actually that great for many (most?) applications. (plus naive developers…
> reasonable SIMD support (let's limit it to SSE2 and above for "reasonable") has been in every Intel processor since what, Pentium 4?
Yeah, and the Athlon64 (and Opteron) for AMD.
Re: Go is boring
#105Earlier quoted context omitted.
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. Python uses native multi-threads, but the GIL restriction means only one thread can run at a time regardless of number of cores or processors you have. > 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. Use pylint and/or syntastic(for vim…
[deleted]
Re: Go is boring
#106Earlier quoted context omitted.
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. Python uses native multi-threads, but the GIL restriction means only one thread can run at a time regardless of number of cores or processors you have. > 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. Use pylint and/or syntastic(for vim…
> Python uses native multi-threads, but the GIL restriction means only one thread can run
Can run Python code, if you're multithreading for e.g. IO the IO code will generally release the GIL.
Re: Go is boring
#107Earlier 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…
no real first class functions - you barely use map/reduce/fold/etc. in python Can you expand on this?
I'll expand a little, because I've been feeling the same thing recently.
Python has syntactic support for list[0] comprehensions, which can be used a little like maps:
def addOne(n):
return n+1
l = [1, 2, 3]
[ addOne(n) for n in l ] # [2, 3, 4]
def isOdd(n):
return n % 2 == 1
l = [1, 2, 3]
[ n for n in l if isOdd(n) ] # [1, 3]
def accum(s):
acc = s
def a(n):
acc += a
return acc
return a
l = [1, 2, 3]
reduce = accum(0)
[ reduce (n) for n in l ][-1] # 6
There are a couple of problems I've run into. The first is that Python's libraries are just not engineered with the idea of using list comprehensions in this way - folding is as awkward as it looks above, exceptions thrown in the list comprehension functions will terminate the comprehension, many python functions alter state and return None rather than a useful output, and so on. The second is that they're amazingly uncomposable, syntactically:
l.map(addOne).filter(isOdd).reduce(accum(0))
[ reduce(nr) for nr in [ nf for nf in [ addOne(nm) for nm in l ] if isOdd(nf) ] ][-1]
I find Python's comprehension style very convenient, and I'm sure you could produce an excellent theoretical abstraction over it, but if you're coming at it from the point of view of wanting them to be map/reduce or something equally reasonable-about, you're going to be disappointed. Python isn't an object-oriented language, and isn't a functional language - the more I use it the more I think it's something akin to a collection-oriented language. Maybe that's just the way I use it. :)
[0] and also set comprehensions, dict comprehensions, and generator (lazy list) comprehensions, which are wonderful but exacerbate both the problems I talk about.
Re: Go is boring
#108I'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.
What if I told you that you're not supposed to be excited about your programming language?
I worked in PHP for years, now we've moved over to NodeJS and I'm massively excited about JS in a way that I never was about PHP.
If you're not excited about your programming language, I would suggest that maybe you're using the wrong one.
Re: Go is boring
#109As 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 no…
I think what you gain from static typing is pretty much that you can compile your programs and run without a fat interpreter.
Note - I am not saying that is the only possible benefit of static typing anywhere, e.g. in Haskell - this is more in line with C, you are doing type declarations to cue the compiler rather than to realize some utopian test-free development methodology.
Re: Go is boring
#110Earlier quoted context omitted.
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...
Installing xmonad requires several hundred megs of dependencies, so what does it mean for it to be light? Low memory footprint?