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

Go Lang: Comments Are Not Directives

news.ycombinator.com

Post reply on HN
Print view View original

191–200 of 222 posts

Re: Go Lang: Comments Are Not Directives

#191

Post by zaphar »

rudolf0 wrote: post #174
zaphar wrote: post #103

Earlier quoted context omitted.

The problem with Go is that, while the language and compiler are excellent, Google doesn't a lot care about tooling & ecosystem. Why? They have their own in-house tooling (which is of course both highly specific to Google's use case and closed of for the public). This is the most bizarre criticism of go I have ever heard. Go has the best tooling of any language I have ever used bar none. A cursory look at: https://go…

The thing that really baffles me is that Go/Google have invested so much into tooling for the language, yet didn't bother to implement official tools for the most important feature of any language: package and dependency management. I've heard this explained as "everyone at Google just points their imports at Git repo HEADs", which is valid for a self-contained organization like that, but seems very closed-minded con…

This is admittedly a shortfall of go. However it's one that is fairly easy to rectify later and one the community is quite capable of solving itself.

Re: Go Lang: Comments Are Not Directives

#192

Post by tomjen3 »

zaphar wrote: post #138
tomjen3 wrote: post #121

Earlier quoted context omitted.

Eclipse has had those things for years for Java. Yeah that is not editor agnostic but when you sit down and learn a platform learning an IDE isn't a big deal. Speaking of which I do not see any official recommendation of an IDE for Go.

It isn't a big deal for you maybe. But I work in many different languages in a day. Switching IDE's/editors is a context switch I shouldn't have to make. Go is one small step in that direction. You don't see an official recommendation because it's not necessary. Pretty much anything you use is going to have comparable functionality due to the work of the go team. Which is how I know that the Go team cares about tooli…

>Pretty much anything you use is going to have comparable functionality due to the work of the go team.

Even so you force every new developer to look around to find whatever he wants, which makes getting started more difficult.

Lets just say that I am a fan of the IntelliJ platform. Which plugin would I install to use with Go?

Re: Go Lang: Comments Are Not Directives

#193

Post by likeclockwork »

tree_of_item wrote: post #122
breakingcups wrote: post #27

The problem with Go is that, while the language and compiler are excellent, Google doesn't a lot care about tooling & ecosystem. Why? They have their own in-house tooling (which is of course both highly specific to Google's use case and closed of for the public). This in itself isn't bad, but the problem it causes is that the Googlers (who do not experience the pain that other users of the language do) are still the…

> The problem with Go is that, while the language and compiler are excellent, Google doesn't a lot care about tooling & ecosystem. I'd say you got this exactly backwards. The language is mediocre, but the tooling and ecosystem are great. The `go` command in particular is something I really want in other languages: no messing around with build files or monsters like `cabal`.

"[Go] is a great [ecosystem], lacking only a decent [programming language."

Re: Go Lang: Comments Are Not Directives

#194

Post by Merkur »

fixxer wrote: post #180
Merkur wrote: post #157

Earlier quoted context omitted.

Actually it would remind me on C. It did not even support a redundant comment token, and of course they did not used a comment to mark directives. go troll your self. I am always open to argue, but you have no leverage to be snarky.

Your entire tirade is a troll. You got an answer from Fitz (looked reasonable to me), but you didn't like it. So you decided to take the debate to HN?! Nothing productive ever happens like this. This is some teenage angst diarrhea. Fork the project and write your own solution. Show us all how fucking brilliant you are.

while arguing against your self is nice practice - diarrhea is just... you know... really messy. I hope you get well soon. :)

Re: Go Lang: Comments Are Not Directives

#195

Post by garthk »

ominous_prime wrote: post #120
pjmlp wrote: post #101

Earlier quoted context omitted.

I doubt that there will ever be a Go 2. EDIT: For the downvoters, quoting Rob Pike in one of his presentations, "Go's design is done".

Maybe he should have said the design is done for go1. Regardless, issues are still filed under the tag of `go2`, even by Rob Pike. There's no reason to believe that go2 won't eventually happen.

On the other hand, there's every reason to believe the "Go [a]Way" prohibition on certain language features will leave Go 2 insufficiently attractive vs Go 1 to overcome the switching costs, dragging out any migration period. See also: Python 3.

Re: Go Lang: Comments Are Not Directives

#196

Post by curun1r »

coldtea wrote: post #159
curun1r wrote: post #152

Earlier quoted context omitted.

> Can you think of some aspect that was especially well thought-out? Go routines, channels and select. With very little else, it's possible to write some very useful code in a way that's concise, elegant and easy to reason about.

