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

81–90 of 138 posts

Re: Go is boring

#81

Post by tmurray »

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…

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 generally write terrible code--if array of structures versus structure of arrays doesn't make sense to you, you're probably writing code that cannot be autovectorized)

the lack of a magic compiler bullet is infinitely more true as soon as you look at anything remotely like a GPU, which gets into other more complicated problems due to a distinct memory space.

if I were to add any features like that to Go, I'd probably look in the direction of generating ISPC ( http://ispc.github.com/ ) or ISPC-like output. no need to solve the distinct address space issue (which you cannot solve), you have work creation so you don't need to do crazy scheduling hoops like persistent launches on the GPU, and it performs very well on Intel processors for SIMD-friendly applications.

Re: Go is boring

#82

Post by rblackwater »

jroesch wrote: post #61
trung_pham wrote: post #50

Earlier quoted context omitted.

Exactly. Duck typing sucks. I don't know why it was invented...

It only "sucks"(causes problems rarely, and can be quite useful regardless) in dynamic languages. Languages like Go, Rust, and Haskell provide the same flexibility with static guarantees. All you must do is define type specific implementations to satisfy the interface(or typeclass). For example in Haskell, I can so something like: class Stream s where read :: s -> (a, s) write :: a -> s -> s and extend it to any type…

I really wish more languages had the option of using a Haskell style type system.

Re: Go is boring

#83

Post by pufuwozu »

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)

Pandoc:

http://johnmacfarlane.net/pandoc/

XMonad:

http://xmonad.org/

Re: Go is boring

#84

Post by pufuwozu »

masklinn wrote: post #79
jroesch wrote: post #61

Earlier quoted context omitted.

It only "sucks"(causes problems rarely, and can be quite useful regardless) in dynamic languages. Languages like Go, Rust, and Haskell provide the same flexibility with static guarantees. All you must do is define type specific implementations to satisfy the interface(or typeclass). For example in Haskell, I can so something like: class Stream s where read :: s -> (a, s) write :: a -> s -> s and extend it to any type…

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

Re: Go is boring

#85

Post by thebluesky »

Mr_T_ wrote: post #60
trung_pham wrote: post #49

Earlier quoted context omitted.

IntelliJ is the best IDE out there. It might be pricy, but it will save you so much time in the long run. Since time is money, you will end up saving money too. :)

The Community Edition is free of cost. The choice depends on what you need: http://www.jetbrains.com/idea/features/editions_comparison_m...

yeah free version supports Java SE, with a really nice Scala plugin for download via the plugin manager.

Re: Go is boring

#86

Post by obtu »

eru wrote: post #11
irishcoffee wrote: post #9

Earlier quoted context omitted.

I think the counter-argument here would be that dynamically-typed languages let the person behind the keyboard run the show, as opposed to the IDE.

Alas, nobody has written a really good IDE for Haskell, yet. So we still have to run the show for that statically typed language manually.

What do you think of leksah?

Re: Go is boring

#87

Post by rsaarelm »

Having simple, established ways for doing most common things makes it easy to write code without thinking about decisions around the programming language, such as how the syntax should be formatted, how the symbols should be named, how should memory management be arranged, what conventions should be used for splitting code into files and modules (with little extra design issues involved in structuring header files and include relations, in case you're doing C/C++), what kind of build system should be used, which unit test framework should be chosen and which third party libraries should be chosen for the very commonly needed stuff that's nevertheless not included in the language's standard library since it was standardized somewhere in the late 80s.

Having all this stuff basically solved out of the box makes it very easy to start cranking out actual solutions with Go, even though none of that is particularly interesting from a programming language design standpoint.

Re: Go is boring

#88

Post by obtu »

tikhonj wrote: post #64
protomyth wrote: post #19

Earlier quoted context omitted.

If I ever develop a program language, the first action I will take is the clang approach and make it a library based architecture. That way, people can build tools for the language including IDE integration without having to reinvent the wheel.

I think GHC does something like that. At the very least, it exposes an API that lets you do all sorts of fun things. There are projects like Scion[1] that let you integrate that into an editor. [1]: https://github.com/nominolo/scion/ However, there is simply less drive to develop tooling like that for Haskell than there is for Java. Haskell is a much easier language to use given just a moderately intelligent text edi…

Indeed, “the architecture of GHC” mentions some uses of GHC as a library: http://www.aosabook.org/en/ghc.html

Re: Go is boring

#89

Post by dan00 »

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

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

Re: Go is boring

#90

Post by AYBABTME »

BasDirks wrote: post #65
dscrd wrote: post #52

Earlier quoted context omitted.

What if I told you that you're not supposed to be excited about your programming language?

I can see where you're coming from but for a programmer who is beyond "programming puberty" it is a great plus to be in love with their programming languages. Even better if he/she is unfaithful, and has massive orgies (oh wait did I just take this analogy too far?)

It's a great analogy. I'll go tell my wife about it.
Post reply on HN