www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - PHP verses C#.NET verses D.

reply "Nick B" <nick.barbalich gmail.com> writes:
Hi.

There is a startup in New Zealand that I have some dealings with 
at present. They have build most of their original code in PHP, 
(as this was quick and easy) but they also use some C#.net for 
interfacing to accounting appls on clients machines. The core PHP 
application runs in the cloud at present and talks to accountings 
applications in the cloud. They use the PHP symfony framework.

High speed in not important, but accuracy, error handling, and 
scalability is, as they are processing accounting transactions. 
They have a new CEO on board, and he would like to review the 
companies technical direction.

Their client base is small but growing quickly.  I know that PHP 
is not a great language, and my knowledge of D is reasonable, 
while I have poor knowledge of C#.net.

Looking to the future, as volumes grow, they could:
1.  Stay with PHP & C#.net, and bring on servers as volumes grow.
2.  Migrate to C#.net in time
3.  Migrate to D in time.

Any comments or suggestions on the above?
Jun 15 2015
next sibling parent "israel" <tl12000 live.com> writes:
On Monday, 15 June 2015 at 23:53:06 UTC, Nick B wrote:
 Hi.

 There is a startup in New Zealand that I have some dealings 
 with at present. They have build most of their original code in 
 PHP, (as this was quick and easy) but they also use some C#.net 
 for interfacing to accounting appls on clients machines. The 
 core PHP application runs in the cloud at present and talks to 
 accountings applications in the cloud. They use the PHP symfony 
 framework.

 High speed in not important, but accuracy, error handling, and 
 scalability is, as they are processing accounting transactions. 
 They have a new CEO on board, and he would like to review the 
 companies technical direction.

 Their client base is small but growing quickly.  I know that 
 PHP is not a great language, and my knowledge of D is 
 reasonable, while I have poor knowledge of C#.net.

 Looking to the future, as volumes grow, they could:
 1.  Stay with PHP & C#.net, and bring on servers as volumes 
 grow.
 2.  Migrate to C#.net in time
 3.  Migrate to D in time.

 Any comments or suggestions on the above?
We have seen this before. I believe the verdict was..."Experiment" first, if things seem like they will work out with D. Go full force. But from the sound of your situation it seems there is no time for experimentation. The best you could do is tell your boss the pros and cons of D and ask if he can give you some time to test things out first. But i doubt they will listen to the insight of a normal employee...unless you have a good reputation?
Jun 15 2015
prev sibling next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 16/06/2015 11:53 a.m., Nick B wrote:
 Hi.

 There is a startup in New Zealand that I have some dealings with at
 present. They have build most of their original code in PHP, (as this
 was quick and easy) but they also use some C#.net for interfacing to
 accounting appls on clients machines. The core PHP application runs in
 the cloud at present and talks to accountings applications in the cloud.
 They use the PHP symfony framework.

 High speed in not important, but accuracy, error handling, and
 scalability is, as they are processing accounting transactions. They
 have a new CEO on board, and he would like to review the companies
 technical direction.

 Their client base is small but growing quickly.  I know that PHP is not
 a great language, and my knowledge of D is reasonable, while I have poor
 knowledge of C#.net.

 Looking to the future, as volumes grow, they could:
 1.  Stay with PHP & C#.net, and bring on servers as volumes grow.
 2.  Migrate to C#.net in time
 3.  Migrate to D in time.

 Any comments or suggestions on the above?
Hello follow Kiwi!
Jun 15 2015
parent reply "Nick B" <nick.barbalich gmail.com> writes:
On Tuesday, 16 June 2015 at 06:29:46 UTC, Rikki Cattermole wrote:
 On 16/06/2015 11:53 a.m., Nick B wrote:
 Hi.

 There is a startup in New Zealand that I have some dealings 
 with at
 present. Any comments or suggestions on the above?
Hello follow Kiwi!
Hello kiwi from the south Island. :)
Jun 16 2015
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 17/06/2015 6:41 a.m., Nick B wrote:
 On Tuesday, 16 June 2015 at 06:29:46 UTC, Rikki Cattermole wrote:
 On 16/06/2015 11:53 a.m., Nick B wrote:
 Hi.

 There is a startup in New Zealand that I have some dealings with at
 present. Any comments or suggestions on the above?
Hello follow Kiwi!
Hello kiwi from the south Island. :)
Oh please say Christchurch!
Jun 16 2015
parent reply "Nick B" <nick.barbalich gmail.com> writes:
On Wednesday, 17 June 2015 at 04:51:44 UTC, Rikki Cattermole 
wrote:
 On 17/06/2015 6:41 a.m., Nick B wrote:
 On Tuesday, 16 June 2015 at 06:29:46 UTC, Rikki Cattermole
 Oh please say Christchurch!
sorry for the confusion. Its Wellington.
Jun 16 2015
parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 17/06/2015 5:40 p.m., Nick B wrote:
 On Wednesday, 17 June 2015 at 04:51:44 UTC, Rikki Cattermole wrote:
 On 17/06/2015 6:41 a.m., Nick B wrote:
 On Tuesday, 16 June 2015 at 06:29:46 UTC, Rikki Cattermole
 Oh please say Christchurch!
