41–50 of 124 posts
So does Go's net/http module really provide basically exactly the same programming model as Node? If so, why use Node? One thing the author didn't mention is that Go will use multiple cores in this example, whereas Node is single-threaded. Right?
Earlier quoted context omitted.
npm is awesome, this direct import doesn't seem like a feature, more like a lack of a feature.
It works very well for me. If I want someone to install a Go program I've developed, in Ubuntu 12.04 they can just: $ sudo apt-get install golang $ go get github.com/pauek/garzon/grz That's it, and it takes a few seconds.
If Go adds some method to specify a tagged version that could be pretty nice though.
I hope it goes without saying that there's no way this kind of hack (neat as it is) is a substitute for a proper package management system like npm (which is a very good package manager).
Earlier quoted context omitted.
'npm' is covered by the Go tools themselves. You can import packages using their github/bitbucket/code.google.com URL.
That is really interesting. Thanks for pointing that out. Can you specify specific version dependencies like you do with a full-blown package manager?
Earlier quoted context omitted.
'npm' is covered by the Go tools themselves. You can import packages using their github/bitbucket/code.google.com URL.
That is really interesting. Thanks for pointing that out. Can you specify specific version dependencies like you do with a full-blown package manager?
I'm sure the reason why users pick node is probably similar reasons why one picks ruby/python -- it's not for the speed. The language of the web is javascript. Until web browsers allow Go as the embeddable language, node will remain useful. I seriously doubt people would pick Go over node because of a micro-benchmark.
You can compile Go to js with gwt. You can reuse code that way. I personally even reuse Java code between Android, front end Web and server. Because of gwt. I don't think there are many people who choose js because they like it. It's usually because they feel forced. Javascript is a terrible language, I always prefer one of the compilers. Dart can't come fast enough.
Is there a separate branch/fork of GWT with Go support? That would be absolutely awesome in fact but it doesn't seem to be true.
Choosing Node.JS isn't just a performance / scaling decision for me -- one of the main draws to Node is the huge community and wealth of awesome modules. Socket.io, Now.js, cradle, redis, and dozens of other modules abstract away the tedious work and let me build functionality _really_ fast. Go is really promising but it won't win over the majority of casual developers until there's a community around it. I might as…
Really? In my experience, all but the most mature modules are hardly beta-quality and in constant flux. Find a good module for your job? Too bad it only runs on 0.4. Find another to get around that; oops, too bad your version of gcc needs to be patched and re-built. The language and its entire package ecosystem is so immature, I'm blown away people trust it in production at all.
"So fix it and submit a Pull Request," you say? That doesn't help me when I'm trying to deliver on a deadline. I love contributing, but I often have more pressing things on my plate.
Earlier quoted context omitted.
If I wanted a specific tag or release, I would just download that revision in the GOPATH directories, and refer to the package directly, instead of through the github URL.
Kind of a clunky way to handle versioning though. In Lein (for example), adding [noir "1.2.0"] ensures I'm always grabbing the same version. In Go, appears the only way to guarantee this is to check in the full source of the library alongside your own in your repo.
{deps, [
{quoted, "1.0.3",
{git, "git://git.corp.smarkets.com/quoted.erl.git", {tag, "1.0.3"}}},
{proper, ".*",
{git, "git://git.corp.smarkets.com/proper.git", {branch, "master"}}}
]}.Earlier quoted context omitted.
Why not validate on both? Validate on the client to give a nicer and quicker notice if something is wrong (good UX) and then validate on the server for actual security.
To avoid a split-brain validation scenario. Update your model? Don't forget to update your validation in both the client and server. Otherwise, you'll validate something on the client but not the server (bad UX), invalidate something on the client but not the server (bad UX), or corrupt your data slowly when validation entirely fails (bad UX). Since it's a pain in the ass to remember to update two places when you mak…
Earlier quoted context omitted.
Why not validate on both? Validate on the client to give a nicer and quicker notice if something is wrong (good UX) and then validate on the server for actual security.
To avoid a split-brain validation scenario. Update your model? Don't forget to update your validation in both the client and server. Otherwise, you'll validate something on the client but not the server (bad UX), invalidate something on the client but not the server (bad UX), or corrupt your data slowly when validation entirely fails (bad UX). Since it's a pain in the ass to remember to update two places when you mak…