Hello World in D, Go and Rust in VS Code

A few days ago a friend asked me what languages I’m learning. I told him I had been rather lazy of late and was not currently studying any new languages in my programming repertoire. So he said something like this:

每天早上刷牙后研究一种新语言。
Měitiān zǎoshang shuāyá hòu yánjiū yī zhǒng xīn yǔyán.

When I told him I had no idea what he just said, he laughed and explained that he is learning Mandarin and had just told me, “Study a new language after you brush your teeth every morning.” To be honest, I pulled the above Mandarin from Google Translate because I had no way to remember exactly how he had said what he said. But he had successfully goaded me into getting back on the polyglot track. We talked about Rust and Go and D. I’ve played with D some years ago, but have never done anything real with Rust, Go or D.

Here’s Part 1 of my journey through these three languages. The Hello World with a tiny input twist looks like this:

image

I decided to get each of them working in Visual Studio Code. I’m a Windows user, so if you’re on a Mac or using Linux, your mileage will vary. Hopefully what I’ve found here will help you get a start on one or all of these languages as well.

Visual Studio Code

First things first. If you don’t already have it installed, follow the link in the header above and get and install it. It’s simple so I won’t walk you through it here. My first love is the big old fashioned Visual Studio and I’ll continue using it for most of my work, but I wanted to learn more about VS Code as I learn more about these three programming languages. Here’s the version I’m using:

image

Of course you can use your own favorite editor. We’re not going to use any special integrations in VS Code for the Hello World examples here.

Hello in DLang

You can get a pretty good history of DLang here. There are three compilers that support D. In this post, we will only use the DMD compiler, the reference compiler for the language. Download and install DMD. Once installed, open a new console and enter the command DMD. You should get something like this:

[path]>dmd 

DMD32 D Compiler v2.086.0
Copyright (C) 1999-2019 by The D Language Foundation, All Rights Reserved written by Walter Bright

Once you have the compiler installed, install the DLang VS Code extension for D. (There are several. After some experimentation, I found that I liked this one the best but this is by no means a comparison of them, so I’m not mentioning the ones I decided not to use.)

I created the following Hello World in app.d and ran the DMD app.d command in the terminal window in VS Code.

import std.stdio;

void main()
{
	string name;
	write("Hello, what's your name? ");
	readf("%s\n", &name);
	writeln("Hello, ", name);
}

The app.exe produced was 312KB in file size. At run time, it consumed 1,728KB.

Hello in GoLang

I downloaded and installed Go and then the Go VS Code extension. The extension is built by Microsoft, so I expected the VS Code experience to be superior to the other two languages. I was right. This included the automatic suggestion to install several additional Go related extensions which I did.

I was able to run the following code through the debugger, but rather than get into debugging these languages for this post, I wanted to focus on building an executable that would be as close to the same modified Hello World as I could get.

package main

import "fmt"

func main() {
	var name string
	fmt.Printf("Hello, what's your name? ")
	fmt.Scanf("%s\n", &name)
	fmt.Printf("Hello, %s\n", name)
}

The command line to build the executable was a little more tricky but not bad. There are many sites that can help you here. The command go build -o app.exe app.go produced an app.exe that 2,164KB file size but only consumed 1,424KB at runtime. That surprised me a bit. I expect that Go is packing in a whole lot of things into the executable that my little code base is not using.

Hello in Rust-Lang

Next I downloaded and installed Rust for Windows and then added the Rust(rls) VS Code extension. When I first tried to compile this bit of code, I got an error error[E0601]: `main` function not found in crate `app` which seemed odd since there was definitely a main function. After closing and starting VS Code again, the rustc app.rs command line compiled the executable just fine. Perhaps a path had not been picked up.

use std::io;

fn main() {
	let mut name = String::new();
	println!("Hello, what's your name? ");
	io::stdin().read_line(&mut name).expect("Failed to read line.");
	println!("Hello, {}", name);
}

