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

D as a Better C

dlang.org

Post reply on HN
Print view View original

171–180 of 193 posts

Re: D as a Better C

#171

Post by nnq »

Volt wrote: post #168
nnq wrote: post #126

Earlier quoted context omitted.

Julia could have had 10x the adoption if they painted themselves as more of a general purpose language, like "write the web app and your neural networks (GPU accelerable bien sur) in the same language ftw!"... if only they'd have bolted in some support for "non-weird-looking classic OOP" like in "wanna type `window.` and have even the most retarded editor autocomplete methods". Imho they got it backwards: Python got…

They're going after Matlab, Octave and R rather than Python.

That's why I think "they get things backwards" :| ...Python went after Matlab, Octave and R. And for ML/AI is almost completely replaced them. For stats and data-exploration it shares the pie with R because they are so different languages with different strengths.

It's a shame that the best language designers seem to also be the worst at "market positioning" and programming languages a pretty much fashion & promotion driven area. Anyway, maybe I should shut up, find the time to delve into Julia and when I know enough try to give them a helping hand instead of whining...

Re: D as a Better C

#172

Post by jononor »

nnq wrote: post #171
Volt wrote: post #168

Earlier quoted context omitted.

They're going after Matlab, Octave and R rather than Python.

That's why I think "they get things backwards" :| ...Python went after Matlab, Octave and R. And for ML/AI is almost completely replaced them. For stats and data-exploration it shares the pie with R because they are so different languages with different strengths. It's a shame that the best language designers seem to also be the worst at "market positioning" and programming languages a pretty much fashion & promotion…

Python (as in the language designers or core people) did not "go after Matlab, Octave and R". Non-affiliated or loosely-affiliated people who wanted to do their data-oriented work in Python wrote a bunch of libraries, and the result after many years was a pretty competitive set of tools. So yeah, I think that similarly can be done for Julia to improve it for more general purpose tasks.

In educational/academic setting, I think even more importantly for adoption than Python being a general-purpose language is that it is already relatively widely adopted in various industries as a tooling language. For good and bad, universities today are very keen on providing skills with immediate relevance to employeers. The same network effect is kinda what is keeping Matlab alive...

Re: D as a Better C

#173

Post by nnq »

jononor wrote: post #172
nnq wrote: post #171

Earlier quoted context omitted.

That's why I think "they get things backwards" :| ...Python went after Matlab, Octave and R. And for ML/AI is almost completely replaced them. For stats and data-exploration it shares the pie with R because they are so different languages with different strengths. It's a shame that the best language designers seem to also be the worst at "market positioning" and programming languages a pretty much fashion & promotion…

Python (as in the language designers or core people) did not "go after Matlab, Octave and R". Non-affiliated or loosely-affiliated people who wanted to do their data-oriented work in Python wrote a bunch of libraries, and the result after many years was a pretty competitive set of tools. So yeah, I think that similarly can be done for Julia to improve it for more general purpose tasks. In educational/academic setting…

> more importantly for adoption than Python being a general-purpose language is that it is already relatively widely adopted in various industries as a tooling language. For good and bad, universities today are very keen on providing skills with immediate relevance to employeers

Maybe I phrased it confusingly but you're saying the same things I thought. I don't mean "go after" in a conscious/targeted way. I meant "it evolved towards taking over". And "immediate relevance to employeers" is provided by being a "general purpose language" (like in "look, you can quickly wip up web apps, general server admin scrips and even excell plugins with it"). And "tooling" mostly equals "general purpose" in my book: there is no clear definition of "tooling" it's about "glue code" that needs to do "a bit of everything" to tie things together... so you need a "general purpose" language for tooling.

(Now I see that maybe some people use "general purpose" as in "you can write anything from device drivers and OSs to web apps if you really want to" but this is "systems languages" in my terms or C and C++ and the newcomers Rust and D. But by this definition even Go would be very far from "general purpose"...)

Re: D as a Better C

#174

Post by wentoodeep »

gjm11 wrote: post #61
Rhinobird wrote: post #16

D is one better than C, but K goes all the way to 11.

(This is a slightly funnier joke than it may appear at first glance, because as well as being the name of another programming language K is in fact the 11th letter of the alphabet.)

M is 2 steps ahead of K

Re: D as a Better C

#175

Post by vram22 »

WalterBright wrote: post #87
vram22 wrote: post #58

Earlier quoted context omitted.

>According to their respective Wikipedia articles, D is 8 years older than Go. And Go itself is some years old now (created in either 2007 or 2009 - according to its Wikipedia article - maybe they mean initial creation and first release for public use, by those two year values). So Go is about either 8 or 10 years old. And that makes D either 16 or 18 years old. >Go had a lot of success breaking into the Python marke…

I've always been attracted to systems programming, and it's what I know best. Hence D is angled that way.

