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

121–130 of 220 posts

Re: Leaving Go

#121

Post by Jtsummers »

tdees40 wrote: post #12
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

Wow, "writing lots of compilers and type checkers" definitely wasn't on my radar screen when I was in high school.

Me neither, but a classmate was reading over/working through the dragon book our senior year of high school. There's a reason he went to CMU and I didn't. On the other hand, compilers (well, a less than formal version) was the third CS course topic at GT. Definitely approachable, with good faculty/staff, as an early topic of study.

Re: Leaving Go

#122

Post by zem »

Locke1689 wrote: post #41
pron wrote: post #18

It's ironic that the "better" the language (for some hazy definition of "better") the less actual work seems to get done with it. So Go can be pretty annoying at times, and so can Java (I've said before that I find the two almost identical, but that's beside the point now); and C is horrible and completely unsafe and downright dangerous. Yet more useful working code has probably been written in Java and C than all ot…

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.

this is a thought-provoking article on the subject: http://prog21.dadgum.com/21.html

Re: Leaving Go

#123

Post by tptacek »

stiff wrote: post #110
tptacek wrote: post #107

Earlier quoted context omitted.

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 don't think simply having a separate symbol table for packages and a separate one for types and variables would hurt much, and I hate writing things like aList := list.New(). Having said this, I know many of those things are purported to have such and such super important reasons, it doesn't change the ugly "feel" of the end result. Another instance is the indication of visibility by case, they will go on and on ab…

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

Re: Leaving Go

#124

Post by jamra »

tptacek wrote: post #24

If you're looking for a language that will enable "bottom-up development", where you gradually define, in Paul Graham On Lisp style, a language optimized for your problem domain, Golang is not the language for you. Similarly, if you're looking for a language that will read and write like a specification for your problem domain, so that writing your program has the side effect of doing half the work of proving your pr…

Golang is a programming language that applies for readability over language features. Built in channels make it easy to break down your code into more granular pieces. It's like the unix approach to piping but in a program.

Reading a golang program is simple because you don't have to chase class hierarchies very far. I personally find polymorphic code to be a detriment to team projects. Anything that hides implementation is a hit on readability.

Re: Leaving Go

#125

Post by mjdwitt »

webkike wrote: post #114
pcwalton wrote: post #108

Earlier quoted context omitted.

> 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. No, vector::insert() is the common idiom and mutates in place. It'd be written `x.insert(x.end(), foo.begin(), foo.end());` For single elements, vector::push_back() is the common idiom, and also mutates in place.

vector::insert() is certainly not a C idiom. In can never be a C idiom because that is C++ code. the x = append(x, foo) idiom can be seen all over C, most obviously with the use of realloc, which is often called to resize an array via x = realloc(x, newsize).

Indeed. Which is why pcwalton is answering Thomas' conjecture about C++'s STL containers.

Re: Leaving Go

#126

Post by rakoo »

piokuc wrote: post #36

I think people gave Go a lot of credit just because it was designed at Google. People have high respect for Google engineers and so they assume what Googlers have designed must be flawless. So they take for granted ideas like lack of exceptions or lack of operators' overloading being a good thing, even though I'm quite sure they would be quick to criticize such BS if that was a feature in a language not coming from G…

I think people gave Go a lot of credit just because it gets a lot done, especially comparatively to the time taken to learn it, and the stuff you come up with can very well be used in production because you made it robust thanks to the excellent built-in testing and profiling tools.

What's interesting with go is that if you can program, you already know it; all your time is spent building stuff, not learning the language. And when it comes to building stuff, Go is just straightforward.

Re: Leaving Go

#127

Post by Donch »

bsdetector wrote: post #115
Donch wrote: post #31

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

This isn't simpler, it's smaller. In fact it's more complicated , since instead of 4 completely separate cases you have 4 half-cases and a default. For instance, pass a positive int16 and you get the right answer, but pass a negative int16 and you get a useable but wrong answer instead of nil from the original.

It was an example of a language feature, that is short variable declarations in type switches, which avoid repetitive casting. The example below has the default clause which handles unknown types. I suppose the point is that you'd never actually do any of this because the method is disgusting.

Thanks for the downvote :-)

Re: Leaving Go

#128

Post by stiff »

tptacek wrote: post #123
stiff wrote: post #110

Earlier quoted context omitted.

I don't think simply having a separate symbol table for packages and a separate one for types and variables would hurt much, and I hate writing things like aList := list.New(). Having said this, I know many of those things are purported to have such and such super important reasons, it doesn't change the ugly "feel" of the end result. Another instance is the indication of visibility by case, they will go on and on ab…

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 := file.Open(filename)
depending on who wrote the code.

Re: Leaving Go

#129

Post by Haul4ss »

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

That's pretty remarkable, actually. I see he's going to CMU in the fall, which is a win for CMU. He's obviously a smart dude.

Re: Leaving Go

#130

Post by pekk »

bsg75 wrote: post #94
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.

If you are looking for X, Y will disappoint you. -or- If you are looking for X, use X.

Unless X is Python, then use Go (??)
Post reply on HN