On Tuesday, 23 December 2014 at 07:57:22 UTC, Bienlein wrote:
> What I'm saying is that being good at everything is good, but only a true selling point would receive people's attention. That's the way it is. Making D fit for server side development is a suggestion of mine. It seems to me something that has traction and will continue to have so unless the Internet dies a sudden death. There might be other even better ideas what could be selling points, but continuing with being good at everything and hoping that one day a big spender will come along might in the end not work out and result in a great loss of time. I don't want to appear harsh. It only seems to me that I wasn't able to bring my point across.

You have a point that from a marketing/deployment perspective it is better to focus on one niche and do well there, then expand outwards, a point Ola has made before.  It is tougher to get potential users to focus on quality across the board, rather than one unique selling point, as you say.

But D has a much more ambitious goal, to be a better general-purpose programming language.  That has already been focused on the server to some extent, with vibe.d and the success of Sociomantic's real-time ad platform.  The problem with starting in a niche is that you can get too optimized for that niche and have trouble undoing those decisions later to become more general-purpose.  Is there any realistic chance that Go ever takes on a more general-purpose language like C++?  Probably not.

Walter and Andrei know what they're doing, but they need help building that vision, especially given the quality of implementation issues everyone is pointing out.  Hopefully enough people agree with that vision that they pitch in to help build it.  Success at building a general-purpose language will not come right away, but if and when it comes, it's much bigger and longer-lasting. :)

19-Dec-2014 18:08, deadalnix пишет:
> On Friday, 19 December 2014 at 14:38:02 UTC, Tobias Pankrath wrote:
>>> As for Walter already saying "no" a lot, given how many features D
>>> has, obviously one can still wish he went from 99% "no" to 99.5%. ;)
>>> You don't need to be around the D community forever to feel that D
>>> still has too many features that made it in.
>>
>> Care to name a few and justify why exactly those features should be gone?
>
>   - lazy . It is completely unable to interact with all qualifier code
> that run should be able to have.
>   - scope in its current state. Do not ensure anything.
>   - in and out parameters.

+1

>   - optional parenthesis. They cause confusion and great language
> complication in their current form.

Unless there was a way for author to enforce one way of writing it. Which gets us to some useful @properties.

>   - Non first class functions. Useless baggage from C and C++, which
> only benefit are to complicate the situation with optional () and cause
> a large part of the standard lib to go banana when passed a non first
> class function via alias parameter.

>   - inout. Completely underpowered for its cost, ambiguous and can cause
> compiler crash in some ambiguous cases.

I too never understood the appeal of inout. Not only interfaces now allow template final functions but also the bolierplate is easily removed with (template) mixins.

>   - most of traits. They are completely inconsistent, for instance, some
> return aliases, some return strings and there is no way to really know.
>   - __parameters. Yes, this is a keyword.

That's just baggage that's far less destructive.

> That is what you get you add half assed feature to solve an immediate
> problem, but don't look at the broader picture.



-- 
Dmitry Olshansky

On 12/18/14 4:38 AM, bioinfornatics wrote:
> - range even the basic io as ByLine which implement range can't work
> with std.range.takeOne as is not an Input Range. While a basic function
> such as takeOne do not really need to use save method to work a forward
> range is enough.

Could you please give an example of this? Thanks. -- Andrei

On Mon, 2014-12-22 at 23:46 +0200, ketmar via Digitalmars-d wrote:
> […]
> matters. oh, really? Go can magically do all header parsing,
> database management and other things for me? or we talking about
> "echo" servers?

What happened was that a lot of people interested in all this HTTP bullshit, SQL dross, UI using Qt, and Go, and wrote a lot of libraries that everyone can use. So yes Go can do all that magic stuff – not just echo servers.

