top | item 7966814

(no title)

emanuelez | 11 years ago

I surely prefer a language that comes with HTML/JSON parsing in the standard library, as opposed as trying to find which library is better implemented, hoping it will keep being maintained.

discuss

order

wtetzner|11 years ago

I can see wanting JSON parsing built-in, but HTML is another problem. There isn't an obvious way to parse broken HTML, and every HTML parser does it differently. When you need to parse some HTML, you need to think about the differences, instead of just choosing the standard library one.

vilhelm_s|11 years ago

HTML5 aims to specify how to parse broken HTML as well (http://www.whatwg.org/specs/web-apps/current-work/multipage/...), and there should ideally not be any differences between different parsers.

The HTML5 specification explicitly asks you to not think about this yourself: "for security reasons, it is imperative that those rules be followed precisely. Differences in how invalid byte sequences are handled can result in, amongst other problems, script injection vulnerabilities ("XSS")".

grey-area|11 years ago

I don't think they have html parsing in the standard library for this reason:

http://golang.org/pkg/

They have HTML templating (which is pretty useful), but AFAIK html parsing is in an experimental module which may never be included in the stdlib because of the reasons you mention, it is over here:

code.google.com/p/go.net/html

But I don't see this mentioned in the rant.

Re the rant linked, it doesn't strike me as very useful or informative. Compile time is a huge issue on many projects, even ones which are relatively simple - I've worked on a few involving C++ and many of them had compile times in the minutes, which was pretty dispiriting and definitely got in the way - on much larger projects of course this is a bigger problem. That golang compiles far faster even on large projects is a definite plus. Bash isn't the only choice at all for systems programming or munging data as he implies, there are lots of other better tools.

Re his call for SIMPLE GUI PROGRAMMING I really can't agree at all - the best ecosystems let the tooling get out of the way, and some of the worst tools make a point of making you click around a confused trainwreck of a UI to perform simple tasks (Apple's Xcode or Eclipse come to mind). That's not progress.

The section on operating systems is similarly wrong-headed; talking about adding a huge number of abstractions (and APIs to go with them), which would lock programmers in to the ecosystem they choose even more completely and be a huge block to cross-platform work. That's a rather dystopian future - I'd rather leave the OS as a collection of badly debugged device drivers (to quote Andreessen), and let other systems build on top of it. There are some really good ideas in unix, and some nice ideas in golang, and the focus on simplicity is not only for the compiler writers, I think that's an incorrect assumption.

It's much easier to denigrate than to actually create, and if the author really cared about any of this, he'd take the time to do something about it, but has he attempted any of the points on his list himself since?