Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Faster Command Line Tools in D

dlang.org

Post reply on HN
Print view View original

61–70 of 100 posts

Re: Faster Command Line Tools in D

#61

Post by nemo1618 »

penpapersw wrote: post #12
mhh__ wrote: post #5

Earlier quoted context omitted.

The answer is fairly obvious: dlang is a nicer language, by design. Go isn't meant to be particularly impressive on the language design/innovation front.

Honest question: what strengths does Go have over D? I became very proficient at Go several years ago, and was reading about D for hours and hours last night, and it looks like D is overall a much better language.

Simplicity and consistency is the biggest strength of Go. D is a complicated language with a ton of features. That makes it harder to learn, and it makes it more likely that you'll encounter "cleverness" in other people's code.

As a tiny nit, it's interesting to compare D's `out` keyword to Go's multiple return values. An `out` keyword seems like a prime example of "thinking in blub."

Re: Faster Command Line Tools in D

#62

Post by ajbonkoski »

I don't get articles like this.. they seem to miss the bigger point.

Typically there are two modes in my computing: (1) Scripting / Command-line get stuff done and throw-away, and (2) Serious applications that are heavily used, need to process lots of data and be as fast as possible (e.g. processing millions of files like this one where the algorithm constant factor really matters).

In case 1: Hack something together with shell or python and get an answer. If it takes 100-1000x of the equivalent C program, than fine..

In case 2: Custom special purpose C or C++ code

I really don't understand the middle ground here. The equivalent C version that does the same job runs in ~250 millis on my slow Yoga 2 Pro laptop. Total line count 83 of pure C (no other libraries).

Is it "elegant"? Depends who you ask.. But, at the end of the day, "elegant" doesn't pay the bills..

Re: Faster Command Line Tools in D

#63

Post by destructionator »

milcron wrote: post #43
maxxxxx wrote: post #38

Earlier quoted context omitted.

D would make a good case study to look at why some technologies find widespread use whereas others don't. I don't understand why it never took over from C++.

D's standard library uses garbage collection.

So do Java, C#, Python, Ruby, PHP, Javascript, and virtually everything else and they are very heavily used. Garbage collection is a smashing success in the real world and D made the right decision to follow that success.

Of course, it is also true that much of the standard library doesn't actually use it... but these objections are never actually about facts.

Re: Faster Command Line Tools in D

#64

Post by colechristensen »

ajbonkoski wrote: post #62

I don't get articles like this.. they seem to miss the bigger point. Typically there are two modes in my computing: (1) Scripting / Command-line get stuff done and throw-away, and (2) Serious applications that are heavily used, need to process lots of data and be as fast as possible (e.g. processing millions of files like this one where the algorithm constant factor really matters). In case 1: Hack something together…

I'd expect a significant amount of the shell code I cobble together to run faster than anything I could write in a more advanced programming language.

Re: Faster Command Line Tools in D

#65

Post by KirinDave »

AceJohnny2 wrote: post #42
agumonkey wrote: post #20

Earlier quoted context omitted.

Yeah code only dealing with elegant cases is elegant. News at 20. Sometimes I wonder if software should error first, then when you bounded the failure space, you iterate on the success space as you see fit.

You've just defined Test-Driven-Development.

Sorta? But unit testing is such a problem-solving methodology that it really does seem like we want something stronger.

Re: Faster Command Line Tools in D

#66

Post by Twirrim »

nerdponx wrote: post #57
ramses0 wrote: post #8

This article is trash. They start with "obvious" python at 12s, run it with pypy instead for 3s, and then rewrite and optimize a D version from 3s to 1s w/o attempting any further optimization of the python version(!?!). In my opinion omit all of the discussion on python and just talk about "how to optimize a D program" b/c that's what this article is.

Not to mention using .split(delim) instead of the proper CSV parsing library that ships with Python.

Out of curiosity, I gave it a shot. I came out roughly 20% faster using python's inbuilt csv library.

When I switched to pypy the csv library actually made it nearly 2x slower than pypy using .split(delim)

Re: Faster Command Line Tools in D

#67

Post by gregwebs »

If you are interested in fast TSV tooling you might also try xsv [1], which is written in Rust and has similar features to the linked tsv-utils-dlang project.

The frequency command computes the frequency of values in 2 columns in 

    xsv frequency -n -s 1,2 -l 100 googlebooks-eng-all-1gram-20120701-0.tsv
    5.19s user 0.06s system 351% cpu 1.490 total
[1] https://github.com/BurntSushi/xsv

Re: Faster Command Line Tools in D

#69

Post by paulddraper »

Twirrim wrote: post #66
nerdponx wrote: post #57

Earlier quoted context omitted.

Not to mention using .split(delim) instead of the proper CSV parsing library that ships with Python.

Out of curiosity, I gave it a shot. I came out roughly 20% faster using python's inbuilt csv library. When I switched to pypy the csv library actually made it nearly 2x slower than pypy using .split(delim)

And you were using the pure Python CSV library, not the C one?
Post reply on HN