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

OpenD, a D language fork that is open to your contributions

dpldocs.info

Post reply on HN
Print view View original

121–130 of 322 posts

Re: OpenD, a D language fork that is open to your contributions

#121

Post by fiddlerwoaroof »

datadeft wrote: post #116
fiddlerwoaroof wrote: post #27

Earlier quoted context omitted.

Rust is a really frustrating language for me: I understand the safety it provides but find the pain of actually using it makes it uncompelling. Plus, the Rewrite it in Rust movement is very off-putting

Rust is for people who stick around, can come over hurdles, can take in new concepts and see the overall benefits. It has a steep learning curve that pays off. For me there are three reasons why Rust is suitable for many usecases: - performance - safety - static binary compilation with targeting different cpu architecture After spending majority of my time with Python and Java in the last 10 years these are things i…

Performance isn’t a problem for Java for just about any business application most programmers will work on and, if it is, you can usually figure out how to optimize Java to hit your performance target. Safety is also not a problem in Java. And fat jars remain the single best way to deploy an application I’ve seen in just about any ecosystem (and nix is working out pretty well to bring their benefits to the rest of the programming world).

Re: OpenD, a D language fork that is open to your contributions

#122

Post by fuzztester »

wussboy wrote: post #63
tlivolsi wrote: post #22

What's Walther's take on the many gripes with the D leadership?

I’m not sure I’ve ever seen him comment here on a D related post. Which I totally understand.

He did on this post, here:

https://news.ycombinator.com/item?id=38988220

Re: OpenD, a D language fork that is open to your contributions

#123

Post by petre »

badsectoracula wrote: post #60
dataflow wrote: post #50

Earlier quoted context omitted.

I keep saying this and having the exact same argument with everyone every single time I mention it (and I'm sure here we'll go again), but D's fundamental problem was its GC. Its mere presence colors the code that uses it, and once your dependencies use the GC, you have no recourse. It's impossible to abstract away. I fail to see how such a language could ever substitute for C++.

According to the followup a week later[0] it seems OpenD is doubling down on GC: > One of the guiding principles of this fork is to embrace the GC as a successful design rather than to shun and avoid it. [...] I have harshly criticized @nogc in the past as putting a disproportionate burden on library authors while being the wrong answer to what can be a perfectly fair question. [0] https://dpldocs.info/this-week-in-d…

The GC works fine. Why waste energy to duplicate the functionality that requires it? Programmers who don't want the GC are already using C++ or Rust instead. The GC is one of those tools that makes programming in D productive. The lack of libraries and modern tooling is the part that ruins it. That's why you get software written in Go and Java instead of D.

I'd love to use it for embedded work instead of C and C++, even in the current state. Embeded meaning 32bit MCUs running some kind of RTOS, not ARM SBCs powerful enough to run Linux. If not D, then maybe Zig. For this it needs to be able to link against and build upon existing C/C++ libraries.

Re: OpenD, a D language fork that is open to your contributions

#124

Post by fsckboy »

eklavya wrote: post #117
nwallin wrote: post #77

Earlier quoted context omitted.

Rust is a frustrating language for me too. I never saw the need for it, really. I just stuck with the language constructs in C++ that makes it basically impossible for memory leaks/use after free/use outside of bounds to occur or if they do occur, explode loudly in debug environments. I haven't used new/delete in a personal project in like a decade; longer than Rust has been around. Now I'm working on a project where…

I am yet to see someone who can't make memory safety mistakes in C++. You might want to start a tutorial series on how to do that. If this skill can be taught that is, and isn't genetic.

i don't make memory safety errors in C or C++.

i'd recommend embracing hungarian naming (if you call it apps-hungarian you've not embraced it fully enough, read older documentation) and be as rigid as rust about using it. i-, c-, p-, and Max are your best friends, don't declare one of those without declaring all the others that you will need.

