Hacker News Reader

Hacker News

Comment by systems | Hacker News Reader

Full thread

systems

i dont think going after c++ will help d's adoption it didn't work in the past

i dont know what have changed to make it work in the future

i dont remember Go or Rust ever focusing on comparing themselves to another language as much as d compare itself to c++

d should create its own path same way any other more popular language did

View on HN

I'm a fan of Rust, but I think you must be reading a different HN if you don't think the Rust community focuses on comparing it to C and C++. The Go language creators have specifically stated that they created Go to solve problems they had with C and C++: http://web.stanford.edu/class/ee380/Abstracts/100428.html

I don't think "focuses on comparing it to C" is the right phrasing, but being a drop-in replacement for C is certainly a killer feature.

C++ will always have a leg up over D for me due to the GC stuff. I like not having GC in C++.

When I want a GC'd C-like I use Go.

D has to find a space between those two for me and a lot of other people.

I don't dislike D. I think D has a LOT of great work done in it. I just really want all my libraries to be able to be used without GC. And I'm not sure it's really feasible to have each foot in either world and not just get split down the middle.

Can someone argue against this worry? It's literally the only thing stopping me spending more time with D.

Also I've been coding in Ada (lord help me) for fun. Contracts are interesting.

I've been told (in other threads on HN) that you can disable GC in D. I don't know how that integrates with stdlib (or other library) bits that use GC (are they disallowed, or do they fail at runtime?).

You can't allocate with GC in @nogc functions, you will get compile time error. There is ongoing work in standard library (Phobos) to make it work without GC.

So if you @nogc main(), you're set? Thanks.

Affirmative.

You don't have to have GC in D, and manual memory can work side-by-side the GC with or without disabling it.

You can delete objects early, or call GC.disable

The safer approach is to mark that code @nogc. There is no guarantee that the GC won't run when calling GC.disable. You do get a guarantee with @nogc.

> There is no guarantee that the GC won't run when calling GC.disable.

If you have called GC.disable, the collector becomes `return;`. Sure, the GC function is called, but it doesn't do anything, it just immediately returns.

I'm not sure tbh. The documentation says "Collections may continue to occur in instances where the implementation deems necessary for correct program behavior, such as during an out of memory condition." My understanding from the forum discussions is that a collection could happen and you would not know about it.

An important factor in choosing a language is platform. I'm not going to choose Go or D to write an iOS app in, because it would be painful and buggy, if it's even possible in the first place. I'm restricted to Objective-C(++) if I want it to really be a high quality & native app.

Most languages with a C FFI (and ARM/Mach-O compiler support) can do pretty well on iOS. Rust bindings to Objective-C APIs are pretty painless for example.

D can interface with Objective-C just fine. The Apple-provided tooling will indeed be more convenient for the developer, but the result the end user sees will be a "high quality & native app" just the same.

I'm only lurking on the D forums, so this should probably be taken with a grain of salt. From what I understand the GC is required for various array, hash map and string operations, and things like closures and exceptions (maybe assertions?). Though there is work being done on fixes and alternatives (scope limitations, ref counted things).

This does seem to come up sometimes. I'm wondering if it makes sense to add a "end-vision for GC-less D" section to the D GC documentation, now that there are various undertakings to make it easier. Might also help with finding volunteers that care about @nogc to help out with various bits.

There is a pull request in now to make throwing exceptions GC-free. It hasn't been merged yet, but should be soon.

There's been a lot of work recently to enable GC-free D code. Yes, that means some of the standard library is off bounds, as are some of the built-in operators (new, array concatenation). However, you can have _static_ guarantees that there will be no GC allocations whatsoever. Writing an executable?

`void main() @nogc { /* ... */ }`

Done.

I've written a log of `@nogc` code lately.

Then what? How much of the standard library and the library ecosystem compiles with nogc?

Subsetting languages (and comunities) usually doesn't end well...

Depends on the kind of code you write. std.algorithm? No problem

Remedy Entertainment has a talk - actually two talks, one from 2013 and one from 2016 [0], about how they added D to their game engine, replacing a major subsystem, and then shipped a AAA title(Quantum Break) with it. The GC did not present a major issue although the talk notes that their solution was "unfinished" and got the result they wanted by wasting memory instead of what they initially aimed for(ARC, this is work-in-progress for D [1][2]). Most of the nuts-and-bolts work came from achieving smooth integration with the C++ codebase, and building for the release devices.

