On Thursday, 20 August 2020 at 21:36:04 UTC, Andre Pany wrote:
On Thursday, 20 August 2020 at 18:13:46 UTC, ddcovery wrote:
On Monday, 17 August 2020 at 15:45:05 UTC, aberba wrote:
[...]
After 18 years following DLang, and some disagrees about
productivity lacks at the beggining (no IDE, Debugging?, an
standard library battle, not a good database connection
library, missing web framework) and Walter adding more and
more compiler functionalities (all of them nice ones) I
decided to forget DLang for a time (C# covered my needs really
well).
Last month I decided it was time to start a new project (my
own company) and I reviewed some languages/frameworks for web
development (REST services, image processing, PDF generation,
...): Java based ones (I'm experienced with
scala/playframework and spring/java, and Kotlin is really
nice), c# and Net core, Node/Typescript (Last 6 years I have
been mainly a node backend developer) and, finally, native
ones (GO, Rust and D... I developed some windows apps in 90's
using Symantec C++ but 20 years are a really long time).
I really wanted to give D an opportunity: lets go with vibe.d
I tested vibe.d on my ubuntu 20.04 and SURPRISE: the hello
world project began to eat all my machine memory (just
requesting with Firefox and CTRL+F5 pressed continuosly).
Using an HAPROXY between calls and backend memory problems
disappeared.
Process doesn't stop properly after CTRL+C... but I decided
not to be so demanding.
I discovered hunt-framework (with a fantastic ORM
implementation) and my eyes shinned. I tried an example
project. Like vibe.d, I began to perform requests with Firefox
and CTRL+F5 pressed and application stopped immediately
(yesterday I discovered it is a SIGPIPE unmanaged signal that
stops the process). I'm quite sure if I use HAPROXY to
intermediate between requests and backend, the problem will
disappear, but I don't want to perform this test, because I
decided not to use hunt-framework neither.
Finally I'm using Rust (with Rocket and Diesel): it's my
money folks :).
Sorry for this not constructive post.
DLang needs to bright in some market niche to attract
developers and to solve the actual most demanded needs: a lot
of developers, like me, expect a good/robust framework for
backend development (web/rest/microservices/data processing)
and a de-facto standard library for Database integration.
In my opinion, "hunt-framework" (or similar) should be one of
the central projects of DLang next years (like vibe.d in the
past) with a really impressive documentation (English,
please!!!) demonstrating how robust, performant and expressive
D lang is.
Actually your feedback is very constructive, thanks a lot. The
ctrl+c issue can be solved with a work around, by adding the
version "VibeHighEventPriority".
I have only a very small vibed backend application (websockset)
and never noticed the memory issue. Also another forum user
which has a quite large web application in productive use
didn't mentioned this issue.
Could I ask you to open a github issue for vibe-d describing
your findings regarding the memory issue?
As far as I remember the GC does not immediately runs, but only
at a certain limit. Maybe your memory issue isn't really an
issue but the desired behavior. (Not an expert here, just what
I remember).
Kind regards
Andre
Thanks a lot Andre,
I opened immediately the issues to receive some feedback:
In vibe.d
https://github.com/vibe-d/vibe.d/issues/2459
In hunt-framework
https://github.com/huntlabs/hunt-framework/issues/161
With vibe.d case, memory is never recalled.
Problems disappear in vibe.d when I introduce an intermediate
HAPROXY... this gave me an idea about the origin of the problem:
Local pipe closed by destination (that haproxy manages nicely)
Linux man page about write and EPIPE:
https://linux.die.net/man/2/write
EPIPE
fd is connected to a pipe or socket whose reading end is
closed. When this happens
the writing process will also receive a SIGPIPE signal.
(Thus, the write return
value is seen only if the program catches, blocks or ignores
this signal.)
I have to recognize I learned this last days (I am not a native
linux developer, but I began to recall my past knowledge about it
:-)
The main reason I have dropped the 2 frameworks for my new
project:
* Entry "ready for use" projects simple examples must work (I
can't be confident that projects based on them will be stable on
production if basic projects fail in development)