> Go is just hyped, that's all. there is NOTHING hard in creating simple HTTP(S) server with templated pages, forms and data processing with vibe.d. hey, it even has a sample of such server out of the box! it's dead easy. and vibe.d can utilize threads to use all CPU cores (you will lost some handyness here, but hey: don't use global variables! ;-).

I have no doubt that Vibe.d can do this. If there was a way of mocking (so that you can run integration tests without the actual network) with Vibe.d I would be having a play with it, but there isn't, so I am not.

> even adding the whole Go to D will not make D overtake Go. Go is hyped. D is not. that's all.

At this stage hype or not is a complete irrelevance, the point is that Go has a lot of people writing a lot of software for wide availability and use. D…is probably a far better language, but…

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Tuesday, 23 December 2014 at 17:01:13 UTC, Russel Winder via Digitalmars-d wrote:
> If there was a way of mocking
> (so that you can run integration tests without the actual network)

With my cgi.d, I made a command line interface that triggers the library the same as a network does. This works even if you compile it with the embedded http server:

$ ./hellocgi  GET / foo=bar
Cache-Control: private, no-cache="set-cookie"
Expires: 0
Pragma: no-cache
Content-Type: text/html; charset=utf-8

hello


It was really easy for me to implement and it gives easy access to any function for testing and debugging. It also lets me use the shell as a kind of web console too.

This is something that often amazes me that everyone doesn't do.

On 12/23/14, 2:08 PM, Adam D. Ruppe wrote:
> On Tuesday, 23 December 2014 at 17:01:13 UTC, Russel Winder via
> Digitalmars-d wrote:
>> If there was a way of mocking
>> (so that you can run integration tests without the actual network)
>
> With my cgi.d, I made a command line interface that triggers the library
> the same as a network does. This works even if you compile it with the
> embedded http server:
>
> $ ./hellocgi  GET / foo=bar
> Cache-Control: private, no-cache="set-cookie"
> Expires: 0
> Pragma: no-cache
> Content-Type: text/html; charset=utf-8
>
> hello
>
>
> It was really easy for me to implement and it gives easy access to any
> function for testing and debugging. It also lets me use the shell as a
> kind of web console too.
>
> This is something that often amazes me that everyone doesn't do.

This looks interesting.

How do you specify what the mock should respond?

On Tuesday, 23 December 2014 at 17:37:57 UTC, Ary Borenszweig wrote:
> How do you specify what the mock should respond?

I'd just grep it or something like that. The main thing with this bit though is just not needing additional network programs to get a response - I typically use this functionality to load up the program in a debugger easily.

On Tue, 23 Dec 2014 17:01:02 +0000
Russel Winder via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On Mon, 2014-12-22 at 23:46 +0200, ketmar via Digitalmars-d wrote:
> > […]
> > matters. oh, really? Go can magically do all header parsing,
> > database management and other things for me? or we talking about
> > "echo" servers?
> 
> What happened was that a lot of people interested in all this HTTP bullshit, SQL dross, UI using Qt, and Go, and wrote a lot of libraries that everyone can use. So yes Go can do all that magic stuff – not just echo servers.
and so D. and i still has to learn libraries for all that. yet people talking Go being magic bullet: just use concurency and that's all!

nope. that's not all. that's not even the biggest part.

> I have no doubt that Vibe.d can do this. If there was a way of mocking (so that you can run integration tests without the actual network) with Vibe.d I would be having a play with it, but there isn't, so I am not.
isn't localhost enough? sure, you can test all the logic without network at all, and then use some of the available packages to test web part.

> > even adding the whole Go to D will not make D overtake Go. Go is hyped. D is not. that's all.
> 
> At this stage hype or not is a complete irrelevance, the point is that Go has a lot of people writing a lot of software for wide availability and use. D…is probably a far better language, but…
but it has no Google behind. the recipe is simple and easy:
1. take gw-basic.
2. take Google.
3. let Google to throw money into gw-basic hype.
4. people start writing alot of software in gw-basic.

there is no direct corellation between "being good in technical sense" and "being successfull". but there is such corellation between "advertising by Big Player" and "being successfull".

most people are morons. i'm not talking about Go uses here, not at all, i'm talking about the attitude like "everybody talking about X! Big Player supporting X! X is great!" here X can be anything.

On Tuesday, 23 December 2014 at 19:14:02 UTC, ketmar via Digitalmars-d wrote:
> and so D. and i still has to learn libraries for all that. yet people
> talking Go being magic bullet: just use concurency and that's all!
>
> nope. that's not all. that's not even the biggest part.

Library support is really important when doing web servers and integration with existing systems and workflows. This is not an area where D will be able to compete anytime soon, it is a crowded space: Java, Python, Ruby, Php, node.js and eventually Go. I have to connect to Google infrastructure, to legacy databases like Pervasive, parse Excel files, add encryption cross platform etc... Every other project might need a new library if you are to integrate with existing solutions, so there is really no end to what you need to support...


Reality check on stuff that could be relevant for a server:

https://github.com/trending?l=go&since=monthly

4943 stars for Go
2947 stars for Rocket
1029 stars for Docker
747 stars for  ssh-chat
622 stars for Kubernetes
672 stars for Jason
672 stars for aws-go
594 stars for bone
405 stars for influxdb
364 stars for etcd
356 stars for surgemq
246 stars for kite

https://github.com/trending?l=d&since=monthly

28 stars for vibe.d
10 stars for phobos
6 stars for druntime
6 stars for libasync
5 stars for arsd

That's a wipe out...

> 1. take gw-basic.
> 2. take Google.
> 3. let Google to throw money into gw-basic hype.
> 4. people start writing alot of software in gw-basic.
>
> there is no direct corellation between "being good in technical sense"
> and "being successfull". but there is such corellation between
> "advertising by Big Player" and "being successfull".

There is a strong correlation between not having a stable release and getting less attention from people who write libraries and frameworks for commercial use.

Besides, Basic got traction at a time where people charged for good languages, it was available for free and was not too demanding on resources so it was built into the ROM on basically all home computers in the 80s. That's how Basic got big.

On Tue, 23 Dec 2014 19:54:19 +0000
via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On Tuesday, 23 December 2014 at 19:14:02 UTC, ketmar via Digitalmars-d wrote:
> > and so D. and i still has to learn libraries for all that. yet
> > people
> > talking Go being magic bullet: just use concurency and that's
> > all!
> >
> > nope. that's not all. that's not even the biggest part.
> 
> Library support is really important when doing web servers and integration with existing systems and workflows.
and learning libraries is not free (if such libraies exists in the first place). yet people talking about Go tend to ignore this fact.

> This is not an area where D will be able to compete anytime soon
with all the C support libraries available D is not in a bad position.

> I have to connect to Google infrastructure
no wonder google support this with one of their pet language. ;-)

> to legacy databases like Pervasive
does it have C interface library?

> parse Excel files
good god!

> add encryption cross platform
in a web-server? O_O

> Every other project might need a new library if you are to integrate with existing solutions, so there is really no end to what you need to support...
that's where C libraries comes to rescue.

> Reality check on stuff that could be relevant for a server: https://github.com/trending?l=go&since=monthly
yes, this is good indicator of "hypeness". that's all.

> > 1. take gw-basic.
> > 2. take Google.
> > 3. let Google to throw money into gw-basic hype.
> > 4. people start writing alot of software in gw-basic.
> >
> > there is no direct corellation between "being good in technical
> > sense"
> > and "being successfull". but there is such corellation between
> > "advertising by Big Player" and "being successfull".
> There is a strong correlation between not having a stable release and getting less attention from people who write libraries and frameworks for commercial use.
i personally don't give a shit about that. i already expressed my attitude to "commercial use", even though i'm an employer myself.

> Besides, Basic got traction at a time where people charged for good languages, it was available for free and was not too demanding on resources so it was built into the ROM on basically all home computers in the 80s. That's how Basic got big.
i took gw-basic as a widely-known sample of bad language. you can replace it with your language of choice if you want, it doesn't matter.