Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Learning Go as a Node.js Developer #14
@tothandras I think it was intentional. When using the
If you're using
One way to get around this is to make a locally scoped variable, or variables in this case. The other way is to pass the variables in to the function you're invoking.
You also see this pattern used in Go unit tests, where parallel tests are executed. They do it for the same reason.
@tothandras This shadows the iterator variables to prevent access to modified closures inside the goroutines. I would have used different variables names to make it more clear. You can use
@theckman The heck, man? You got me by a few minutes
It's only natural that you're trying to find solutions for problems you encountered in past.
But exploring new technology this way leads to absolutely natural mistakes.
You can forget about this problem while you learn go.
I did the same mistake as you: I thought that channels and messages are similar to Actor pattern in Erlang, Akka.
Don't try to think about
In fact, you need learn
I'd be surprised if someone else hasn't already said this, but I'd say it's better to come to terms with the built in HTTP server before looking at a Framework like Gin.
It's added dependency / overhead and in practice usually not necessary. The built in server is quite mature and production ready.
We personally have production servers fielding several thousand requests per second using the built-in HTTP server.
It's honestly very flexible when you get your head around the interfaces it uses, and for things like more complex routing, CORS, etc – http://www.gorillatoolkit.org/ Gorilla components can be used to supplement rather than replace.
Re: The async Go code
No Go developer would write code like this. Asynchronous calls are useful when you have a limited number of threads in a pool and you want to re-use them while waiting for I/O to come back. Go's internal goroutine scheduler handles this already, so there is no need to complicate your life by writing async code.
It's not async actually, it's sync. Async calls are only needed when you have a limited number of threads. In Node.js you only have one thread, so you are very limited, but even in Java/C#/etc. which typically use thread pools of a small size you are still limited. If you have high throughput (like with a web server) you can end up running out of threads; async solves that problem by returning threads to the pool when they are waiting for I/O.
In Go (and any other system that uses fibers) you are not as limited. You can just fire off goroutines without really worrying. If a goroutine is blocked because it is waiting on I/O, it doesn't matter since you're not wasting a scarce resource and so dealing with the complexity that async introduces is not worth the effort.
Example (Go-ish pseudocode):
Technically you could use promises/futures here, but they are still conceptually weird compared to sync code, especially when you have to start dealing with failure scenarios.