D 2.093.0 | Hacker News Reader

D 2.093.0

dlang.org

157 pointscrazypython43 comments

See D 2.092.0 for D's preview support for Ownership and Borrowing. https://dlang.org/changelog/2.092.0.html

I really need to do a basic D -betterC project, just using it as a basic low level language, maybe with a dash of DbC. Probably with embracing some Oberon concepts (static imports, single return etc.)

You can use D with GC but manually deallocate memory. This let's one use the GC as a backup.

The D compiler has a switch where you can select the compiler implementation itself to use the GC or manual. This gives options when compiling very large projects (the compiler allows an entire project to be compiled at once, giving the benefits of total program optimization without needing involvement from the linker, this of course uses prodigious amounts of memory).

Recreating Oberon in D sounds like an interesting blog post. Please write about it!

One thing that is needed for the proper experience is dynamic linking and strong type exports from the libraries.

Otherwise, as idea for other languages that also want to explore the same OS concepts, make use of IPC like dbus, XPC, COM, with a name server able to translate Module.Command into calls.

Then expose this as means to be called on the REPL, via mouse actions, supporting text as parameters, selected text, selected widget or window.

Actually from my list above, the IPC tools are already there in modern OSes, but the idea is not properly explored across the whole stack.

> With this release it is now possible to install and activate compilers from the Windows command prompt directly.

> Assuming an MSYS2 installation is present in C:\msys64, necessary decompression tools can be installed from the Windows command prompt

Huh? I would think the whole point of running from command prompt would be that MSYS2 is not needed. And the reality is its probably not. Someone would just need to reimplement the Bash script as a PowerShell script.

There are dedicated installers for Windows if that is what you want: https://dlang.org/download.html

I never used the "install.sh" but just tried and since I have Windows git installed (which comes with MSYS2) it just worked without any issues.

> Someone would just need to reimplement the Bash script as a PowerShell script.

... and then maintain it.

Installing MSYS2 to run a bash script is like deploying an A-10 Warthog to light the fuse for one of those fountain fireworks.

There are much better ways to install things in windows. Such as MSI files if you need to change paths and registry entries. Chocolatey if you want a 'aptget' like usage, there are several of these types. Using bash to install something is unique. I personally am a fan of in place portable install, unzip, run exe, done.

Anyone who doesn't already have a bash environment installed on Windows isn't the target of install.sh.

Any bash environment on Windows will do. install.sh serves a specific use case for those who need it. It installs dmd in the user's home directory along with a script that enables/disables that specific version in the environment, so multiple dmd versions can be installed side-by-side, and the user can switch between versions as needed. It's a convenience script, more than anything else. More suited for people used to developing in Linux who need to work in Windows from time to time (with or without WSL) than regular Windows developers. The latter group will certainly prefer the Windows installer.

> Assuming an MSYS2 installation is present in C:\msys64

Wow, really? Hardcoded paths in 2020?

I've read it differently, the line below shows an example that begins with 'C:\msys64' prefix. So perhaps this was a way to say that the user doesn't have to install msys to that folder.

Noice! Reading through the release notes leaves a feeling of D being a mature language long enough.

If you're looking for magnitutes faster scripting alternative to Python like once me, take a peek!

I'll read through the article but is D really like python in any way? functionals, closures, comprehensions, decorators etc.?

Anonymous lambdas instead of comprehensions, delegates instead of closures. D does not have decorators in the sense Python does, well function attributes might come close. What I do enjoy in D syntax-wise is UFCS: https://tour.dlang.org/tour/en/gems/uniform-function-call-sy...

Array slicing, ranges, compile-time execution. Probably the most succinct and easy-to-read syntax out of many compiled languages. It's an investment (as with any other language) but the learning curve is not steep if you get scared away by C++ or Rust for that matter. Julia comes to mind too in terms of syntax but no UFCS and its interoperability with C++/C looks like a lot of work compared to D.

UFCS is awesome, I had no idea it existed! Implicit classes are my favorite feature of scala[1], I agree .chain syntax is infinitely more readable.

[1] https://riptutorial.com/scala/example/7538/implicit-classes

Unlike in Scala, you can chain your custom methods in D.

For example, seqOfChars.map!(a => a.toLower).filterIfNotDigitChar.sort.uniq; is simply not possible in Scala.

Here is a great presentation about fp in D: http://beza1e1.tuxen.de/stuff/FunctionalD.pdf

It is possible in Scala: https://scastie.scala-lang.org/k7bHR6EWS7qXvaC8gIj3VA

(Unless you mean something different).

True. I forgot about implicits (because I try not to use them :).

Unfortunately it looks more like a kludge tbo. Sort and uniq get also hidden in a class which can be tucked away from your eyes and this is never good.

Thanks for calling my presentation "great". I don't design my slides to work without me talking though.