sorry for the confusion. Its Wellington.
Ahh right right.
Jun 16 2015
prev sibling next sibling parent "Abdulhaq" <alynch4047 gmail.com> writes:
First off I would stress that architecture and process are more 
important than which of those 3 languages you choose, i.e. good 
testing (I prefer test driven), continuous integration, and a 
solid architecture that you are confident will provide the 
reliability, correctness  and uptime that you require.

Having said that I would then personally be conservative and 
choose to standardise on C# for its maturity, expressiveness and 
great tooling. It also has a good ecosystem (libraries etc.) 
which will prove very useful in business related tasks.

D has better expressiveness and probably would run faster but 
given all the other factors I would be concerned right now about 
its slight lack of maturity and under-developed ecosystem.
Jun 16 2015
prev sibling next sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Monday, 15 June 2015 at 23:53:06 UTC, Nick B wrote:
 Hi.

 There is a startup in New Zealand that I have some dealings 
 with at present. They have build most of their original code in 
 PHP, (as this was quick and easy) but they also use some C#.net 
 for interfacing to accounting appls on clients machines. The 
 core PHP application runs in the cloud at present and talks to 
 accountings applications in the cloud. They use the PHP symfony 
 framework.

 High speed in not important, but accuracy, error handling, and 
 scalability is, as they are processing accounting transactions. 
 They have a new CEO on board, and he would like to review the 
 companies technical direction.

 Their client base is small but growing quickly.  I know that 
 PHP is not a great language, and my knowledge of D is 
 reasonable, while I have poor knowledge of C#.net.

 Looking to the future, as volumes grow, they could:
 1.  Stay with PHP & C#.net, and bring on servers as volumes 
 grow.
 2.  Migrate to C#.net in time
 3.  Migrate to D in time.

 Any comments or suggestions on the above?
Both C# and D sound like good fits there. It depends on whether it's the sort of team who like to innovate and explore new possibilities or whether they want a completely fleshed out, stable ecosystem. D can make boring work interesting: endless boiler-plate can be neatly abstracted and many models* can be expressed JustRightâ„¢ as opposed to being shoehorned in to a standard abstraction. C# is also pretty good at this (sometimes), but D has a significant edge.
Jun 16 2015
parent reply "Nick B" <nick.barbalich gmail.com> writes:
On Tuesday, 16 June 2015 at 08:47:40 UTC, John Colvin wrote:
 On Monday, 15 June 2015 at 23:53:06 UTC, Nick B wrote:
 Hi.


 Any comments or suggestions on the above?
Both C# and D sound like good fits there. It depends on whether it's the sort of team who like to innovate and explore new possibilities or whether they want a completely fleshed out, stable ecosystem.
Is anyone else able to comment on the comparisions/differences between C#.Net & D ?? Any comments on cost ? Any comments on getting bugs fixed ?
Jun 16 2015
next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 06/17/2015 12:25 AM, Nick B wrote:
 On Tuesday, 16 June 2015 at 08:47:40 UTC, John Colvin wrote:
 On Monday, 15 June 2015 at 23:53:06 UTC, Nick B wrote:
 Hi.


 Any comments or suggestions on the above?
Both C# and D sound like good fits there. It depends on whether it's the sort of team who like to innovate and explore new possibilities or whether they want a completely fleshed out, stable ecosystem.
Is anyone else able to comment on the comparisions/differences between C#.Net & D ??
I'm obviously biased, being on the D forums and all (although I used to be a fan of both languages, a long time ago), but IMHO:
 Any comments on cost ?
I find D lets you get things done quicker/easier (worker cost) and potentially run a little faster (hardware cost). Though I image other arguments might be possible in favor of C#, too.
 Any comments on getting bugs fixed ?
Not too bad in D. With D, bugs do get fixed, AND if you really need a fix right away you can always just DIY. With C#, you're pretty much stuck with whatever MS feels like working on. There's very little feedback and community outreach. It's *their* product, and their business strategy dictates where development resources go. For example, people have been needing some sort of IArithmetic (counterpart to IComparable) ever since generics were first introduced back in v2 (so that you could, y'know, actually do arithmetic generically), but even to this day MS never really did bother to put it in or really even acknowledge the matter at all.
Jun 17 2015
prev sibling parent reply "Etienne" <etcimon gmail.com> writes:
On Wednesday, 17 June 2015 at 04:25:38 UTC, Nick B wrote:
 On Tuesday, 16 June 2015 at 08:47:40 UTC, John Colvin wrote:
 On Monday, 15 June 2015 at 23:53:06 UTC, Nick B wrote:
 Hi.


 Any comments or suggestions on the above?
