Live data from Hacker News

Faster Command Line Tools in D

dlang.org

31–40 of 100 posts

Re: Faster Command Line Tools in D

#31
post #5

I'd be interested in the perspective of someone who has used both GO and Dlang for command line tools. Go is my current tool for this, but D seems like a much nicer, less dogmatic language.

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.

Allow me to defend the honor of Go a bit here!

It's not to everyone's taste, but it was designed by people who've been programming for a long time to be a language they'd like to program in. It is my favorite language for many tasks (and I've been coding for a couple decades now).

For me what's impressive about it is it's very simple, reasonably expressive, and just a really well-designed cohesive whole that doesn't usually expose sharp edges.

The longer I program the less I care about fancy things or being elegant or writing the smallest possible code, and the more I care about eliminating bullshit problems and wtf moments. Go's good at that.

Re: Faster Command Line Tools in D

#32
post #30

Makes me wonder, how many people actually use D-lang in production. Specifically with HTTP stack what kind of numbers/performance benchmarks we are looking at? Other than toy projects is there a company out there running D on massive scale (millions per day)?

Netflix and Machine Learning with D.

Re: Faster Command Line Tools in D

#33
post #30

Makes me wonder, how many people actually use D-lang in production. Specifically with HTTP stack what kind of numbers/performance benchmarks we are looking at? Other than toy projects is there a company out there running D on massive scale (millions per day)?

They have a page here: http://dlang.org/orgs-using-d.html

Re: Faster Command Line Tools in D

#34

> (Note: For brevity, error handling is largely omitted from programs shown.) I found this article interesting but to be honest I hate it when people do this. Usually it is the real-world considerations and error handling that cause the code to cease being an elegant demo and look more like the same stuff everyone else writes.

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.

In a way, isn't this how software works? The problem being that an unaccounted for error might make your program exit, or produce an incorrect result, etc. I like your idea conceptually but struggling to imagine what working on software would like in a practical sense.

Re: Faster Command Line Tools in D

#35
post #28

Earlier quoted context omitted.

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.

Golang: Easy concurrency using go-routines, a (comparatively) good minimal latency GC, an excellent comprehensive and stable standard library and few bugs. Dlang: Traditional concurrency (thread based), great generics implementation, nice algorithm/container libraries and C++ interop

Actually the standard libraries containers (In D) are fairly poor/ignored. Also concurrency in D is not traditional in the way you seem to imply: Immutability and message passing are the recommended way to do it, Fibers are also in the standard library.

Re: Faster Command Line Tools in D

#36

> (Note: For brevity, error handling is largely omitted from programs shown.) I found this article interesting but to be honest I hate it when people do this. Usually it is the real-world considerations and error handling that cause the code to cease being an elegant demo and look more like the same stuff everyone else writes.

Given that one normally throws an exception when encountering a runtime error in D, it often is not necessary to have specific runtime error handling code.

Re: Faster Command Line Tools in D

#37

Earlier quoted context omitted.

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.

I haven't actually used Go, but one of its big strengths seems to be that you get a binary with no dependencies (beyond libc I believe) at the end of it. You can just deploy it through a file copy and have it just work.

Well, Go will require compilation just like C++. The strength is its build tooling seems better integrated with the language implementation. C++ has make and friends but honestly, I prefer Go's. This is all history. Go is designed from the ground up with pitfalls of other languages in mind. Rust is obviously even better at this, with Golang as a case study.

For production you want to omit things like debug from binary so your binary is smaller. You have to play with the build flags. I can get a simple TCP server in Go in just a dozen lines but the binary is around 5MB before optimization.

[1]: https://blog.filippo.io/shrink-your-go-binaries-with-this-on...

Re: Faster Command Line Tools in D

#38
post #30

Makes me wonder, how many people actually use D-lang in production. Specifically with HTTP stack what kind of numbers/performance benchmarks we are looking at? Other than toy projects is there a company out there running D on massive scale (millions per day)?

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++.

Re: Faster Command Line Tools in D

#40
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.

The article wasn't really an attempt to show how D is "faster" or "better" than Python. I think the author was trying to baseline code size and relevance to the problem by illustrating how it compares to a typical Python solution.
Post reply on HN