Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Leaving Go

jozefg.bitbucket.org

Post reply on HN
Print view View original

161–170 of 220 posts

Re: Leaving Go

#161

Post by m0th87 »

tptacek wrote: post #89
m0th87 wrote: post #52

Earlier quoted context omitted.

You're right, Golang is all about pragmatism, and a very pragmatic thing for language designers to do is to listen to the marketplace on how the language should evolve. Lack of polymorphism must be the most common critique of Golang. It seems pretty practical to add it, as it would greatly reduce the amount of boilerplate. And it's not as if polymorphism is stuck in the ivory tower - languages used in industry have h…

When I wrote that paragraph, I definitely did not think of "pragmatism" as "doing whatever people wanted them to do". Golang is also not Perl. If you're looking for Perl, Golang will disappoint you.

I'm not sure how you can create a pragmatic language while ignoring the most common complaints about it.

There's this common attitude of "if you want feature X and Go does not have it, Go is not for you." To some extent it's not surprising since there was confusion about what niche Go hit when it first came out. But when there's repeated patterns in critiques of Go coming from very smart people, it's probably worth paying attention rather than saying it just doesn't fall into the language's sense of "pragmatism".

FWIW, I'm a Python programmer who loves Go. Despite all its good stuff, though, we shouldn't remain content with what we have already.

Re: Leaving Go

#162

Post by pcwalton »

tomp wrote: post #153
stiff wrote: post #128

Earlier quoted context omitted.

You frequently have packages that are named after generic nouns, like time, host, file etc. There are many contexts where this same generic name makes for the best variable name: clear, short, and easy to type: func ReadFile(filename String) { file := file.Open(filename) } In Go you have to invent a new name, so invariably you will see a lot of: theFile := file.Open(filename) aFile := file.Open(filename) readFile :=…

Unless you're also frustrated by not being able to write `int int = 3` in C/C++/C#/Java/most other languages, I don't see the point of your concern. f = file.open("a.txt") out_file = file.open("b.txt", file.WRITE)

You can write that in C though.

    typedef int foo;

    foo main() {
        foo foo = 0;
        return foo;
    }

Re: Leaving Go

#163

Post by yongjik »

pnathan wrote: post #46
Locke1689 wrote: post #41

Earlier quoted context omitted.

As someone who thinks that more advanced type systems and proof-carrying-code are some of the biggest advances in theoretical computer science and practical programming in the last few decades, but also is a C# compiler developer, I have also noticed this. Haskell is really interesting, but C# developers get shit done. I'm not sure what the cause is, but it definitely gnaws at me.

> C# developers get shit done. Yes, and that says a lot about the final quality too, no? We could say the same about Perl/PHP/Java/C++ and then we're sitting in the same horrible morass we live in today, because people settle for minimally bad code produced as fast as possible. Good, cheap, fast. Pick 2. Almost invariably: Cheap+fast are the picked results.

More often than not, it is: Good, existent, fast. Pick 2.

Re: Leaving Go

#165

Post by twic »

jamra wrote: post #83

I have a problem with his extensibility critique. I don't agree that having generic types are good for the language. The problem in using polymorphism is that your users are going to abuse polymorphism. There will be class hierarchies that will confuse and abstract from the algorithm at hand. You will be mutating and mangling objects rather than dealing with the issues at hand. Reading a go source file is like follow…

The genericity that is being talked about here is parametric polymorphism, not subtype polymorphism. Parametric polymorphism doesn't lead to confusing class hierarchies. Parametric polymorphism doesn't involve inheritance, so it doesn't lead to any class hierarchies.

Re: Leaving Go

#166

Post by astine »

deadghost wrote: post #98
astine wrote: post #66

Earlier quoted context omitted.

I think that part of the problem is that more 'powerful' languages often more concept heavy than more 'pragmatic' languages and that makes them harder to learn for a lot of programmers. Take Clojure for example. A lot of people including myself like this language a lot, but to be productive in it, you have to get used to the JVM, Lisp s-expressions, a heavily functional programming style with few side effects, a sign…

Not to mention emacs and the REPL. Emacs was my biggest hurdle learning Common Lisp. Learning a language - OK. Learning an editor - OK. Learning both at the same time - Not OK. I don't think light table was around at the time.

I had the same problem when I learned CL. On the flip-side, I really like Emacs now so I'm glad I learned it.

Re: Leaving Go

#167

Post by tptacek »

pcwalton wrote: post #162
tomp wrote: post #153

Earlier quoted context omitted.

Unless you're also frustrated by not being able to write `int int = 3` in C/C++/C#/Java/most other languages, I don't see the point of your concern. f = file.open("a.txt") out_file = file.open("b.txt", file.WRITE)

You can write that in C though. typedef int foo; foo main() { foo foo = 0; return foo; }

You can do the same thing in Golang by renaming the import that clashes with your preferred variable name. Nobody does it, though, because it's not worth the trouble.

Re: Leaving Go

#168

Post by tptacek »

m0th87 wrote: post #161
tptacek wrote: post #89

Earlier quoted context omitted.

When I wrote that paragraph, I definitely did not think of "pragmatism" as "doing whatever people wanted them to do". Golang is also not Perl. If you're looking for Perl, Golang will disappoint you.

I'm not sure how you can create a pragmatic language while ignoring the most common complaints about it. There's this common attitude of "if you want feature X and Go does not have it, Go is not for you." To some extent it's not surprising since there was confusion about what niche Go hit when it first came out. But when there's repeated patterns in critiques of Go coming from very smart people, it's probably worth p…

I wrote the comment you're replying to, so I'm probably in the best position to determine what I meant by the word "pragmatic". I didn't mean "implementing whatever feature people complained most about missing".

If there's a debate to have here, it's about what word better captures the point I was trying to make than "pragmatic". But that's an incredibly boring debate, so, I opt out.

Re: Leaving Go

#169

Post by maxk42 »

Donch wrote: post #31

The example could have been simplified: func abs(x Top) Top { switch v := x.(type) { case int32: if v

This doesn't work, but if it did you could simplify the switch statement to:

    switch v:= x.(type) {
    case int32, int64, float32, float64:
        if v
Go has some neat improvements to the switch statement: http://golang.org/doc/effective_go.html#switch

Re: Leaving Go

#170

Post by joeshaw »

personZ wrote: post #60

These sorts of posts are profoundly boring. I know people will up arrow it -- some sort of spiteful "Down with Go!" contrarian thing, when they aren't talking up rust -- but it isn't because the content is interesting or illuminating, but rather as some sort of activist thing. This particular piece (by a high school student, as an aside) starts off trying to create a surrogate for generics in Go. Don't . Here's the t…

I posted a comment about this to the blog, but I released a tool which will generate type-specific source code from a generic definition. Code is at https://github.com/joeshaw/gengen

The abs example could be reduced to:

    import "github.com/joeshaw/gengen/generic"

    func abs(x generic.T) generic.T {
        if x
You could then generate different type-specific versions:

    gengen abs.go int32 | gofmt -r 'abs -> absInt32' > abs_int32.go
    gengen abs.go float64 | gofmt -r 'abs -> absFloat64' > abs_float64.go
    ...
The downside is that the API is annoyingly non-generic (a different abs variant for each type) but at least you didn't have to type it in a bunch of times.

I agree that abs() is kind of a toy example, but this approach has helped me a lot for various slice operations like indexing and deleting.

Post reply on HN