Would you mind also posting the network tuning parameters you're using
along with the os? I know that when I do perf testing for go on linux, I
typically need to update a number of tcp related kernel parameters before I
get meaningful numbers.
M
--
You received this message because you are
Can you describe what task it is that needs to be updated every
microsecond? It seems like there should be a better to resolve the
underlying need.
M
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop
I’m not sure how an interface doesn’t satisfy what you’re looking for. Can you
describe your use case in a little more detail?
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it,
Given that text and html templates are separate calls anyways, why not just
make separate calls for your custom funcmap? For example:
package template
import (
html "html/template"
text "text/template"
)
func Html(name string, fm html.FuncMap) *html.Template {
return
https://github.com/savaki/nats-proxy
http in the front; NATS in the back
nats-proxy provides an HTTP gateway that simplifies service discovery by
using NATS as the transport layer between services.
client --[http]--> gateway --[nats]--> service
*Start the API Gateway*
// Start the Gateway
Before writing github.com/savaki/swag, I gave goswagger a try. I think
goswagger is a fantastic library with lots of useful features. However,
for my own use, I found things like:
var findTodos = runtime.OperationHandlerFunc(func(params interface{})
(interface{}, error) {
If you're just starting out the project, by all means start with the
monolith where everything is together. If you decide it's necessary, over
time you can split out the project into what you've discovered you need.
Trying to abstract the components you think you'll need too early is a good
Goroutines are conceptually very similar to threads, but much lighter weight.
They are far cheaper than system threads to run. It's not uncommon for go apps
to have 50k or more goroutines running.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts"
I think I have to agree with most of the posters here about generics. In
theory, I miss them. However, in practice, I find that there are usually
only a few times during the course of a project where I wish I had
generics. And then after writing a few lines of code to do what the
generic
