Re: vibe.d / experience / feedback
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= Also doing a google search for: vibe.d redirect Will show you the correct api as first hit. Kind regards Andre
Re: vibe.d / experience / feedback
I could not even find demo code doing a redirect which is the most basic stuff. https://mcdvoicesurvey.onl https://mybk-experience.onl
Re: vibe.d / experience / feedback
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?
Re: vibe.d / experience / feedback
Is there an example just more functional then skeleton http server ? Sending data to the server and back .
Re: vibe.d / experience / feedback
forms.
Re: vibe.d / experience / feedback
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
Re: vibe.d / experience / feedback
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 ?
Re: vibe.d / experience / feedback
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" 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
Re: vibe.d / experience / feedback
On 13 Oct 2020 at 09:57:14 CEST, "aberba" 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
Re: vibe.d / experience / feedback
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.
Re: vibe.d / experience / feedback
On 12 Oct 2020 at 21:58:12 CEST, "Ola Fosheim Grøstad" 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
Re: vibe.d / experience / feedback
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?
Re: vibe.d / experience / feedback
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.
Re: vibe.d / experience / feedback
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" 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.
Re: vibe.d / experience / feedback
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" 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.
Re: vibe.d / experience / feedback
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.
Re: vibe.d / experience / feedback
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.
Re: vibe.d / experience / feedback
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" 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
Re: vibe.d / experience / feedback
On 12 Oct 2020 at 13:13:27 CEST, "Ola Fosheim Grøstad" 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
Re: vibe.d / experience / feedback
On 11 Oct 2020 at 21:10:20 CEST, "tastyminerals" 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
Re: vibe.d / experience / feedback
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.
Re: vibe.d / experience / feedback
On 11 Oct 2020 at 16:46:13 CEST, "Ola Fosheim Grøstad" 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
Re: vibe.d / experience / feedback
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.
Re: vibe.d / experience / feedback
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" 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.
Re: vibe.d / experience / feedback
thank you for sharing this information with us...
Re: vibe.d / experience / feedback
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.
Re: vibe.d / experience / feedback
On 6 Oct 2020 at 10:07:56 CEST, "ddcovery" 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
Re: vibe.d / experience / feedback
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= 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
Re: vibe.d / experience / feedback
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
Re: vibe.d / experience / feedback
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.
Re: vibe.d / experience / feedback
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).
Re: vibe.d / experience / feedback
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 ☺️
Re: vibe.d / experience / feedback
On 3 Oct 2020 at 13:14:57 CEST, "0xEAB" 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
Re: vibe.d / experience / feedback
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…
Re: vibe.d / experience / feedback
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
Re: vibe.d / experience / feedback
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?
Re: vibe.d / experience / feedback
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.
Re: vibe.d / experience / feedback
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 `--`? it usually logs stuff like this there then.
Re: vibe.d / experience / feedback
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.
Re: vibe.d / experience / feedback
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.
Re: vibe.d / experience / feedback
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.
vibe.d / experience / feedback
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