Both C# and D sound like good fits there. It depends on whether it's the sort of team who like to innovate and explore new possibilities or whether they want a completely fleshed out, stable ecosystem.
Is anyone else able to comment on the comparisions/differences between C#.Net & D ?? Any comments on cost ? Any comments on getting bugs fixed ?
I've been working on developing the entire Web Stack in D, down from the kernel to the multiplexed HTTP/2 protocol and the high-level framework that queries the database and serves the response in json. If I did so at a high personal investment cost, it was so those insane web development languages wouldn't bother me anymore. In D, if you have a bug, you are 100% certain that you can resolve it yourself. You have all the C/C++ tools available to go all the way down to the memory and debug anything you want. You have statically typed language that allows huge projects to breathe very healthy and increment features at low cost. Nothing beats D in my opinion. It's 20 years ahead of everything out there. All you need to do, is know how to use it and understand it enough to resolve any bugs you come up with.
Jun 17 2015
parent reply "Laeeth Isharc" <nospamlaeeth laeethnospam.laeeth.com> writes:
On Wednesday, 17 June 2015 at 16:28:42 UTC, Etienne wrote:
 I've been working on developing the entire Web Stack in D, down 
 from the kernel to the multiplexed HTTP/2 protocol and the 
 high-level framework that queries the database and serves the 
 response in json.
Your work looks very interesting, although I haven't used it yet. Any idea how far away it might be from being something that someone could use in an enterprise environment simply, in the same kind of way that vibed is easy? I appreciate that making it broadly usable may not be what interests you, and may be a project for someone else.
 If I did so at a high personal investment cost, it was so those 
 insane web development languages wouldn't bother me anymore. In 
 D, if you have a bug, you are 100% certain that you can resolve 
 it yourself. You have all the C/C++ tools available to go all 
 the way down to the memory and debug anything you want. You 
 have statically typed language that allows huge projects to 
 breathe very healthy and increment features at low cost.

 Nothing beats D in my opinion. It's 20 years ahead of 
 everything out there. All you need to do, is know how to use it 
 and understand it enough to resolve any bugs you come up with.
Any chance you could write a bit more on this? Your personal story and why you believe this. We could post on the Wiki as part of a series of narratives on people who have found D helpful. Stories are a powerful complement to just ticking off features. Thanks. Laeeth.
Jun 17 2015
next sibling parent reply "Nick B" <nick.barbalich gmail.com> writes:
On Wednesday, 17 June 2015 at 18:40:01 UTC, Laeeth Isharc wrote:
 On Wednesday, 17 June 2015 at 16:28:42 UTC, Etienne wrote:
 I've been working on developing the entire Web Stack in D, 
 down from the kernel to the multiplexed HTTP/2 protocol and 
 the high-level framework that queries the database and serves 
 the response in json.
Your work looks very interesting, although I haven't used it yet. Any idea how far away it might be from being something that someone could use in an enterprise environment simply, in the same kind of way that vibed is easy? I appreciate that making it broadly usable may not be what interests you, and may be a project for someone else.
 If I did so at a high personal investment cost, it was so 
 those insane web development languages wouldn't bother me 
 anymore. In D, if you have a bug, you are 100% certain that 
 you can resolve it yourself. You have all the C/C++ tools 
 available to go all the way down to the memory and debug 
 anything you want. You have statically typed language that 
 allows huge projects to breathe very healthy and increment 
 features at low cost.

 Nothing beats D in my opinion. It's 20 years ahead of 
 everything out there. All you need to do, is know how to use 
 it and understand it enough to resolve any bugs you come up 
 with.
Any chance you could write a bit more on this? Your personal story and why you believe this.
Yes I too would be interested on more background as to your opinion, as why its 20 years ahead of everything else out there.
Jun 17 2015
parent "Etienne Cimon" <etcimon gmail.com> writes:
On Thursday, 18 June 2015 at 02:01:33 UTC, Nick B wrote:
 Yes I too would be interested on more background as to your 
 opinion, as why its 20 years ahead of everything else out there.
Natively compiled: Moore's law predicts that the burden in advancements in computing speed will migrate into software. This may be enough to rule out increasingly the use of managed language for developments where cost is important and more than 1 server will be needed. Compiling vs interpreting can make all the difference between requiring 1000 servers vs 10 servers. Template metaprogramming: This is the first reason I've chosen to use D in the first place. The idea that I could write code that writes code, and make it statically typed and safe. C++ has this but the errors are insane, the static if is not there, CTFE is just starting to pick up, there's no traits or very limited compile-time reflection (ie. static if(__traits(compiles, { some_operation(); })). The compile time is also much slower, there's simply too many legacy features in the language that have made it suffer in the long run. Even a package manager like dub is something nobody can agree on, because the community is so divided. Overall, it would take decades for the most powerful language C++ to reach the current state of D in terms of compile-time capabilities. This is important because preprocessors are the only alternatives and they suck for larger projects. I won't cover again everything that the dlang site can say about the language, and I could go on with how D has the entire web stack (I didn't release it fully yet) but that would be throwing myself flowers :P
Jun 17 2015
prev sibling parent reply "Etienne Cimon" <etcimon gmail.com> writes:
On Wednesday, 17 June 2015 at 18:40:01 UTC, Laeeth Isharc wrote:
  Any idea how far away it might be from being something that 
 someone could use in an enterprise environment simply, in the 
 same kind of way that vibed is easy?  I appreciate that making 
 it broadly usable may not be what interests you, and may be a 
 project for someone else.
