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

121–130 of 138 posts

Re: Go is boring

#121

Post by pcwalton »

tmurray wrote: post #81
genbattle wrote: post #32

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

I don't think the issue of separate address spaces is unsolvable. As long as you have a type system powerful enough to forbid aliasing between the CPU and the GPU code, you can do it. (For example, Rust's type system can encode task-local data.)

Re: Go is boring

#122

Post by ozataman »

icebraining wrote: post #93
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…

no real first class functions - you barely use map/reduce/fold/etc. in python Can you expand on this?

Sure. What I meant is that while python does have first-class functions, you don't make much use of it in idiomatic style. Much of the logic is still encapsulated in bloated, less flexible classes and/or imperative style variables you create to hold middle values.

If you wanted to use first-class functions in your code pervasively, then you lack the massive libraries and compiler optimizations available to Haskell. As a result, first-class functions are only used at a superficial level in Python, perhaps as key arguments to some functions.

In a language like Haskell, on the other hand, you make use of the first-class nature of functions all the time.

It's common to have pipelines like:

foldr step 0 . map convert . concatMap (chunks 2) $ inputList

  where

    step = ...

    convert = ...
Almost everything in that pipeline takes a function as a parameter. Also note how chunks takes an integer, partially applying the function, and returns a new function that is now ready to take a list to chunk into groups of 2. You really get used to this stuff.

Re: Go is boring

#123

Post by hythloday »

icebraining wrote: post #120
hythloday wrote: post #114

Earlier quoted context omitted.

Of course you can . But the poor support for lambdas and higher-order-functions makes comprehensions a worse-is-better solution, because you can e.g. pickle comprehension expressions (which you can't do for lambdas), and you don't need to import a module for reduce (in 3.x). I gave up on using them when I realized they were just too frictive (or that they were "un-Pythonic", if you prefer).

I'm sorry, but can you clarify what you mean by poor support for higher-order-functions? And how can one pickle comprehension expressions? I'm not trying to be argumentative, I just don't have much experience with that. I write functions that return functions/closures regularly, but they're always simple cases.

You're not coming across as argumentative.

By poor support for higher-order functions, I mean that e.g. you have to do "from functools import reduce, partial" for fold or partial function application. It's a trivial complaint, I'll give you, but it's one that's bitten me on more than one occasion (you think I'd learn!). There's also no foldr unless you implement it yourself.

I badly misspoke when I said that you could pickle comprehensions, because what I meant was that the language gives you no hint that you might be able to. Pickling

  sum([ os.stat(f).st_size for f in os.listdir(".") ])
is obviously (I hope) not going to work. On the other hand pickling

  [ lambda n: n % 2 == 0 ]
intuitively ought to, since pickling [ isEven ] would work fine. I've had to rewrite a couple of modules because of this - again, maybe I should have learnt from my mistakes - but it gives me the general impression of "avoid lambdas and functions that regularly use lambdas, because they're occasionally a lot of unexpected work".

Re: Go is boring

#124

Post by ntrel »

blablabla123 wrote: post #103
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…

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

> C++ has the best (imperative) language support for templates

D's template support is far superior: static if, constraints, compile-time function execution, string mixins, opDispatch. These features make templates much more practical and more powerful.

Re: Go is boring

#125

Post by irahul »

irahul wrote: post #62
dhconnelly wrote: post #36

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

For some reason, masklinn's comment is dead. Posting it here:

> 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.

Yes, native code can release the GIL and run in parallel. As far as it's pure python, only one thread runs at a time. The options are multiprocessing, gevent style concurrency(which I prefer to node's) and native extensions. It isn't as bleak as people make it out to be.

Re: Go is boring

#126

Post by icebraining »

hythloday wrote: post #123
icebraining wrote: post #120

Earlier quoted context omitted.

I'm sorry, but can you clarify what you mean by poor support for higher-order-functions? And how can one pickle comprehension expressions? I'm not trying to be argumentative, I just don't have much experience with that. I write functions that return functions/closures regularly, but they're always simple cases.

You're not coming across as argumentative. By poor support for higher-order functions, I mean that e.g. you have to do "from functools import reduce, partial" for fold or partial function application. It's a trivial complaint, I'll give you, but it's one that's bitten me on more than one occasion (you think I'd learn!). There's also no foldr unless you implement it yourself. I badly misspoke when I said that you coul…

I don't understand. You can't pickle functions; when you pickle a function, you get a reference to the function, not the actual function code.

E.g., this doesn't work:

    Dump.py:
      def isEven(n):
          return n % 2 == 0
      import pickle
      with open('pickled','w') as dumpfile:
          pickle.dump(isEven, dumpfile)

    Loader.py
      import pickle
      with open('pickled') as loadfile:
          isEven = pickled.load(loadfile)
This throws

    AttributeError: 'module' object has no attribute 'isEven'
What you can do is marshal the function's code:

    import marshal
    marshal.dump(isEven.func_code, file)
    #Then to load
    isEven = types.FunctionType(marshal.load(file), globals())
But you can also dump a lambda's code:

    import marshal
    marshal.dump((lambda n: n % 2 == 0).func_code, file)
    #Loading is the same
    isEven = types.FunctionType(marshal.load(file), globals())
    isEven(4)
So frankly, I don't get the problem with lambdas.

Re: Go is boring

#127

Post by icebraining »

ozataman wrote: post #122
icebraining wrote: post #93

Earlier quoted context omitted.

no real first class functions - you barely use map/reduce/fold/etc. in python Can you expand on this?

Sure. What I meant is that while python does have first-class functions, you don't make much use of it in idiomatic style. Much of the logic is still encapsulated in bloated, less flexible classes and/or imperative style variables you create to hold middle values. If you wanted to use first-class functions in your code pervasively, then you lack the massive libraries and compiler optimizations available to Haskell. A…

Thanks. Yes, I can definitively see the benefits in having a stdlib and compiler that follows a functional approach.

Re: Go is boring

#128

Post by Olreich »

dan00 wrote: post #89
hasenj wrote: post #78

Earlier quoted context omitted.

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

class A { public: int do() { return 1; } }; class B { public: int do() { return 2; } }; template int do(T t) { return t.do(); }

How does one use that template? Can you show me a function that takes anything with a do() method? Like this?:

    do(a)
    do(b)
Can I take any arbitrary type with an "int do()" method and use that with do? Like:

    do(Arbitrary)

Re: Go is boring

#130

Post by dan00 »

Olreich wrote: post #128
dan00 wrote: post #89

Earlier quoted context omitted.

class A { public: int do() { return 1; } }; class B { public: int do() { return 2; } }; template int do(T t) { return t.do(); }

How does one use that template? Can you show me a function that takes anything with a do() method? Like this?: do (a) do (b) Can I take any arbitrary type with an "int do()" method and use that with do? Like: do(Arbitrary)

"How does one use that template? Can you show me a function that takes anything with a do() method? Like this?:"

It should work without the template parameter: do(a), do(b)

"Can I take any arbitrary type with an "int do()" method and use that with do?"

Yes.

Post reply on HN