www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - vibe.d / experience / feedback

reply =?UTF-8?B?Um9iZXJ0IE0uIE3DvG5jaA==?= <robert.muench saphirion.com> writes:
Hi, we are currently using vibe.d for a prototype and I want to post some
experiences. I know one shouldn't only address the problems but provide some
solutions. 

However, our current use-case is that we want to get a job done, and not
creating a web-framework. 

1. For many things the docs are missing, or inconsistent, or wrong. So, it's
pretty hard to make your way through it. Or you just start reading the code
and reverse engineer vibe. => We are waisting a lot of time.

2. There are many inconsistencies / half-done implementations in vibe. Again,
this makes it hard to find out what works, what doesn't or which parts behave
differently. => Costs a lot of time.

3. Vibe can't handle GET & POST on the same URL... and the bad thing is, the
later route will just be ignored, so you don't get any hint or crash. The docs
don't mention this clearly. => We waisted a lot of time to find out, that this
doesn't work.

4. Vide uses an own JSON type, not the standard one. We don't understand why,
this just makes things much more complicated and one has to mess around with
this.

5. One can't access the raw HTTP request body, things must be go through
Vibe's JSON parser. To get access to the raw body, a lot of workarounds are
necessary.

So, overall... compared to other web-frameworks we know, there are many
pitfalls which just cost a lot of time... We think it's a good base, but there
needs to be much less magic, much better docs, much less complexity.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Sep 30 2020
next sibling parent reply mipri <mipri minimaltype.com> writes:
On Thursday, 1 October 2020 at 06:32:23 UTC, Robert M. Münch 
wrote:

 5. One can't access the raw HTTP request body, things must be 
 go through Vibe's JSON parser. To get access to the raw body, a 
 lot of workarounds are necessary.


given an HTTPServerRequest req,
req.bodyReader.readAll for binary data and .readAllUTF8 for text.
Sep 30 2020
parent ab <andreas.bolka saphirion.com> writes:
On Thursday, 1 October 2020 at 06:39:39 UTC, mipri wrote:

 On Thursday, 1 October 2020 at 06:32:23 UTC, Robert M. Münch 
 wrote:

 5. One can't access the raw HTTP request body, things must be 
 go through Vibe's JSON parser. To get access to the raw body, 
 a lot of workarounds are necessary.


 given an HTTPServerRequest req,
 req.bodyReader.readAll for binary data and .readAllUTF8 for 
 text.


thanks. that was tough to find from 
https://vibed.org/api/vibe.core.stream/InputStream (because it's 
located and thus documented in the helper module 
https://vibed.org/api/vibe.stream.operations/). a link from 
InputStream to vibe.stream.operations would be super-good.
Oct 01 2020
prev sibling next sibling parent reply ab <andreas.bolka saphirion.com> writes:
On Thursday, 1 October 2020 at 06:32:23 UTC, Robert M. Münch 
wrote:

 3. Vibe can't handle GET & POST on the same URL...


we solved this one as well: fortunately (and: of course) vibe can 
handle this.

what lead us to believe otherwise, was that, unfortunately, one 
of the handlers crashed (effectively due to a `cast(JSONValue)` 
of a `Json.Undefined`), without any visible error output; and the 
only visible error was a "no route matches path" output from vibe.

sorry for the confusion.
Oct 01 2020
parent WebFreak001 <d.forum webfreak.org> writes:
On Thursday, 1 October 2020 at 08:24:42 UTC, ab wrote:

 On Thursday, 1 October 2020 at 06:32:23 UTC, Robert M. Münch 
 wrote:

 3. Vibe can't handle GET & POST on the same URL...


 we solved this one as well: fortunately (and: of course) vibe 
 can handle this.

 what lead us to believe otherwise, was that, unfortunately, one 
 of the handlers crashed (effectively due to a `cast(JSONValue)` 
 of a `Json.Undefined`), without any visible error output; and 
 the only visible error was a "no route matches path" output 
 from vibe.

 sorry for the confusion.


