supersillyus

7 ms·

1.
by supersillyus 12y ago
IIRC Servo is using html5ever for HTML parsing, which (at least in one branch) uses SSE4.2 for parsing.
2.
by supersillyus 12y ago
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 ab
3.
by supersillyus 12y ago
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 lang
4.
by supersillyus 12y ago
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
5.
by supersillyus 12y ago
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.
6.
by supersillyus 13y ago
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
7.
by supersillyus 13y ago
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/
8.
by supersillyus 13y ago
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
9.
by supersillyus 13y ago
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.
10.
by supersillyus 13y ago
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
11.
by supersillyus 14y ago
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.
12.
by supersillyus 14y ago
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) l
13.
by supersillyus 14y ago
If you don't care about types, schemas, and schema changes, probably not.
14.
by supersillyus 14y ago
Also, segmented stacks ( http://llvm.org/releases/3.0/docs/SegmentedStacks.html ). GCC already supports it.
15.
by supersillyus 14y ago
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 disc
16.
by supersillyus 14y ago
Does the answer here make sense to you?: http://golang.org/doc/go_faq.html#creating_a_new_language
17.
by supersillyus 14y ago
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 monit
18.
by supersillyus 14y ago
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 c
19.
by supersillyus 14y ago
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 a
20.
by supersillyus 14y ago
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 expl
21.
by supersillyus 14y ago
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
22.
by supersillyus 14y ago
For comparison, what do the automatically generated XML versions of those JSON examples look like?
23.
by supersillyus 14y ago
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 le
24.
by supersillyus 14y ago
Would the comparison be more fair if the Python/Dart code were mapping the JSON to an existing type?
25.
by supersillyus 14y ago
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
26.
by supersillyus 14y ago
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.
27.
by supersillyus 15y ago
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?
28.
by supersillyus 15y ago
Pretty sure that's not actually Matt Cutts.
29.
by supersillyus 15y ago
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.
30.
by supersillyus 15y ago
Somehow, I both don't quite understand what he's trying to say and strongly agree.

More ›