June 09, 2022

On 6/9/22 5:28 PM, Paul wrote:

>

Our company (www.ucora.com) created GamePlanPro in D 7 years ago. GPP is a web-based workflow platform used by a majority of our customers. Quotes, work orders, invoices, asset management, scheduling, periodic maintenance, reporting, user created procedures and forms, CRM, and user management. We are fully invested in D and we hope to see it grow in popularity.

This sounds amazing! I've been doing quite a bit of the same (I gave a presentation in 2018 on my efforts to port a php tracking system to vibe-d, it's still ongoing).

Did you use an OTS web framework (vibe/hunt) or build your own? I'm just curious.

-Steve

June 09, 2022

On Thursday, 9 June 2022 at 21:35:49 UTC, Steven Schveighoffer wrote:

>

On 6/9/22 5:28 PM, Paul wrote:

>

Our company (www.ucora.com) created GamePlanPro in D 7 years ago. GPP is a web-based workflow platform used by a majority of our customers. Quotes, work orders, invoices, asset management, scheduling, periodic maintenance, reporting, user created procedures and forms, CRM, and user management. We are fully invested in D and we hope to see it grow in popularity.

This sounds amazing! I've been doing quite a bit of the same (I gave a presentation in 2018 on my efforts to port a php tracking system to vibe-d, it's still ongoing).

Did you use an OTS web framework (vibe/hunt) or build your own? I'm just curious.

-Steve

I'll out myself as some one who is also associated with Ucora, I'm one of the original founders. I was the one who discovered D and eventually adopted it as our choice language. To answer your question, yes we did consider Vibe, it was a long time ago, and at that time it wasn't really suitable for embedding into our applications. We prefer fully embedded as opposed to separate. I think a lot of work was eventually done to make Vibe more suitable to integrate into a package, and we should revisit because we are looking for an alternative. The tool we're still using (tntnet) is based on C++ and runs as a separate process. it's not what we want but has worked well enough that no one took the time to move one to better alternatives. The situation for us is changing, we really do want an embedded solution.

June 09, 2022

On Thursday, 9 June 2022 at 22:23:24 UTC, Rob T wrote:

>

We prefer fully embedded as opposed to separate.

What do you mean by embedding here?

June 09, 2022

Hi Steven

GPP would not have been possible without D. We know this because we created a previous workflow system in C++. It was a painful slow slog to develop. Once you go with D, you can never go back. I would hazard a guess of it making us 10 times more efficient at coding, however I don't have hard numbers to prove this. Still, if anyone sees a demo of GPP, they would be shocked to find that it was created with such a tiny team. Previously, we came from a background of c, c++, PHP, Javascript, and some other languages so old I would be embarrassed to mention them (such as Pascal!) Our lines of code alone is reduced by at last a factor of 10 with D.

And yet, even someone within our own team will question why we are using such an obscure language. "Why aren't we using nodejs? Everyone is using it." (It breaks me to hear that.) So, nothing would make us happier than to see D grow in popularity. Our wish is to see D reach out and draw people in. To make it easy for them to get started, without ever compromising the core vision. It really should be the next dominant compiled programming language.

How to do this? I am the furthest from an expert. There must be examples to learn from, on how others have succeeded with inferior products. And how to avoid it being polluted by people who don't really understand the core reasoning behind the design choices? Always a challenge.

June 10, 2022

On Wednesday, 8 June 2022 at 18:34:20 UTC, Paul wrote:

>

I see your point Bauss. I suppose I am not yet experienced enough with D.

Here is an example. Working with one of our programmers, he could not understand the following (sorry for my newbie simplistic example and understanding of D):

The D community so far has said you just need to learn it and the documentation makes sense. I think that summary speaks volumes about missing the point of documentation but that is the reality in D. You have to learn it from books and forum and then you pretty much don't need the documentation.

Just a few days ago, I actually posted about documentation, among other things, but I threw 80% of that reply away because I'm trying to be less negative on the forum. Here is the excerpt:

In fact, I'm on the forum right now because I was looking for a map function in D. Here it is:
https://dlang.org/library/std/algorithm/iteration/map.map.html.

