Must be some shit tutorials. The ones I read were great. Did you just take "some-random-guy"'s blog at face value? There's an official Go home-page full of beginner guides.
This is what I've ended up doing, and it still drives me absolutely batty. Typically I'd group together all of the code and assets for a project in one place; any Go code has to exist in this separate namespace for no convincing reason.
It's fine, I can work around it, but it's still quite annoying.
I think I am in the same boat -- Go file layout model seems to be for multiple projects written in Go instead of (my typical case) a multi-language project with a component in Go.
It is not really a big deal, I can overcome it with some simlinks and conventions, but this is not elegant; I hope a model to support this better will be added sometime.
Something I pretty much do and have heard from other Go people that they do this also, is to just keep all my projects in the GOPATH. Whether they be written in Go or not. It essentially gives you an organised structure based on git URLs, so it's always easy to find anything. I use $HOME/go, and have projects in there written in a bunch of languages.
Setting up GOPATH, when _starting_ Go projects, has been one of the top frictions for newcommers. That why Cloudflare came up with a solution: https://github.com/cloudflare/hellogopher.
> Hellogopher: "just clone and make" your conventional Go project
I was frustrated with the directory convention as well. What I did was set up the Go directory structure, and then created a symlink to for my projects directory in the Go directory structure. I was already using a directory convention that followed the GitHub/user/project convention, and it seems to work fine. Use at your own risk :)
It may seem to work fine, but it doesn't. Symlinks are not officially supported by any of the Go tooling. Your setup is working by accident, and may break with any future release.
I saw a comment recently that suggested URL imports are only meant for quick-start, hacky or stuff that won't be deployed somewhere. If you want a given version instead of the tip of master, for example, you're meant to retrieve them separately and set your GOPATH to that directory.
This is called vendorising your dependencies and is done because you can't/shouldn't rely on the third party server being available and serving the same version of the source code to build your code.
But the reason you don't want to mention a third party is precisely because you may want to change that third party.
And if you start maintaining a redirect on a site you control, what happens when you let the domain die because you never use it?
The amount of HN people who have a personal domain listed in their profile that is dead because life got in the way is surprisingly high (including me until recently).
>And if you start maintaining a redirect on a site you control, what happens when you let the domain die because you never use it?
Right. Either you trust that Github or whomever will always be there or you manage your own domain, or you vendorise and put your dependencies in tree. There are benefits and drawbacks to each approach. It's not magic and we're all adults.
New uses of go get will not work, but it's not impossible to work this way. Alternatively, you use find . -name \*.go -exec sed -i 's:github.com/coolpeople/coolpackage:gitlab.com/coolpeople/coolpackage:' {} +`.
About as much extra effort as it's saving the end users (devs) from having to find and download the package in the first place. And you could just tell your users to download from your site and stick it in their gopath, so it's literally just an enhancement over the model you are wanting, just allows an author to spend a few minutes to save every user some time...
And there is literally nothing preventing that from functioning with Go. All you are complaining about is that the central "package repository" doesn't exist yet, where as my point is that Go has given you all the tools to build a central or distributed repository as you choose. You seem to be most upset that people are just using GitHub cause it's free and it works, and how is that different then any other central repository?
URLs are part of package name and there is no guarantee they will survive a repository change unless the package author has taken the effort to use canonical imports.
As for being upset, not really, unless my boss requires me to use Go, I don't plan using it again.
In practice the author rarely changes the import domain/url so it's not really an nuisance. There are tools to fix imports if the unlikely case actually happens. I value the fact that I don't need config files to make it work more than this small possible inconvenience. There is also a `alias` feature in the upcoming version which allows the author to make the transition from one path to another even easier for clients.
https://godoc.org/golang.org/x/tools/refactor/rename
I think it stupid, not merely annoying. In my own projects I have to import "github.com/.." of sibling packages in the same project or go get breaks for my users.
One of the most stupid engineering decisions I've seen in years, imo.
Have you looked at the build system of a C++ project lately? Or a Java project? It's not like that's some super-elegant not-at-all-rolling-catastrophe of a system.
Java and Node, for example, don't solve anything - to get something that builds sensibly they both entirely depend on "external service" being always available and enforcing naming (see the leftpad fiasco). C/C++ are the source of the term "dependency hell".
I've had to deal with CMake as well as automake/autoconf at work recently and I'll take Go's system of fetching/building any day over the Wild West that is the C/C++ eco-system.
You could ask failed kickstarter projects Haunts: The Manse Macabre what the problem is. Just last week I compiled some 25 year old, K&R style C code and it worked. Will any go code compile in 10 years? 1 year?
It is interesting to me that this feature has evoked such passion and feeling. To me it is a few extra characters and easily managed at the top of a file. It generally will take at least one line of code to import some other package or library. It isn't as terse as say C or C++ nor is it as flexible as Python's import system. Of all the things that bother me about a particular language, this just never bubbled to the surface for me.
(Vendoring and package management are different issues)
If you fork a go package with subfolders, you will be in for some trouble. Your fork is still importing the original subpackages, because they are referenced by their absolute (original) address. You don't want to rename the imports in the entire fork because you still want to merge/pull request with the original. So your fork needs to live in a folder that uses the original name, not your fork's name (that local repo will have two remotes, the original and yours). This is a pretty annoying and error prone disconnect, especially for people wanting to use your fork; they need to do the same type of workarounds.
If package `github.com/foo/bar` imports a nested package, say, `github.com/foo/bar/baz`, this will break as it will be trying to look for said package in `$GOPATH/src/github.com/foo/bar/baz`.
1. I know precisely where a package is coming from.
2. When vendored, I know precisely in which directory a package is stored.
3. I actually want to know if a random no-name library is introduced by developers, so I can google it. URL looking import is a nice feature in this case.
Interestingly, the very first thing I've read, that is the environment setup contains instructions that I was told are incorrect by Golang people - one should not use brew to install Golang on macs, one should download the official package. The brew installation, for example, lacks the offline tour package, and who knows what else.
The Golang people could save a lot of headaches and fix whatever they see wrong in the formula so people can continue to use their package manager instead of being reduced to Windows style savagery.
Edit: looks like someone indeed tried to make an issue:
If I understand, the Go team made the binary package install stuff not in the source tarball. That's doesn't sound like a good idea but they're some smart people; I'm sure they have some reasons. T'woud be nice if they helped bring brew in-line as well.
Homebrew is a perfectly acceptable, even preferred way to install Go on Macs. Who has told you otherwise? They are wrong, or are speaking from a very specific context.
I agree that Go makes programming simple, in a matter of less than 6months, I learned how to write a webapp in Go just by using the standard library, later, I wrote a guide to teach how to write webapps in Go without using a framework, using an example based approach
Go is simple for simple tasks that fit Go type system, and yes the single formatting standard and the linting helps with readability.
Go is a pain in the ass for complex tasks that don't fit go type system, like de-serializing polymorphic data or working with XML. But at the end of the day, the lack of polymorphism in the language makes complex things way more complex than they should be. Finally, Go relies way to much on runtime behavior for a statically typed language.
These are quite unsubstantiated claims. Go is used in many a non-trivial program, such as Kubernetes, Docker, Google internal projects, and so on, and the one denominator among these is the plethora of data formats they need to work with.
His claim isn't necessarily wrong, and neither is yours.
I find dynamically-typed languages easier to work with when dealing with (de)serialization, it's just that Go isn't too horrible at that to warrant abandoning it and losing out on its other niceties in favor of a different stack.
I mean, everything sucks at something, and Go's type-system isn't....great....but it's "good enough" to where you just kind of curl your lips in slight disapproval sometimes instead of tearing your hair out.
> "I agree that Go makes programming simple, in a matter of less than 6months, I learned how to write a webapp in Go just by using the standard library"
I've met non-technical people who were able to make a webapp in PHP after 6 days with just the standard library and the O'Reilly Head First book.
So then you have nothing to compare it to, and you can't say that Go made things simpler or faster than if you had started making web apps in say, python.
I had tried my hand with Django and flask, just read the tutorials, and for 6-7 months, I was still reading tutorials, and every 6 months a new version of framework would come up, and I'd be upgrading stuff. I would write views without understanding what they really mean.
Maybe I learned Python webdev in a wrong way, so, compared to that, Gonwas a cakewalk.
So you don't think the background knowledge you gained about web dev in 6-7 months of studying python helped you pick it up faster in Go?
> for 6-7 months, I was still reading tutorials, and every 6 months a new version of framework would come up
So, according to you, the invention of ONE new python framework caused you to rewrite everything you had been working on? What frameworks did you switch between? Why?
Golang is a popular language now, and there are going to be frameworks coming out all the time. There are already lots of Golang webdev frameworks. Imagine if you were starting with Go now, and you learned something like Revel (https://revel.github.io/) before learning how to make web apps with the standard library. Or imagine you spent 6 months learning a framework and then decided to jump to a new one when another one came out.
Also, from perusing the introduction to your Golang book, it seems like you were lacking knowledge of HTTP and other standards. I find that it's very difficult for anyone to learn web development without at least understanding a little bit about HTTP first. Only once you understand how all web development is the same, can you evaluate the ways that different languages do the job of writing HTTP servers.
>So you don't think the background knowledge you gained about web dev in 6-7 months of studying python helped you pick it up faster in Go?
No, the thing is, while I was studying Django, I wasn't learning how to write webapps, I was learning the framework. As I said earlier, I might have gone in the wrong way to learn. I didn't find a book which taught me what I wanted to learn, they all either were too abstract or taught a framework, thus, I started to write my guide, which assumes no background knowledge.
> the invention of ONE new python framework
Did I say that?
>Imagine if you were starting with Go now, and you learned something like Revel
The whole point behind my tutorial was to teach newcomers how to write webapps without using a framework.
> Also, from perusing the introduction to your Golang book, it seems like you were lacking knowledge of HTTP and other standards
I don't claim to know each and every aspect of HTTP and other standards, my book was about the journey I had while learning webdev and Go without using a framework, everyday there are new programmers trying to write webservers in Go, and I felt that there was a need of a book which taught by example.
> Only once you understand how all web development is the same, can you evaluate the ways that different languages do the job of writing HTTP servers.
True, with Go, it was no hassle to write webapps because Go has built in http library and it is a compiled language, thus my shift from Django to Go.
No, not exactly, but you complained that "for 6-7 months, I was still reading tutorials, and every 6 months a new version of framework would come up," can you explain what you meant by this? You say you were learning Django, why did you not stick with that? What new frameworks came out that made you stop learning Django?
> True, with Go, it was no hassle to write webapps because Go has built in http library and it is a compiled language, thus my shift from Django to Go.
See, these are the kind of statements I take issue with. interpreted languages are incredibly popular in web development because of how much easier they are to get started with than compiled languages. Not that I think AOT compilation makes a language bad for web development, but you seem to be asserting that Go is better for web dev and easier to learn because it is compiled and has a built in http library (python has one too! (https://docs.python.org/2/library/httplib.html) and if it's too low level for you, the documentation even points you to the open source requests library, which is the standard in the python community).
> As I said earlier, I might have gone in the wrong way to learn.
Yes, this is the point I'm trying to make. You're comparing apples to oranges when you say that Go makes web development easy to pick up compared to Python when you didn't really try to learn web development in Python, you tried to learn a high level framework without knowing anything about HTTP, a recipe for disaster in Python OR Golang (the point I was trying to make by referencing Revel).
6 months isn't anything. I've been programming in Go professionally for over 6 years and I still learn new things on a regular basis. There's a great essay by Peter Norvig on this subject called Teach Yourself Programming in Ten Years. http://norvig.com/21-days.html
Has anyone noticed an extreme explosion in languages? It seems like a good hobby project to create your own language and then evangelize evangelize evangelize.
I'm all for advancement, but this feels like overload. We have each of the big companies promoting their own languages. Microsoft: C# (and other flavors), Apple: Swift, Google: Go, Mozilla: Rust... I'm sure I could keep going, but that seems to be the trend lately. You can't be a big company and not have your own programming language.
So I guess the language changes for each domain. There is no longer the dream of a single language to unite all the plebes! Maybe it was a dream anyways.
I see what you're saying between Swift, Go, and Rust, but I'm not sure C# belongs in the same category. There are orders of magnitude more real-life lines of code implemented in C# than the other three combined. It's much more comparable to Java.
I think this is the future. There will always be a few main do-anything languages, but we're going to see languages that fit certain use cases becoming very common.
Historically languages were limited by their compilers and VMs. You ran Java or C++ because it took a large company to come up with a fast enough environment. Now we have the tools and experience that anyone can create a fast enough language in a few weeks.
Also historically, if you wanted your code to run faster, the answer was pretty much always to move to a lower level language. Java too slow? Use C++. C++ too slow? Use C and/or optimize choke points with assembly.
The tooling exists now that we can solve a lot of those same hard problems using languages and tools designed to solve them without reinventing the wheel in C or assembly.
I'm all for advancement, but this feels like overload. We have each of the big companies promoting their own languages. Microsoft: Visual Basic, Apple/NeXT: Objective-C, Bell Labs: C and C++, Sun: Java... I'm sure I could keep going, but that seems to be the trend lately. You can't be a big company and not have your own programming language.
True. And it's a beautiful language. I'm not necessarily knocking the other languages either. It's just that it seems that the fragmentation is becoming an issue, when all that development effort doesn't seem to necessarily be generating more value. I'm sure it's possible by all of this experimentation someone will stumble upon the next Javascript, or the next C. So there may be a benefit in the long run. Or maybe not.
It's 2017 and developers are still abbreviating variable names ('err', 'resp', etc. in the article). It's tragic that readability is still not seen as a priority by so many people.
Given that errors and error handling itself is a very normal thing to come across in most projects, would the abbreviated `err` not seem more familiar than defect or fault, to you?
I don't know about other people, but I read symbols not characters, and having those symbols be actual words makes them easier to parse.
In this case, it sounds like resp is commonly used, so that's not necessarily a problem. But in general, if a line is long enough that shaving a few characters off a symbol helps, it probably should be split up regardless.
While I agree readability is key, you may find people who disagree about what constitutes "readable". I think the Go community in particular may be partially inspired by the philosophy outlined under "Variable names" in Rob Pike's "Notes on Programming in C":
"Ah, variable names. Length is not a virtue in a name; clarity of expression is. A global variable rarely used may deserve a long name, maxphysaddr say. An array index used on every line of a loop needn't be named any more elaborately than i. Saying index or elementnumber is more to type (or calls upon your text editor) and obscures the details of the computation. When the variable names are huge, it's harder to see what's going on."
I don't agree with everything written therein, and it was written circa 1989. But in practice single letter variable names are used diligently and frequently in Go, they're convenient and don't break readability if you understand the (simple) convention.
We've learned a lot since 1989. And while clarity is more important than length, clarity has more dimensions than length.
For example, maxphysaddr we now write: max_phys_addr. And when it comes to loop indices, using single letter 'i' isn't practically searchable.
Also, our notion of iterators has progressed in the last 27 (gulp) years. Arrays these days are generally too abstract. There's a reason a block of values has been assembled. If they're pixels or bananas, the index can represent that, e.g. for( banana_idx = 0; banana_idx < bananas.num; banana_idx++ )
This is doubly important in blocks of code where multiple types are used, for example, a uint8_t for one index, a unit16_t for another. They need different variable names anyway, so make name them germane to their function.
"Amount to type" and especially "calls upon your text editor" are irrelevant to clarity.
Maybe it's because I program Go, but I don't find the use of err and resp diminish readability. I don't feel any cognitive hurdle when reading those code examples.
This is actually common convention for Go. One letter variables are used throughout the canonical examples, coupled with very short functions that cause this to make more sense.
Common convention doesn't make it automatically readable.
Every modern language should strive to be user friendly. Gone are the days when we were constrained by hardware limitations which caused us to adopt such practices in the first place.
One letter variable/parameter names is a despicable trend. Abbreviated function names are also rather vile in my eyes.
* err, i, req, resp are so common in a lot of Go codebase that they become a convention themselves. So it's not that hard to read. Another example: Javascript's function(e) {}
* If a name is too long, it impedes readability as well, e.g. SimpleBeanFactoryAwareAspectInstanceFactory.
Andrew Gerrand did a great talk a while back (I'll try to hunt it out) in which he talked about naming conventions. One of the things that stuck out for me, was when he said, if you're declaring a variable that is only going to be used very locally (i.e. within the next few lines or around there), then using a short name is preferred. So instead of 'response', you would simply use 'resp'. However if you're declaring something that may be used in a different part of the file, or Go package itself, go with something more verbose as to not confuse someone seeing it for the first time with no prior context. Also `error` is meaningful in Go, so `err` is used pretty much all the time.
I absolutely love Howistart, but some of their tutorials are getting a little dated. This one uses Go 1.3, whereas 1.8 is now GA, and there has been a lot of progress around vendorizing dependencies.
For those of us who are new to go, can you say a little more about how this might be different if it was updated for 2017? (Or if it is involved, perhaps a link?)
There would be no substantial changes, as this project has little to no interaction with the GOPATH, and doesn't use any dependencies. It's a testament to the stability of the language.
Some things are easier now, like an automatic $GOPATH set to $HOME/go, or the ability of vendoring dependencies so you don't need to worry if companyx.com/project/package no longer exists.
I like to do this for my main Go path (I use per-project ones as needed), since I want ~/bin and ~/src (the former is where all of my personal binaries go, and the latter is where all of my personal source trees go). I guess I don't really mind that there's a ~/pkg — I might mind quite a bit more if I ever used a GUI file manager, but I never do that.
To answer 2) yes, you're correct. If there is a main package that exists at `github.com/your-username/hello`, a go get will leave the resulting binary in $GOPATH/bin.
125 comments
[ 3.4 ms ] story [ 253 ms ] threadsee Github project https://github.com/peterbourgon/how-i-start-go
and Twitter https://twitter.com/How_I_Start/status/506510262909030400
I've never encountered anyone -- both online and offline -- who has had trouble with this beyond "huh, I didn't know I had to do that. Duly noted".
Until now, that is. You are making a mountain out of a molehill ... nay, an anthill.
[0] https://golang.org/doc/install
[1] https://golang.org/doc/code.html
This is the official installation document. If you have problems finding proper tutorials, there is also
https://tour.golang.org
which also links to the previous document on install instructions.
It's fine, I can work around it, but it's still quite annoying.
It is not really a big deal, I can overcome it with some simlinks and conventions, but this is not elegant; I hope a model to support this better will be added sometime.
The convincing reason is that you get several automated behaviors in fetching, installing and building this way.
If you don't care for those, you can use whatever path you like for your code, and a custom makefile for building.
Just don't expect "go build", "go install" etc to work.
> Hellogopher: "just clone and make" your conventional Go project
import "http://www.geocities.com/bla/packagebla"
i.e. I don't want to mention some 3rd party irrelevant company name, and especially its URL in my source code.
And if you start maintaining a redirect on a site you control, what happens when you let the domain die because you never use it?
The amount of HN people who have a personal domain listed in their profile that is dead because life got in the way is surprisingly high (including me until recently).
Right. Either you trust that Github or whomever will always be there or you manage your own domain, or you vendorise and put your dependencies in tree. There are benefits and drawbacks to each approach. It's not magic and we're all adults.
There is no way to avoid doing code changes in order to update the code that was vendored, this assuming that it isn't a binary package to start with.
New uses of go get will not work, but it's not impossible to work this way. Alternatively, you use find . -name \*.go -exec sed -i 's:github.com/coolpeople/coolpackage:gitlab.com/coolpeople/coolpackage:' {} +`.
More about this here https://golang.org/doc/go1.4#canonicalimports
And he/she also don't have do any extra work so that I can keep using the same package names.
As for being upset, not really, unless my boss requires me to use Go, I don't plan using it again.
For me, it means that all dependencies are declared by origin, meaning you don't need to track where they come from , the origin is the import.
One of the most stupid engineering decisions I've seen in years, imo.
Now explain your side.
Java and Node, for example, don't solve anything - to get something that builds sensibly they both entirely depend on "external service" being always available and enforcing naming (see the leftpad fiasco). C/C++ are the source of the term "dependency hell".
https://www.kickstarter.com/projects/2066438441/haunts-the-m...
(Vendoring and package management are different issues)
https://github.com/coreos/etcd/blob/master/lease/leasehttp/h...
What could possibly justify having to use that import line in a sibling package of the same code?
Then don't use a irrelevant company name. Use your own name e.g. rsc.io/pdf . See more here https://golang.org/doc/go1.4#canonicalimports
1) I know exactly where the package came from:
import "geocities.com/bla/packagebla"
vs
import "packagebla"
2) Easy to determine if the package is official, internal, or external (gofmt).
However, what is lacking is a unified vendoring standard. They will address this shortly.
1. I know precisely where a package is coming from.
2. When vendored, I know precisely in which directory a package is stored.
3. I actually want to know if a random no-name library is introduced by developers, so I can google it. URL looking import is a nice feature in this case.
https://github.com/Homebrew/homebrew-core/blob/master/Formul...
This checksum matches the one on the official download page:https://golang.org/dl/
406865f587b44be7092f206d73fc1de252600b79b3cacc587b74b5ef5c623596
The Golang people could save a lot of headaches and fix whatever they see wrong in the formula so people can continue to use their package manager instead of being reduced to Windows style savagery.
Edit: looks like someone indeed tried to make an issue:
https://github.com/Homebrew/homebrew-core/issues/9272
If I understand, the Go team made the binary package install stuff not in the source tarball. That's doesn't sound like a good idea but they're some smart people; I'm sure they have some reasons. T'woud be nice if they helped bring brew in-line as well.
https://github.com/thewhitetulip/web-dev-golang-anti-textboo...
Go is simple for simple tasks that fit Go type system, and yes the single formatting standard and the linting helps with readability.
Go is a pain in the ass for complex tasks that don't fit go type system, like de-serializing polymorphic data or working with XML. But at the end of the day, the lack of polymorphism in the language makes complex things way more complex than they should be. Finally, Go relies way to much on runtime behavior for a statically typed language.
I find dynamically-typed languages easier to work with when dealing with (de)serialization, it's just that Go isn't too horrible at that to warrant abandoning it and losing out on its other niceties in favor of a different stack.
I mean, everything sucks at something, and Go's type-system isn't....great....but it's "good enough" to where you just kind of curl your lips in slight disapproval sometimes instead of tearing your hair out.
I've met non-technical people who were able to make a webapp in PHP after 6 days with just the standard library and the O'Reilly Head First book.
Maybe I learned Python webdev in a wrong way, so, compared to that, Gonwas a cakewalk.
> for 6-7 months, I was still reading tutorials, and every 6 months a new version of framework would come up
So, according to you, the invention of ONE new python framework caused you to rewrite everything you had been working on? What frameworks did you switch between? Why?
Golang is a popular language now, and there are going to be frameworks coming out all the time. There are already lots of Golang webdev frameworks. Imagine if you were starting with Go now, and you learned something like Revel (https://revel.github.io/) before learning how to make web apps with the standard library. Or imagine you spent 6 months learning a framework and then decided to jump to a new one when another one came out.
Also, from perusing the introduction to your Golang book, it seems like you were lacking knowledge of HTTP and other standards. I find that it's very difficult for anyone to learn web development without at least understanding a little bit about HTTP first. Only once you understand how all web development is the same, can you evaluate the ways that different languages do the job of writing HTTP servers.
No, the thing is, while I was studying Django, I wasn't learning how to write webapps, I was learning the framework. As I said earlier, I might have gone in the wrong way to learn. I didn't find a book which taught me what I wanted to learn, they all either were too abstract or taught a framework, thus, I started to write my guide, which assumes no background knowledge.
> the invention of ONE new python framework
Did I say that?
>Imagine if you were starting with Go now, and you learned something like Revel
The whole point behind my tutorial was to teach newcomers how to write webapps without using a framework.
> Also, from perusing the introduction to your Golang book, it seems like you were lacking knowledge of HTTP and other standards
I don't claim to know each and every aspect of HTTP and other standards, my book was about the journey I had while learning webdev and Go without using a framework, everyday there are new programmers trying to write webservers in Go, and I felt that there was a need of a book which taught by example.
> Only once you understand how all web development is the same, can you evaluate the ways that different languages do the job of writing HTTP servers.
True, with Go, it was no hassle to write webapps because Go has built in http library and it is a compiled language, thus my shift from Django to Go.
No, not exactly, but you complained that "for 6-7 months, I was still reading tutorials, and every 6 months a new version of framework would come up," can you explain what you meant by this? You say you were learning Django, why did you not stick with that? What new frameworks came out that made you stop learning Django?
> True, with Go, it was no hassle to write webapps because Go has built in http library and it is a compiled language, thus my shift from Django to Go.
See, these are the kind of statements I take issue with. interpreted languages are incredibly popular in web development because of how much easier they are to get started with than compiled languages. Not that I think AOT compilation makes a language bad for web development, but you seem to be asserting that Go is better for web dev and easier to learn because it is compiled and has a built in http library (python has one too! (https://docs.python.org/2/library/httplib.html) and if it's too low level for you, the documentation even points you to the open source requests library, which is the standard in the python community).
> As I said earlier, I might have gone in the wrong way to learn.
Yes, this is the point I'm trying to make. You're comparing apples to oranges when you say that Go makes web development easy to pick up compared to Python when you didn't really try to learn web development in Python, you tried to learn a high level framework without knowing anything about HTTP, a recipe for disaster in Python OR Golang (the point I was trying to make by referencing Revel).
Either you use query params, or you use a library like gorilla, where you just insert pattern variables into the url.
I'm all for advancement, but this feels like overload. We have each of the big companies promoting their own languages. Microsoft: C# (and other flavors), Apple: Swift, Google: Go, Mozilla: Rust... I'm sure I could keep going, but that seems to be the trend lately. You can't be a big company and not have your own programming language.
So I guess the language changes for each domain. There is no longer the dream of a single language to unite all the plebes! Maybe it was a dream anyways.
F# may be a better comparison.
Historically languages were limited by their compilers and VMs. You ran Java or C++ because it took a large company to come up with a fast enough environment. Now we have the tools and experience that anyone can create a fast enough language in a few weeks.
Also historically, if you wanted your code to run faster, the answer was pretty much always to move to a lower level language. Java too slow? Use C++. C++ too slow? Use C and/or optimize choke points with assembly.
The tooling exists now that we can solve a lot of those same hard problems using languages and tools designed to solve them without reinventing the wheel in C or assembly.
By the way, C# has been around for 17 years.
In this case, it sounds like resp is commonly used, so that's not necessarily a problem. But in general, if a line is long enough that shaving a few characters off a symbol helps, it probably should be split up regardless.
https://www.lysator.liu.se/c/pikestyle.html
Quoting:
"Ah, variable names. Length is not a virtue in a name; clarity of expression is. A global variable rarely used may deserve a long name, maxphysaddr say. An array index used on every line of a loop needn't be named any more elaborately than i. Saying index or elementnumber is more to type (or calls upon your text editor) and obscures the details of the computation. When the variable names are huge, it's harder to see what's going on."
I don't agree with everything written therein, and it was written circa 1989. But in practice single letter variable names are used diligently and frequently in Go, they're convenient and don't break readability if you understand the (simple) convention.
For example, maxphysaddr we now write: max_phys_addr. And when it comes to loop indices, using single letter 'i' isn't practically searchable.
Also, our notion of iterators has progressed in the last 27 (gulp) years. Arrays these days are generally too abstract. There's a reason a block of values has been assembled. If they're pixels or bananas, the index can represent that, e.g. for( banana_idx = 0; banana_idx < bananas.num; banana_idx++ )
This is doubly important in blocks of code where multiple types are used, for example, a uint8_t for one index, a unit16_t for another. They need different variable names anyway, so make name them germane to their function.
"Amount to type" and especially "calls upon your text editor" are irrelevant to clarity.
Every modern language should strive to be user friendly. Gone are the days when we were constrained by hardware limitations which caused us to adopt such practices in the first place.
One letter variable/parameter names is a despicable trend. Abbreviated function names are also rather vile in my eyes.
* err, i, req, resp are so common in a lot of Go codebase that they become a convention themselves. So it's not that hard to read. Another example: Javascript's function(e) {}
* If a name is too long, it impedes readability as well, e.g. SimpleBeanFactoryAwareAspectInstanceFactory.
It's a matter of getting used to, leater it's easy and fast to read.
Abbreviations I can think of right now are: w writer, r reader/request, i, j, k, ctx context, resp response, req request, err error, cli Client
2. in his example, `go get github.com/your-username/hello` also automatically compile the thing into a binary in `$GOPATH/bin`. Is that correct?
A lot more people uses $HOME/go as GOPATH. So much so that $HOME/go is the default in Go 1.8.
Does anyone know of a resource like that? I understand it would be different in on each platform but a fun and interesting read either way.