did you run your app with `--vvvv`? it usually logs stuff like 
this there then.
Oct 01 2020
prev sibling next sibling parent aberba <karabutaworld gmail.com> writes:
On Thursday, 1 October 2020 at 06:32:23 UTC, Robert M. Münch 
wrote:

 Hi, we are currently using vibe.d for a prototype and I want to 
 post some experiences. I know one shouldn't only address the 
 problems but provide some solutions.

 [...]



I've been in a similar position once... when it slows you down. 
Vibe could stay simple and break things down into separate 
packages.

The docs is also a major issue. But try filling issues like these 
on the repo.
Oct 01 2020
prev sibling next sibling parent reply Denis Feklushkin <feklushkin.denis gmail.com> writes:
On Thursday, 1 October 2020 at 06:32:23 UTC, Robert M. Münch 
wrote:


 4. Vide uses an own JSON type, not the standard one. We don't 
 understand why, this just makes things much more complicated 
 and one has to mess around with this.


Because standard implementation worse?


 5. One can't access the raw HTTP request body, things must be 
 go through Vibe's JSON parser. To get access to the raw body, a 
 lot of workarounds are necessary.


Can you create PR?
Oct 02 2020
parent reply Martin <martin.brzenska googlemail.com> writes:
On Friday, 2 October 2020 at 09:46:09 UTC, Denis Feklushkin wrote:

 Because standard implementation worse?


