Most gasoline cars will get pretty low on gas with a full day on the track. I track and usually end up topping up some after lunch. Most tracks have gas there, and charge like $6-8/gal.
Often with Tesla, year people leave at lunch to go to the nearest supercharger. If tracks added some fast DC chargers, it would be a nice boost.
Derek's hashmap was faster than than Go 1.0's built in hashmap. With Go 1.1 or 1.1.1 (don't remember which one exactly), the standard one did become faster, though Derek had decided to stick with it as is. I can ask him what the reason was... I don't recall right now.
I think I may know why they are sticking with the self-built version: random key selection. The built-in hash map doesn't include a method to discover a random key, but the gnatsd hashmap does.
I hadn't looked at that issue before, but have definitely been bit by it.
On our main codebase, we experienced some major issues when moving from Go 1.0 to 1.1 from this exact issue. We had a goroutine that was doing some remote calls wrapped with a timeout, and the call was consistently timing out even though the remote service was perfectly fine (it was another service on the same box).
We found the cause was another goroutine running something in an for loop that didn't do anything that would allow a pause in execution for another goroutine. So, the scheduler just obsessed on that goroutine, running none of the others until that one was done, and by then the timeout on the remote call had expired.
We fixed up that case, but also found a few others were we simply added a very small sleep call... for no other reason than allowing the scheduler to evaluate other goroutines. Meh. It made sense when we finally tracked it down, but was one of those things where we had to pause and ask "really?"... and adding a sleep call with comments "yes, I am really calling sleep".
While it would be nice if the programmer never had to worry about this situation in the first place, when confronted with something like this I use runtime.Gosched() rather than a sleep call to yield. It more directly performs what you're attempting to do and is much more clearly self-documenting for situations where you really don't need to sleep for whatever period of time but do need to yield.
I hadn't seen runtime.Gosched() before, will take another look at it. Mentioned it to a coworker and they already knew of it, so maybe it was always switched to call it instead of sleep. :)
I had what I think was a related problem with file descriptor retention in timeouted socket code when writing a simple portscanner in Golang; I had to implement simple time-based flow control to give the runtime time to collect file descriptors, or I'd run out of them.
If you use Go's time.Sleep(), the goroutine will yield to all other goroutines while it is sleeping. Unfortunately, as georgemcbay says, using the system's sleep impedes Go's runtime as it cannot use that thread to run any goroutines in that time.
But yeah, I would say that is one of the quirks of Go at this time. You definitely need to be aware of how the scheduler works if you're using it in production.
This doesn't make a whole lot of sense to me. As long as you have GOMAXPROCS set > 1 this shouldn't happen, right? Go doesn't make a secret about only supporting cooperative multitasking above the OS thread level. Are you saying that one spinning thread was locking up all the others?
EDIT: Okay, saw your reply below. Just to reiterate, Erlang has to make a lot of throughput compromises to support pre-emptive multitasking. Just being compiled pretty much takes Go out of that conversation entirely. I'm happy with the tradeoffs for the kinds of things I need to do. And you can always set GOMAXPROCS to a _multiple_ of the number of cores on your machine to get OS-managed pre-empting.
The remote package importing is quiet easy to work around and to lock on things. It actually forces you to think about the process and tracking more. But also, dismissing Go solely because if that doesnt do it justice. Same as any language...
We didn't write our own HTTP server, but rather a framework that sits on top of it and makes it easier to use.
The logging library is quite unlike anything else we're aware of, and the goals of it were language independent. The author of it is giving a talk about the library and our experiences with Go at GlueCon next month.
The ORM is the one which is more a result of what we wanted not being represented by existing libraries, and the community being still smaller compared to Node.
However, with all those still considered, we've gained a lot of velocity with Go, better concurrency without doing full async development, etc. Personally, I've hated testing async code in the past with both Node and EM+Ruby.
The timeframe referenced the length of the discussion of the two, not the knowledge the decision was based on. Several of us had previous experience with Node, and some of the team had prior Go experience.
"my fellow co-founder who just happens to have a lot more experience in the field of hacking and getting hacked"
I see irony in the "getting hacked" part. But seriously, if he is more experienced, then why do they have machines unpatched like that for 6 months?
"it seems it was indeed a kid who did not understand how to install a proper rootkit and cover up his tracks"
It is rather bold to be posting about how you just got hacked by not applying simple patches, and to then bash the "kid" who couldn't install a proper rootkit.
That is indeed the case - both players in this match were not careful. We are open about our shortcomings and also think that the other player was not too careful to say the least ...
Often with Tesla, year people leave at lunch to go to the nearest supercharger. If tracks added some fast DC chargers, it would be a nice boost.