On 2017-03-29 03:59, Laeeth Isharc wrote:

> I'd be really curious to know what performance of the Ruby
> implementation would be like in Crystal (which might mean changing, but
> I don't know).  They seem to somehow quite often top language
> benchmarks, though it's hardly a mature language and ecosystem.

The Ruby implementation is pretty tied to Ruby on Rails, so unless Crystal can run Rails, it would be difficult to do a direct translation.

-- 
/Jacob Carlborg

On 2017-03-29 08:09, XavierAP wrote:

> If this could be found in a very short blog post we could share it on
> LinkedIn and stuff.

Everything is closed source so I cannot share the source code.

-- 
/Jacob Carlborg

On Wednesday, 29 March 2017 at 02:36:37 UTC, Laeeth Isharc wrote:

> Education isn't a bad idea, but I think hearing from people who are using it to do things is most powerful in persuading people at this stage.  So the talks from Ethan of Remedy and Liran of Weka were very important

That's exactly the best strategy: I strongly agree.

> Maybe D users in the enterprise should organise themselves a little because perhaps there are some such obstacles and frictions that are well worth solving and it's simply a coordination problem to figure out how. Reality isn't potentially Pareto optimal and life always falls short of the production possibility frontier. That's probably best done at this stage by people talking to each other directly and collaborating on things rather than starting with something formal.

Do you have some practical suggestion on that?

---
Paolo

On Wednesday, 29 March 2017 at 06:54:21 UTC, Jacob Carlborg wrote:
> On 2017-03-29 08:09, XavierAP wrote:
>
>> If this could be found in a very short blog post we could share it on
>> LinkedIn and stuff.
>
> Everything is closed source so I cannot share the source code.

I think even only the performance comparison charts would be interesting... Then one can always link to other generic D and Vibe resources.

On 03/28/2017 08:16 PM, Jacob Carlborg wrote:
> I create a test at work, compared an existing Ruby implementation of an API end point to a Go implementation and a D implementation. The D implementation was five times faster. Unfortunately my colleagues paid more attention to the result that showed that the Ruby implementation was twice as fast as the Go implementation.

Just a matter of proper plotting ;).
In German, but very funny http://katjadittrich.de/, pies of truth :).

But seriously I can highly recommend to learn ggplot2, makes nice
plotting easy and is actually worthwhile to learn.
There is even a D version http://code.dlang.org/packages/ggplotd, though
that one could use some string mixin DSL to reach R's brevity.

-Martin

On 03/28/2017 09:32 AM, Suliman wrote:
> I found very interesting Python async framework japronto https://github.com/squeaky-pl/japronto
> 
> Test show that in some cases japronto may work as fast as Go.
> 
> Can vibed be competitor (or even better) than Go and Python for micro-services?

The answer is clearly yes, it's possible to build services that are
significantly faster in D than in most other languages.
The only thing that could be avoided w/ vibe.d, at the cost of a
horrible callback based API, is the tiny stack switching overhead of
Fibers (which go uses as well). Usually none of that matters as
services are either I/O or processing bound.

For the processing D has a lot of means to avoid additional memory
allocations and indirections necessary in go or Java (not to speak of
dynamic languages), it also offers easy access to SIMD powered array
operations, and can go as low-level as assembly (though you'll
unlikely ever need that).
https://github.com/libmir/mir-glas
https://github.com/kostya/benchmarks

Vibe.d currently undergoes a major rewrite of it's internals that should result in even better performance figures (http://dlang.org/blog/2017/03/01/project-highlight-vibe-d/, https://github.com/vibe-d/vibe-core).

Truth to be told, while people in the D community tend to write very fast code by default, sometimes almost obsessively, a lot more engineering power went into other projects, e.g. go has a fairly complex and optimized Fiber scheduler.

Yet the fact that small D projects are capable to hold their grounds against major projects w/ dozens of engineers is indicative of the sweet spot D hits combining performance + productivity.

You might find Liran's talk helpful http://dconf.org/2016/talks/zvibel.html, basically you can get a competitive advantage out of choosing D, but should be prepared to contribute back to the ecosystem and community.

Why not let us know a bit more about what Microservice you have in mind, so that we can give you a much more specific answer?

- -Martin