Hacker Newsnew | comments | show | ask | jobs | submit | supersillyus's comments login

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.

-----


> So, do you consider the Go1 compatibility guarantee to be a mistake?

No, I think a language basically has to declare that level of compatibility for a major version. The important part is to get as much real-world feedback and iteration in as possible before you bang the 1.0 gong.

-----


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.

-----


Yes, we are working on static analysis and automated refactoring tools. We will make them available publicly when they are ready, but that won't be very soon. We wanted to publicize Context now to encourage people to start using it and incorporating it into new code and frameworks.

-----


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/

-----


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.

-----


That is a pretty serious bug, that is not at all as easy to miss as something like a memory leak is in C/C++.

It is also pretty easy to detect by this (or something better), which might be handy in a big program: http://play.golang.org/p/XmKfgQ4TmS

-----


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.

-----


>>A goroutine count doesn't seem like it'd be useful for diagnosing this in a non-trivial program.

Sure it is, if you are leaking goroutines you will see an every increasing count, even when your app is idle if the count doesn't return to the proper baseline then you know you have a problem.

If you start a goroutine should should have a plan for terminating it. If you don't have a natural way like the life cycle of handling a request then you need to use channels (defer/close are your friends), waitgroups, condition vars etc. I work on some fairly large Go applications and this hasn't been a pain point.

-----


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.

-----


Don't assume -- measure.

-----

More

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: