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

My Vision of D’s Future

dlang.org

Post reply on HN
Print view View original

161–170 of 211 posts

Re: My Vision of D’s Future

#161

Post by grogenaut »

atombender wrote: post #104
kernyan wrote: post #30

>I think we need a ridiculously fast interpreter so that we can skip machine code generation and linking. To me, this should be the default way of running unittest blocks for faster feedback, with programmers only compiling their code for runtime performance and/or to ship binaries to final users. This would also enable a REPL. I am most excited about this, where a language supports two modes 1) interpreter for devel…

I'm a fan of Go's "go run". For example, you can do: go run main.go or: go run ./cmd/server When invoked this way, Go compiles your code behind the scenes, but you don't have to create a binary. This means Go lends itself pretty well to ad-hoc scripting or writing small script-like tools. Unfortunately, Go doesn't support shebang lines, but with gorun [1] you can: #!/usr/bin/env gorun package main func main() { print…

I actually use this for all of my complicated build scripts and just use make to glue them together. For instance I have a stack name from computer,branch,sha,username that I calculate so I have a different stack per thing I'm working on. I tried getting that to work with awk fu but doesn't work the same on every platform, so instead "go run cmd/get_stack_name/main.go" instead. Fast and like it.

Re: My Vision of D’s Future

#162

Post by Shorel »

atilaneves wrote: post #46

I didn't submit the link but I did write the blog post. AMA!

The interpreter thing could work better in the current software landscape if it could be integrated in Jupyter notebooks.

Nowadays many people are migrating to Python to use machine learning in Jupyter or just to run machine learning code in Python.

Re: My Vision of D’s Future

#163

Post by einpoklum »

pjmlp wrote: post #160
einpoklum wrote: post #94

Earlier quoted context omitted.

... and over the past decade-and-a-bit, C++ has been evolving itself quite nicely (IMHO), so the motivation for moving away from it has decreased. Also, now D probably has to "chase" some C++ developments.

The problem is that while modern C++17/20 are quite productive, we cannot get rid of C copy-paste compatibility and the errors of the past (see Python 3). So either you work alone, in a small team that appreciates modern safe C++ (including Core guidelines), and enjoy C++, or you are faced to deal with all idiocrasies and unsafety issues from the past.

Well, it's not quite that dichotomous. It's quite possible to gradually modernize, or "beautify", an older-C-style codebase. And actually, having a transition path from older to newer code without a cliff is an advantage to switching languages.

Re: My Vision of D’s Future

#164

Post by skocznymroczny »

mhh__ wrote: post #142
skocznymroczny wrote: post #51

Earlier quoted context omitted.

BetterC was created at first to make it easier to port D compiler from C to D. Then people realized that it might be interesting to have D without GC and without runtime, because it makes it trivial to port to other platforms such as embedded, mobile or WASM. The problem is, betterC is kind of in that awkward spot. It's not comparable to the "real" D, and if you can live with betterC, you might as well just use C and…

> if you can live with betterC, you might as well just use C and enjoy the wide C ecosystem. If you can be bothered to use betterC then that's probably not true. To be argumentative, C is fucking horrible. BetterC still gives you a decent chunk of D's features - templates alone make it worth the switch. No more macro spam for example. Can you imagine how much boilerplate you'd have to write to mimic this: https://d.g…

I wish betterC had associative arrays :(

Re: My Vision of D’s Future

#165

Post by pjmlp »

einpoklum wrote: post #163
pjmlp wrote: post #160

Earlier quoted context omitted.

The problem is that while modern C++17/20 are quite productive, we cannot get rid of C copy-paste compatibility and the errors of the past (see Python 3). So either you work alone, in a small team that appreciates modern safe C++ (including Core guidelines), and enjoy C++, or you are faced to deal with all idiocrasies and unsafety issues from the past.

Well, it's not quite that dichotomous. It's quite possible to gradually modernize, or "beautify", an older-C-style codebase. And actually, having a transition path from older to newer code without a cliff is an advantage to switching languages.

I agree, however that modernization is only possible if the team actually buys into it, hence my remark about working alone or in a small team that embraces modern C++.

Re: My Vision of D’s Future

#166

Post by Discombulator »

flowerlad wrote: post #128

A major missing feature is checked exceptions. See long discussion thread here: https://forum.dlang.org/thread/hxhjcchsulqejwxywfbn@forum.dl...

This is glossing over the fact that checked exceptions are a very controversial feature and that most language designers (is there any language besides Java that supports them?) do not implement them on purpose.

Re: My Vision of D’s Future

#167

Post by quickthrower2 »

tsegratis wrote: post #97
rickette wrote: post #10

Earlier quoted context omitted.

It's beyond me why most languages fall into this trap: C, C++, C#, D, Go, etc. All hard to search for. Granted some of these predate the internet, but most do not. Almost looks like some kind of secret agreement between language designers.

I'm going to name my language after ' ', ascii 32

What about lower case c

Re: My Vision of D’s Future

#168

Post by atilaneves »

abaga129 wrote: post #88
atilaneves wrote: post #46

I didn't submit the link but I did write the blog post. AMA!

In a recent blog post Walter talked about adding borrowing to D. Is this planned to be implemented and if so do you see any hurdles and/or benefits in relation to your Vision? Looking forward what new perspective you bring to the community!

> Is this planned to be implemented

Yes.

> any hurdles and/or benefits in relation to your Vision?

Hurdles: implementation issues, figuring out later on that there are ways to corrupt memory despite the rules we come up with.

Benefits: Compile-time memory safety.

Re: My Vision of D’s Future

#169

Post by atilaneves »

arunc wrote: post #74
atilaneves wrote: post #46

I didn't submit the link but I did write the blog post. AMA!

I personally believe that it's all about _people_. How do you plan to push the community forward? After all everyone just shares their free time. So far based on what I've observed, people in the D community is the biggest critique of it's own, even more so than any other community I've seen on the internet. The D forum is full of shit posts thrashing D for what it is.

Part of my new job is trying to motivate people to do their best work. I'm still figuring it out.

Re: My Vision of D’s Future

#170

Post by atilaneves »

Shorel wrote: post #162
atilaneves wrote: post #46

I didn't submit the link but I did write the blog post. AMA!

The interpreter thing could work better in the current software landscape if it could be integrated in Jupyter notebooks. Nowadays many people are migrating to Python to use machine learning in Jupyter or just to run machine learning code in Python.

It's already possible to use D with Jupyter, but an interpreter will make it a lot faster.
Post reply on HN