The map function is there and it works really well. But go ask 10 of your co-workers (that haven't used D) how this function works and maybe 2 or 3 can even guess something close. I don't even know for sure how I specify the mapping function (sometimes it's a function, sometimes it's a string) but with a bit of trial and error, I'll figure it out. There's not even an example of usage in the documentation.

The documentation is not good is not a way to learn D, although it is somewhat useful. If you want your team to learn and get familiar with D enough to use the documentation, I would suggest you get Andrei's and Adam's books. There are other good books as well I'm sure, but I have not read them. Some sit in my Amazon cart where I covet them from time to time. ;) You might find comments about them being out of date, but by the time your colleagues are done with them, they will be able to understand the documentation.

I hate to bug people on the forum, but I know if I have a question, I will get a response by the next day, but usually a lot faster than that.

So if I were you, I would solve the immediate problem by getting and distributing those book as well as inviting your colleagues onto the forum if they have questions you can't answer.

In the medium term, you could start a knowledge base or documentation site or maybe join one of the dozens of others that undoubtedly exist.

The long term problem is harder to address. Until building documentation, tools and library is sustainable, people won't do it. I have spent a lot of effort on projects that die (including D programs, as it happens) and I have a lot going on in my life. It's going to take a large effort to establish clear goals and visions with a known way to work on them or it may take forking the language and leaving one stable for a bit before people decide. I hope that happens before another language enters D's odd niche.

June 10, 2022

On Thursday, 9 June 2022 at 23:13:06 UTC, Paul wrote:

>

How to do this? I am the furthest from an expert. There must be examples to learn from, on how others have succeeded with inferior products. And how to avoid it being polluted by people who don't really understand the core reasoning behind the design choices? Always a challenge.

Open source libraries tend to attract people to languages.
The more ecosystem we have, the more people can disrupt legacy verticals.
People don't change their mind until you compete with them. :)

Also getting on Orgs-using-D page, filing bugs, going to DConf.
Telling your story like this is very inspiring!

June 10, 2022

On Thursday, 9 June 2022 at 22:53:04 UTC, Adam Ruppe wrote:

>

On Thursday, 9 June 2022 at 22:23:24 UTC, Rob T wrote:

>

We prefer fully embedded as opposed to separate.

What do you mean by embedding here?

What I mean by that is incorporate the http code directly into our application and compile it into a single executable binary, ie no separate process for handling https requests. Having said that, ideally the http code should be in the form of a standard library that we tap into, just as we do with any other library.

What we do not want or need is a traditional style http server process that is feeding typical web apps, we're not running a typical web app, the web side is simply the user interface, that's the only use we have for it.

June 10, 2022

On Friday, 10 June 2022 at 00:35:17 UTC, Rob T wrote:

>

What I mean by that is incorporate the http code directly into our application and compile it into a single executable binary

Huh, I'm surprised you had trouble with vibe since it works that way too.

Of course, I have my own D libraries (the oldest continually maintained web code in D) which is not just embedded, it is a single source file http server with no extra dependencies!

...but I never bothered doing https support since I prefer to use the outer proxy server for that. Probably about 50 lines to add it, maybe I will one of these days.

June 10, 2022

On Friday, 10 June 2022 at 00:59:00 UTC, Adam Ruppe wrote:

>

On Friday, 10 June 2022 at 00:35:17 UTC, Rob T wrote:

>

What I mean by that is incorporate the http code directly into our application and compile it into a single executable binary

Huh, I'm surprised you had trouble with vibe since it works that way too.

Of course, I have my own D libraries (the oldest continually maintained web code in D) which is not just embedded, it is a single source file http server with no extra dependencies!

...but I never bothered doing https support since I prefer to use the outer proxy server for that. Probably about 50 lines to add it, maybe I will one of these days.

Yeah last I remember Vibe was being re-coded to work like a library rather than only as an http server, like I said it was a long time ago when I was looking around at Vibe. I'll take a good look again, it sounds promising. I'll also take a look at your library as well, this must be it https://code.dlang.org/packages/arsd-official%3Ahttp

We also use a proxy (haproxy), main reason is we still have to support ipv4, and a proxy is ideal solution for a server with only 1 ipv4 address. We run most things today as lxc containerised appliances, one server will have many containers. A proxy however does come with a single point of failure issue, it would be more ideal for ipv6 enabled clients to by-pass the proxy and go directly to each container.

June 10, 2022
On Friday, 10 June 2022 at 00:59:00 UTC, Adam Ruppe wrote:
> On Friday, 10 June 2022 at 00:35:17 UTC, Rob T wrote:
>> What I mean by that is incorporate the http code directly into our application and compile it into a single executable binary
>
> Huh, I'm surprised you had trouble with vibe since it works that way too.
>
> Of course, I have my own D libraries (the oldest continually maintained web code in D) which is not just embedded, it is a single source file http server with no extra dependencies!
>
> ...but I never bothered doing https support since I prefer to use the outer proxy server for that. Probably about 50 lines to add it, maybe I will one of these days.

Here we are using your code as a base for our single process backend (well, copy-pasting only the needed parts of it).

It was easier to add SSL support directly using Deimos than configuring NGINX. But we don't have big workloads to deal with.

/P