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

171–180 of 220 posts

Re: Leaving Go

#171

Post by m0th87 »

tptacek wrote: post #168
m0th87 wrote: post #161

Earlier quoted context omitted.

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.

I thought the debate was about polymorphism. It's apparently not worth including because...? It's not already in the language spec? Because the people who advocate it are using the wrong tool? Surely there's a better argument than this.

Re: Leaving Go

#172

Post by burntsushi »

eridius wrote: post #77
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…

A generic abs? Not particularly useful, you're right. But he was using that as a trivial example. Generics are incredibly useful in a lot of contexts. One context that the author touched on briefly is new container types. In Go, if I have a Slice, the type of element the slice contains is specified. But if I have a user-defined container, either the container has to be specialized for a single type (which makes it la…

Trivial examples are terrible as evidence to support a point. Trivial examples are generally good for pedagogical purposes, which doesn't really fit with the OP.

For example, the OP mentioned that using a stack in Go requires casting from `interface{}`. But this is patently ridiculous. Most people who need a stack in Go just use a slice: https://code.google.com/p/go-wiki/wiki/SliceTricks --- Is this a bit messier and limited than a container type suited to stacks? Yes! But it gets the job done the majority of the time. Therefore, it's not as big of a problem as the article leads you to believe.

Not all things require clean polymorphic container types. Sometimes you can get by with less. And when you need more, you're going to feel a bit of pain with a less expressive type system. It's all part of the trade off. But it's not good to represent this as a scenario where it's all just bad stuff all the time.

Re: Leaving Go

#173

Post by moreentropy »

DAddYE wrote: post #3

> I’ve been using Go since November and I’ve decided that it’s time to give it up for my hobby projects. I’d still be happy to use it professionally, but I find that programming in Go isn’t “fun” in the same way that Python, Haskell, or Lisp is. I can't leave go, but indeed I think absolutely the same. The thing is that GO was designed to replace c++ thing that absolutely failed. So we have a python/ruby replacement…

> So we have a python/ruby replacement with very old patterns (I think manual checking errors ie.).

Before using Go, I have always programmed with "modern" languages that use exceptions for error handling. So the concept of only doing manual error handling was new to me, but after a few months of golang I love it now and exceptions in python started to really annoy me.

In Go, I'm forced to do error handling right after every single call that will possibly return an error. While I thought that the resulting code looked ugly and repetitive, the result is a much more focused and intelligent error handling.

If i wanted the same granularity and robustness of error handling in python, I'd have to put a catch all try..except block around every single call .

Exceptions are a good time saver in stateless request based programs (like HTTP/web stuff) where it's sort of accetable if one request fails. I could just not care so much about detailed error handling, the worst that could happen is that i don't catch some error and the wsgi wrapper will catch it and return error 500 to the client. But building daemons in python is just plain painful. If I don't want my program to crash at some point I have to reckon that anything can raise an exception I didn't think of.

Re: Leaving Go

#174

Post by tptacek »

m0th87 wrote: post #171
tptacek wrote: post #168

Earlier quoted context omitted.

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.

I thought the debate was about polymorphism. It's apparently not worth including because...? It's not already in the language spec? Because the people who advocate it are using the wrong tool? Surely there's a better argument than this.

Lack of polymorphism isn't even close to the most common objection to Golang. The most common objection is the lack of generics, which make it tricky to write reusable container libraries.

Golang comes pretty close to flat-out rejecting object orientation. It's only barely more object-friendly than C is. If you're the kind of programmer that wants to model a problem domain or build code with the Smalltalky feel that Gang of Four patterns give Java and C++, you will also hate Golang.

