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.
Go Lang: Comments Are Not Directives
211–220 of 222 posts
Re: Go Lang: Comments Are Not Directives
#212Although 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…
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
#213Earlier 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…
Re: Go Lang: Comments Are Not Directives
#214Earlier 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…
Re: Go Lang: Comments Are Not Directives
#215Earlier 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.
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
#216Earlier 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.
Docker is written in Go and $95m is more validation than you'll get in ten lifetimes.
Re: Go Lang: Comments Are Not Directives
#217Earlier 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.
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
#218Earlier 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…
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
#219Earlier 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.
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
#220Earlier quoted context omitted.
And there's //line path/to/file:linenumber and //go:noescape
don't forget //go:nosplit too