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

71–80 of 138 posts

Re: Go is boring

#71

Post by vdm »

protomyth wrote: post #19
eru wrote: post #11

Earlier quoted context omitted.

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.

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.

Compiler As A Service. Microsoft are pushing this with Roslyn.

http://www.infoworld.com/d/application-development/microsoft...

Re: Go is boring

#72

Post by swdunlop »

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…

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.

Re: Go is boring

#73

Post by swdunlop »

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)?

Go has a smaller, narrower standard library that is more tightly maintained and governed than Python. Python's original slogan, "batteries included" could be amended after 20 years of use to "bitrot included." Some libraries have partially broken semantics that have been maintained because legacy applications rely on those broken semantics. Python modules don't even agree on tab width or casing.

Part of that is youth, Go went 1.0 just this Spring, and had a serious housecleaning applied in the process. "Being boring" is a big part of Go's identity -- most changes have been pragmatic and thoroughly thought out, and when they come, "gofix" often knows how to apply them to legacy code. (Static linking doesn't hurt, either.)

In theory, Go has more to gain in performance with the GC leaving a lot of room for improvement -- CPython has been subject to a lot of tuning over the years and has found a nice local maximum to settle on. In practice, this does not matter nearly as much as picking the right algorithm, profiling, and avoiding dumb mistakes. (A favorite gaffe: "string concatenation is faster than using a format string in Python".)

Re: Go is boring

#74

Post by masklinn »

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.

> 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 has much lower overhead, but it's subject to false positives (structurally equivalent but semantically unrelated objects) and tends to have much worse error reporting. Not to mention structurally typed systems still usually have and need nominative types in their core, for "non-object" types.

Re: Go is boring

#75

Post by [deleted] »

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)?

[deleted]

Re: Go is boring

#76

Post by [deleted] »

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)?

[deleted]

Re: Go is boring

#78

Post by hasenj »

masklinn wrote: post #74
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.

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

Re: Go is boring

#79

Post by masklinn »

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…

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):

    # let x =
          object
              method foo = 42
          end;;
    val x :  = 
    # let y =
          object
              method foo = 63
              method bar = 12
          end;;
    val y :  = 
    # x = y;;
    Error: This expression has type 
           but an expression was expected of type 
           The second object type has no method bar
    # type simple = ;;
    type simple = 
    # (y :> simple) = x;;
    - : bool = false
    #

Re: Go is boring

#80

Post by edwkar »

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)

Well, xmonad is an excellent example :-)
Post reply on HN