Generics might happen in the future (the more Golang I write, the less excited I am at the prospect), but a richer object model seems very unlikely. If you want to hang your argument on polymorphism rather than generics (I applied the principle of charity and assumed that's what you meant), the argument gets less valid, not more.

Re: Leaving Go

#175

Post by Locke1689 »

stiff wrote: post #128
tptacek wrote: post #123

Earlier quoted context omitted.

I honestly am not sure I follow what your concern is with that line of code. list.New() looks extremely clean to me.

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 :=…

In the C# language we refer to this as the 'Color Color problem'. You have some enum or type Color and then a member of an object which you, quite obviously, want to name 'Color'. It's so annoying for the programmer to work around this that we define special exceptions in naming rules so the programmer can do what they want.

Re: Leaving Go

#176

Post by pjmlp »

tptacek wrote: post #107
stiff wrote: post #92

Earlier quoted context omitted.

There is something to your description. I use Go sometimes, for pragmatic reasons, when I need more performance than I can get from Python or Ruby, but boy is it a ugly language! There are just tens of little ugly things Go does and the result is, well, even uglier. Writing four functions for every collection to be sorted, writing x = append(x, foo) everywhere, shitty namespacing that prevents you from writing list :…

x = append(x, foo) is a common C idiom too; in fact, it's been awhile since I had to work with STL containers, but I think it was common there too. I love Golang namespacing rules. They do exactly what I need them to do to allow me to call into other people's code using the right function calls, and nothing else . I think Golang's namespacing is a high point of the language.

> I think Golang's namespacing is a high point of the language.

Really?!? Available in modular languages since Mesa days (mid 70's).

Re: Leaving Go

#177

Post by rurban »

nostrademons wrote: post #102
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.

It's not a good thing - for production software - for a language to be too much fun to use. It means that developers spend all their time using the language and not enough time solving problems . The suckiness of Java/C# tends to encourage people to solve their problem and move on quickly to the next problem, because it's honestly not much fun trying to extend the language or build abstractions. Haskell & Lisp progra…

Nonsense. A high-level language developer uses the higher concepts to get more work done, in better ways, and less time. Hacks always strike back, sooner or later.

Re: Leaving Go

#178

Post by pron »

tel wrote: post #152
pron wrote: post #91

Earlier quoted context omitted.

> Sophisticated programs running sophisticated systems? They exist Not really. Well, far less than in all those horrible, unusable languages. All I'm saying is, if Haskell makes writing correct code so easy, where is it? There should be tons of it now. It should be practically everywhere. In fact, it should be financially stupid to do anything in any language other than Haskell. So where are all the companies making…

Maybe it already is. That doesn't mean it would happen. People do not genuinely optimize for what they want, they tend to optimize for what they want given what they know today and their internal biases. I'm not willing to claim that Haskell is perfect, but I am willing to claim it is better. I'm also willing to claim that if it had anything resembling the community, say, C# has (to pick a random example) then it'd s…

> People do not genuinely optimize for what they want, they tend to optimize for what they want given what they know today and their internal biases.

Absolutely. Which means that there are substantial switching cost, which a slight marginal improvement can't overcome. But if benefits are so immense, they should be able to. I think Haskell's supporters tend to overstate its advantages (and it certainly has plenty of those), and discount its disadvantages (and it's got plenty of those, too). All in all, Haskell is an extremely interesting and very good language, but it most certainly does not solve all or even most of the challenges of modern software development. It's good, it's very interesting, but it's not the second coming. I, for one, would take the JVMs monitoring and hot code swapping capabilities over Haskell's type safety, because those solve a bigger pain point for me.

Re: Leaving Go

#179

Post by taylorlapeyre »

camus2 wrote: post #65
taylorlapeyre wrote: post #8

I just wanted to point out that the author of this article is a high school student. http://jozefg.bitbucket.org/about.html

How does it make the OP less relevant? i know pretty smart programmers that are still in high school. And tt doesnt matter, the guy obviously knows Go.

My implication was that the article was very professional and I was quite impressed that it was written by somebody so young. I think that it makes it more relevant, not less.

Re: Leaving Go

#180

Post by taylorlapeyre »

awj wrote: post #133
taylorlapeyre wrote: post #8

I just wanted to point out that the author of this article is a high school student. http://jozefg.bitbucket.org/about.html

Why do you feel this is worth pointing out?

I think that it is very impressive that he is having these thoughts at such a young age. That's it, I wasn't saying that his opinion should be discredited!
Post reply on HN