What do you mean with "worse"?
In my experience std.json is a very thin implementation of the 
JSON spec - without/very low "magic". IMO this is what one wants 
in a std lib. Its a good starting point for further simplfication 
wrappers or framework specific magic (what vibe actually do, if i 
am not mistaken
Oct 03 2020
parent reply 0xEAB <desisma heidel.beer> writes:
On Saturday, 3 October 2020 at 07:54:58 UTC, Martin wrote:

 On Friday, 2 October 2020 at 09:46:09 UTC, Denis Feklushkin 
 wrote:

 Because standard implementation worse?


 What do you mean with "worse"?


It's said to be pretty slow…
Oct 03 2020
parent reply =?UTF-8?B?Um9iZXJ0IE0uIE3DvG5jaA==?= <robert.muench saphirion.com> writes:
On 3 Oct 2020 at 13:14:57 CEST, "0xEAB" <desisma heidel.beer> wrote:


 On Saturday, 3 October 2020 at 07:54:58 UTC, Martin wrote:

  On Friday, 2 October 2020 at 09:46:09 UTC, Denis Feklushkin 
  wrote:

  Because standard implementation worse?


 
  What do you mean with "worse"?


 
 It's said to be pretty slow…


Well, then it should be fixed... it doesn't make sense to spread N version
because everyone things, A or B is not fitting for such a code framework. 

And, this argument sounds like pre-mature optimization. Who has a real life
use-case where the std lib JSON thing is too slow? By how much?

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Oct 03 2020
next sibling parent reply shamsmehra90 <shamsmehra1990 gmail.com> writes:
thank you for sharing this information with us...
Oct 11 2020
parent reply shamsmehra90 <shamsmehra1990 gmail.com> writes:
I could not even find demo code doing a redirect which is the 
most basic stuff. https://mcdvoicesurvey.onl 
https://mybk-experience.onl
Oct 17 2020
parent Andre Pany <andre s-e-a-p.de> writes:
On Saturday, 17 October 2020 at 16:35:29 UTC, shamsmehra90 wrote:

 I could not even find demo code doing a redirect which is the 
 most basic stuff. https://mcdvoicesurvey.onl 
 https://mybk-experience.onl


There are 6 examples doing a redirect:
https://github.com/vibe-d/vibe.d/search?q=redirect&type=


Also doing a google search for:
vibe.d redirect
Will show you the correct api as first hit.

Kind regards
Andre
Oct 17 2020
prev sibling parent reply aberba <karabutaworld gmail.com> writes:
On Saturday, 3 October 2020 at 11:31:27 UTC, Robert M. Münch 
wrote:

 On 3 Oct 2020 at 13:14:57 CEST, "0xEAB" <desisma heidel.beer> 
 wrote:


 On Saturday, 3 October 2020 at 07:54:58 UTC, Martin wrote:

  On Friday, 2 October 2020 at 09:46:09 UTC, Denis Feklushkin
  wrote:

  Because standard implementation worse?


 
  What do you mean with "worse"?


 
 It's said to be pretty slow…


 Well, then it should be fixed... it doesn't make sense to 
 spread N version because everyone things, A or B is not fitting 
 for such a code framework.

 And, this argument sounds like pre-mature optimization. Who has 
 a real life use-case where the std lib JSON thing is too slow? 
 By how much?



The community discord is a great place to get help BTW. Wherever 
issue it is, I'm sure you'll find solution there.
Oct 13 2020
parent reply Alaindevos <devosalain ymail.com> writes:
What is weird is that rails is THE ruby application , that flask 
is the python application, and that dlang can't have something 
like that in their standard library.
An opportunity missed.
On the other hand I don't understand the interest in Java/swing 
when there is a good working gtkd which is a good working and 
beautiful framework.
Oct 13 2020
parent reply aberba <karabutaworld gmail.com> writes:
On Tuesday, 13 October 2020 at 15:02:08 UTC, Alaindevos wrote:

 What is weird is that rails is THE ruby application , that 
 flask is the python application, and that dlang can't have 
 something like that in their standard library.
 An opportunity missed.
 On the other hand I don't understand the interest in Java/swing 
 when there is a good working gtkd which is a good working and 
 beautiful framework.


What exactly do you want to do with vibe.d that it can't anyway?
Oct 13 2020
parent Alain De Vos <devosalain ymail.com> writes:
I find the code with   ugly. But i know this is not a good 
argument. Maybe the glue could have been done better. I think 
there is a lot of functionality but I don't understand it by 
looking at the code which you easily can with flask or rails.
Oct 13 2020
prev sibling next sibling parent Arun <aruncxy gmail.com> writes:
On Thursday, 1 October 2020 at 06:32:23 UTC, Robert M. Münch 
wrote:

 Hi, we are currently using vibe.d for a prototype and I want to 
 post some experiences. I know one shouldn't only address the 
 problems but provide some solutions.

 However, our current use-case is that we want to get a job 
 done, and not creating a web-framework.

 1. For many things the docs are missing, or inconsistent, or 
 wrong. So, it's pretty hard to make your way through it. Or you 
 just start reading the code and reverse engineer vibe. => We 
 are waisting a lot of time.

 2. There are many inconsistencies / half-done implementations 
 in vibe. Again, this makes it hard to find out what works, what 
 doesn't or which parts behave differently. => Costs a lot of 
 time.

 3. Vibe can't handle GET & POST on the same URL... and the bad 
 thing is, the later route will just be ignored, so you don't 
 get any hint or crash. The docs don't mention this clearly. => 
 We waisted a lot of time to find out, that this doesn't work.

 4. Vide uses an own JSON type, not the standard one. We don't 
 understand why, this just makes things much more complicated 
 and one has to mess around with this.

 5. One can't access the raw HTTP request body, things must be 
 go through Vibe's JSON parser. To get access to the raw body, a 
 lot of workarounds are necessary.

 So, overall... compared to other web-frameworks we know, there 
 are many pitfalls which just cost a lot of time... We think 
 it's a good base, but there needs to be much less magic, much 
 better docs, much less complexity.


I concur with 1 and 2. We waste lot of time trying to understand 
vibe code instead of working on the business logic.

Never had issues with 3.

I've found vibe JSON to be a relative of nlohmann::json 
https://github.com/nlohmann/json
Similar API, seamless code reusability (copy paste). I never 
really cared about std.json as the usability is not good.

5. is definitely possible with readAll. Never had issues with 
this. Just dig more into the code ☺️
Oct 05 2020
prev sibling next sibling parent reply ddcovery <antoniocabreraperez gmail.com> writes:
On Thursday, 1 October 2020 at 06:32:23 UTC, Robert M. Münch 
wrote:

 Hi, we are currently using vibe.d for a prototype and I want to 
 post some experiences. I know one shouldn't only address the 
 problems but provide some solutions.

 However, our current use-case is that we want to get a job 
 done, and not creating a web-framework.
 ...
 So, overall... compared to other web-frameworks we know, there 
 are many pitfalls which just cost a lot of time... We think 
 it's a good base, but there needs to be much less magic, much 
 better docs, much less complexity.


Hi Robert,

I found myself in a similar situation recently, and I can't help 
but ask you: What technology do you use regularly? What 
drives/draws you to try dlang/vibe.d? Do you have other 
alternatives to dlang/vibe.d for your project?
In my case we usually work in Node+js/ts (previously Scala+Play) 
and I wanted to jump to something really performant for a new 
project without losing code expressiveness and development speed. 
Dlang seemed a good alternative (I like it much more than Go or 
Rust).
Oct 06 2020
next sibling parent reply Alaindevos <devosalain ymail.com> writes:
For a framework to be successful you need at least a minimum of 
sample code in public domain.
For vibe it is none existent.
I could not even find demo code doing a redirect which is the 
most basic stuff.
The number of books on a framework is also an indication of the 
success after a few years.
Compare for instance to Flask or rails.
Also a framework must concentrate on one task.
A web framework should not care about sql. Neither a GUI 
framework.
Oct 10 2020
parent Andre Pany <andre s-e-a-p.de> writes:
On Saturday, 10 October 2020 at 16:00:47 UTC, Alaindevos wrote:

 For a framework to be successful you need at least a minimum of 
 sample code in public domain.
 For vibe it is none existent.
 I could not even find demo code doing a redirect which is the 
 most basic stuff.
 The number of books on a framework is also an indication of the 
 success after a few years.
 Compare for instance to Flask or rails.
 Also a framework must concentrate on one task.
 A web framework should not care about sql. Neither a GUI 
 framework.


For samples of redirect please see here
https://github.com/vibe-d/vibe.d/search?q=redirect&type=

But yes, I got your point. Vibe.d and a lot other projects in the 
D ecosystem are currently at the point where each community 
member could help to make a little improvement here and there 
(including documentation/ sample coding / blog posts ,...).

Kind regards
Andre
Oct 10 2020
prev sibling parent reply =?UTF-8?B?Um9iZXJ0IE0uIE3DvG5jaA==?= <robert.muench saphirion.com> writes:
On 6 Oct 2020 at 10:07:56 CEST, "ddcovery" <antoniocabreraperez gmail.com>
wrote:


 I found myself in a similar situation recently, and I can't help 
 but ask you: What technology do you use regularly?


Hi, well we use a couple of different things. Scripting languages, C, Lua,
..


 What drives/draws you to try dlang/vibe.d?


A prototype we wanted to build while evaluating D as our next tech stack
foundation.


 Do you have other alternatives to dlang/vibe.d for your project?


Yes. We are currently looking into Go as well.


 In my case we usually work in Node+js/ts (previously Scala+Play) 
 and I wanted to jump to something really performant for a new 
 project without losing code expressiveness and development speed. 
 Dlang seemed a good alternative (I like it much more than Go or 
 Rust).


Well, for us it's getting more and more clear, that a decision what to use in
the future will be based on less and less technical aspects.

The interesting thing about Go is, that their main focus is thinking from an
enterprise perspective, not only from a technical one. So, their focus is
getting stuff done, keeping maintainability in big, constantly changing teams
and stripping everything away, that reduces productivity in such an
environment... I don't know about any other language which puts all these
non-technical aspects on the top of the agenda.

Viele Grüsse.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Oct 11 2020
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 11 October 2020 at 11:56:29 UTC, Robert M. Münch wrote:

 environment... I don't know about any other language which puts 
 all these non-technical aspects on the top of the agenda.


Ada, Java, Eiffel are supposed to.

I'm not sure if Go is a success in that department either. I 
suspect it tanks when programs get large.
Oct 11 2020
parent reply =?UTF-8?B?Um9iZXJ0IE0uIE3DvG5jaA==?= <robert.muench saphirion.com> writes:
On 11 Oct 2020 at 16:46:13 CEST, "Ola Fosheim Grøstad"
<ola.fosheim.grostad gmail.com> wrote:


 Ada, Java, Eiffel are supposed to.


Yes... beside Java, the other two are already in the exotic department...


 I'm not sure if Go is a success in that department either. I 
 suspect it tanks when programs get large.


Go seems to be kept as simple as possible, even if you have to write more
code. Which is, in the long run, the cheaper and smaller burden. No tricks, no
surprises... that has a lot of merits.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Oct 12 2020
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 12 October 2020 at 11:06:55 UTC, Robert M. Münch wrote:

 Go seems to be kept as simple as possible, even if you have to 
 write more code. Which is, in the long run, the cheaper and 
 smaller burden. No tricks, no surprises... that has a lot of 
 merits.


Yes, it is a good fit for web services with medium sized code 
bases.

Or for Google Cloud Functions. Then you write one program for 
each request handler. This is where I am heading.

The advantage with such a solution is that you can write one 
handler in Python, another in Go and perhaps one in node.js.
Oct 12 2020
parent reply =?UTF-8?B?Um9iZXJ0IE0uIE3DvG5jaA==?= <robert.muench saphirion.com> writes:
On 12 Oct 2020 at 13:13:27 CEST, "Ola Fosheim Grøstad"
<ola.fosheim.grostad gmail.com> wrote:


 Yes, it is a good fit for web services with medium sized code 
 bases.


We don't have a lot of "big project" experience with Go yet, but we would use
it for a plain-old desktop application.

Even most people seem to use Go for the web services stuff, I think it might
be underrate for desktop apps.

Viele Grüsse.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Oct 12 2020
next sibling parent Andre Pany <andre s-e-a-p.de> writes:
On Monday, 12 October 2020 at 11:21:40 UTC, Robert M. Münch wrote:

 On 12 Oct 2020 at 13:13:27 CEST, "Ola Fosheim Grøstad" 
 <ola.fosheim.grostad gmail.com> wrote:


 Yes, it is a good fit for web services with medium sized code 
 bases.


 We don't have a lot of "big project" experience with Go yet, 
 but we would use it for a plain-old desktop application.

 Even most people seem to use Go for the web services stuff, I 
 think it might be underrate for desktop apps.

 Viele Grüsse.


Just to avoid a wrong impression, there are also a lot of 
projects using vibe-d with great success (small companies and big 
size enterprises).
In my case I needed a websocket server, which will run on 
Kubernetes. The documentation was available and usable. Also a 
sample was available as far as I remember. I had here the "get 
things done" experience.

Kind regards
Andre
Oct 12 2020
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 12 October 2020 at 11:21:40 UTC, Robert M. Münch wrote:

 Even most people seem to use Go for the web services stuff, I 
 think it might be underrate for desktop apps.


Go is good at what it has Go libraries for, and I believe it has 
gotten quite a few over the past years, some that has been 
translated from Python. If you look at some of the 
awesome-go-lists on github then you get a picture of whether it 
will be a good fit for your project.
Oct 12 2020
prev sibling next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 12 October 2020 at 11:06:55 UTC, Robert M. Münch wrote:

 Go seems to be kept as simple as possible, even if you have to 
 write more code. Which is, in the long run, the cheaper and 
 smaller burden. No tricks, no surprises... that has a lot of 
 merits.


Btw, Go has some major weaknesses related to tricks and surprises:

1. No exceptions... they encourage old 70s-style checking of 
errors everywhere. That makes code much less readable. It is 
possible to roll your own mechanism using their panic() feature, 
but most Go enthusiasts frown upon that. (ignore them, they are 
clueless)

2. Not as strong typing as it should have. Things related to 
interfaces may not be detected until runtime if you get sloppy 
with it. (avoid very generic interfaces)

3. I believe dynamic arrays are reallocated automatically, like 
in D. So in Go, if you extend a dynamic array it will relocate 
and old slices will peek to the old copy:
	a := make([]int, 3)
	b := a[:]
	a = append(a,4,5,6)
	b[2] = 3;
	
	fmt.Println(a)
	fmt.Println(b)
output:
[0 0 0 4 5 6]
[0 0 3]

So you have to define your own coding standard to avoid such 
issues. Basically, ignore what is touted as Go idioms and create 
a ruleset that makes sense for you.
Oct 12 2020
parent =?UTF-8?B?Um9iZXJ0IE0uIE3DvG5jaA==?= <robert.muench saphirion.com> writes:
On 12 Oct 2020 at 21:58:12 CEST, "Ola Fosheim Grøstad"
<ola.fosheim.grostad gmail.com> wrote:


 On Monday, 12 October 2020 at 11:06:55 UTC, Robert M. Münch wrote:

  Go seems to be kept as simple as possible, even if you have to 
  write more code. Which is, in the long run, the cheaper and 
  smaller burden. No tricks, no surprises... that has a lot of 
  merits.


 
 Btw, Go has some major weaknesses related to tricks and surprises:


I don't expect Go to be perfect and as with every language you need to get a
good sense of the dark corners. At least it looks like there are not so many
of them, and as long as you are doing "normal" stuff you won't be bitten too
frequent.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Oct 13 2020
prev sibling parent reply aberba <karabutaworld gmail.com> writes:
On Monday, 12 October 2020 at 11:06:55 UTC, Robert M. Münch wrote:

 On 11 Oct 2020 at 16:46:13 CEST, "Ola Fosheim Grøstad" 
 <ola.fosheim.grostad gmail.com> wrote:


 Ada, Java, Eiffel are supposed to.


 Yes... beside Java, the other two are already in the exotic 
 department...


 I'm not sure if Go is a success in that department either. I 
 suspect it tanks when programs get large.


 Go seems to be kept as simple as possible, even if you have to 
 write more code. Which is, in the long run, the cheaper and 
 smaller burden. No tricks, no surprises... that has a lot of 
 merits.


Aside all the issues with the D ecosystem... which requires 
writing certain stuff yourself. And things like vibe.d not well 
documented, here's one thing that D gives that I don't get 
anywhere else.

D is a great language that is capable of solving any problem 
easier than what it'll take to do in equivalent languages.

D's ecosystem is not currently where I would want it to be... 
simply not enough dub packages and alternatives.

Vibe.d for instance is great but it's currently moving at slow 
pace because Sonke isn't able to work on it as much as he used 
to. Personally I think it should just focus on the core base and 
let others extend on it.

But it's only a matter of time. Certain things are very doable in 
vibe.d but I guess there's not enough blog posts on vibe.d.


D is a language you learn once and use every. Just hope the 
ecosystem gets better to meet business needs... getting things 
done.
Oct 13 2020
parent reply =?UTF-8?B?Um9iZXJ0IE0uIE3DvG5jaA==?= <robert.muench saphirion.com> writes:
On 13 Oct 2020 at 09:57:14 CEST, "aberba" <karabutaworld gmail.com> wrote:


 D is a great language that is capable of solving any problem 
 easier than what it'll take to do in equivalent languages.


Don't get me wrong, D is great, it has a lot of technically cool things on
board.

As said, those technical things won't be our major decision aspect. The
non-technical aspects are more important when looking from a company
perspective.


 D is a language you learn once and use every.


The question is: Which language and eco-system take how much time to learn to
become productive? As team? How to handle a code-base that requires multi-year
maintenance?


 Just hope the  ecosystem gets better to meet business needs... 


Well, from a business perspective "hope" is a very bad advisor.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Oct 13 2020
parent reply Andre Pany <andre s-e-a-p.de> writes:
On Tuesday, 13 October 2020 at 17:08:04 UTC, Robert M. Münch 
wrote:

 On 13 Oct 2020 at 09:57:14 CEST, "aberba" 
 <karabutaworld gmail.com> wrote:


 D is a great language that is capable of solving any problem 
 easier than what it'll take to do in equivalent languages.


 Don't get me wrong, D is great, it has a lot of technically 
 cool things on board.

 As said, those technical things won't be our major decision 
 aspect. The non-technical aspects are more important when 
 looking from a company perspective.


 D is a language you learn once and use every.


 The question is: Which language and eco-system take how much 
 time to learn to become productive? As team? How to handle a 
 code-base that requires multi-year maintenance?


 Just hope the  ecosystem gets better to meet business needs...


 Well, from a business perspective "hope" is a very bad advisor.


My opinion: D really shines when it comes to long code base 
maintenance. It is easy to write beautiful, expressive and high 
quality code.

While there could be more native D libraries, please do not 
forget that you can use easily any (battle tested) C library by 
having a minimal D wrapper. Everything I needed, I was always 
able to find s.th. (Kafka, Parquet, AWS, Azure).

 From a business perspective, using D is a success story.

Kind regards
Andre
Oct 13 2020
parent reply Alaindevos <devosalain ymail.com> writes:
One concept at a time.
This is one of the simplest examples in vibe.d.
I look for the code for the same functionality but without 
authentication/login.
https://github.com/vibe-d/vibe.d/blob/master/examples/web/source/app.d
Where are the   lines explained ?
Oct 14 2020
parent reply Andre Pany <andre s-e-a-p.de> writes:
On Wednesday, 14 October 2020 at 12:29:24 UTC, Alaindevos wrote:

 One concept at a time.
 This is one of the simplest examples in vibe.d.
 I look for the code for the same functionality but without 
 authentication/login.
 https://github.com/vibe-d/vibe.d/blob/master/examples/web/source/app.d
 Where are the   lines explained ?


While this is already a sophisticated example and you might look 
for a simpler one (app skeleton/http server) I really like this 
example.
You can read the source code like a story and the comments 
actually described the purposes of the   UDAs.

(They are also new for me, I only use the WebSocket server part 
of Vibe.d so far).

Kind regards
Andre
Oct 14 2020
parent reply Alaindevos <devosalain ymail.com> writes:
Is there an example just more functional then skeleton http 
server ?
Sending data to the server and back .
Oct 14 2020
next sibling parent Alaindevos <devosalain ymail.com> writes:
forms.
Oct 14 2020
prev sibling parent aberba <karabutaworld gmail.com> writes:
On Wednesday, 14 October 2020 at 15:11:29 UTC, Alaindevos wrote:

 Is there an example just more functional then skeleton http 
 server ?
 Sending data to the server and back .


If you're having vibe.d trouble and can't get a quick response, 
jump in the discord. We're there to help?
Oct 17 2020
prev sibling next sibling parent reply tastyminerals <tastyminerals gmail.com> writes:
On Sunday, 11 October 2020 at 11:56:29 UTC, Robert M. Münch wrote:

 On 6 Oct 2020 at 10:07:56 CEST, "ddcovery" 
 <antoniocabreraperez gmail.com> wrote:


 I found myself in a similar situation recently, and I can't 
 help but ask you: What technology do you use regularly?


 Hi, well we use a couple of different things. Scripting 
 languages, C, Lua, ..


 What drives/draws you to try dlang/vibe.d?


 A prototype we wanted to build while evaluating D as our next 
 tech stack foundation.


 Do you have other alternatives to dlang/vibe.d for your 
 project?


 Yes. We are currently looking into Go as well.


 In my case we usually work in Node+js/ts (previously 
 Scala+Play) and I wanted to jump to something really 
 performant for a new project without losing code 
 expressiveness and development speed. Dlang seemed a good 
 alternative (I like it much more than Go or Rust).


 Well, for us it's getting more and more clear, that a decision 
 what to use in the future will be based on less and less 
 technical aspects.

 The interesting thing about Go is, that their main focus is 
 thinking from an enterprise perspective, not only from a 
 technical one. So, their focus is getting stuff done, keeping 
 maintainability in big, constantly changing teams and stripping 
 everything away, that reduces productivity in such an 
 environment... I don't know about any other language which puts 
 all these non-technical aspects on the top of the agenda.

 Viele Grüsse.


And I feel like you guys will just pick Go because it will get 
stuff done.


I am in a philosophical mood today so here it goes...

When I just started learning about D ecosystem, vibe frequently 
popped up as one of the popular frameworks available for the 
language AND also a reason for ppl to jump in and try out D. 
However, as time goes, I also pick up many complaints about vibe, 
its performance and ease of use compared to competitors. This 
post just solidifies the impression. Bad documentation is the 
worst thing that can happen to a project which gets promoted as a 
one of the jems of the language ecosystem and actually hurts the 
language image much more than does good. Sigh... I will never 
advice vibe to anyone because I know that better alternatives 
exist. People will use Go, Python, Ruby, Rust whatever has better 
docs to get it running fast and not risk wasting time.

Sadly, this is how some languages grow and some don't. And it's 
not all about the corporate support, hype, GC or random luck, 
it's about cases like the above.
Oct 11 2020
parent =?UTF-8?B?Um9iZXJ0IE0uIE3DvG5jaA==?= <robert.muench saphirion.com> writes:
On 11 Oct 2020 at 21:10:20 CEST, "tastyminerals" <tastyminerals gmail.com>
wrote:


 And I feel like you guys will just pick Go because it will get 
 stuff done.


That's the main focus from a company perspective. We try to waste as less time
& money as possible.


 When I just started learning about D ecosystem, vibe frequently 
 popped up as one of the popular frameworks available for the 
 language AND also a reason for ppl to jump in and try out D. 


I love D, like it a lot, follow it for many years, use it from time to time...
but it's not about me, but a team and a product we need to develop and
maintain. There are much more non-technical aspects important then
technical...

And, deciding about your tech-stack base is a path-dependent decision. Turning
to something else, has a very high cost impact.


 However, as time goes, I also pick up many complaints about vibe, 
 its performance and ease of use compared to competitors. This 
 post just solidifies the impression. Bad documentation is the 
 worst thing that can happen to a project which gets promoted as a 
 one of the gems of the language ecosystem and actually hurts the 
 language image much more than does good. Sigh...


Well... I expect a lot of people taking a look at D do it like we do with
other solutions: I take a list of things I want to try out and start the timer
to see how long I take to get it done. This gives a good impression of the
eco-system, etc.

Taking a step back, D looks a bit scattered. A lot of stuff is there, the
standard lib is pretty good, many half-done packages, many corners to take a
look at. D is a big language, with a lot of concepts to learn and building up
experience is not fast.


 I will never advice vibe to anyone because I know that better alternatives 
 exist. People will use Go, Python, Ruby, Rust whatever has better 
 docs to get it running fast and not risk wasting time.


I'm pretty sure Vide is suitable for all kind of applications today. But you
need to have a higher "experimentation" scope in what you do. Once you build
up experience with all this stuff, I think there is no big difference to other
approaches. But the question is how long is this? 1, 2, X years?


 Sadly, this is how some languages grow and some don't. And it's 
 not all about the corporate support, hype, GC or random luck, 
 it's about cases like the above.


I think less is more, and D is pretty huge tpday. And, it's an OS project, so
people do what makes fun.

Go is mostly driving from a corporate perspective and the OS part is a side
aspect. That has some merits too.

Viele Grüsse.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Oct 12 2020
prev sibling parent ddcovery <antoniocabreraperez gmail.com> writes:
On Sunday, 11 October 2020 at 11:56:29 UTC, Robert M. Münch wrote:

 Well, for us it's getting more and more clear, that a decision 
 what to use in the future will be based on less and less 
 technical aspects.

 The interesting thing about Go is, that their main focus is 
 thinking from an enterprise perspective, not only from a 
 technical one. So, their focus is getting stuff done, keeping 
 maintainability in big, constantly changing teams and stripping 
 everything away, that reduces productivity in such an 
 environment... I don't know about any other language which puts 
 all these non-technical aspects on the top of the agenda.


Thanks for being so clear, Robert.
Oct 11 2020
prev sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Thursday, 1 October 2020 at 06:32:23 UTC, Robert M. Münch 
wrote:

 Hi, we are currently using vibe.d for a prototype and I want to 
 post some experiences. I know one shouldn't only address the 
 problems but provide some solutions.

 [...]


Have you tried Diamond?

https://code.dlang.org/packages/diamond
Oct 10 2020