Hacker News Reader

Comment by berntb | Hacker News Reader

The feature with scripting languages compared with system languages (C, Java, etc) is that they are fast -- not to run code, but to develop functionality.

The article argued that idiomatic Go gave at least as good runtime speedup as a normal scripting language (Perl, Ruby, etc) with the (small) time critical parts rewritten in C.

But it didn't touch the important question -- is the development time for Go faster than for scripting languages with critical sections in C?

Go looks fun, but I'd personally want information on that metric before trying it on a project. [Edit: Yeah, as the article noted, Go excels re parallelization etc. I might Go for it in those use cases.]

(What I'd really want is to find a place which use Lisp, since development speed is roughly as fast as for scripting languages and there has been good compilers for decades.)

Edit: Spelling, must start going over the room for the keyboard when using the iPad.

View on HN

> But it didn't touch the important question -- is the development time for Go faster than for scripting languages with critical sections in C?

At YouTube (which is a predominantly Python shop) we use Go for some elements of our infrastructure, and I spend approximately half of my time working in each language (main project in Go, integration tests in Python). In my experience easy things (say, split and massage some strings) are more complicated/annoying in Go than in Python (and much more verbose). However, difficult things usually end up being much simpler in Go than in Python – especially if they involve concurrency (Python threading is a trainwreck). The difficult parts of our code consume most of our brainpower, so that's a net gain from our point of view. What is more, for some weird reason Go code seems to be less susceptible to bitrot (go fmt FTW).

Even string splitting in Go isn't that bad, frankly.

    words := strings.Split(wordList, " ")
    foo := words[0]
    if len(words) > 1 {
      bar := words[1]
    }

Where things can get a bit tedious is data conversion from byte buffers, like reading in data from disk or Redis or something. But that's no different from any other statically-typed language.

I would like to see more libraries in Go, though. Much of what's complex is there, but one of the benefits of languages like Python and Ruby is there are lots of libraries for the easy stuff, too. Having to write a data model validation library yourself is boring.

I see this as a devtime-runtime tradeoff, If you follow the link to the mentioned article [1] there is some discussion about how to improve on this tradeoff.

FWIW: I use C for many of my personal projects as I often enjoy solving problems at that level, however at my job I am 90% Perl with the other 10% being various web things (css, js, html, etc.).

I too would be very interested in articles looking at performance of some of the older dynamic languages.

[1] https://speakerdeck.com/alex/why-python-ruby-and-javascript-...

Well, partly. The argument re scripting language + C is that mostly, the run time is in a small part of the code. Measure to find that part (NYTProf etc for Perl), then rewrite it in C. (I.e. inner loops, not reading config files.) The inefficiency of scripting languages is then irrelevant for many use cases which don't even involve databases.

My experiences of using Lisp compilers is very much out of date, I never saw any Lisp jobs I wanted after university.

Edit: Clarity

> But it didn't touch the important question -- is the development time for Go faster than for scripting languages with critical sections in C?

"Writing critical sections in C" is a terrible cop-out of the Python community, by which they try to make the engineer do the compiler/VM's job.

Compare:

1) Write algorithmically efficient code.

2) Profile for hotspots.

3) Lift out the hotspots by rewriting them in C.

4) Repeat throughout the lifetime of your project.

Versus:

1) Write algorithmically efficient code.

2) There's no step two.

What winds up happening is that A) nobody does steps 1-4 with any regularity, and B) The bar at which a C rewrite is set very high, while Python is very slow across the board. The whole system winds up slow in aggregate, with only a few hotspots optimized, if any.

"But he didn't touch the important question -- is the development time for Go faster than for scripting languages + C?"

That is a good question, but- Isn't that going to vary a lot by the person/team involved? Calculating "effort" is far more difficult than run-time or complexity characteristics.

Doesn't that question also assume that people writing in the scripting language can write (correct/decent/secure) C. Ironically, I have a strong feeling that many more Go developers can write C than say Ruby or PHP devs.

>>Calculating "effort" is far more difficult than run-time or complexity characteristics.

If it really was impossible to measure development/support speed, then we'd still use hex code with switches on a console. :-)

And yeah, kids today often don't learn C at school, it is a pity.

"If it really was impossible to measure development/support speed, then we'd still use hex code with switches on a console. :-)"

Of course it can be quantified. Some people use gzipped source code size to approximate this. I just meant that this is more subjective, has more variables and sometimes must be decided per organization or team.

"And yeah, kids today often don't learn C at school, it is a pity."

Most C-S programs I have interacted with still teach C, but yes that is a problem. I was more thinking of the "too cool for school" portion of the startup crowd, those who learn only learn scripting languages, etc

Actually I think it is even worse than that.

I would say "kids today often don't learn about compiler design and computer language's history".

Given my CS background, it baffles me how languages get mixed with implementations or language runtimes with VMs in current discussions.

I started coding in the mid-80s, we lacked the information access kids have nowadays with Internet, and yet most of us were quite aware what language design was all about.

Yeah, I've been enjoying using Clojure for this reason. The strengths of the JVM and Java libraries with the development time and functional style of a Lisp.

The crop of interesting languages on top of the JVM is intriguing. My Java experience is very much out-of-date, so I haven't looked at those much.

Reply on news.ycombinator.com