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

121–130 of 193 posts

Re: D as a Better C

#121

Post by zombinedev »

steveklabnik wrote: post #88

> What may be initially most important to C programmers is memory safety in the form of array overflow checking, no more stray pointers into expired stack frames, and guaranteed initialization of locals. Are there any docs about this anywhere? http://dlang.org/spec/betterc.html doesn't really describe this stuff.

It is not described in the betterC page as these features are not new for D. The betterC page only describes the differences versus the full D feature set.

Documentation for the individual features mentioned:

http://dlang.org/spec/function.html#safe-functions

> array overflow checking

http://dlang.org/spec/arrays.html#bounds

> guaranteed initialization of locals

http://dlang.org/spec/type.html http://dlang.org/spec/declaration.html#void_init

> no more stray pointers into expired stack frames

DIP1000 describes D's scoped pointers approach to memory safety - https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md. This is work in progress and the document doesn't reflect latest state of things. Conceptually, scoped slices/pointers/references are similar to concept of borrowing that you guys have in Rust.

Re: D as a Better C

#122

Post by steveklabnik »

zombinedev wrote: post #121
steveklabnik wrote: post #88

> What may be initially most important to C programmers is memory safety in the form of array overflow checking, no more stray pointers into expired stack frames, and guaranteed initialization of locals. Are there any docs about this anywhere? http://dlang.org/spec/betterc.html doesn't really describe this stuff.

It is not described in the betterC page as these features are not new for D. The betterC page only describes the differences versus the full D feature set. Documentation for the individual features mentioned: http://dlang.org/spec/function.html#safe-functions > array overflow checking http://dlang.org/spec/arrays.html#bounds > guaranteed initialization of locals http://dlang.org/spec/type.html http://dlang.org/spec/d…

Great, thanks! That makes sense, but it wasn't clear to me in the post.

Re: D as a Better C

#123

Post by nindalf »

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 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 developers are capable of writing multi-threaded, correct C code. Go is simple to learn, lightning quick to compile and runs reasonably fast. By no means is it perfect, and it is not the tool I'd use for every task in front of me, but it is good enough for most tasks.

I agree that Rust is the future in the low level space.

Re: D as a Better C

#124

Post by logicallee »

TylerE wrote: post #98
christophilus wrote: post #23

Earlier quoted context omitted.

Yeah. It should have been in that list, actually. I wanted to like Go. It seems simple (which is what I like so much about Clojure), but honestly, I found it to be frustrating for all the standard reasons the Go team is tired of hearing (e.g. no generics, error handling littering my code and obscuring intent, etc). In fact, I think Go doesn't quite deserve the reputation it has as being a simple language. It's a fami…

I sometimes feel Go went to far, as in the classic quote "Make it as simple as possible, but no simpler".

I understand what you mean by your quote. I will give you a toy example, then show the single example I have from Go, and ask if you know of any more.

Toy example, a language that is simpler than possible:

- If a language does not have functions, you must copy and paste the code every time you call it. Such a language would be "simpler than possible".

The only example I know from Go:

- Many people feel that the lack of generic functions can be solved similarly - such as copying and pasting code or doing search/replace - but makes the language "simpler than possible". (in the exact sense you mean.)

(A generic function is one that works on different types without knowing what they are when it is written, or similar behavior.)

So I've given you a single real example. But it's the only one I can think of.

Other than this example, can you list the ways in which you feel it's "simpler than possible" or went "too far"? I would really appreciate if you could be specific.

Re: D as a Better C

#125

Post by christophilus »

dom96 wrote: post #74
christophilus wrote: post #67

Earlier quoted context omitted.