I would say 3 months. So it'll probably be a year considering how off my last estimates were. Of course, I never calculated any help (and haven't gotten any really)
 Any chance you could write a bit more on this?  Your personal 
 story and why you believe this.  We could post on the Wiki as 
 part of a series of narratives on people who have found D 
 helpful.  Stories are a powerful complement to just ticking off 
 features.
I started off as a C, C#, Javascript & PHP programmer with 6 years of experience, building mostly e-commerce and information systems on a contractual basis. One day, I decided I had enough and wanted to invest my time in a faster web engine because I was tired of seeing all those slow and bloated libraries that can barely serve 10 requests per second when they're put to any practical use. I decided to go for C++ and learn everything I could about writing an integrated solution. I found interesting libraries but everytime I wanted to add a feature, I'd have to import another library and it again became bloated but in terms of code base. Nothing seemed to work together (Qt & Boost?). The D programming language came up frequently in search results when looking for C++-related concepts, and I saw everything I needed in Phobos. The language features seemed similar at first but I quickly realized how much more convenient the language was as a whole and it felt much like a managed language overall. Even the vibe.d library was much more advanced than what I could find with an open source license that allowed static compilation at the time (1 yr 1/2 ago), so I went forward with that and worked my way through. The most interesting part is that everytime I had a problem, I never had to google the error from the compiler because it was quite straightforward. I did have to debug the memory a lot but all the tools from C/C++ work for that. So now I can build a full web application/server executable in less than 2mb packed, and it runs faster than anything out there. It's standalone, works cross-platform, etc. I really have to put the blame on the language for the speed at which this very large project was finished. I completed the STL-equivalent memory library, TLS/crypto security library, the low-level async TCP library, the HTTP/2 implementation and the integration of everything in a web application framework within about 10 months. I learned the language for about 6 months through that coming from a background more familiar with managed languages. I can't say D isn't meant for large projects, it's a really fucking solid language that was built for the future.
Jun 17 2015
next sibling parent reply "Nick B" <nick.barbalich gmail.com> writes:
On Thursday, 18 June 2015 at 03:44:08 UTC, Etienne Cimon wrote:
 On Wednesday, 17 June 2015 at 18:40:01 UTC, Laeeth Isharc wrote:
  Any idea how far away it might be from being something that 
 someone could use in an enterprise environment simply, in the 
 same kind of way that vibed is easy?  I appreciate that making 
 it broadly usable may not be what interests you, and may be a 
 project for someone else.
I would say 3 months. So it'll probably be a year considering how off my last estimates were.
Etienne - Interesting back story. Will this be under a Boost licence ? Will you provide a link ?
 Even the vibe.d library was much more advanced than what I 
 could find with an open source license that allowed static 
 compilation at the time (1 yr 1/2 ago), so I went forward with 
 that and worked my way through.
[snip\]
 So now I can build a full web application/server executable in 
 less than 2mb packed, and it runs faster than anything out 
 there. It's standalone, works cross-platform, etc.
Will you explain how it is different to Vibe.d ?
Jun 17 2015
next sibling parent "Nick B" <nick.barbalich gmail.com> writes:
On Thursday, 18 June 2015 at 05:23:25 UTC, Nick B wrote:
 On Thursday, 18 June 2015 at 03:44:08 UTC, Etienne Cimon wrote:
 On Wednesday, 17 June 2015 at 18:40:01 UTC, Laeeth Isharc 
 wrote:
  Any idea how far away it might be from being something that 
 someone could use in an enterprise environment simply, in the 
 same kind of way that vibed is easy?  I appreciate that 
 making it broadly usable may not be what interests you, and 
 may be a project for someone else.
I would say 3 months. So it'll probably be a year considering how off my last estimates were.
Etienne - Interesting back story.
 So now I can build a full web application/server executable in 
 less than 2mb packed, and it runs faster than anything out 
 there. It's standalone, works cross-platform, etc.
Will you explain how it is different to Vibe.d ?
Thanks everyone for their suggestions. Thanks Etienne on the heads-up on your new web application/server executable. If anyone wants to add any final comments they are most welcome. Nick
Jun 19 2015
prev sibling parent reply "Etienne Cimon" <etcimon gmail.com> writes:
On Thursday, 18 June 2015 at 05:23:25 UTC, Nick B wrote:
 On Thursday, 18 June 2015 at 03:44:08 UTC, Etienne Cimon wrote:
 On Wednesday, 17 June 2015 at 18:40:01 UTC, Laeeth Isharc 
 wrote:
  Any idea how far away it might be from being something that 
 someone could use in an enterprise environment simply, in the 
 same kind of way that vibed is easy?  I appreciate that 
 making it broadly usable may not be what interests you, and 
 may be a project for someone else.
I would say 3 months. So it'll probably be a year considering how off my last estimates were.
Etienne - Interesting back story. Will this be under a Boost licence ? Will you provide a link ?
 Even the vibe.d library was much more advanced than what I 
 could find with an open source license that allowed static 
 compilation at the time (1 yr 1/2 ago), so I went forward with 
 that and worked my way through.
[snip\]
 So now I can build a full web application/server executable in 
 less than 2mb packed, and it runs faster than anything out 
 there. It's standalone, works cross-platform, etc.