using hungarian, adopt naming conventions about Open/Close, Init/Finish, Alloc/Free, Start/End, Alpha/Omega, or whatever, and apply them rigidly to any class/struct (with indentation that's obvious). When you put in an Open, you go and put the Close in at that moment, just as you would close any paren you opened. don't return from all over the place in a function, goto endblock and free what needs freeing, you need to work on autopilot not thinking through the twists and turns to play monte carlo with getting it right. If you are going to return an allocation, your name needs to be Open, Init, etc. Use whatever words you want, but it's got to be something that makes you as the caller think "this is an open paren, i need to close it"

using ifdef debug type mechanisms, hook malloc and free and put guard word asserts at the beginning and end of every allocation, and magic number ids and reference counts in all structs, and hook main() and exit() so you check those for leaks. all. the. time.

work in a systematic way that avoids problems and make that your priority, everything else like functionality is slaved to that.

Re: OpenD, a D language fork that is open to your contributions

#125

Post by IshKebab »

bachmeier wrote: post #18
Kranar wrote: post #7

D is such a sad case of how a good technical product can fail due to poor leadership and decision making. A language is more than just a compiler, it's also an ecosystem and a community. D's community is actually very welcoming but man, watch some of the DConf videos and Q&As on Youtube and it's cringe seeing key leaders talking down to people, or dismissing people's concerns, or just have this ego about themselves l…

> Good luck to these guys on trying to bring life back to it, but frankly I think at this point most people have given up and moved on to alternatives like Rust, Nim, Zig, etc... And back in 2015, folks were saying the same thing, but with different alternative languages. I remember twenty years ago when C++ was dead. Oh, and remember the good old days when Java was dead? I'm not sure why programming language discuss…

Because it's not very difficult to lurk on forums like this and get a pretty accurate idea of which programming languages are on the way in or out. Or look at GitHub/Stackoverflow surveys and data if you want something quantitative.

I don't think many people thought C++ was dead 20 years ago; that seems like revisionism. Same with Java.

People looking for a C++ replacement have definitely moved on to Rust, Zig and maybe Go & Nim. Not D. I don't see how you could seriously argue otherwise.

Some languages are pretty easy to predict, e.g. Ruby is going to decline quite quickly. C++ is going to stick around for a long time because of its current enormous usage. PHP will probably stick around for a while but slowly decline like Visual Basic and Perl. Rust is going to gain in popularity for a long time and probably stick around for a very long time.

Some are more difficult to predict. I'm not sure what will happen to Go or Nim for example.

Re: OpenD, a D language fork that is open to your contributions

#126

Post by TylerE »

masklinn wrote: post #120
pjmlp wrote: post #110

Earlier quoted context omitted.

Easy, see the use of Oberon, Java, .NET in bare metal IoT deployments. PTC, Aicas, microEJ, Astrobe, Meadow,... The problem isn't having a GC, is its poor implementation.

> The problem isn't having a GC, is its poor implementation. OTOH Java and .Net exist and have large investment (D is younger than C#), so for people who are fine with GC, there are already plenty of "C++ alternatives". What's left is people who can't or won't use a GC, and for them a GC'd language can not be an alternative.

There is a substantial… feel… difference in using a well gced language that isn’t tied to a monolithic runtime. A big part of that is having zero perceptible startup overhead, since it isn’t parsing a class path or trying to load a bunch of dlls or anything beyond what your code explicitly doe + a much more minimalistic than you might expect GC runtime. Often only 20-30kb of machine code.

While it hasn’t really taken off yet, I’ll point to nim, specifically with its very recently stable arc GC, as a very compelling local (at least) maximum in this space.

Re: OpenD, a D language fork that is open to your contributions

#127

Post by quikoa »

Kranar wrote: post #7

D is such a sad case of how a good technical product can fail due to poor leadership and decision making. A language is more than just a compiler, it's also an ecosystem and a community. D's community is actually very welcoming but man, watch some of the DConf videos and Q&As on Youtube and it's cringe seeing key leaders talking down to people, or dismissing people's concerns, or just have this ego about themselves l…

That reminds me of Elm. It has (had?) so much potential if it only were more open with accepting contributions.

Re: OpenD, a D language fork that is open to your contributions

#128

Post by WhereIsTheTruth »

teleforce wrote: post #92
countWSS wrote: post #84

My suggestions: completely get rid of GC(use refcounts or borrowed pointers), add macros(see FreeBasic extensions of C macros), migrate everything complex/optional out of stdlib to specific packages(Rust ecosystem is centered on packages not stdlib), and you will have a solid competitor to C++ and perhaps Rust. Rust of course has better macros and type system, but D looks simpler and more approachable for rapid proto…

Your suggestions are moving backward, and GC by default and no macro made D intuitive and Pythonic that are big plus in any modern programming language construct. The non GC is not really needed unless you're working on OS control primitives but again D give you alternative unlike Go. Every modern languages should avoid macro like a plaque otherwise you will sooner or later create a ghetto inside your community not u…

If you don't have state of the art GC, it's a burden to have in your language since it'll cripple performance, GC pausing threads, collection becoming slower as your heap grows and memory fragmentation for example

D doesn't have state of the art GC, it perhaps should focus on its strengths, being a better C/C++ and embrace the concept of allocators

https://dlang.org/phobos/std_experimental_allocator.html

To me D shine with its -betterC mode, it completely strip the runtime, giving you a great low level language to work with, a great better C/C++, I would have quit D a long time ago if it didn't have this compiler flag

Re: OpenD, a D language fork that is open to your contributions

#129

Post by ignoramous »

nindalf wrote: post #86
nwallin wrote: post #77

Earlier quoted context omitted.

Rust is a frustrating language for me too. I never saw the need for it, really. I just stuck with the language constructs in C++ that makes it basically impossible for memory leaks/use after free/use outside of bounds to occur or if they do occur, explode loudly in debug environments. I haven't used new/delete in a personal project in like a decade; longer than Rust has been around. Now I'm working on a project where…

Hell is other people’s code. Of course our code is perfect, and we would never write a buffer overflow or issue that would be solved by memory safety. But I find consistently that other people seem to, and then I’m forced to contribute to the same code base.

GP isn't wrong though. There genuinely are total hell codebases. Not everyone is as dedicated to their craft like Mozart was. There are levels. And some teams and individuals do indeed produce better outcomes because not only they know how but also show how.

Re: OpenD, a D language fork that is open to your contributions

#130

Post by eklavya »

fsckboy wrote: post #124
eklavya wrote: post #117

Earlier quoted context omitted.

I am yet to see someone who can't make memory safety mistakes in C++. You might want to start a tutorial series on how to do that. If this skill can be taught that is, and isn't genetic.

i don't make memory safety errors in C or C++. i'd recommend embracing hungarian naming (if you call it apps-hungarian you've not embraced it fully enough, read older documentation) and be as rigid as rust about using it. i-, c-, p-, and Max are your best friends, don't declare one of those without declaring all the others that you will need. using hungarian, adopt naming conventions about Open/Close, Init/Finish, Al…

I should take this to the security team although I have a hunch that they'll think I am full of shit. What with the CVE count never going down with asan, ubsan, tsan and all kinds of guidelines, analyzers, tests and what not.
Post reply on HN