Unfortunately, I don't have any examples off-hand. It was a month ago. I'll see if I can dig the repo back up and reproduce the error. As for how it failed, it did not segfault. It just stopped and dumped me back out on the terminal with no output at all. (I'm on OSX 10.12.6.)

That's a pity. Let me know if you dig it up. Next time please create an issue on GitHub[1], you don't have to worry about creating a small example either, as long as you give us all the code to compile it. 1 - https://github.com/nim-lang/nim

I tracked down the repo and wasn't able to get it to bomb on me as before. I honestly can't remember what scenarios triggered that, unfortunately, and I'm no longer working on the project (due to actually being back at the 9-5 job!).

Re: D as a Better C

#126

Post by nnq »

ziotom78 wrote: post #46
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…

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 so popular in scientific computing because it was first and foremost a general-purpose scripting language and didn't isolate (library-wise) sci-coders from all the other developers, second because it was designed as a "teaching language" so simple examples looked close enough to pseudocode so were liked by people in the business of having to explain their code (academia), and only lastly because it happen to be easily extensible for things like matrix operation (operator overloading...) and had non-weird general syntax (like in "functions are value and that's that" not Ruby-like weird blocks and procs that spooked math and physics folks...).

My only hope for "general purpose & sci computing" language would be Go if they dragged they heads out their asses and added some damn sugar to the langue - like operator overloading, some parametric types or templates (good luck bothering a physicists to understand when to use type switches and type assertions...), and something to allow "casual" developers to not be bitten by things like "not all nill's are equal, wtf?!" things. I like Go, but it's a hard language to sell to a non-100%-professional-developer...

Re: D as a Better C

#127

Post by theprotocol »

steveklabnik wrote: post #110
theprotocol wrote: post #105

Earlier quoted context omitted.

Could you point to any materials (e.g. blog post, roadmap document...) that deal with this? Thanks.

https://blog.rust-lang.org/2017/07/05/Rust-Roadmap-Update.ht... is our "the year is half over" update, and has a link to the overall goals right at the top.

Awesome, thanks!

Re: D as a Better C

#128

Post by lwitt51 »

new299 wrote: post #6
nindalf wrote: post #3

Earlier quoted context omitted.

The better Python market isn't an easy one to crack because its a bit crowded. Go (despite its perceived and real faults) has succeeded in this space by delivering better GC, good libraries, static typing and faster programs. Python itself is improving rapidly, for example with the addition of Type Hints. Its pretty difficult to be a better Python in 2017. The better C market, on the other hand, hasn't seen any real…

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…

Try out the Numba package: https://numba.pydata.org/

Re: D as a Better C

#129

Post by dom96 »

christophilus wrote: post #125
dom96 wrote: post #74

Earlier quoted context omitted.

That's a pity. Let me know if you dig it up. Next time please create an issue on GitHub[1], you don't have to worry about creating a small example either, as long as you give us all the code to compile it. 1 - https://github.com/nim-lang/nim

I tracked down the repo and wasn't able to get it to bomb on me as before. I honestly can't remember what scenarios triggered that, unfortunately, and I'm no longer working on the project (due to actually being back at the 9-5 job!).

Thank you for taking a look. Maybe the problem was already fixed :)

If you do find anything else then do post it on GitHub, or at least let us know on IRC/Gitter.

Re: D as a Better C

#130

Post by ejanus »

christophilus wrote: post #93
logicallee wrote: post #62

Earlier quoted context omitted.

EDIT: this is getting downvotes for some reason even though it's just addressed to OP. OP, you could email me at the link on my profile if you didn't want to answer here. I'm not on the Go team or anything, just curious. --- Thanks for your answers! So I know you don't want to rehash what's easy to find elsewhere, but your perspective is different because you wrote a Clojure interpreter. It's not the same as what I c…

[EDIT: I didn't down-vote you, and I appreciate the question.] Simplicity is not the same as familiarity. It's not the same as a small feature-set, either. Gratuitous Rich Hickey reference for what I mean by simple[1]. So most languages aren't simple by that definition, but I'd say that Go's inconsistencies prevent it from being what I call simple. Some examples: Instead of having a general mechanism for describing d…

What is "vendoring"?
Post reply on HN