supersillyus

IIRC Servo is using html5ever for HTML parsing, which (at least in one branch) uses SSE4.2 for parsing.

So, do you consider the Go1 compatibility guarantee to be a mistake? Most suggested stdlib or lang improvements are DOA for the time being as a result, which is annoying, but of course so too would be frequent breakages. I'm curious about your take, since you have some relevant experience.

I read that they have static analysis tools to track the flow of Contexts, making it much easier to verify that Contexts are threaded through correctly, which can make things a bit safer statically. It seems Go-like I guess: instead of language support for that sort of type system, simple enough lang and good enough tooling to implement the analysis externally.

From that, it's not too hard how people could think it was influenced by Go (though it apparently wasn't): http://play.golang.org/p/oWNRd0D2Zp looks superficially very similar

There is a GSOC to add escape analysis (https://www.google-melange.com/gsoc/project/details/google/g...). It'll be interesting to see how that affects things.

Yes, in the same sense that any language with first class functions can.

So, like:

   var SomeFunc = RequireAuth(func(...) {
        ...
   });

However, there's no language-level support, so you can't decorate methods as easily as you might in a language like Python.

If I'm not mistaken, Plan9 comes with a code formatter, and this idiom is common in Plan9, so it seems likely that it is supported. http://plan9.bell-labs.com/sources/plan9/sys/src/cmd/cb/

I somewhat disagree. Even if you don't use channels as iterators/generators (which many folks do), it's not hard to end up with a goroutine blocked on a channel that'll never be closed/written to, and this situation (like memory leaks) can result from changes elsewhere in the program or branches not normally taken. A goroutine count doesn't seem like it'd be useful for diagnosing this in a non-trivial program. The runtime could probably detect if there are goroutines blocked on channels that no other goroutine has access to, and that'd be quite helpful for debugging, but as of now it doesn't. Even if it did, it couldn't catch all goroutine leaks.

You can leak memory by leaking goroutines. If a goroutine is waiting on a channel that nobody else has access to, it lives forever, as does the memory it references.

So, you can pretty easily leak memory without messing with unsafe things.

According to Last Call by Daniel Okrent, Gough St was named after famed temperance orator John Bartholomew Gough. I'd assumed that was true until I saw this site. Wikipedia has support for both theories, but it looks like Charles H was the real namesake.

Why should C and Go (AOT compiled) be faster than Java for pure integer numerics? For long-running simple tight loops of numerics, I'd assume HotSpot would be faster.

I agree with them on the readability issue mostly, but I don't understand the preference for parens-less function calls, especially where there are arguments.

Maybe it's a matter of training, but

   @_update_status_position(e, files)

looks much clearer to me than

   @_update_status_position e, files

If you don't care about types, schemas, and schema changes, probably not.

Also, segmented stacks (http://llvm.org/releases/3.0/docs/SegmentedStacks.html). GCC already supports it.

My "ah ha" moment with Haskell was after a few years of using it quite regularly, I realized that it wasn't actually making me more productive in the kind of code I actually write from day-to-day. It's a lovely language and I wouldn't discourage anyone from using it, but for my purposes I realized it was more exciting than useful at some point, and after that I haven't been back to it as much.

Does the answer here make sense to you?: http://golang.org/doc/go_faq.html#creating_a_new_language

I don't think the spike in VM means it's paging all that. That just means it has that address space reserved, not that it's using it. I'm not aware of any real cost to having a huge pile of address space reserved, aside from that some monitoring utilities will penalize you for it (unreasonably). So, no, I don't think it'll slow anything down by thrashing, unless the locality of the memory it is accessing is really bad, but I'm no expert on Linux virtual memory or how Go uses it.

It doesn't sound like you're using the benchmarking tools that Go provides; I'd recommend using that if you're not.

Ah, yeah, I was testing a much much smaller byte array with multiple split points. I'm not terribly surprised that in your case you've found the hand-coded byte version to be faster (though the difference is more than I would've guessed; care to post the code?) However, I'm still not sure it's merited in the standard library. Split() could pretty easily be further specialized to basically call your single byte implementation or equivalent at the cost of a handful of instructions per call. Alternately, if you know you're dealing with very large byte slices with only a few split points, it is only a couple lines of code to write a specialized version that is tuned for that. The same argument could be make for IndexByte, but I'd claim that IndexByte is a much more fundamental operation in which one more often has need for a hand-tuned assembly implementation. I wouldn't say the same for Split. There's a benefit to having fewer speed-specialized standard library calls, and I don't think splitting on a byte with performance as a primary concern happens often enough to merit another way to split on a byte in the standard library. But I'm certain that reasonable people who are smarter than me would disagree.

For what it's worth, I've looked into the 'Split' case, and the performance difference when specialized to the single-byte case is about 2%, which is mostly because Split already has built-in specialization for the single-byte case, which amounts to a couple extra instructions in a function whose running time is dominated by allocation.

I think they made the right choice there; the Go team seems very good about optimizing only where it matters; there's lots of low hanging fruit, but the majority of it isn't very useful fruit.

It is quite neat and mighty convenient, but I sorta live in fear that at some arbitrary point the library will change and my code will just stop working. I konw this isn't a problem unique to Go and there are solutions, but the lack of explicit versioning makes me nervous. Then again, it hasn't bit me yet, and I certainly have benefitted from the ease.

FYI, the original article has been updated with graphs showing reqs/sec, virtual, and real memory for both using 100, 500, and 1000 simultaneous requests. Aside from virtual memory (do we care about that?) it seems to show Go as continuing to perform better.

For comparison, what do the automatically generated XML versions of those JSON examples look like?

It certainly could be more optimized. For example, all numeric literals are converted to strings before being parsed. That's a mostly unnecessary copy/allocation per number. Similarly, it doesn't make use of the fact that a []T can only legally contain Ts. It's all very clean and generic, which is great, because when working on the compiler they can work on making good code faster without being mislead by code that tries to work around lack of optimizations. As an experiment, I replaced the []int in the Go code in the link with an IntList that implements json.Unmarshaler, and does a single-pass integer list parsing there (without overflow checking, but eh). With that quick 40 line change, the Go code was faster than the CPython, at least on my machine.

That and similar type-specific handling could be built into the json package fairly easily, and would make those cases quite a bit faster. Then again, I bet the Go team would have a better and more general idea.

Would the comparison be more fair if the Python/Dart code were mapping the JSON to an existing type?

I've written a few relatively small (a few K LOC) Go projects, and my experience has been quite positive. The libraries are really well designed and impressively complete. With goroutines and the fact that most things work with io.Reader/io.Writer, plugging different components together and having them work efficiently is pretty easy. I love gofmt (sweet sweet consistency), and despite some early reservations, I'm quite happy with what the go tool provides. The couple servers I have written in Go have been great, in that they were pretty easy to write in a straightforward way, and they ended up impressively fast. The speed is actually somewhat seductive; I've been unnecessarily microoptimizing some things, just because I see what sort of speed is possible without leaving the language. I also find that due to gofmt, the constraints of the language, and the aesthetic leadership of the Go team (along with, likely, a self-selection in those writing Go right now), third party Go libraries are very readable. When I'm trying to understand a data structure or a protocol, I often look for source code; python used to be my preference, but in part thanks to types, I now find Go to be my first choice.

I do wish the Thrift support was as good as the protocol buffer support, though. :)

I believe it could be faster still. Their Itoa cache is a map[int]string, where it could be a []string. Also, I suspect that a few more primitive type special cases in the first type switch in EncodeField could go a long way.

From https://www.dropbox.com/terms:

"You retain full ownership to your stuff. We don’t claim any ownership to any of it."

Or am I missing something?

Pretty sure that's not actually Matt Cutts.

Does anyone have a link to some examples of non-trivial Rust programs? It looks like a pretty neat language (despite making a few more distinctions than I tend to care about), but I'd like to see how it reads in practice.

Somehow, I both don't quite understand what he's trying to say and strongly agree.