Live data from Hacker News

Go Lang: Comments Are Not Directives

news.ycombinator.com

211–220 of 222 posts

Re: Go Lang: Comments Are Not Directives

#211
post #205
post #178

Earlier quoted context omitted.

No, it was a question. The statement was asinine. I'm legitimately curious if the comment owner knows who is part of the core team.

> I'm legitimately curious if the comment owner knows who is part of the core team. Yes, I know. And I know perfectly well that Go at its current immature state would never have gotten the kind of attention and consideration if it had not been designed by Mr. Pike. While I believe that many of the warts of Go are by design, some are obviously not.

Tell me then why Go is being used to drive so many big projects? Docker just raised another $95m for fucks sake. Why should I listen to you? What are your qualifications? Sell me on your position.

Re: Go Lang: Comments Are Not Directives

#212
post #38

Although I don't use go (yet), I can see the benefit of this mechanism as I use a similar one for my own c/c++ code. There I use specially tagged comments to embed python in the c/c++ sources, and then run all the code through a python interpret stage to expand/execute the python code before compiling it. Actually it supports C macro style for the embedded code, which is a bit more sensible than misusing code comment…

As long as you're making it seem like C / C++ code, but isn't, and will break if you treat it like C / C++ code, why not actually extend the syntax?

Something like PY_CODE(), for instance. That way it won't compile unless you run it through the preprocessor.

Re: Go Lang: Comments Are Not Directives

#213
post #149
post #65

Earlier quoted context omitted.

It's quite good, but e.g. Java SDK has stuff that runs circles around Go's standard library regarding breadth and maturity, especially stuff added since 1.4 (nio, etc). And some aspects of the Go SKD are horrible in practical use. Case in point, most things math related.

Well, yes. But Java's standard library is also huge and full of deprecated stuff. I have not done a lot of Java programming, but when I did play around with Java, I found myself spending most of the time actually browsing through the standard library's documentation (which is, to be fair, really, really good) looking for stuff. Also, Java has a head start of nearly 15 years on Go, and the Java community is (or used t…

Add an extra 30 years to that. Java's designers didn't history of computer science and language development for the of sake "simplicity". (Generics, error handling, etc.)

Re: Go Lang: Comments Are Not Directives

#214

Earlier quoted context omitted.

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

Just poor, don't make me laugh.

Re: Go Lang: Comments Are Not Directives

#215
post #211
post #205

Earlier quoted context omitted.

> I'm legitimately curious if the comment owner knows who is part of the core team. Yes, I know. And I know perfectly well that Go at its current immature state would never have gotten the kind of attention and consideration if it had not been designed by Mr. Pike. While I believe that many of the warts of Go are by design, some are obviously not.

Tell me then why Go is being used to drive so many big projects? Docker just raised another $95m for fucks sake. Why should I listen to you? What are your qualifications? Sell me on your position.

> Tell me then why Go is being used to drive so many big projects?

False dichotomy. The fact that a language is being used for big projects (or used at all) doesn't mean it has great design. Think of PHP...

I also completely fail to see what Docker's funding has to do with Go's design.

Re: Go Lang: Comments Are Not Directives

#216
post #211

Earlier quoted context omitted.

Tell me then why Go is being used to drive so many big projects? Docker just raised another $95m for fucks sake. Why should I listen to you? What are your qualifications? Sell me on your position.

> Tell me then why Go is being used to drive so many big projects? False dichotomy. The fact that a language is being used for big projects (or used at all) doesn't mean it has great design. Think of PHP... I also completely fail to see what Docker's funding has to do with Go's design.

Good design = it gets shit done. I don't care for PHP syntax, but it gets shit done. Any definition of good design beyond that simple metric is pure masturbation.

Docker is written in Go and $95m is more validation than you'll get in ten lifetimes.

Re: Go Lang: Comments Are Not Directives

#217
post #216

Earlier quoted context omitted.

> Tell me then why Go is being used to drive so many big projects? False dichotomy. The fact that a language is being used for big projects (or used at all) doesn't mean it has great design. Think of PHP... I also completely fail to see what Docker's funding has to do with Go's design.

Good design = it gets shit done. I don't care for PHP syntax, but it gets shit done. Any definition of good design beyond that simple metric is pure masturbation. Docker is written in Go and $95m is more validation than you'll get in ten lifetimes.

Again, that says absolutely nothing about the quality of Go compared to other languages. You can write programs that work in Go, big deal.

Maybe it would have been easier or harder with another language? Who knows.

The valuation has everything to do with Docker's business model and nothing to do with the language they use to implement that vision.

Re: Go Lang: Comments Are Not Directives

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

I guess I agree with you, that from some kind of evolutionary perspective, having yet another language-specific package and dependency management system, this time for Go, might be a good way to boost popularity / uptake of Go. The system doesn't necessarily need to be a good idea, just quick and easy to use.

On the other hand, I think that dependency management isn't really a language specific problem, and it is silly to have different incompatible language-specific solutions for it.

E.g. I work mainly with Python, that has popular python-specific packaging tools, yet those tools cannot express dependencies of python libraries upon e.g. native libraries. The python-specific tools are convenient on a pure-python project, for multi-language projects it feels more like an anti-pattern than a solution, particularly if you end up having to use many different packaging ecosystems / tools.

I think google's approach makes more sense in the context of an organisation where some kind of uniform approach can be imposed, and particularly where there are uniform approaches to code quality / test coverage / continuous integration.

To be clear -- I have never worked at google, this is my external perception.

I have worked somewhere where there are simultaneous software projects with wildly varying levels of code quality / test coverage / continuous integration, this does not seem to agree with very well with the source-control-based "import from HEAD" in one big repository. The organisation is currently transitioning from this approach to more decentralised many-repository approach linked with language specific package management. I do not think this change is a clear improvement, but it does make some things easier.

Re: Go Lang: Comments Are Not Directives

#219
post #216

Earlier quoted context omitted.

Good design = it gets shit done. I don't care for PHP syntax, but it gets shit done. Any definition of good design beyond that simple metric is pure masturbation. Docker is written in Go and $95m is more validation than you'll get in ten lifetimes.

Again, that says absolutely nothing about the quality of Go compared to other languages. You can write programs that work in Go, big deal. Maybe it would have been easier or harder with another language? Who knows. The valuation has everything to do with Docker's business model and nothing to do with the language they use to implement that vision.

So you think that the ability to execute a large project successfully implies nothing about the quality of the tools used to implement the project? I disagree.

At no point have I made a relative statement about Go being better than another language. The only claim I would ever make is that Go is well designed and effective for certain tasks, as demonstrated by use (validated by investment, which we can accept if we assume rational investors -- not going to debate that).

Now the claim that started this was that Go authors are greenfield celebrity programmers and they don't spend their time in the trenches (as indicated by certain parts of the language that some people - usually from "enterprise" languages - don't like; heavily and unapologetically paraphrased). That statement is asinine when you consider the background of the authors and the projects they've been involved in over their collectively lengthy careers.

Re: Go Lang: Comments Are Not Directives

#220
post #24

Earlier quoted context omitted.

And there's //line path/to/file:linenumber and //go:noescape

don't forget //go:nosplit too

And go:linkname, go:nointerface, and go:nowritebarrier You can see the lexer for these here: https://github.com/golang/go/blob/88c08b06b97296e41fc3069f4a...
Post reply on HN