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

181–190 of 222 posts

Re: Go Lang: Comments Are Not Directives

#181

Post by Dewie3 »

chimeracoder wrote: post #98
TheDong wrote: post #75

Earlier quoted context omitted.

Consistent standard library? It's a crapshoot what will be an interface and what will be a struct, which is one of the fundamental features of the language. 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), and sometimes panics. If you can't even get error han…

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

> It's really important to keep in mind that errors are adopted from error values in C, which means that their idioms and usage is inspired by that rather than by exception handling. Many new Go programmers (including me, when I started) were more familiar with exception handling in higher-level languages than error handling in idiomatic C, so it does take some getting used to.

It's also important to keep in mind that people who don't like Go's approach to error handling might not be in favour of the exception-handling way, either. :)

https://news.ycombinator.com/item?id=9439948

Re: Go Lang: Comments Are Not Directives

#182

Post by kbenson »

mpdehaan2 wrote: post #171
kbenson wrote: post #158

Earlier quoted context omitted.

Python's list comprehensions always struck me as an odd way to go given Python's tendency to choose clarity and simplicity over complexity and expressiveness. As a Perl user, Python list comprehensions make me go cross-eyed half the time. It's something Perl specifically decided to forego as too complex and prone to causing confusion, which is saying something.

Nesting them I feel is almost always bad blarg = [ foo(x) for x in y if x > 2] I think is pretty decent. Helps if they are calling named functions, so it's more self documenting, depending on complexity. Dict comprehensions can be a little brain-warping too :)

Yeah, the Perl equivalent of that is:

  my @blarg = map { foo($_) } grep { $_ > 2 } @y;
A bit more verbose, but if you know Perl, obvious (and the same building blocks allow for more powerful constructs[1], since they really are functional code blocks).

You can argue the Python version is clearer, but placement of the conditional always throws me off. I like to think of my transforms as a pipeline.

1: http://en.wikipedia.org/wiki/Schwartzian_transform

Re: Go Lang: Comments Are Not Directives

#183

Post by tomjakubowski »

Ygg2 wrote: post #102
bane wrote: post #76

As soon as you start using comments for something other than comments or documentation, you've basically admitted the language is broken and you end up becoming Java.

Funny that you mention it, but Rust also checks all code in comments/documentation for validity, and runs test on your comments and catches if any of them fails to compile/return appropriate result.

No it doesn't. Rustdoc examines the "doc" attribute on every item for Markdowk code blocks and checks those. The "doc" attribute can be attached to an item directly, using Rust's general attribute syntax, or using so-called "doc comments" which are visually and lexically distinct from ordinary comments. In the case of single line comments (the preferred style), doc comments have three slashes instead of two; a good IDE or editor mode for Rust will highlight doc comments differently than ordinary ones.

Re: Go Lang: Comments Are Not Directives

#184

Post by andrewchambers »

ominous_prime wrote: post #82
andrewchambers wrote: post #59

Earlier quoted context omitted.

They aren't used by the compiler at all.

//#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.

Re: Go Lang: Comments Are Not Directives

#185

Post by andrewchambers »

nevergo wrote: post #112
andrewchambers wrote: post #58

Earlier quoted context omitted.

Go has the best and most consistent std library I have seen.

Go has the poorest std lib I've ever seen.

Compared with? My reference point is python,java,clojure,c,c++. Python is huge and useful but messy and inconsistent. Java is huge and doesn't compose well. Clojure is underdocmented and hardly batteries included. C and C++ can't do anything useful without a bunch of extra libraries. From what I can see, C# is like java in this regard.

Go is a small incredibly useful and composable set of libraries that handles a vast amount of cases with a small amount of code.

Re: Go Lang: Comments Are Not Directives

#186

Post by jmgao »

zaphar wrote: post #103
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. 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…

Does go even have a usable debugger yet?

Re: Go Lang: Comments Are Not Directives

#187

Post by tomjen3 »

zaphar wrote: post #169
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.

For the record I don't think you deserve to be downvoted like this. You stated a valid opinion. Go is not meeting a need you have and thus the value proposition for you is not the same as mine. This appears to be a case of people downvoting because they disagree not due to the quality of your comment.

Thanks, but don't worry. I should have known better than attacking peoples choice of editors.

Re: Go Lang: Comments Are Not Directives

#188

Post by mattkrea »

kevingadd wrote: post #115
mattkrea wrote: post #86

Earlier quoted context omitted.

Reminds me of typescript ///

/// is metadata/docstrings - it's a convention from C#. So a /// block is parsed by the compiler and tooling (to generate documentation xml files, for example), while a // comment is not parsed at all, just stripped.

Gotcha. Although most of the guys I see use the /// stuff as comments in the real world I guess I can see the difference.

Re: Go Lang: Comments Are Not Directives

#189

Post by tomjen3 »

fixermark wrote: post #137
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.

That's the point---rather than create a tooling ecosystem that forces a particular IDE choice upon developers, Go is aiming for a set of minimally-sufficiently-powerful tools that IDEs can hook into. Learning an IDE isn't a big deal, but it isn't, say, preferable to not having to learn one. I know Eclipse, but I avoid using it in all contexts where I can---it's slow, its project model borders on filesystem hostility…

>Learning an IDE isn't a big deal, but it isn't, say, preferable to not having to learn one.

Everything else being equal, perhaps you are right. However by blessing one as the official editor the tools can be written to work with that rather than the lowest common denominator. This will make it more difficult for alternatives which is a cost, but I do believe the upside is worth it - unfortunately I can't prove it.

Re: Go Lang: Comments Are Not Directives

#190

Post by zaphar »

jmgao wrote: post #186
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…

Does go even have a usable debugger yet?

Depends on your definition I guess. I don't debug that often but when I have had to I've found the GDB debugger to be good enough for my purposes.
Post reply on HN