|
I've been using Go at work for some time, mainly coding server-side web stuff. It's not perfect (far from it) but it's so much better than the alternatives, it's a no brainer. We start every new project in Go now and we have long term plans to migrate everything there (from Python, PHP, and Java) Go runs as fast as Java, with a startup time as small as a C executable or Bash script; it's as easy to write as Python / Ruby, if not easier; its standard library is already as good as Python's; and the compiler and standard toolchain is blazing fast and useful. etcetera08 posted:If it had not horrible package management […] I'd recommend it unreservedly. What. If by "package management" you mean the fact that you have to pull all the sources for the libraries you use inside your project's source tree, or use your version control "linked repo" feature, and then it compiles everything down to a static binary that you can deploy anywhere, then I believe Go has the best package management I've ever seen. Otherwise I'm not sure what you mean. Bozart posted:
That looks interesting! I'll make sure to give it a look. After all, relational algebra is what makes databases tolerable. I just wish they had a nicer syntax than SQL. (My idea of a nice syntax is APL, so I know I'm in the minority there.) One note though: I've seen a lot of libraries using empty structs (or their pointers: &Foo{}) as a Go type literal, like Foo.class in Java. The problem with it is that it allocates and zeroes an entire struct of that type for nothing. That could be large, if it contains fixed arrays or other embedded structs. Unfortunately Go does not have a clean type literal that can be passed around, but there is a cheap alternative in the form of a typed nil pointer: pre:(*Foo)(nil) It only takes two words of memory (as interface values do, IIRC) and it's not too verbose. Users of your library may even define their own nil pointers as global vars, to be used as type literals, and that's even easier to write: var FooType *Foo See: http://play.golang.org/p/nom0uJBeDs The fact that it needs two sets of parentheses is another of the many unfortunate choices the Go designers made. See here for an explanation. I wish they had used Pascal syntax. etatoby fucked around with this message at 21:47 on Jul 15, 2014 |
#
¿
Jul 15, 2014 21:44
|
|
|
|
| # ¿ May 3, 2024 13:37 |
|
|
Azazel posted:Not trying to nitpick too hard here, it's clear he was talking about your library. However, "I've seen a lot of libraries using empty structs" is a very general statement, which is the part I was addressing. Feel free to ignore my comment if it does not apply. That quote finished with "…as a Go type literal, like Foo.class in Java." I know empty struct types are useful, for example as method receivers, channel element types, singletons, and so on. What I was ranting about was the amount of libraries that use empty (rather, "zero") struct values as a way to convey type information, like you would use a class literal in Java (MyClass.class) or the class name in Python, and so on. The standard library fortunately avoids it. For example, when the various Unmarshal() methods accept an interface{} value, it's not just used to convey information about its type: it's the actual pointer to a variable that the Unmarshal() method is supposed to fill. good jovi posted:Are you using any of the 3rd party dependency management tools? Or checking in your entire GOPATH? Frankly I haven't even looked into dependency management tools, because to me, the only way to make sure whatever I commit is reproducible is to check every dependency in. If and when I want to update a library, it will be a deliberate action. I will use go get, then I'll make sure that everything still works, update my code as needed, and commit everything into my tree in the correct branch. A consequence of this is that every project (repository) of mine is a GOPATH in its own right, with a src/ dir containing every dependency needed to build the project, alongside my code; a build.sh script in the root, that sets GOPATH (plus other env vars or go/cgo flags) and calls go install; a tpl/ dir for HTML templates; various other dirs for static resources (js, css, img…); more dirs for sources in other languages (sass, coffeescript…); their build or watch scripts in the root; and finally the pkg/ and bin/ dirs created by go install, that I configure my VCS to ignore. Of course, different commits or branches in the history of your project will depend on different versions of various libraries, that's just natural. If you check everything in, then your update/checkout commands will bring your repository into the exact state it was when you made that commit, even if it was years ago. No need to access remote repositories that may no longer exist, have changed names or hosts, their history been rewritten and hashes changed, and so on. Hah! Where is your "dependency management tool" now?  You can even have the go releases in different places (/usr/local/go1.2, go1.3…) and reference the right one in your build script, to be committed alongside the other source changes. In fact, I think I will do just that, starting tomorrow. Perfectly reproducible commits, across all dependencies and language versions, on as many parallel projects and branches as you need, using your favorite VCS and nothing else. I've always considered this to be the Go way, so I'm quite puzzled that people look for "dependency management tools" in the first place. /rant
|
|
#
¿
Jul 16, 2014 19:45
|
|