Only compared to something like C or explicit old-skool Java like threading. A lot of modern languages have CSP built-in or as a lib (Java, Scala, Haskell, Clojure, C++, Ada, Erlang, heck even Rust). And Go is not quite expressive to address higher level, but common, constructs ( https://gist.github.com/kachayev/21e7fe149bc5ae0bd878 ) in a conceise and elegant way. And if you access anything outside of channel provid…

You seem very focused on what you can't do with it rather than focusing on what you can do with it. I've found, in practice, that you learn to adapt to not having that level of expressiveness and start thinking through problems the Go way. And I've come around to the viewpoint that expressiveness is also a liability of a language in addition to being a feature. Sharing code in a team becomes so much easier when using Go compared to other, more expressive, languages. And I've even come around to liking it for my personal projects too after returning to code I hadn't seen in months and immediately grokking it.

Maybe it's just my advancing age (for a programmer), but I find myself gravitating towards the "It's not finished when there's nothing left to add, but when there's nothing left to remove" mentality when it comes to programming languages. I find that I'm only willing to tolerate new language features when they introduce benefits that go beyond expressiveness.

Re: Go Lang: Comments Are Not Directives

#197

Post by fixxer »

Merkur wrote: post #194
fixxer wrote: post #180

Earlier quoted context omitted.

Your entire tirade is a troll. You got an answer from Fitz (looked reasonable to me), but you didn't like it. So you decided to take the debate to HN?! Nothing productive ever happens like this. This is some teenage angst diarrhea. Fork the project and write your own solution. Show us all how fucking brilliant you are.

while arguing against your self is nice practice - diarrhea is just... you know... really messy. I hope you get well soon. :)

Oh no, you misread what I wrote. I was comparing your tirade to diarrhea. As in, "I think your words are shit".

Sorry for the mixup! Take care!

Re: Go Lang: Comments Are Not Directives

#198

Post by Dewie3 »

curun1r wrote: post #196
coldtea wrote: post #159

Earlier quoted context omitted.

Only compared to something like C or explicit old-skool Java like threading. A lot of modern languages have CSP built-in or as a lib (Java, Scala, Haskell, Clojure, C++, Ada, Erlang, heck even Rust). And Go is not quite expressive to address higher level, but common, constructs ( https://gist.github.com/kachayev/21e7fe149bc5ae0bd878 ) in a conceise and elegant way. And if you access anything outside of channel provid…

You seem very focused on what you can't do with it rather than focusing on what you can do with it. I've found, in practice, that you learn to adapt to not having that level of expressiveness and start thinking through problems the Go way. And I've come around to the viewpoint that expressiveness is also a liability of a language in addition to being a feature. Sharing code in a team becomes so much easier when using…

> Maybe it's just my advancing age (for a programmer), but I find myself gravitating towards the "It's not finished when there's nothing left to add, but when there's nothing left to remove" mentality when it comes to programming languages. I find that I'm only willing to tolerate new language features when they introduce benefits that go beyond expressiveness.

Yes, "maybe it's just my experience and wisdom with regards to programming". Do you really expect anyone to fall for that crap?

Re: Go Lang: Comments Are Not Directives

#199

Post by comex »

TheDong wrote: post #131
chimeracoder wrote: post #98

Earlier quoted context omitted.

> Returned error values are sometimes errors.New (e.g. io.EOF) and sometimes random fmt.Errorf strings that couldn't possibly be handled (e.g. all of tls.go basically), sometimes actual structs (e.g. PathError), This is the advantage of having errors be interfaces rather than concrete values. Once you learn how to use it, it's a strength. The usage of structs that satisfy the interface (as in PathError) is clearly do…

No, the advantage of having an interface is everything can return an error I can typeswitch on. Unfortunately, you can't (in a backwards compatible way) change io.EOF or any of the other 'constant' errors because there's so much code doing 'if err != io.EOF' which now breaks. In addition, it's backwards incompatible due to anyone doing 'reflect.TypeOf' which I guess you could argue is fine to break. Speaking of refle…

I don't know about consistency within the standard library, but NewTimer's behavior definitely sounds consistent with the concept of distinguishing programming errors from exceptional conditions. Passing a negative number as a duration could either be defined behavior (equivalent to zero for programmer convenience and consistency with the principle that timers can fire late) or a programming error (should've checked that whatever you were subtracting to get that duration isn't backwards), but it's not an exceptional condition that can't be predicted in advance. Indeed, checking for a negative number, which is rarely necessary, is no more code than the 'if err' thing, and if it isn't necessary in a particular use of the function, you have the luxury of knowing it can't fail, and you don't need to figure out what will happen if it does.

(I bet you'd be unhappy at Rust irrecoverably panicking the thread for simply performing addition, if the result overflows!)

Re: Go Lang: Comments Are Not Directives

#200

Post by ominous_prime »

andrewchambers wrote: post #184
ominous_prime wrote: post #82

Earlier quoted context omitted.

//#cgo //go:nosplit //go:noescpae are all used by the compiler in one way or another

nosplit and noescape are internal details which are implementation specific.

All of these are implementation specific. That's one reason they're in comments, and not listed in the language spec.
Post reply on HN