Will you explain how it is different to Vibe.d ?
It has HTTP/2, a new encryption library, it uses a native TCP event library, lots of refactoring. In short, the entire thing is in D rather than linking with OpenSSL and libevent. It's MIT licensed. I have it here: https://github.com/etcimon/vibe.d The dub.json uses relative paths though while I'm developing. You're free to adjust the file and try it, we can consider it stable.
Jun 19 2015
next sibling parent reply "Etienne Cimon" <etcimon gmail.com> writes:
On Friday, 19 June 2015 at 11:28:30 UTC, Etienne Cimon wrote:
 On Thursday, 18 June 2015 at 05:23:25 UTC, Nick B wrote:
 On Thursday, 18 June 2015 at 03:44:08 UTC, Etienne Cimon wrote:
 [...]
Etienne - Interesting back story. Will this be under a Boost licence ? Will you provide a link ?
 [...]
[snip\]
 [...]
It has HTTP/2, a new encryption library, it uses a native TCP event library, lots of refactoring. In short, the entire thing is in D rather than linking with OpenSSL and libevent.
Also, the HTTP client has a cookiejar and more settings.
Jun 19 2015
parent "Etienne Cimon" <etcimon gmail.com> writes:
On Friday, 19 June 2015 at 11:29:58 UTC, Etienne Cimon wrote:
 On Friday, 19 June 2015 at 11:28:30 UTC, Etienne Cimon wrote:
 On Thursday, 18 June 2015 at 05:23:25 UTC, Nick B wrote:
 On Thursday, 18 June 2015 at 03:44:08 UTC, Etienne Cimon 
 wrote:
 [...]
Also, the HTTP client has a cookiejar and more settings.
hmm, I think I can mention the capture debugger. I'm still developing it but it's becoming quite complete. It's a runtime tool shows the HTTP client/server request/response headers, form files/fields, json input/output, for specific request paths, and works in builds without debug info. The trace library that's used for it also maintains custom call stack trace that works in builds withoutu debug info. https://htmlpreview.github.io/?https://github.com/etcimon/vibe.d/blob/master/views/capture.html
Jun 19 2015
prev sibling next sibling parent reply "Suliman" <evermind live.ru> writes:
 It has HTTP/2, a new encryption library, it uses a native TCP 
 event library, lots of refactoring. In short, the entire thing 
 is in D rather than linking with OpenSSL and libevent.

 It's MIT licensed. I have it here: 
 https://github.com/etcimon/vibe.d
Cool! 1. Do you plain to merge it's with original dub? 2. "new encryption library" does it's written entirely in D and do all that do OpenSSL? 3. Do you any plan to add some futures from net.curl? I really dislike to use it, I would like native lib.
Jun 19 2015
next sibling parent "ZombineDev" <valid_email he.re> writes:
On Friday, 19 June 2015 at 11:35:07 UTC, Suliman wrote:

 2. "new encryption library" does it's written entirely in D and 
 do all that do OpenSSL?
http://forum.dlang.org/thread/mc0a99$2bfn$1 digitalmars.com
Jun 19 2015
prev sibling parent "Etienne" <etcimon gmail.com> writes:
On Friday, 19 June 2015 at 11:35:07 UTC, Suliman wrote:
 It has HTTP/2, a new encryption library, it uses a native TCP 
 event library, lots of refactoring. In short, the entire thing 
 is in D rather than linking with OpenSSL and libevent.

 It's MIT licensed. I have it here: 
 https://github.com/etcimon/vibe.d
Cool! 1. Do you plain to merge it's with original dub?
Work is in progress, it will be gradual over the next year to avoid merge conflicts with existing users: https://github.com/rejectedsoftware/vibe.d/tree/http2-botan-cleanup Don't expect that branch to build though.
 2. "new encryption library" does it's written entirely in D and 
 do all that do OpenSSL?
Botan does everything that OpenSSL does, but also in a more convenient way. If you need something for anything crypto, chances are it's going to do it. https://github.com/etcimon/botan
 3. Do you any plan to add some futures from net.curl? I really 
 dislike to use it, I would like native lib.
Vibe.d tasks are one level further from my point of view. You can write procedural TCP read/write and the thread will not block.
Jun 19 2015
prev sibling next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 06/19/2015 07:28 AM, Etienne Cimon wrote:
 The dub.json uses relative paths though while I'm developing. You're
 free to adjust the file and try it,
You may want to consider just using dub's (add|remove)-local for that instead. You can rip those "path" elements out of dub.json completely, then just do: $ dub add-local ../botan $ dub add-local ../libasync And it will use those paths on your machine only, without mucking up the dub.json. Then when you're done (or if you want to change paths): $ dub remove-local ../botan $ dub remove-local ../libasync
Jun 19 2015
parent "Etienne" <etcimon gmail.com> writes:
On Friday, 19 June 2015 at 15:31:19 UTC, Nick Sabalausky wrote:
 On 06/19/2015 07:28 AM, Etienne Cimon wrote:
 The dub.json uses relative paths though while I'm developing. 
 You're
 free to adjust the file and try it,