The Rust compiler wins the size competition with an executable coming in at on 154KB for a file size and only 324KB at runtime. Call me impressed.

Video Tutorials

If you like to learn by watching, here are three fairly good YouTube tutorials that I’ve found. There are many more of course. I’m not saying these are the best, but I liked them. I will return to them a few more times as I continue to learn each of these languages.

What’s Next

Most programming language documentation will take you on a journey of variables, control flow, etc. I figure you can read those on your own. Google works just as well for you as it does for me. So next I want to explore the following. Hold me to it.

  1. How to write object oriented code
  2. How to write SOLID code
  3. How to write a RESTful service client and server
  4. How to write scalable code (threading, message passing, etc.)

That seems like a fair number of things to explore. There are a multitude of others that may emerge as I walk down these three learning paths.

Windows Service in the D Programming Language

Nine months ago I blogged about my curiosity about the D programming language. It is possible that this curiosity is turning into a hobby. Time will tell. Recently I decided to create a Windows Service written in the D programming language. I’ll share my journey to that end here.

When I started I assumed it would be easy to find examples in the open source world from which I could learn. That assumption turned out to be mostly false. I found some posts on the forum that were helpful. I then dug up an email address using that famously free detective, Google. Graham Fawcett was very helpful in sharing some code with me but for some reason I could not get it to work.

After a week or more of evenings attempting to find a solution, I gave up and offered a bounty on the forum. And Vladimir Panteleev, a regular D community contributor, came to my rescue and gladly took the $100 bounty to be applied toward other issues he would like to see resolved. My deep thanks to both of these community members.

As it turns out, the code that Graham shared with me would have worked except the Win32 bindings code had an x64 bug that would not have manifested itself had I been compiling for x86. Specifically, the winsvc.d code file contained the line:

alias DWORD SERVICE_STATUS_HANDLE;

I took Vladimir’s advice and changed it to:

alias size_t SERVICE_STATUS_HANDLE;

And then later pulled in his final fix as;

mixin DECLARE_HANDLE!("SERVICE_STATUS_HANDLE");