The official tour has a short page about FP as well: https://tour.dlang.org/tour/en/gems/functional-programming

Anyways, since Walter is probably reading this: Any new insights around this quote five years later?

> I know a lot of the programming community is sold on exclusive constraints (C++ concepts, Rust traits) rather than inclusive ones (D constraints). What I don't see is a lot of experience actually using them long term. They may not turn out so well. –Walter Bright

It would seem that D and Nim have many similar goals and features.

Yes, they are frequently compared. If you like style-insensitive (case insensitivity, underscore ignored) languages with hacker mentality, Nim is for you. This is simply a no-go for me. I briefly tried Nim before even knowing about D and it never stuck with me due to awkward syntax (subjective). Later I learnt that Nim (being a younger language) frequently breaks backward compatibility. Maybe it changed now but all the above was enough to pass it and move on.

What I dislike is the {. .} annotations, Active Oberon also followed that path and I don't find it that great.

Some context would be nice - can you say a little more on that annotation please.

That is how Nim does pragmas,

https://nim-lang.org/docs/manual.html#pragmas

And Active Oberon as well (here called flags),

http://cas.inf.ethz.ch/projects/a2/repository/raw/trunk/Lang...

The way to interpret that statement IMO is that D is a good alternative to using a scripting language. I use it that way all the time - it's almost completely replaced Ruby, which was my previous scripting language of choice.

What about the standard library?

Not as comprehensive as Python.

However, you can write scripts which pull in packages from the internet called "single-file packages": https://dub.pm/advanced_usage

Just tried it myself for the first time:

    #!/usr/bin/env dub
    /+ dub.sdl:
    name "hello"
    dependency "requests" version="1.1.5"
    +/
    import std.stdio : writeln;
    import requests : postContent;

    void main() {
      auto content = postContent("http://httpbin.org/post",
          ["name": "any name", "age": "42"]);
      writeln(content);
    }

On Linux, put this into a file, chmod +x it, and execute. The first time it will take a while (downloading and compiling packages). After that on my crappy laptop it takes:

    0.66user 0.06system 0:01.25elapsed 57%CPU

That is a lot more convenient than venv in Python.

> D being a mature language long enough.

I do not follow D closely, but i get the impression that the language breaks backwards compatibility every now and then - i remember some posts here or Reddit some months ago by someone complaining that Walter Bright introduced some changes to the language that broke existing code.

IMO a mature language is a language that you can depend on for your existing code to keep working in a timespan of decades - like C and C++ for example. A language that willingly breaks backwards compatibility is a toy, not something to be taken seriously for long term work.

The Wikipedia page history section [0] talks about stability. The most relevant part is this:

> The release of Andrei Alexandrescu's book The D Programming Language on June 12, 2010, marked the stabilization of D2, which today is commonly referred to as just "D".

In other words, D is backwards compatible for 10 years now. At least, I don't know any breaks and the little code I have in D never broke.

The transition from D1 to D2 did break backwards compatibility in 2007. The change is comparable to the Python2 to Python3 transition but in a much smaller community. Outdated news from that time still pop up sometimes. Maybe you heard something related to that?

[0] https://en.wikipedia.org/wiki/D_(programming_language)#Histo...

So basically if i write some D code now it'll keep working (assuming no OS ABI changes) and compiling in 20 years from today? I'm ok with very minor changes due to compiler bugs or whatever.

I wonder what that complain was about then.

I have code that I wrote on D like in early 2010's, and keeps working with very minor changes.

Then I guess C and C++ are toys as well, given there are a couple of breaking changes.

K&R C, gets, Annex K, VLA, gone by now in C17.

gets, exception specifications, external templates, std::auto_ptr now gone, RVO semantics changed, and a couple of other minor semantic changes by C++20.

Nobody has removed support for gets nor VLA (of those that bothered to add them in the first place) or anything else they provided.

TBH i'm not sure about modern C++20 since that has been a shitshow anyway.

Apparently you have to update yourself with ISO C contents.

Hint, there are more C compilers out there than clang and GCC.

I know, i've tried a bunch of them and have several C compilers installed but AFAIK none has removed support for gets or VLA (or anything else they bothered to implement). When i wrote "none" i wasn't referring to the standard but to the actual compilers. I do not care what the standard says is deprecated or to be removed, what i care is what compilers actually do since that is what affects existing code.

Have VLAs really been removed from the C language? I can't find a source for this.

What happens some times is that changes in the compiler fixes issues that were not well defined in the specification, or were bugs in the implementation. Programs that used the feature wrongly or that were in fact buggy then break when compiled with the better specified feature. It's comparable to compiling a K&R conforming C program with C89 or C99 enforcing: it will reveal bugs that were none in K&R (type punning, uninitialized variable, prototype violations, etc.).

Reply on news.ycombinator.com