You may want to consider just using dub's (add|remove)-local for that instead. You can rip those "path" elements out of dub.json completely, then just do: $ dub add-local ../botan $ dub add-local ../libasync And it will use those paths on your machine only, without mucking up the dub.json. Then when you're done (or if you want to change paths): $ dub remove-local ../botan $ dub remove-local ../libasync
I don't know why so many people take it personal, I love being corrected. Thanks so much for the tip :)
Jun 19 2015
prev sibling parent reply "Nick B" <nick.barbalich gmail.com> writes:
On Friday, 19 June 2015 at 11:28:30 UTC, Etienne Cimon wrote:
 On Thursday, 18 June 2015 at 05:23:25 UTC, Nick B wrote:
 On Thursday, 18 June 2015 at 03:44:08 UTC, Etienne Cimon wrote:
 Will you explain how it is different to Vibe.d ?
It has HTTP/2, a new encryption library, it uses a native TCP event library, lots of refactoring. In short, the entire thing is in D rather than linking with OpenSSL and libevent.
Etienne Can you explain the benefits of writing these libraries in D, as against just linking to these libraries. Is it for faster execution, or better debugging, or some other reason ?
Jun 20 2015
parent "Etienne Cimon" <etcimon gmail.com> writes:
On Sunday, 21 June 2015 at 03:16:31 UTC, Nick B wrote:
 On Friday, 19 June 2015 at 11:28:30 UTC, Etienne Cimon wrote:
 On Thursday, 18 June 2015 at 05:23:25 UTC, Nick B wrote:
 On Thursday, 18 June 2015 at 03:44:08 UTC, Etienne Cimon 
 wrote:
 Will you explain how it is different to Vibe.d ?
It has HTTP/2, a new encryption library, it uses a native TCP event library, lots of refactoring. In short, the entire thing is in D rather than linking with OpenSSL and libevent.
Etienne Can you explain the benefits of writing these libraries in D, as against just linking to these libraries. Is it for faster execution, or better debugging, or some other reason ?
When writing bindings, you need to write unit tests for your bindings and an interface. You're adding a layer of software with its own propensity for errors. You also don't have access to the underlying implementation in the IDE. You also can't add features to facilitate your own programs unless you control the repository. Honestly, I can't stand having layers and layers of garbage to make up for language differences. I like the cleanliness of it all and it probably ended up taking me half the time because I avoided debugging new code.
Jun 21 2015
prev sibling next sibling parent reply "Laeeth Isharc" <nospamlaeeth laeethnospam.laeeth.com> writes:
On Thursday, 18 June 2015 at 03:44:08 UTC, Etienne Cimon wrote:
 On Wednesday, 17 June 2015 at 18:40:01 UTC, Laeeth Isharc wrote:
 Any chance you could write a bit more on this?  Your personal 
 story and why you believe this.  We could post on the Wiki as 
 part of a series of narratives on people who have found D 
 helpful.  Stories are a powerful complement to just ticking 
 off features.
I started off as a C, C#, Javascript & PHP programmer with 6 years of experience, building mostly e-commerce and information systems on a contractual basis. One day, I decided I had enough
Thanks for this. I am collecting narratives here: http://wiki.dlang.org/User_narratives_on_switching_to_D (I am not very good with Wiki, but we can clean up later).
Jun 18 2015
parent "Nicholas Wilson" <iamthewilsonator hotmail.com> writes:
On Thursday, 18 June 2015 at 07:34:28 UTC, Laeeth Isharc wrote:
 On Thursday, 18 June 2015 at 03:44:08 UTC, Etienne Cimon wrote:
 On Wednesday, 17 June 2015 at 18:40:01 UTC, Laeeth Isharc 
 wrote:
 Any chance you could write a bit more on this?  Your personal 
 story and why you believe this.  We could post on the Wiki as 
 part of a series of narratives on people who have found D 
 helpful.  Stories are a powerful complement to just ticking 
 off features.
I started off as a C, C#, Javascript & PHP programmer with 6 years of experience, building mostly e-commerce and information systems on a contractual basis. One day, I decided I had enough
Thanks for this. I am collecting narratives here: http://wiki.dlang.org/User_narratives_on_switching_to_D (I am not very good with Wiki, but we can clean up later).
This page needs WAAAY more hyperlinks, particularly the acronyms and resources (e.g. Ali's book), as I assume that this is meant for 'advertising'. Anyway good start and nice work!
Jun 19 2015
prev sibling next sibling parent reply "Nick B" <nick.barbalich gmail.com> writes:
On Thursday, 18 June 2015 at 03:44:08 UTC, Etienne Cimon wrote:
 On Wednesday, 17 June 2015 at 18:40:01 UTC, Laeeth Isharc wrote:
  Any idea how far away it might be from being something that 
 someone could use in an enterprise environment simply, in the 
 same kind of way that vibed is easy?  I appreciate that making 
 it broadly usable may not be what interests you, and may be a 
 project for someone else.
I would say 3 months. So it'll probably be a year considering how off my last estimates were. Of course, I never calculated any help (and haven't gotten any really)
Etienne Would you like to detail what still needs to be completed/on the to-do list ? What would be the best way to learn it ? Does it need documentation as well ? Nick
Jun 21 2015
parent "Etienne" <etcimon gmail.com> writes:
On Monday, 22 June 2015 at 06:32:31 UTC, Nick B wrote:
 On Thursday, 18 June 2015 at 03:44:08 UTC, Etienne Cimon wrote:
 Etienne

 Would you like to detail what still needs to be completed/on 
 the to-do list  ?

 What would be the best way to learn it ?

 Does it need documentation as well ?

 Nick