Cool!

Re: D as a Better C

#176

Post by vram22 »

pjmlp wrote: post #83
vram22 wrote: post #54

Earlier quoted context omitted.

>Go (despite its perceived and real faults) has succeeded in this space by delivering better GC, good libraries, static typing and faster programs. Also fast compilation, which D also has.

Most Algol derived languages have it, it became a lost art as C and C++ pushed them aside.

Interesting, didn't know that most had it - only knew it about Pascal and Delphi.

Re: D as a Better C

#177

Post by flavio81 »

nnq wrote: post #126
ziotom78 wrote: post #46

Earlier quoted context omitted.

I am in a similar situation, as I develop a lot of scientific code. I've tested several solutions, and so far the most viable for me (though far from perfect) is Python+NumPy+Fortran, the latter exposed to Python using f2py (much easier than binding C/C++ to Python). Not sure if this might be a good solution for you, it depends whether the bottleneck in your code is in I/O or in raw calculations (in the former case y…

Julia could have had 10x the adoption if they painted themselves as more of a general purpose language, like "write the web app and your neural networks (GPU accelerable bien sur) in the same language ftw!"... if only they'd have bolted in some support for "non-weird-looking classic OOP" like in "wanna type `window.` and have even the most retarded editor autocomplete methods". Imho they got it backwards: Python got…

> if only they'd have bolted in some support for "non-weird-looking classic OOP" like in "wanna type `window.

Ah, so you want an inferior way of doing OOP? Because the reason Julia is the way it is, it is because it supports OOP based on multiple dispatch (and over more than one object per method). I think this is a major quantum leap over the OOP you are requesting.

Sincerely, if that's what you want, there is always Java to make you happy.

Re: D as a Better C

#178

Post by vardump »

saghm wrote: post #15
new299 wrote: post #6

Earlier quoted context omitted.

I really really don't been to pile on Python... but every time I've had to interact with it I've been shocked at how slow it is compared with C or C++. I tend to write scientific code to process datasets in the range on 10Gb, for simple operations Python code can take hours as opposed to just taking minutes or seconds in C. I'm sure it's possible to write more highly optimized code in Python, but it never seems to be…

Python is a high-level interpreted language, and C/C++ are low-level (even compared to other) compiled languages. While you might be able to optimize your Python code to run faster than it does now, it's never going to match the performance of C/C++, nor is it intended to. Go will be a significant speedup over Python, but likely won't quite match the speed of C/C++ for most tasks. Then again, the ease of development…

> Go...but likely won't quite match the speed of C/C++ for most tasks.

Last I checked golang generated code 3 years ago, it was full of redundant instructions, most notably redundant range checks. Seemed to be about half as fast as equivalent C/C++ code.

I believe golang can approach something like 80-95% of C/C++ performance once codegen is good.

Re: D as a Better C

#179

Post by vardump »

nindalf wrote: post #123
saghm wrote: post #15

Earlier quoted context omitted.

Python is a high-level interpreted language, and C/C++ are low-level (even compared to other) compiled languages. While you might be able to optimize your Python code to run faster than it does now, it's never going to match the performance of C/C++, nor is it intended to. Go will be a significant speedup over Python, but likely won't quite match the speed of C/C++ for most tasks. Then again, the ease of development…

> Go will be a significant speedup over Python, but likely won't quite match the speed of C/C++ for most tasks. Its true, Go won't match the speed of C, but it comes pretty damn close. Say you have 4 cores, 1 would be dedicated to GC and the other 3 would be executing your program. That sounds sub-optimal, meaning that a Go program could only be 75% as fast as an equivalent C program. But you have to wonder how many…

> Say you have 4 cores, 1 would be dedicated to GC

In my opinion, idiomatic golang is not that GC heavy. A slice (a bit like ArrayList) of structs can be a contiguous chunk of memory as opposed to array of object references, which requires allocating each object separately.

There are an order of magnitude less allocated objects than in Java for example. (Perhaps the situation will change once Java gains value types in maybe Java 9).

Re: D as a Better C

#180

Post by rurban »

Houshalter wrote: post #165
new299 wrote: post #6

Earlier quoted context omitted.

I really really don't been to pile on Python... but every time I've had to interact with it I've been shocked at how slow it is compared with C or C++. I tend to write scientific code to process datasets in the range on 10Gb, for simple operations Python code can take hours as opposed to just taking minutes or seconds in C. I'm sure it's possible to write more highly optimized code in Python, but it never seems to be…

What everyone in this subthread is looking for is LuaJIT. It's the fastest JITed language. Comparable to C for many tasks. It has a very tiny memory footprint and integrates into C and C++ well. And there's torch if you need to do fast matrix math or machine learning.

That's up to interpretation. Eg. Pony is faster and safer than LuaJIT or C for example.
Post reply on HN