[0] http://dconf.org/2016/talks/watson.html

[1] https://wiki.dlang.org/Language_design_discussions#Automatic...

[2] http://www.digitalmars.com/d/archives/digitalmars/D/ARC_in_D...

The slides say the GC never collects, which is the same as having no GC.

After a while decreasing GC usage in D, I ended up removing it completely. I got reduced memory usage but no speed gain. What I've found is that before you remove the GC, you can turn the overhead from excessive to very affordable with optimizations. Especially today with std.experimental.allocator and -profile=gc

Please note that, GC or not GC, you still can have deterministic destruction (e.g RAII).

Rust has Mozilla, and the community does tend to appear in C/++ threads.

Go has Google.

Swift & ObjC has Apple.

D... Doesn't have a large mindshare/corporation backing it.

dont reduce Rust and Go relative success to just having google or mozilla

Rust and Go .. made better design choices that made them more popular

> Rust and Go .. made better design choices that made them more popular

[citation needed]

I found Rust by googling languages that compile to LLVM bytecode. It was version 0.6, but I was already excited by the fact that it was promising to be a fast, safe, concurrent language. Even back then it had a value proposition to early adopters.

I wrote a Fizzbuzz implementation. I did it to test language features. As language features and the standard library kept on changing, I kept updating my repository. It's had something like 70+ commits to it since 0.6 days.

https://bitbucket.org/iopq/fizzbuzz-in-rust/src/d4638b2ba3f0...

it's a little bit more complicated than necessary BECAUSE it's a test of new functionality (even now it only compiles on Nightly)

but it has a certain charm to it (fizzbuzz done in a few filter and map operations)

> dont reduce Rust and Go relative success to just having google or Mozilla

I don't think Go would have been popular without Google. It's easier to sell a solution to your manager when it is backed by a big org, and when people are paid fulltime to work on it. Same for Rust and Mozilla. The barrier for adoption of new languages is pretty high today in enterprise space.

so why did python and ruby became popular

and why isnt dart more popular

Python became popular because many people saw it as a cleaned-up Perl, and ESR wrote about it.

Ruby became popular because of Rails.

Dart isn't popular because it was designed to be a browser language but did little to court Web developers who like JS (contrary to the HN consensus, a lot of Web developers actually like JS) or other browser vendors.

so you agree with me, we python and ruby didnt need a huge corporate backing and dart even with some corporate backing didnt become popular

more examples that debunk that corporate backing is what made rust or go ... are scala and clojure, scala being way more popular than d and clojure ... and neither have corporate backing

in conclusion, you dont really need corporate backing if you have a nicely designed language that have its own path

I also said 'mindshare'.

Cs syntax can be awful. Similar symbols with different meanings. But, it was powerful, fast and simpler than some competitors.

Bash is frequently used today, for all sorts of things. Its even in production products, like git. However, even its creator thought it was a kludge.

There is no simple answer to language success, but a large group of people adopting and improving a language is probably going to be helpful.

d is not unpopular because of lack of corporate backing

d is unpopular because of poor project objectives and positioning and playing catch up with other languages rather than leading in any specific area

d needs a novel idea ... i guess they made bet on execution rather than innovation

Rust yes, Go just has Google.

i like your logic .. but i think Go have more than just Google, it also had Rob Pike and Ken Thompson as designers

two legendary programmers

And yet somehow they managed to ignore the majority of what has been learned in the last several decades of language design progress.

Given their experience, I strongly suspect they made the choices they did knowingly, rather than out of ignorance.

These two comments are not mutually incompatible. There is also a reason I've been heard to say that Not Invented Here syndrome was invented at Bell Labs.

Better design choices or better design?

D... Doesn't have a large mindshare/corporation backing it.

I had a strong interest in D from 2007-2009. The problem is that there were two competing, incompatible standard libraries for D1 (Phobos and Tango). Then came D2, which was a large improvement, both language-wise and library-wise, but basically split the ecosystem in three for some time.

I think the library and D1 vs. D2 situation stifled the growth of D. I gave up on D because the community was so fragmented.

That ended ~10 years ago. There's only D2 now. We have one user left using D1, and they're transitioning to D2.

Reply on news.ycombinator.com