The docs should be the same as the ones on vibed.org As for the todo list, It's a little long to detail it. Depends also on where you want to go. Urgent: - Update libhttp2 and botan with recent changes from the original repos (nghttp2, botan). No stability issues, only new algorithms mostly. - Write a Windows/Mac/linux daemon utility with rights elevation to have support for desktop application development (currently finishing up windows) - The Mac daemon requires launchd, which compiles only with DMD pull request to be merged: https://github.com/D-Programming-Language/dmd/pull/4321 - Uses the http://diveframework.com/ to elevate - Test the live debugging features with third party applications (similar to packet-capturing but server-side). - This is completed and available on my fork of vibe.d and a reverse proxy request looks like this: http://htmlpreview.github.io/?https://github.com/etcimon/vibe.d/blob/maste /views/capture.html => http://pastebin.com/raw.php?i=E51RXyt2 - Also includes json req/response or call stack in builds compiled with release - Try running with LDC and debug the libraries until everything completely compiles with it (2.067+) - Find a way to add a thread-local GC in druntime or at least make dub compile the projects with it. Less urgent: - Implement administration interface for the new redis 3.0 clustering feature - Write a DNS server with A-record scheduling for distribution - Adapt VibeDist to send requests to worker tasks - Add support for runtime loading of DLL plugins that auto-register/unregister to the router. - Test lua bindings to develop runtime themes I also have private application development on the todo list which ends up testing the library. Lots of testing is still needed but I think the server exceeds what I could make any other server do. It compiles in a single portable executable 2mb packed after all.
Jun 22 2015
prev sibling parent reply "Nick B" <nick.barbalich gmail.com> writes:
On Thursday, 18 June 2015 at 03:44:08 UTC, Etienne Cimon wrote:

 So now I can build a full web application/server executable in 
 less than 2mb packed, and it runs faster than anything out 
 there.
Etienne Do you have an performance numbers, as to how fast your web application/server is, or is this based on your personal experience ? Nick
Jun 22 2015
parent reply "Etienne Cimon" <etcimon gmail.com> writes:
On Tuesday, 23 June 2015 at 06:26:39 UTC, Nick B wrote:
 On Thursday, 18 June 2015 at 03:44:08 UTC, Etienne Cimon wrote:

 So now I can build a full web application/server executable in 
 less than 2mb packed, and it runs faster than anything out 
 there.
Etienne Do you have an performance numbers, as to how fast your web application/server is, or is this based on your personal experience ? Nick
I don't have current performance results because I've been focused on adding features, but these results were taken on a previous version: https://atilanevesoncode.wordpress.com/2013/12/05/go-vs-d-vs-erlang-vs-c-in-real-life-mqtt-broker-implementation-shootout/
Jun 23 2015
parent reply "Nick B" <nick.barbalich gmail.com> writes:
On Tuesday, 23 June 2015 at 11:22:40 UTC, Etienne Cimon wrote:

 Nick
I don't have current performance results because I've been focused on adding features, but these results were taken on a previous version: https://atilanevesoncode.wordpress.com/2013/12/05/go-vs-d-vs-erlang-vs-c-in-real-life-mqtt-broker-implementation-shootout/
Etienne Thanks for the responses and your details replies. I'm going to talk to the CEO of the company described, at the beginning of this long thread, and find out they are willing to consider a proof of concept web site based on your work. This could take a couple of weeks. What is the best way to get in touch with you if I have more questions ? Nick
Jun 23 2015
parent reply "Etienne" <etcimon gmail.com> writes:
On Wednesday, 24 June 2015 at 05:34:08 UTC, Nick B wrote:
 On Tuesday, 23 June 2015 at 11:22:40 UTC, Etienne Cimon wrote:

 Nick
I don't have current performance results because I've been focused on adding features, but these results were taken on a previous version: https://atilanevesoncode.wordpress.com/2013/12/05/go-vs-d-vs-erlang-vs-c-in-real-life-mqtt-broker-implementation-shootout/
Etienne Thanks for the responses and your details replies. I'm going to talk to the CEO of the company described, at the beginning of this long thread, and find out they are willing to consider a proof of concept web site based on your work. This could take a couple of weeks. What is the best way to get in touch with you if I have more questions ? Nick
Skype: Etcimon or gmail the same username
Jun 25 2015
parent "Nick B" <nick.barbalich gmail.com> writes:
On Thursday, 25 June 2015 at 13:48:38 UTC, Etienne wrote:
 On Wednesday, 24 June 2015 at 05:34:08 UTC, Nick B wrote:
 On Tuesday, 23 June 2015 at 11:22:40 UTC, Etienne Cimon wrote:
 Thanks for the responses and your details replies.
 I'm going to talk to the CEO of the company described, at the 
 beginning of this long thread, and find out they are willing 
 to consider a proof of concept web site based on your work.
 This could take a couple of weeks.  What is the best way to 
 get in touch with you if I have more questions ?

 Nick
