Linked by Thom Holwerda on Mon 4th Feb 2013 18:41 UTC
Gnome "At the GNOME Developer Experience Hackfest in Brussels, the GNOME developer community has tackled the problem of specifying a canonical development language for writing applications for the GNOME desktop. According to a blog post by Collabora engineer and GNOME developer Travis Reitter, members of the GNOME team are often asked what tools should be used when writing an application for the desktop environment and, up until now, there has been no definitive answer. The team has now apparently decided to standardise on JavaScript for user-facing applications while still recommending C as the language to write system libraries in." Discuss.
Thread beginning with comment 551477
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: That's terrible
by voidlogic on Tue 5th Feb 2013 05:11 UTC in reply to "RE[3]: That's terrible"
voidlogic
Member since:
2005-09-03

If you are talking about a large codebase with significant portions of execution time are in the application itself rather than the libraries used (which in nodes case are C), this is definitely not the case. I have ported node.js applications to Go and it was well worth it.

Also, keep in mind this is a single threaded test, Go scales much better on multiprocessor machines than V8 javascript.

(Also the version of Go used is 1.0.3 rather than tip. I switched to tip for a project yesterday and it had a surprising but appreciated 50% speed-up.)

Edited 2013-02-05 05:13 UTC

Reply Parent Score: 5

RE[5]: That's terrible
by Hiev on Tue 5th Feb 2013 06:05 in reply to "RE[4]: That's terrible"
Hiev Member since:
2005-09-27

Hey, I'm just interpreting the table in the link, that's all, you mean that table is flawed?

Reply Parent Score: 1

RE[6]: That's terrible
by voidlogic on Tue 5th Feb 2013 15:04 in reply to "RE[5]: That's terrible"
voidlogic Member since:
2005-09-03

Hey, I'm just interpreting the table in the link, that's all, you mean that table is flawed?


Well- yes every benchmark is flawed to some degree. ;)
So that is always worth talking about; however, that does not make all benchmarking meaningless.

I was pointing out that:
1. Testing small JS programs that make a lot of library calls ends up being a benchmark of C with a little JS glue and the performance profile changes as a codebase grows and JS comes to represent where a larger percent of where the execution time is spent.

2. The benchmark linked is single threaded (that side has both, but JS data is only bailable to compare single threaded). This is esp. relevant since Go makes writing multithreaded applications easy (so most Go application are multithreaded from the start).

3. I was pointing out that the link is using Go used is 1.0.3 rather than tip. In the Go community tip is highly recommended for performance critical projects. I have seen tip be much faster than 1.0.3.

Reply Parent Score: 4