I won’t try to explain the differences here. In any case, the handle in x64 world needed to be a ulong and it was getting declared as a uint (C# equivalents here). And once that was resolved, I was very happy to see the code work.

You can get or read the code for that first success on GitHub. I refactored that code using a reference app in C++ that followed a familiar pattern having written many Windows Service in C#, even to the point of writing a short cut to standing up a Windows Service in .NET.

In any case, if you are curious to see my first real foray into the world of D programming, you can check out the code on GitHub. It even includes a minor improvement suggested by a forum member already. And if you have questions or need help, please leave a comment and I will do my best to help.

DMD x64 with Visual D in Visual Studio 2013 on Windows 8.1

About ten days ago, I installed the latest Visual D from GitHub and ran into some problems when trying out the DMD/GDC console application to use the “DMD | x64” config to compile a simple console app as an x64 native Windows application.

While I have not yet tested it, I believe the installer would have worked out of the box on my Windows 7 machine. But on my Windows 8.1 laptop, I had some trouble. Rather than boring you with all the things I tried, I will just share what finally worked for me.

Here’s the console app code I was working with:

import std.stdio;

int main(string[] argv)
{
    writeln("Hello D-World!");
	readln();
    return 0;
}

I had downloaded and installed Visual D with VisualD-v0.3.37.exe. I had also downloaded and installed the latest DMD compiler from dlang.org. In the process of figuring things out, I also reinstalled Visual D.

In Visual Studio, I created a new DMD/GDC console app from the D Language tab in the new project dialog. This console app template comes preconfigured with a configuration called "Debug DMD|x64" and I switched to that. But when I hit F6 to build, I would get the following error:

------ Build started: Project: ConsoleApp1, Configuration: Debug DMD x64 ------
Building Debug DMD x64\ConsoleApp1.exe...
LINK : fatal error LNK1181: cannot open input file 'user32.lib'
Building Debug DMD x64\ConsoleApp1.exe failed!
------

After doing some browsing and searching, I found the known issues page and the fix described on the page did not work but it did lead me to do some more digging and experimenting until I found that modifying the sc.ini file with some very specific changes solved the problem. Here are the relevant lines, as modified, in my sc.ini file that finally made it possible for my little program to compile. (update—only the Environment64 changes are required—while Rainer Scheutze suggests that the paths can be modifed in Visual Studio, I’ve not been able to make that work).

[Environment64]
   ; original LIB="%@P%\..\lib64"
   LIB="%@P%\..\lib64";\dm\lib;"C:\Program Files (x86)\Windows Kits\8.0\Lib\win8\um\x64";%DMD_LIB%

This post will be my saved notes for the next time I have to configure a Windows 8.1 machine for D programming language in Visual Studio 2013 (and beyond). And I hope you find it useful too.

Diversions in the D Programming Language

I am not a systems programmer, meaning I do not write operating system device drivers or file systems or operating system modules, etc, all written in a language that will compile down to raw machine code. I write in C# primarily which is arguably an applications programming language, running in the much loved .NET Common Language Runtime.

The vast majority of systems programming is done in C and C++. And for some reason, C++ has always been a daunting mess of libraries, odd syntax and pointer and memory allocation madness to me. Even setting up an environment to get the right build libraries, the right compiler and linker, etc., have always led me to fits of impatience. And for that reason and many others, I have stuck to C# and applications development.

But every once in a while, I look in on systems programming to see if anyone has really solved the problems I love to hate with respect to C and C++. And for a few years I’ve read a little about the D programming language here and there. A week ago, over the weekend, I decided to give it a try and really see what I could learn.

I have to say, I have been impressed. The D programming language offers a few things that I would dearly love to see in C#.

1. Exception Safety – the scope keyword

void abc() 
{ 
  auto resource = getresource();  // acquire some resource 
  scope(exit) resource.close();   // close the resource 
  doSomeProcessing();             // do processing
}

As C# programmers, we’re used to the try..catch..finally blocks. And we clean up a resource in the finally block. The trouble with that is many lines of code can end up separating your resource acquisition code from your resource cleanup code. Yes, with vigilance and well written tests, this is okay. But wouldn’t it be cool to be able to tell the compiler, “Hey, when I’m done with this thing I just now created, clean it up for me, no matter what code comes after this in this method.” I would love to see the scope keyword added to C#.

2. Concurrency approach

int perThread;
shared int PerProcess;

In C#, when you declare a class level variable, it is automatically shared between threads. You can use the [ThreadStatic] attribute to get a per thread instance of a given value or object. But it then has to be static. With the D programming language, you get thread safety in class variables. To override that safety, you have to explicitly tell the compiler you want the value shared. While I’m not advocating a change to C# in this regard, I would love to have a way to assure that a variable cannot be modified across thread boundaries.

3. Message based threads

import std.concurrency, std.stdio;
void main() {
   auto low = 0, high = 100;
   auto tid = spawn(&writer);
   foreach (i; low .. high) {
      writeln("Main thread: ", i);
      tid.send(thisTid, i);
      enforce(receiveOnly!Tid() == tid);
   }
}

void writer() {
   for (;;) {
      auto msg = receiveOnly!(Tid, int)();
      writeln("Secondary thread: ", msg[1]);
      msg[0].send(thisTid);
   }
}

For me, this is perhaps the coolest part of the D programming language’s base class library which they call Phobos. Note that main spawns a thread calling writer. The loop in main then sends a message to writer and the loop in writer receives the messages and operates on them and then sends a message back to the original thread.

You can learn a lot about D on www.dlang.org and read more about D concurrency on Informit. And if you want to play with D in Visual Studio, hop on over to see VisualD on dsource.org.