Skype: Etcimon or gmail the same username
Thanks again. Nick
Jun 25 2015
prev sibling next sibling parent "Etienne" <etcimon gmail.com> writes:
On Monday, 15 June 2015 at 23:53:06 UTC, Nick B wrote:
 Looking to the future, as volumes grow, they could:
 1.  Stay with PHP & C#.net, and bring on servers as volumes 
 grow.
 2.  Migrate to C#.net in time
 3.  Migrate to D in time.

 Any comments or suggestions on the above?
Don't mess up a working solution. Don't mess it up. Go with this logic: will it mess up the existing software? Choose the solution that will not mess it up. This being said, you start a new project with spare money or spare time. Migrations are 99.9% of the time not worth it.
Jun 16 2015
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-06-16 01:53, Nick B wrote:

 Looking to the future, as volumes grow, they could:
 1.  Stay with PHP & C#.net, and bring on servers as volumes grow.
 2.  Migrate to C#.net in time
 3.  Migrate to D in time.

 Any comments or suggestions on the above?
Anything would be better than PHP. You can't go wrong picking either D or C# over PHP. -- /Jacob Carlborg
Jun 16 2015
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 06/17/2015 02:30 AM, Jacob Carlborg wrote:
 On 2015-06-16 01:53, Nick B wrote:

 Looking to the future, as volumes grow, they could:
 1.  Stay with PHP & C#.net, and bring on servers as volumes grow.
You mentioned cost elsewhere, and this can be a big cost that doesn't scale very well.
 2.  Migrate to C#.net in time
 3.  Migrate to D in time.

 Any comments or suggestions on the above?
Anything would be better than PHP. You can't go wrong picking either D or C# over PHP.
Definitely. http://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ Even Facebook, every PHP-proponent's favorite example of a supposed "PHP user" has spent many years putting lots of effort into: 1. Mitigating PHP's problems (big coding standards guidelines based on many years experience by an army of developers, plus completely rewriting the PHP engine itself something like three times, see "HipHop". They don't use stock "Zend" PHP.) 2. Migrating *away* from PHP. See Facebook's own "Hack" language.
Jun 17 2015
prev sibling next sibling parent Marco Leise <Marco.Leise gmx.de> writes:
Am Mon, 15 Jun 2015 23:53:04 +0000
schrieb "Nick B" <nick.barbalich gmail.com>:

 Hi.
 
 There is a startup in New Zealand that I have some dealings with 
 at present. They have build most of their original code in PHP, 
 (as this was quick and easy) but they also use some C#.net for 
 interfacing to accounting appls on clients machines. The core PHP 
 application runs in the cloud at present and talks to accountings 
 applications in the cloud. They use the PHP symfony framework.
 
 High speed in not important, but accuracy, error handling, and 
 scalability is, as they are processing accounting transactions. 
 They have a new CEO on board, and he would like to review the 
 companies technical direction.
 
 Their client base is small but growing quickly.  I know that PHP 
 is not a great language, and my knowledge of D is reasonable, 
 while I have poor knowledge of C#.net.
 
 Looking to the future, as volumes grow, they could:
 1.  Stay with PHP & C#.net, and bring on servers as volumes grow.
 2.  Migrate to C#.net in time
 3.  Migrate to D in time.
 
 Any comments or suggestions on the above?
I'd probably migrate the PHP to ASP/C#.net and call it a day. You get WYSIWYG web page editing with error checking for forms and lists with database table backing store. Without your explicit library needs it is difficult to explain to you if and how D could work in this case. As for bugs, it seems that commercial users get some priority bonus. -- Marco
Jun 17 2015
prev sibling parent dennis luehring <dl.soluz gmx.net> writes:
you should stay with PHP + C# or migrated to pure C# if you need to ask 
such a question here (without giving any infos about what the co-workers 
understand, the real size of the project is, etc.)

Am 16.06.2015 um 01:53 schrieb Nick B:
 Hi.

 There is a startup in New Zealand that I have some dealings with
 at present. They have build most of their original code in PHP,
 (as this was quick and easy) but they also use some C#.net for
 interfacing to accounting appls on clients machines. The core PHP
 application runs in the cloud at present and talks to accountings
 applications in the cloud. They use the PHP symfony framework.

 High speed in not important, but accuracy, error handling, and
 scalability is, as they are processing accounting transactions.
 They have a new CEO on board, and he would like to review the
 companies technical direction.

 Their client base is small but growing quickly.  I know that PHP
 is not a great language, and my knowledge of D is reasonable,
 while I have poor knowledge of C#.net.

 Looking to the future, as volumes grow, they could:
 1.  Stay with PHP & C#.net, and bring on servers as volumes grow.
 2.  Migrate to C#.net in time
 3.  Migrate to D in time.

 Any comments or suggestions on the above?
Jun 21 2015