subject:"Where will D sit in the web service space\?"

On Thursday, 16 July 2015 at 13:34:32 UTC, Ola Fosheim Grøstad 
wrote:


If you go node.js, you get static typing with typescript if you 
want + same language on the browser, debuggable.


If you go Dart you get static typing if you want  + same 
language the browser, debuggable.


Oh! someone thinks typescript is a programming language. 
Typescript runs in which browser? :) (Because when I use 
typescript, I worry about two things in my development process, 
.js and .ts)

Re: Where will D sit in the web service space?

On Tuesday, 14 July 2015 at 16:25:29 UTC, Ola Fosheim Grøstad 
wrote:


I think neither, but what I have alluded to in this thread. A 
lack of decision making regarding picking an application domain 
that is large enough to sustain an ecosystem of libraries, and 
going 100% for honing the feature set towards that domain. 
"Possible" is not good enough.






I think the rest comes when you have the best feature set for a 
particular domain and a polished compiler/runtime. So yeah, 
maybe Game clients is the best bet, since you don't have to 
change the semantics too much (low latency GC and linear typing 
would take time to work in) and games benefits from C++/iOS 
interop. Indie games have low adoption threshold and could work 
as marketing.


The Gaming industry is quiet a path to go on. Expecially since no 
language actually focus on that area.


For now, I see some new projects making good moves to writing 
gaming tools (I dislike bindings to C++).

Re: Where will D sit in the web service space?

On Wednesday, 15 July 2015 at 06:57:36 UTC, Sebastiaan Koppe 
wrote:


When I think about Web services and D, I don't think about just 
repeating what people do in other languages, but more about 
anticipating the future in web services. With my humble 
knowledge of the field that would be something with micro 
services and containers.


If D can do something cool with that, e.g. a web application 
framework where services sit behind a vibe-d web server, and 
where they can be easily developed, tested, deployed and 
upgraded - with 0 downtime - that would be great. Combine it 
with a knowledgeable community and some good practices (e.g. 
12factor apps) and you can have a honey-pot.


I don't think people care as much about the other stuff (gc, 
etc).


Yeah, no  one cares about GC considering the benefits and 
uplifted burden :)

Re: Where will D sit in the web service space?


On Tuesday, 14 July 2015 at 15:17:13 UTC, Sebastiaan Koppe wrote:
On Sunday, 12 July 2015 at 12:14:31 UTC, Ola Fosheim Grøstad 
wrote:

What do you think about the future for D in the web service
space?


What about this question: in 5 years from now what would be the 
reason D failed?


These come to my mind:

Tooling
Marketing
Talent Pool (companies not willing to adopt)


That is not going to happen. Maturity is the priority here. After 
that, boom!

Re: Where will D sit in the web service space?

2015-08-13 Thread via Digitalmars-d


On Wednesday, 12 August 2015 at 22:17:11 UTC, rsw0x wrote:

Rust is also backed by a major organization.

I(and others from what it seemed) was hoping Facebook using D 
internally and hiring major D developers would have Facebook 
promote/champion D a bit, but this did not happen. D needs a 
major corporation to champion it.


Yes, well. Java caught on because it was heavily marketed as THE 
web-programming language by SUN. That might not be how it is used 
today, but that is what got it attention and traction.


C++ was essentially a cost-free upgrade for existing C-code bases 
that provided more scalable abstraction mechanisms. So C++/OO was 
heavily pushed by magazines as the next big thing (this was 
before templates).


Maybe you need an organization, not sure. If it is commercial 
then people might not want to contribute so it can work both 
ways. I think people have been quite reluctant to jump in on 
Google-owned open source projects. Mozilla is perceived as a 
non-profit, so it's good.


So, I think being the best tool in your domain makes people more 
inclined to contribute. It makes business sense to improve the 
tooling you use in production.


Most languages that are "recognized as serious" had a domain 
where they were perceived as the only good option when they got 
picked up:


- C++ had existing C code bases as their domain.
- Java had the web as their domain.
- Ada had government contractors as their domain.
- Javascript had browsers as their domain.
- Lua had game scripting as the domain.
- Delphi had rapid prototyping/development as a domain.
- Haskell had language research as the domain.
etc.

Re: Where will D sit in the web service space?

2015-08-12 Thread Rikki Cattermole via Digitalmars-d


On 13/08/2015 10:17 a.m., rsw0x wrote:

On Wednesday, 12 August 2015 at 22:10:18 UTC, Ola Fosheim Grøstad wrote:

On Wednesday, 12 August 2015 at 21:16:28 UTC, karabuta wrote:

Not long ago, C++ was the perfect programming language that everybody
was running to. Then came ~ Java, 


Well, C++ was never considered a good language by anyone. It was
shunned at universities by lecturers. Java was basically Simula67 with
a different syntax and some adjustments.


But the demand of the past shifted to the web and now the worst p.
language rules the web (Sorry if you love JS too much but there is
too much bugs). Now we are stuck in it, who knows until when before
the world rushes to a new domain.


I am actually starting to kinda like TypeScript 1.5… And next gen
EcmaScript will have comprehensions…


maturing, and I see it maturing like gold. When D grows up (even
though it is doing powerful things in its infancy), you and I will
appreciate that it did not rush into any domain.


The contributor list to Rust1.2 claims 180 people were involved...

http://blog.rust-lang.org/2015/08/06/Rust-1.2.html

If you focus on a domain more people will have a significant interest
in making it work better.


Rust is also backed by a major organization.

I(and others from what it seemed) was hoping Facebook using D internally
and hiring major D developers would have Facebook promote/champion D a
bit, but this did not happen. D needs a major corporation to champion it.


Even so, D at Facebook is like D kinda still in it's infancy. Anyway. Do 
we really want newbies who think OOP is the best thing since sliced 
bread to come and try D out just because Facebook is using it?

Re: Where will D sit in the web service space?

2015-08-12 Thread rsw0x via Digitalmars-d

On Wednesday, 12 August 2015 at 22:10:18 UTC, Ola Fosheim Grøstad 
wrote:

On Wednesday, 12 August 2015 at 21:16:28 UTC, karabuta wrote:
Not long ago, C++ was the perfect programming language that 
everybody was running to. Then came ~ Java, 


Well, C++ was never considered a good language by anyone. It 
was shunned at universities by lecturers. Java was basically 
Simula67 with a different syntax and some adjustments.


But the demand of the past shifted to the web and now the 
worst p. language rules the web (Sorry if you love JS too much 
but there is too much bugs). Now we are stuck in it, who knows 
until when before the world rushes to a new domain.


I am actually starting to kinda like TypeScript 1.5… And next 
gen EcmaScript will have comprehensions…


maturing, and I see it maturing like gold. When D grows up 
(even though it is doing powerful things in its infancy), you 
and I will appreciate that it did not rush into any domain.


The contributor list to Rust1.2 claims 180 people were 
involved...


http://blog.rust-lang.org/2015/08/06/Rust-1.2.html

If you focus on a domain more people will have a significant 
interest in making it work better.


Rust is also backed by a major organization.

I(and others from what it seemed) was hoping Facebook using D 
internally and hiring major D developers would have Facebook 
promote/champion D a bit, but this did not happen. D needs a 
major corporation to champion it.

Re: Where will D sit in the web service space?

2015-08-12 Thread via Digitalmars-d


On Wednesday, 12 August 2015 at 21:16:28 UTC, karabuta wrote:
Not long ago, C++ was the perfect programming language that 
everybody was running to. Then came ~ Java, 


Well, C++ was never considered a good language by anyone. It was 
shunned at universities by lecturers. Java was basically Simula67 
with a different syntax and some adjustments.


But the demand of the past shifted to the web and now the worst 
p. language rules the web (Sorry if you love JS too much but 
there is too much bugs). Now we are stuck in it, who knows 
until when before the world rushes to a new domain.


I am actually starting to kinda like TypeScript 1.5… And next gen 
EcmaScript will have comprehensions…


maturing, and I see it maturing like gold. When D grows up 
(even though it is doing powerful things in its infancy), you 
and I will appreciate that it did not rush into any domain.


The contributor list to Rust1.2 claims 180 people were involved...

http://blog.rust-lang.org/2015/08/06/Rust-1.2.html

If you focus on a domain more people will have a significant 
interest in making it work better.

Re: Where will D sit in the web service space?

2015-08-12 Thread karabuta via Digitalmars-d

On Monday, 13 July 2015 at 07:11:35 UTC, Ola Fosheim Grøstad 
wrote:

On Sunday, 12 July 2015 at 19:02:23 UTC, Brad Anderson wrote:
I'd consider D a failure if it couldn't fill both of these 
roles. D is a general purpose systems programming language. It 
doesn't and shouldn't care about what you are using it for. 
There is plenty of overlap in what you need for high 
performance web backends and high performance gamedev.


Here's the deal: there is no such thing as a general purpose 
(system) language in the empirical sense. We might have been 
lead to believe that C or C++ were general purpose, but that 
only happend because there were no visible viable alternatives. 
C is more and more becoming a kernel/embedded language, C++ is 
more and more becoming a legacy/niche language. C++ is only a 
game dev language after you add various extensions (e.g. simd). 
It is only a number-crunching language after you add some other 
extensions. So you need a direction in the feature set towards 
an application area.


When you get new languages that cut down on development time 
(like Rust and Go) the C/C++ application domain will leak over 
to those niches based on the desired feature set. But the 
feature set needs to be complete for that application area 
(e.g. GC with the right characteristics, inlining/simd, GPU 
programming etc).


D needs to complete the feature set for some sizeable domain in 
order to compete in this emerging market of "many languages" 
(thanks to LLVM).


Not long ago, C++ was the perfect programming language that 
everybody was running to. Then came ~ Java, 


What I am saying is people do not know what they want at times. 
They get up everyday and they have a new idea on what D should 
be. Follow such comments and you will make some bad decisions. 
Currently, we are in a world where p. languages are driven by the 
demands of today.


Who knew that JavaScipt will become the language for the web? But 
the demand of the past shifted to the web and now the worst p. 
language rules the web (Sorry if you love JS too much but there 
is too much bugs). Now we are stuck in it, who knows until when 
before the world rushes to a new domain.



Now back to D:
The absence of certain tools and frameworks does not mean D is 
not picking up (not catching interests). The language is still 
maturing, and I see it maturing like gold. When D grows up (even 
though it is doing powerful things in its infancy), you and I 
will appreciate that it did not rush into any domain. With 
extensions, D can fit in any domain and this obviously takes time.


I am so tired(:>;) of seeing them (rust, Go, Pony, Cat, ..) 
everywhere, if one thinks rust rust OR JavaScript is the language 
they are planing to use for your next record-breaking kernel, 
. Because D cannot be them all.



The comparison war a bad chakra

Re: Where will D sit in the web service space?

2015-08-12 Thread karabuta via Digitalmars-d


On Sunday, 12 July 2015 at 18:53:35 UTC, weaselcat wrote:
On Sunday, 12 July 2015 at 17:54:02 UTC, Ola Fosheim Grøstad 
wrote:

On Sunday, 12 July 2015 at 12:32:32 UTC, Peter Alexander wrote:

[...]


Mostly because there is no real visible direction towards 
making D a competitor that directly addresses specific needs 
of web programming.


[...]


And suckerpunch everyone that has zero interest in a web 
language?



There's how many mature web languages? 10? 20? Why not dedicate 
D as a game programming language, am area that is completely 
untouched?


+3000

Re: Where will D sit in the web service space?


On Saturday, 25 July 2015 at 14:49:36 UTC, David Nadlinger wrote:
Why would that be so? You can still e.g. keep vector 
instructions in the IR and specialize according to the actual 
hardware width when you generate the binary.


You have several rather peculiar SIMD instructions that reflect 
the specifics of the CPU pipeline that can shave off quite a few 
cycles for specific algorithms. Different CPUs have different 
penalties for alignments, ARM can do rather well with 
misalignments. Different CPUs have different primitives, e.g. on 
ARM complex functions like sincos can be broken down into simpler 
primitives, so you can do less exact calculations (fewer 
iterations than on x86).

Re: Where will D sit in the web service space?

2015-07-25 Thread Joakim via Digitalmars-d

On Saturday, 25 July 2015 at 14:35:18 UTC, Ola Fosheim Grøstad 
wrote:

On Saturday, 25 July 2015 at 14:20:28 UTC, Joakim wrote:
The IR is only for Apple, they're still compiling it and 
distributing ASM to the device.


Yes, but if they go down that road it means you cannot target 
SIMD instructions. So you cannot get serious performance.


Most apps do not care about "serious performance" from SIMD, as 
you yourself pointed out.  But if they can get good performance 
from native languages, that is worth it.

Re: Where will D sit in the web service space?

2015-07-25 Thread David Nadlinger via Digitalmars-d

On Saturday, 25 July 2015 at 14:35:18 UTC, Ola Fosheim Grøstad 
wrote:
Yes, but if they go down that road it means you cannot target 
SIMD instructions.


Why would that be so? You can still e.g. keep vector instructions 
in the IR and specialize according to the actual hardware width 
when you generate the binary.


 — David

Re: Where will D sit in the web service space?


On Saturday, 25 July 2015 at 14:20:28 UTC, Joakim wrote:
The IR is only for Apple, they're still compiling it and 
distributing ASM to the device.


Yes, but if they go down that road it means you cannot target 
SIMD instructions. So you cannot get serious performance.

Re: Where will D sit in the web service space?

2015-07-25 Thread Joakim via Digitalmars-d

On Saturday, 25 July 2015 at 08:00:32 UTC, Ola Fosheim Grøstad 
wrote:

On Saturday, 25 July 2015 at 07:18:23 UTC, Joakim wrote:
Given the trend towards native/AoT compilation and that Dart 
doesn't fit in, I don't see it.


I have no idea, it is all about tooling, ease of development 
and end user experience.


And iOS appears to be moving away from ASM and towards using an 
intermediate representation that is hardware independent. So 
not a strict trend towards native. The trend over the past 5 
years appears to be going towards vendor specific solutions.


The IR is only for Apple, they're still compiling it and 
distributing ASM to the device.

Re: Where will D sit in the web service space?


On Saturday, 25 July 2015 at 07:18:23 UTC, Joakim wrote:
 In fact, I now see that Apple announced that they will be 
contributing a linux port when they open-source it later this 
year, so it won't even be tied to Apple's platform soon.


GNUStep has existed for decades. And gone nowhere.


What does that have to do with Swift getting a linux port?  
It's a lot easier to port and reuse a programming language than 
something like GNUStep.


I somehow doubt that anyone outside those already using 
Objective-C/Foundation will pick up Swift. Time will show.


As your subsequent posts show, it can easily be made to be 
almost as fast as C++, since it's a native language.


Well, those were not obvious tweaks in my book. Maybe Swift will 
improve in the future, I don't know.


For apps that are mostly GUI code, this may be true.  Still, 
google felt Java itself was enough of a bottleneck that they 
switched it from JIT compilation to AoT.


It did at least save them some memory and start up/warm-up time?

cross-platform.  Since the native GUIs can always be called 
from other languages, you could simply design a different GUI 
for each platform, by calling the native GUI APIs from one 
non-default language, say D, and use that same non-default 
language for all non-GUI code.


Yes, people do that.

Anyway, your point seems to be that native mobile is only 
taking off for superficial GUI reasons, but this ignores the 
fact that every mobile platform moved from higher-level and 
less efficient languages to lower-level native languages over 
time, from iOS's initial web sdk that was quickly ditched for 
Obj-C to the recent move by google to AoT-compile all the Java 
apps since Android 5.  I guess they all did this for no reason 
at all.


All I really can say is that many scripting languages are fast 
enough for the typical logic you need in a regular mobile app... 
But both Google/Apple need a lock-in strategy to get unique apps 
on their platform. What killed Mosync as a project was IMHO the 
diverging GUIs and the competing cross platform solutions based 
on scripting-languages.


Performance?  Arguable, for apps that are mostly GUI code.  
Battery life?  No way.


Few developers care about battery life when the app is actively 
used. It's not like end users will say "When I use the weather 
app my battery gets drained faster".  What matters are things 
like not doing frequent work when the app is idle.


Now, vendors might care and have many reasons for pushing their 
own platform.


Given the trend towards native/AoT compilation and that Dart 
doesn't fit in, I don't see it.


I have no idea, it is all about tooling, ease of development and 
end user experience.


And iOS appears to be moving away from ASM and towards using an 
intermediate representation that is hardware independent. So not 
a strict trend towards native. The trend over the past 5 years 
appears to be going towards vendor specific solutions.

Re: Where will D sit in the web service space?

2015-07-25 Thread Joakim via Digitalmars-d

On Saturday, 25 July 2015 at 06:21:50 UTC, Ola Fosheim Grøstad 
wrote:

On Saturday, 25 July 2015 at 03:44:23 UTC, Joakim wrote:
No, Swift is already general-purpose because it isn't highly 
optimized for a single purpose or feature and it's a fairly 
low-level native language which could be used to write 
everything from hardware drivers to webapps.


Hardware drivers?


Why not?  If you can get FFT within 10% of C++, you could 
probably disable ARC, turn off dynamic dispatch, and write 
something reasonably fast.  It is a native language after all, 
just like D.


 In fact, I now see that Apple announced that they will be 
contributing a linux port when they open-source it later this 
year, so it won't even be tied to Apple's platform soon.


GNUStep has existed for decades. And gone nowhere.


What does that have to do with Swift getting a linux port?  It's 
a lot easier to port and reuse a programming language than 
something like GNUStep.


As for Apple's "subconscious gratifications," considering I 
bought my first and last Apple product, a Powerbook G4, a 
decade ago and would never buy any of their products since, 
because of their crazy patent stance, that certainly doesn't 
describe me.  Ola brought up Swift as some sort of exception 
to the "general-purpose native languages on mobile" trend and 
I'm simply pointing out that's not true.


http://www.primatelabs.com/blog/2014/12/swift-performance/

Swift is 24x slower than C++ for FFT…


As your subsequent posts show, it can easily be made to be almost 
as fast as C++, since it's a native language.


Standard apps on Android, iOS and in browsers rely heavily upon 
the builtin rendering/animation engines of their platforms 
(written in C/C++). The bottleneck for Javascript apps on 
mobile is the animation engine and emulating the native GUI. 
For the vast majority of apps Javascript itself performs well 
enough.


For apps that are mostly GUI code, this may be true.  Still, 
google felt Java itself was enough of a bottleneck that they 
switched it from JIT compilation to AoT.


For many mobile apps 80% of the code is GUI code. That means 
you pay a high price for not using the default language and 
TOOLING for the platform. As I've pointed out cross platform 
GUI is no longer a realistic option since the Apple/Google have 
differentiated their GUIs on purpose in order to make it harder.


Even if 80% is GUI code, the remaining 20% can slow you down.  
You don't have to use the default language and tooling in order 
to call the native GUI APIs, as you yourself pointed out with 
your MoSync example.  As for cross-platform GUIs, an app's GUI 
doesn't need to be the _same_ across platforms in order to be 
cross-platform.  Since the native GUIs can always be called from 
other languages, you could simply design a different GUI for each 
platform, by calling the native GUI APIs from one non-default 
language, say D, and use that same non-default language for all 
non-GUI code.  That way, you save some re-implementation time in 
each default platform language for the non-GUI code, at least.


Anyway, your point seems to be that native mobile is only taking 
off for superficial GUI reasons, but this ignores the fact that 
every mobile platform moved from higher-level and less efficient 
languages to lower-level native languages over time, from iOS's 
initial web sdk that was quickly ditched for Obj-C to the recent 
move by google to AoT-compile all the Java apps since Android 5.  
I guess they all did this for no reason at all.


From a performance perspective you could probably do most 
mobile apps in Javascript/V8 with no noticeable impact.


Performance?  Arguable, for apps that are mostly GUI code.  
Battery life?  No way.


Btw, Dart has picked up the null-related-operators from Swift. 
It also has async syntax sugar over Futures. It might 
eventually be positioned as a mobile language for Android, 
through Sky SDK and Material Design widgets.


Given the trend towards native/AoT compilation and that Dart 
doesn't fit in, I don't see it.

Re: Where will D sit in the web service space?


On Saturday, 25 July 2015 at 06:54:09 UTC, Paulo Pinto wrote:
On Saturday, 25 July 2015 at 06:27:29 UTC, Ola Fosheim Grøstad 
wrote:
On Saturday, 25 July 2015 at 06:24:57 UTC, Ola Fosheim Grøstad 
wrote:
On Saturday, 25 July 2015 at 06:21:50 UTC, Ola Fosheim 
Grøstad wrote:

Swift is 24x slower than C++ for FFT…


http://www.primatelabs.com/blog/2015/02/swift-performance-updated/

With some optimizations it is now down to… 10x the execution 
time of C++...


Nnngh, typo. With latest version of Swift it is down to 10x 
the execution time and with careful programmer optimizations 
that more or less sidesteps the default semantics you can get 
within 10%.


Already outdated given the performance improvements in Swift 
2.0 toolchain.


I think those are <20%? Or?

https://github.com/vsco/swift-benchmarks

Re: Where will D sit in the web service space?

2015-07-24 Thread Paulo Pinto via Digitalmars-d

On Saturday, 25 July 2015 at 06:27:29 UTC, Ola Fosheim Grøstad 
wrote:
On Saturday, 25 July 2015 at 06:24:57 UTC, Ola Fosheim Grøstad 
wrote:
On Saturday, 25 July 2015 at 06:21:50 UTC, Ola Fosheim Grøstad 
wrote:

Swift is 24x slower than C++ for FFT…


http://www.primatelabs.com/blog/2015/02/swift-performance-updated/

With some optimizations it is now down to… 10x the execution 
time of C++...


Nnngh, typo. With latest version of Swift it is down to 10x the 
execution time and with careful programmer optimizations that 
more or less sidesteps the default semantics you can get within 
10%.


Already outdated given the performance improvements in Swift 2.0 
toolchain.

Re: Where will D sit in the web service space?

On Saturday, 25 July 2015 at 06:24:57 UTC, Ola Fosheim Grøstad 
wrote:
On Saturday, 25 July 2015 at 06:21:50 UTC, Ola Fosheim Grøstad 
wrote:

Swift is 24x slower than C++ for FFT…


http://www.primatelabs.com/blog/2015/02/swift-performance-updated/

With some optimizations it is now down to… 10x the execution 
time of C++...


Nnngh, typo. With latest version of Swift it is down to 10x the 
execution time and with careful programmer optimizations that 
more or less sidesteps the default semantics you can get within 
10%.

Re: Where will D sit in the web service space?


On Saturday, 25 July 2015 at 03:44:23 UTC, Joakim wrote:
No, Swift is already general-purpose because it isn't highly 
optimized for a single purpose or feature and it's a fairly 
low-level native language which could be used to write 
everything from hardware drivers to webapps.


Hardware drivers?

 In fact, I now see that Apple announced that they will be 
contributing a linux port when they open-source it later this 
year, so it won't even be tied to Apple's platform soon.


GNUStep has existed for decades. And gone nowhere.

As for Apple's "subconscious gratifications," considering I 
bought my first and last Apple product, a Powerbook G4, a 
decade ago and would never buy any of their products since, 
because of their crazy patent stance, that certainly doesn't 
describe me.  Ola brought up Swift as some sort of exception to 
the "general-purpose native languages on mobile" trend and I'm 
simply pointing out that's not true.


http://www.primatelabs.com/blog/2014/12/swift-performance/

Swift is 24x slower than C++ for FFT…

Standard apps on Android, iOS and in browsers rely heavily upon 
the builtin rendering/animation engines of their platforms 
(written in C/C++). The bottleneck for Javascript apps on mobile 
is the animation engine and emulating the native GUI. For the 
vast majority of apps Javascript itself performs well enough.


For many mobile apps 80% of the code is GUI code. That means you 
pay a high price for not using the default language and TOOLING 
for the platform. As I've pointed out cross platform GUI is no 
longer a realistic option since the Apple/Google have 
differentiated their GUIs on purpose in order to make it harder.


From a performance perspective you could probably do most mobile 
apps in Javascript/V8 with no noticeable impact.


Btw, Dart has picked up the null-related-operators from Swift. It 
also has async syntax sugar over Futures. It might eventually be 
positioned as a mobile language for Android, through Sky SDK and 
Material Design widgets.

Re: Where will D sit in the web service space?

On Saturday, 25 July 2015 at 06:21:50 UTC, Ola Fosheim Grøstad 
wrote:

Swift is 24x slower than C++ for FFT…


http://www.primatelabs.com/blog/2015/02/swift-performance-updated/

With some optimizations it is now down to… 10x the execution time 
of C++...

Re: Where will D sit in the web service space?


On Friday, 24 July 2015 at 17:22:14 UTC, Etienne wrote:

On Friday, 24 July 2015 at 16:57:04 UTC, Joakim wrote:
On Friday, 24 July 2015 at 14:50:23 UTC, Ola Fosheim Grøstad 
wrote:
ART.  Of course Metal isn't general-purpose, nobody said it 
is, but I don't see why you'd say Swift isn't.


Swift is clearly designed around Objective-C and Cocoa.


Oh, and I didn't respond to this because I didn't even know 
what you meant, think I got it now.  You're now saying Swift 
isn't general-purpose simply because it's initially designed 
around Apple's Cocoa OS APIs?  Being tied to a single platform 
doesn't make a language any less general-purpose, and since 
they announced that they're open-sourcing Swift later this 
year, it will be ported to other platforms, just as Obj-C has.


Apple has become such a taboo subject. They've invested so much 
on subconscious gratifications that nobody can discuss the 
company objectively. I mean, Swift is general purpose because 
the holy masters of computer culture "want" to open source it, 
and open source can become general purpose, right? Eh..


No, Swift is already general-purpose because it isn't highly 
optimized for a single purpose or feature and it's a fairly 
low-level native language which could be used to write everything 
from hardware drivers to webapps.  In fact, I now see that Apple 
announced that they will be contributing a linux port when they 
open-source it later this year, so it won't even be tied to 
Apple's platform soon.


As for Apple's "subconscious gratifications," considering I 
bought my first and last Apple product, a Powerbook G4, a decade 
ago and would never buy any of their products since, because of 
their crazy patent stance, that certainly doesn't describe me.  
Ola brought up Swift as some sort of exception to the 
"general-purpose native languages on mobile" trend and I'm simply 
pointing out that's not true.

Re: Where will D sit in the web service space?

2015-07-24 Thread David Gileadi via Digitalmars-d


On 7/24/15 9:57 AM, Joakim wrote:

On Friday, 24 July 2015 at 14:50:23 UTC, Ola Fosheim Grøstad wrote:

ART.  Of course Metal isn't general-purpose, nobody said it is, but I
don't see why you'd say Swift isn't.


Swift is clearly designed around Objective-C and Cocoa.


Oh, and I didn't respond to this because I didn't even know what you
meant, think I got it now.  You're now saying Swift isn't
general-purpose simply because it's initially designed around Apple's
Cocoa OS APIs?  Being tied to a single platform doesn't make a language
any less general-purpose, and since they announced that they're
open-sourcing Swift later this year, it will be ported to other
platforms, just as Obj-C has.


I've been doing a lot of Swift programming recently, and here are my 
impressions: Yes, it's heavily designed around Objective-C and Cocoa, 
but it's a nice language on its own. It feels like the designers are 
working for an all-Swift future, and are discarding some 
Objective-C/Cocoa-isms along the way.


As for the language itself I really like the syntax and many of the 
constructs. The nil/non-nil typing tends to intrude a bit too often for 
my liking (like D's const does but more pervasive). And I miss the 
things that D lets me do, particularly its fantastic metaprogramming and 
ability to go low-level. I don't love Swift like I love D, but it's a 
nice language to work with.

Re: Where will D sit in the web service space?

2015-07-24 Thread Etienne via Digitalmars-d


On Friday, 24 July 2015 at 16:57:04 UTC, Joakim wrote:
On Friday, 24 July 2015 at 14:50:23 UTC, Ola Fosheim Grøstad 
wrote:
ART.  Of course Metal isn't general-purpose, nobody said it 
is, but I don't see why you'd say Swift isn't.


Swift is clearly designed around Objective-C and Cocoa.


Oh, and I didn't respond to this because I didn't even know 
what you meant, think I got it now.  You're now saying Swift 
isn't general-purpose simply because it's initially designed 
around Apple's Cocoa OS APIs?  Being tied to a single platform 
doesn't make a language any less general-purpose, and since 
they announced that they're open-sourcing Swift later this 
year, it will be ported to other platforms, just as Obj-C has.


Apple has become such a taboo subject. They've invested so much 
on subconscious gratifications that nobody can discuss the 
company objectively. I mean, Swift is general purpose because the 
holy masters of computer culture "want" to open source it, and 
open source can become general purpose, right? Eh..

Re: Where will D sit in the web service space?

On Friday, 24 July 2015 at 14:50:23 UTC, Ola Fosheim Grøstad 
wrote:
ART.  Of course Metal isn't general-purpose, nobody said it 
is, but I don't see why you'd say Swift isn't.


Swift is clearly designed around Objective-C and Cocoa.


Oh, and I didn't respond to this because I didn't even know what 
you meant, think I got it now.  You're now saying Swift isn't 
general-purpose simply because it's initially designed around 
Apple's Cocoa OS APIs?  Being tied to a single platform doesn't 
make a language any less general-purpose, and since they 
announced that they're open-sourcing Swift later this year, it 
will be ported to other platforms, just as Obj-C has.

Re: Where will D sit in the web service space?

On Friday, 24 July 2015 at 15:06:31 UTC, Ola Fosheim Grøstad 
wrote:

On Friday, 24 July 2015 at 14:55:59 UTC, Joakim wrote:
So Obj-C/Swift aren't as efficient as C/C++, but nobody is 
using those as the main language on any mobile platform- for 
very good reasons, including that nobody other than game 
developers wants to deal with them- and as native languages, 
Obj-C and Swift are still much more efficient than the JIT-ed 
or interpreted, non-native languages, which is why Android 
finally switched from JIT-ing Java to AoT/native compilation 
recently.


People have used C++ for both native mobile development 
(symbian?) and for cross-platform development (e.g. mosync).


Symbian is dead, therefore "nobody is using" it.  As for MoSync, 
they went out of business a couple years ago and their toolkit is 
no longer maintained, nor was it ever the "main language" on any 
platform.


However Android and iOS deliberately set  out to kill off 
cross-platform development a few years ago by making GUI kits 
incompatible and tool-based. So writing GUIs in other languages 
than Obj-C/Java became tedious.


I don't think that's the reason, as their GUI APIs can be called 
from other languages, Java is fairly cross-platform, and the 
Android GUI is open source and can always be ported, as it has 
been.  Perhaps nobody has bothered to build a single GUI toolkit 
that normalizes across the GUI APIs of each OS, but that doesn't 
mean it can't be done.


I found it much easier to use Mosync-C++ than Objective-C, to 
be honest. But it is now a dead technology.


What does this have to do with the original point, which is that 
native/AoT-compiled languages are having a resurgence on mobile?  
You made the point that some native languages are more efficient 
than others, which is irrelevant when they are all much more 
efficient than the non-native languages.

Re: Where will D sit in the web service space?


On Friday, 24 July 2015 at 14:55:59 UTC, Joakim wrote:
So Obj-C/Swift aren't as efficient as C/C++, but nobody is 
using those as the main language on any mobile platform- for 
very good reasons, including that nobody other than game 
developers wants to deal with them- and as native languages, 
Obj-C and Swift are still much more efficient than the JIT-ed 
or interpreted, non-native languages, which is why Android 
finally switched from JIT-ing Java to AoT/native compilation 
recently.


People have used C++ for both native mobile development 
(symbian?) and for cross-platform development (e.g. mosync). 
However Android and iOS deliberately set  out to kill off 
cross-platform development a few years ago by making GUI kits 
incompatible and tool-based. So writing GUIs in other languages 
than Obj-C/Java became tedious.


I found it much easier to use Mosync-C++ than Objective-C, to be 
honest. But it is now a dead technology.

Re: Where will D sit in the web service space?

On Friday, 24 July 2015 at 14:50:23 UTC, Ola Fosheim Grøstad 
wrote:

On Friday, 24 July 2015 at 14:44:54 UTC, Joakim wrote:

What is not "efficiency focused" about Obj-C and Swift?


Objective-C uses a rather expensive reference counting model 
and a dynamic dispatch mechanism.


So Obj-C/Swift aren't as efficient as C/C++, but nobody is using 
those as the main language on any mobile platform- for very good 
reasons, including that nobody other than game developers wants 
to deal with them- and as native languages, Obj-C and Swift are 
still much more efficient than the JIT-ed or interpreted, 
non-native languages, which is why Android finally switched from 
JIT-ing Java to AoT/native compilation recently.

Re: Where will D sit in the web service space?


On Friday, 24 July 2015 at 14:44:54 UTC, Joakim wrote:

What is not "efficiency focused" about Obj-C and Swift?


Objective-C uses a rather expensive reference counting model and 
a dynamic dispatch mechanism.


ART.  Of course Metal isn't general-purpose, nobody said it is, 
but I don't see why you'd say Swift isn't.


Swift is clearly designed around Objective-C and Cocoa.

Re: Where will D sit in the web service space?

On Friday, 24 July 2015 at 06:02:12 UTC, Ola Fosheim Grøstad 
wrote:

On Friday, 24 July 2015 at 05:19:08 UTC, Joakim wrote:
Yep, I specifically mentioned the mobile and server domains as 
places where general-purpose native/AoT-compiled languages are 
having a resurgence, obviously for the efficiency reasons 
Etienne lists.


In theory. Objective-C and Swift are AoT, but not efficiency 
focused and geared towards interactive apps. I wouldn't call 
Swift+Metal general purpose.


What is not "efficiency focused" about Obj-C and Swift?  iOS apps 
are known for their much better battery life and responsiveness, 
which is why google finally started AoT-compiling Java with 
Android 5 and added a concurrent GC in ART.  Of course Metal 
isn't general-purpose, nobody said it is, but I don't see why 
you'd say Swift isn't.


de-emphasized as a result.  However, with the rise of mobile 
and webapps not doing as well there, for a variety of reasons, 
native development is coming back for many apps, at least on 
the client side for networked apps.


For most apps it is mostly about UI look-and-feel, not really 
performance.


That is the dumb reason that many people do native mobile apps, 
no question, but performance is a big part of the equation also, 
which is why some big HTML5 mobile apps ended up switching to 
native mobile instead.

Re: Where will D sit in the web service space?


On Friday, 24 July 2015 at 08:24:45 UTC, Kagamin wrote:

Domain is the same, it's feature overlap, which is small.


Nope. Domain is not the same. Feature set is not at all the same. 
You would not write a web browser in Go.


- Rust is more like C++ and D, abstractions closer to current 
hardware, stricter typing at the cost of complexity, no GC.


- Go use abstractions more detatched from current hardware, 
simplicity over advanced mechanisms, fully based on GC.

Re: Where will D sit in the web service space?

2015-07-24 Thread Kagamin via Digitalmars-d

On Thursday, 23 July 2015 at 07:05:16 UTC, Ola Fosheim Grøstad 
wrote:
But I think Rust and Go are focusing on specific domains. I 
think people pick languages now looking for specific 
characteristics that match their domain. I think the overlap 
between Rust and Go is rather small.


Domain is the same, it's feature overlap, which is small. Highly 
concurrent chat service? Yeah 
http://nbaksalyar.github.io/2015/07/10/writing-chat-in-rust.html

Re: Where will D sit in the web service space?

2015-07-23 Thread via Digitalmars-d


On Friday, 24 July 2015 at 05:19:08 UTC, Joakim wrote:
Yep, I specifically mentioned the mobile and server domains as 
places where general-purpose native/AoT-compiled languages are 
having a resurgence, obviously for the efficiency reasons 
Etienne lists.


In theory. Objective-C and Swift are AoT, but not efficiency 
focused and geared towards interactive apps. I wouldn't call 
Swift+Metal general purpose.


de-emphasized as a result.  However, with the rise of mobile 
and webapps not doing as well there, for a variety of reasons, 
native development is coming back for many apps, at least on 
the client side for networked apps.


For most apps it is mostly about UI look-and-feel, not really 
performance.

Re: Where will D sit in the web service space?

2015-07-23 Thread Joakim via Digitalmars-d


On Thursday, 23 July 2015 at 17:44:59 UTC, Etienne wrote:

On Thursday, 23 July 2015 at 17:03:31 UTC, Laeeth Isharc wrote:
But some of us think general-purpose, native languages are 
coming back,


Yes.  Now why do you think this is the case?  I tried to 
articulate it as best I could for now, but Ola has all these 
_reasons_ why this isn't the case, which may mean he is right, 
but might not.


Native languages are more efficient, they use less power. This 
is increasingly important to reduce the greenhouse gas 
emissions, to improve battery duration on mobile devices or to 
reduce server costs in general.


Yep, I specifically mentioned the mobile and server domains as 
places where general-purpose native/AoT-compiled languages are 
having a resurgence, obviously for the efficiency reasons Etienne 
lists.  Being general-purpose simply means that you wouldn't be 
limited to one of those domains, and could quickly bridge over to 
even newer domains that spring up.


One big trend over the last decade and a half has been the rise 
of webapps, where native desktop apps, which are still 
predominantly written in native languages, have been 
de-emphasized as a result.  However, with the rise of mobile and 
webapps not doing as well there, for a variety of reasons, native 
development is coming back for many apps, at least on the client 
side for networked apps.


On the server, as long as you don't really need to scale out, you 
have a lot of choices for your tech.  But the moment you need to 
scale, you'll probably want to go native, at least for your 
backend.

Re: Where will D sit in the web service space?

2015-07-23 Thread Etienne via Digitalmars-d


On Thursday, 23 July 2015 at 17:03:31 UTC, Laeeth Isharc wrote:
But some of us think general-purpose, native languages are 
coming back,


Yes.  Now why do you think this is the case?  I tried to 
articulate it as best I could for now, but Ola has all these 
_reasons_ why this isn't the case, which may mean he is right, 
but might not.


Native languages are more efficient, they use less power. This is 
increasingly important to reduce the greenhouse gas emissions, to 
improve battery duration on mobile devices or to reduce server 
costs in general.


The language design is also more modern, the compile times 
shorter, the errors more comprehensible, which makes interpreted 
languages less appealing for those who care about learning the 
alternatives. The gap in complexity is closing up.


Finally, I answered an interview in This week in D about how I 
thought D in general had an excellent way to bind multiple 
components together, from other languages, thus making it not 
only general purpose but also a "glue", a centralized hub from 
which every team can build its interface on top of, whichever 
technology is used. After all, it was developed very late in the 
"language wars" with clear attempts to open itself up to the 
legacy software left behind by other languages.

Re: Where will D sit in the web service space?

2015-07-23 Thread Laeeth Isharc via Digitalmars-d


On Wednesday, 22 July 2015 at 21:38:14 UTC, Joakim wrote:
The finance guys seem to be coming on board, the Dconf '15 talk 
by the fund guy, Smith, probably helps.


Yes - that's my impression, too, and I am doing my little bit to 
encourage people to consider the benefits of D.  People are 
sometimes more open to hearing something from a practitioner and 
business person who knows a little technology than from a pure 
tech guy.  Finance is a funny area because the stakes are high, 
but people are much more open-minded in some parts of it to 
trying things (it's not always as enterprisey as more stodgey 
firms in this respect).


There's a crisis in the use of technology in finance.  Citadel 
(large US hedge fund where I worked in London) used to tell 
people that the firm was almost more of a technology firm than a 
finance firm, and I am not going to comment on that.  Similarly, 
the banks also conceive of themselves as leading in technology.  
The reality (in the general case, and without wishing to comment 
on specific firms) is that things are a mess - fragmented, siloed 
operations with significant costs from legacy approaches that no 
longer fit the new needs of the business.  I agree with Dicebot 
that I haven't found an alternative to D that has high 
productivity, decent speed and power, and suitability for 
multiple problem domains.  Innovation requires the ability to 
iterate rapidly, and to get an answer to questions quickly.  In 
theory when cloud power is free, efficiency doesn't matter, but 
it's not that easy in practice.  Despite the theoretically big 
budget, being able to produce a workable proof of concept quickly 
without needing budget approval has tremendous value.


Thanks for the rest of your post - I agree very much with what 
you write, and it carries weight as you know the problem domain 
well.


And as I've said before, focusing on a domain means you 
optimize for it, which inevitably means you become less general.


Quite!  Optimization creates brittleness to things you don't 
optimize for, and nobody can know at this stage what the 
important things might ultimately be.  Central planning has its 
downsides, even if the way that planning occurs through 
polycentric activity in a community seems less rational and pure. 
 Hayek had something to say about this.


But some of us think general-purpose, native languages are 
coming back,


Yes.  Now why do you think this is the case?  I tried to 
articulate it as best I could for now, but Ola has all these 
_reasons_ why this isn't the case, which may mean he is right, 
but might not.

Re: Where will D sit in the web service space?

2015-07-23 Thread via Digitalmars-d


On Thursday, 23 July 2015 at 10:16:02 UTC, Tofu Ninja wrote:
Also game dev does not really have a go to language other than 
C or C++, so D could really make progress in there as it 
already trying to be a C++ replacement. I don't see go or rust 
being used seriously in game dev either, so less competition.


I agree with this. The real competition there is language 
combinations like: C++ combined with Swift, C++ combined with 
some scripting language...

Re: Where will D sit in the web service space?

2015-07-23 Thread Tofu Ninja via Digitalmars-d


On Thursday, 23 July 2015 at 10:24:18 UTC, Rikki Cattermole wrote:

On 23/07/2015 10:16 p.m., Tofu Ninja wrote:

[...]
Though it seems like D is already be moving in that direction. 
Color and

image being worked on,


We need image for a lot more then just game dev. Without it, we 
will never get a GUI toolkit. Web dev will also suffer, barcode 
generation anyone?



allocators and less reliance on GC, and all the


Any high performance program including web development requires 
allocators and friends. In fact, right now allocators are the 
only way to do web development in D properly. With having each 
request able to allocate things temporarily and have it auto 
deallocate without the GC being a burden.




Thats the great part about focusing on game dev, is that it's 
needs are so applicable to other domains.


Gl3n, we need to get that into Phobos. My knowledge of math 
isn't good enough to do it. But it should already be pretty 
reliable on that side of things. It just need to be modified to 
Phobos standards/requirements.


It's an old library, but a damn good one. We would be stupid to 
not get it in. People are remaking it poorly as it is.


https://github.com/Dav1dde/gl3n


Yeah, even I have my own personal matrix lib, but like you said, 
a poor remake.

Re: Where will D sit in the web service space?

2015-07-23 Thread Rikki Cattermole via Digitalmars-d


On 23/07/2015 10:16 p.m., Tofu Ninja wrote:

[...]
Though it seems like D is already be moving in that direction. Color and
image being worked on,


We need image for a lot more then just game dev. Without it, we will 
never get a GUI toolkit. Web dev will also suffer, barcode generation 
anyone?



allocators and less reliance on GC, and all the


Any high performance program including web development requires 
allocators and friends. In fact, right now allocators are the only way 
to do web development in D properly. With having each request able to 
allocate things temporarily and have it auto deallocate without the GC 
being a burden.



great game dev related packages in dub, D is already moving towards good
game dev. Some basic vector math in phobos would really be a great
addition as well.


Gl3n, we need to get that into Phobos. My knowledge of math isn't good 
enough to do it. But it should already be pretty reliable on that side 
of things. It just need to be modified to Phobos standards/requirements.


It's an old library, but a damn good one. We would be stupid to not get 
it in. People are remaking it poorly as it is.


https://github.com/Dav1dde/gl3n

Re: Where will D sit in the web service space?

2015-07-23 Thread Tofu Ninja via Digitalmars-d


On Thursday, 23 July 2015 at 08:16:11 UTC, Joakim wrote:

[...]
Yes, they both captured smaller markets and stopped there, 
unable to go further.  D is aiming for a bigger market.


Personally I think you both make good points, D really shines as 
a general purpose language, and I wouldn't want to change that. 
But getting D to be a go to language for a niche market would 
help D a lot in terms of adoption, and getting contributors.


As others have said before in this thread, I think where D could 
actually make progress in is in game dev as it has such a massive 
set of needs. D covers a lot of its needs really well, and 
focusing on game dev would not make D itself very niche. Also 
game dev does not really have a go to language other than C or 
C++, so D could really make progress in there as it already 
trying to be a C++ replacement. I don't see go or rust being used 
seriously in game dev either, so less competition.


Though it seems like D is already be moving in that direction. 
Color and image being worked on, allocators and less reliance on 
GC, and all the great game dev related packages in dub, D is 
already moving towards good game dev. Some basic vector math in 
phobos would really be a great addition as well.

Re: Where will D sit in the web service space?

2015-07-23 Thread Joakim via Digitalmars-d

On Thursday, 23 July 2015 at 07:05:16 UTC, Ola Fosheim Grøstad
wrote:

On Wednesday, 22 July 2015 at 21:38:14 UTC, Joakim wrote:
"[W]e've loved D so much that we're in the middle of a full
rewrite from C++11 to D. The productivity boost is absolutely
worth it."

http://www.reddit.com/r/programming/comments/3cg1r0/lessons_learned_writing_a_filesystem_in_d/csvyxn8

But it doesn't say why. Did they evaluate Rust too?

It's a reddit comment, not a blog post, understandable that they
didn't get into all that.

Granted, everyone can find several very good reasons to dislike
C++, so any reasonable language that can replace it can be said
to have an advantage if that dislike is present on a C++ team...

Sounds like they love D more than simply disliking C++.

But as far as C/C++ replacement languages go, there are several
focusing on being more suitable than C++ for specific niches:
Rust, Go, Chapel, Vala…

The more generic ones like D, Loci, etc appears to be less
used. I assume the lack of a specific edge over C++ matters.

Perhaps, but are Chapel and Vala more used than D? I wouldn't
think so.

And as I've said before, focusing on a domain means you
optimize for it, which inevitably means you become less
general.

Not really, you just focus your effort at making it work really
well for a particular domain. Like C++ with extensions for a
specific purpose.

Resources are limited, so focusing on that domain usually means
the other domains suffer. Worse, language design choices made to
optimize for that domain can hamstring any attempt to turn the
language more general-purpose later.

Php has proven to be highly optimized for the web programming
domain, in that it is highly successful at being chosen for
many web projects, but almost nobody would want to use it for
anything else, for a variety of reasons, but mainly that the
qualities that make it successful on the web hurt it in other
domains.

Well, Php is quite horrible for web programming too, but they
gained traction for many of the same reasons perl did:

- It was easy to get started with when you needed 10-50 lines
of scripting in 500 lines of HTML.

- Provided library interfaces that was similar to
Unix/C-libraries (really awful, but easy to get started)

- Early adopters, there was no real competition outside perl

- It got "bundled" with web-servers one way or the other.

Right, all but the third are choices they took to do well in that
niche, that don't translate to, say, writing a good native mobile
app. If you want to be general-purpose, you have to put more
thought into staying out of the trap of trying to be as simple as
possible for scripting, because that will hurt you for heavier
tasks.

languages. Even if the pendulum doesn't swing all the way
back as far as we think it will for general-purpose native
languages, that's a very large niche, one with few choices- C,
C++, D, Rust, Go (the first two legacy)- and well worth
competing in.

But I think Rust and Go are focusing on specific domains. I
think people pick languages now looking for specific
characteristics that match their domain. I think the overlap
between Rust and Go is rather small.

Even better for D if Rust and Go are ceding the general-purpose
language niche, :) I only mentioned those two because they're the
native languages with the most hype right now and are somewhat
general-purpose. But Rust is supposedly aiming for the niche of
large codebases written in a native language, such as a browser
engine, and the ownership system they use to enable that turns
off those not in that niche for being too complicated. Go aims
for the network servers niche, but that means those who want
generics are never going to consider it.

Do you not see that there's a niche for a general-purpose
programming language, in that it could theoretically be applied
to everything from writing operating systems to webapps to
scripts (even if it will rarely be used for the later two), one
that C and C++ currently dominate? It may be hard to knock them
off, particularly as they're not standing still, but that's a
much larger niche than the small domains you list.

roaring past D. If your only point is that it's done better
than it has a right to because it has a very specific strength,

I'd say that Erlang captured a market despite shortcoming
because it was the only easy-way-out. And you probably could
say that about PhP too.

Yes, they both captured smaller markets and stopped there, unable
to go further. D is aiming for a bigger market.

Re: Where will D sit in the web service space?

2015-07-23 Thread via Digitalmars-d

On Wednesday, 22 July 2015 at 21:38:14 UTC, Joakim wrote:
The finance guys seem to be coming on board, the Dconf '15 talk
by the fund guy, Smith, probably helps. I thought this was a
nice endorsement recently, a reddit comment by a high-frequency
trader which ended with:

"[W]e've loved D so much that we're in the middle of a full
rewrite from C++11 to D. The productivity boost is absolutely
worth it."

http://www.reddit.com/r/programming/comments/3cg1r0/lessons_learned_writing_a_filesystem_in_d/csvyxn8

But it doesn't say why. Did they evaluate Rust too?

Granted, everyone can find several very good reasons to dislike
C++, so any reasonable language that can replace it can be said
to have an advantage if that dislike is present on a C++ team...

But as far as C/C++ replacement languages go, there are several
focusing on being more suitable than C++ for specific niches:
Rust, Go, Chapel, Vala…

The more generic ones like D, Loci, etc appears to be less used.
I assume the lack of a specific edge over C++ matters.

And as I've said before, focusing on a domain means you
optimize for it, which inevitably means you become less general.

Not really, you just focus your effort at making it work really
well for a particular domain. Like C++ with extensions for a
specific purpose.

Well, Php is quite horrible for web programming too, but they
gained traction for many of the same reasons perl did:

- It was easy to get started with when you needed 10-50 lines of
scripting in 500 lines of HTML.

- Provided library interfaces that was similar to
Unix/C-libraries (really awful, but easy to get started)

- Early adopters, there was no real competition outside perl

- It got "bundled" with web-servers one way or the other.

languages. Even if the pendulum doesn't swing all the way back
as far as we think it will for general-purpose native
languages, that's a very large niche, one with few choices- C,
C++, D, Rust, Go (the first two legacy)- and well worth
competing in.

But I think Rust and Go are focusing on specific domains. I think
people pick languages now looking for specific characteristics
that match their domain. I think the overlap between Rust and Go
is rather small.

roaring past D. If your only point is that it's done better
than it has a right to because it has a very specific strength,

I'd say that Erlang captured a market despite shortcoming because
it was the only easy-way-out. And you probably could say that
about PhP too.

Re: Where will D sit in the web service space?

2015-07-22 Thread Joakim via Digitalmars-d

On Friday, 17 July 2015 at 12:06:08 UTC, Ola Fosheim Grøstad
wrote:

On Friday, 17 July 2015 at 11:23:28 UTC, Kagamin wrote:
An attractive platform is which gets the job done, not the
best one, which doesn't actually exist (if it existed, there
wouldn't be a list of options). And it's not like D has
nothing to show, one must consider requirements for his task
to decide which tool to choose and there's no single answer
that suits everyone.

There is always a relatively small set of best solutions for a
given problem. One needs to find a rational and obvious answer
to the question:

For what domain is D the best choice?

Just a single, well argued answer that stands up to scrutiny.
Without it, few people will feel like endorsing it. (loss of
marketing effect)

The finance guys seem to be coming on board, the Dconf '15 talk
by the fund guy, Smith, probably helps. I thought this was a
nice endorsement recently, a reddit comment by a high-frequency
trader which ended with:

"[W]e've loved D so much that we're in the middle of a full
rewrite from C++11 to D. The productivity boost is absolutely
worth it."

http://www.reddit.com/r/programming/comments/3cg1r0/lessons_learned_writing_a_filesystem_in_d/csvyxn8

While you may be right from a marketing and strategy perspective
that D would be better off to focus on some carefully chosen
niche and try to excel there to begin with, D is a
general-purpose, native language developed by random volunteers
from an online community of users. Even if the community agreed
with your concept of focusing D on some domain, it's hard enough
to get most people in a _company_ to agree on what that plan
should actually be, let alone getting this free-floating
community to agree on a domain.

And as I've said before, focusing on a domain means you optimize
for it, which inevitably means you become less general. Php has
proven to be highly optimized for the web programming domain, in
that it is highly successful at being chosen for many web
projects, but almost nobody would want to use it for anything
else, for a variety of reasons, but mainly that the qualities
that make it successful on the web hurt it in other domains. So
your superior marketing/business strategy has its technical and
strategy downsides too, at least for a general-purpose language.

Now, you can argue that the market for programming languages has
become highly fragmented and that unless you are _the_ language
for statistics, R, or concurrency, erlang, you cannot get
anywhere. But some of us think general-purpose, native languages
are coming back, with mobile made up only of native/AoT-compiled
languages these days and successful web properties moving all
their high-volume backend work to such languages. Even if the
pendulum doesn't swing all the way back as far as we think it
will for general-purpose native languages, that's a very large
niche, one with few choices- C, C++, D, Rust, Go (the first two
legacy)- and well worth competing in.

Ask yourself: why did a weird language like Erlang grow?

It has certainly had a resurgence in recent years, but has it
really gone anywhere? Certain highly concurrent apps, like
Whatsapp, have made good use of it, but it's not like it's
roaring past D. If your only point is that it's done better than
it has a right to because it has a very specific strength, I'll
point out that it's also a good example of what I said above:
focusing on one area can leave you significantly weaker in many
other areas and doom you to that one niche.

Re: Where will D sit in the web service space?

2015-07-22 Thread yawniek via Digitalmars-d


i currently use vibe.d in a couple of productive apps.
i think it really shines when it comes to low latency, traffic 
heavy backend/api services.


its true that the ORM is missing and multi-thread scaling is not 
very good.
but after some tuning i am very happy with single core 
performance.


no immediate need for a full fledged web app with all the html 
stuff but
rather a blazing fast api server that provides the 
realtime/streaming (websocket/http2) interfaces so that apps that 
keep state over requests can be built.
the time of stateless webservices (REST in peace...) is coming to 
an end.
further down that line it would be pretty amazing to be able to 
compile web assembly from d and push it out from the server to 
the client. (  voltframework.com is an interesting approach in 
that direction)


once libasync compiles under ldc and hopefully enters the 
webframework benchmark it better beats the shit out of the 
competition. and if so, people who do this stuff in C/C++ now 
will start to use it.



On Saturday, 18 July 2015 at 14:07:30 UTC, Etienne Cimon wrote:
On Saturday, 18 July 2015 at 11:19:45 UTC, Ola Fosheim Grøstad 
wrote:


Nothing is as elegant and completely featured like D in the 
natively compiled world. I say natively, because that's the 
only way to resolve the "interpreter war", seeing your 
interpreter banned just like firefox did you flash.

Re: Where will D sit in the web service space?


On Saturday, 18 July 2015 at 19:23:54 UTC, Etienne wrote:
I wanted to develop the front end with dart but the final Js 
size ended up being too large and I evaluated that grunt and 
bower with webstorm are relatively more mature environments at 
the moment. I really do accept that these dev environments 
might change frequently at that level though, and I'm satisfied 
by the stability outlooks of D and underlying databases which 
make up for it.


I think WebStorm is the recommended IDE for Dart now.

Re: Where will D sit in the web service space?

2015-07-18 Thread Etienne via Digitalmars-d

On Saturday, 18 July 2015 at 18:56:52 UTC, Ola Fosheim Grøstad 
wrote:

On Saturday, 18 July 2015 at 18:51:01 UTC, rsw0x wrote:
On Saturday, 18 July 2015 at 18:49:04 UTC, Ola Fosheim Grøstad 
wrote:
On Saturday, 18 July 2015 at 16:55:23 UTC, Etienne Cimon 
wrote:

[...]



Btw, just found about this:

https://github.com/dart-lang/dev_compiler/blob/master/STRONG_MODE.md

Basically a typed subset of Dart that transpiles to clean 
Javascript (EcmaScript6). Not finished and production ready, 
but might be interesting to see if there is any help in there 
for transpiling other languages to Javascript.


I thought dart already had a dart->js compiler?


Yes, but the output is unreadable.

Currently you develop for Dart by using a special version of 
Chromium with a Dart VM. Then compile to JS for release (with 
source map support, so you can still debug to some degree).


I wanted to develop the front end with dart but the final Js size 
ended up being too large and I evaluated that grunt and bower 
with webstorm are relatively more mature environments at the 
moment. I really do accept that these dev environments might 
change frequently at that level though, and I'm satisfied by the 
stability outlooks of D and underlying databases which make up 
for it.

Re: Where will D sit in the web service space?


On Saturday, 18 July 2015 at 18:51:01 UTC, rsw0x wrote:
On Saturday, 18 July 2015 at 18:49:04 UTC, Ola Fosheim Grøstad 
wrote:

On Saturday, 18 July 2015 at 16:55:23 UTC, Etienne Cimon wrote:

[...]



Btw, just found about this:

https://github.com/dart-lang/dev_compiler/blob/master/STRONG_MODE.md

Basically a typed subset of Dart that transpiles to clean 
Javascript (EcmaScript6). Not finished and production ready, 
but might be interesting to see if there is any help in there 
for transpiling other languages to Javascript.


I thought dart already had a dart->js compiler?


Yes, but the output is unreadable.

Currently you develop for Dart by using a special version of 
Chromium with a Dart VM. Then compile to JS for release (with 
source map support, so you can still debug to some degree).

Re: Where will D sit in the web service space?

2015-07-18 Thread rsw0x via Digitalmars-d

On Saturday, 18 July 2015 at 18:49:04 UTC, Ola Fosheim Grøstad 
wrote:

On Saturday, 18 July 2015 at 16:55:23 UTC, Etienne Cimon wrote:

[...]



Btw, just found about this:

https://github.com/dart-lang/dev_compiler/blob/master/STRONG_MODE.md

Basically a typed subset of Dart that transpiles to clean 
Javascript (EcmaScript6). Not finished and production ready, 
but might be interesting to see if there is any help in there 
for transpiling other languages to Javascript.


I thought dart already had a dart->js compiler?

Re: Where will D sit in the web service space?


On Saturday, 18 July 2015 at 16:55:23 UTC, Etienne Cimon wrote:
On Saturday, 18 July 2015 at 15:11:30 UTC, Ola Fosheim Grøstad 
wrote:
However, I currently don't see much advantage in having the 
same language on client and server, so I'll probably stick to 
TypeScript/Dart, Angular2/Polymer in the near future because 
of debugging and tooling.


I think these are very good choices. I prefer to really invest 
in learning and developing on D simply because the resulting 
code is more easily redistributable, because you get more bang 
for the buck when optimizing it, because the developers are 
generally better coming from the C++ world and being hobbyists, 
etc. And also, D is more promising. A lot of things can happen 
to deprecate Dart, or TypeScript development completely. 
Nobody/nothing's ever going to deprecate D, if anything you'll 
only see the smarter devs being less afraid to pick it up and 
bring it further.



Btw, just found about this:

https://github.com/dart-lang/dev_compiler/blob/master/STRONG_MODE.md

Basically a typed subset of Dart that transpiles to clean 
Javascript (EcmaScript6). Not finished and production ready, but 
might be interesting to see if there is any help in there for 
transpiling other languages to Javascript.

Re: Where will D sit in the web service space?


On Saturday, 18 July 2015 at 16:55:23 UTC, Etienne Cimon wrote:
I was talking more about being able to operate a website or web 
application that has been censored or sabotaged. If something 
happens in the coming years to the free web as we know it, 
people will have to turn to custom computer programs and p2p to 
help open up their web services. I'm not talking about the NSA 
censoring stuff. I'm talking about companies being 
anti-competitive. This seems to be becoming more and more 
likely as they (Godaddy, Google, Mozilla, Facebook, Amazon, 
Apple, Microsoft, Oracle, ISPs etc) become greedy and start to 
play rough with each-other and newcomers, using "security" as 
an excuse. It can way too easy to flip the switch on a website 
or technology (eg the flash player incidents over the years). 
The only solution I see is to stop relying on them so much!


Interesting viewpoint.

I think most certainly that Apple will try to constrain what we 
can do. With iWatch we are no longer allowed to distribute apps 
with machine language (SIMD?), but must use LLVM IR. It is very 
likely to happen across the board. I guess only Intel has a 
different interest. I can only upload my web servers in 
uncompiled form to Google AppEngine too (but that is actually an 
advantage).


But I don't worry too much. I'm most worried about the "rent an 
application" trend. That everything becomes rented and nothing 
owned is problematic I think.

Re: Where will D sit in the web service space?

2015-07-18 Thread Etienne Cimon via Digitalmars-d

On Saturday, 18 July 2015 at 15:11:30 UTC, Ola Fosheim Grøstad 
wrote:
However, I currently don't see much advantage in having the 
same language on client and server, so I'll probably stick to 
TypeScript/Dart, Angular2/Polymer in the near future because of 
debugging and tooling.


I think these are very good choices. I prefer to really invest in 
learning and developing on D simply because the resulting code is 
more easily redistributable, because you get more bang for the 
buck when optimizing it, because the developers are generally 
better coming from the C++ world and being hobbyists, etc. And 
also, D is more promising. A lot of things can happen to 
deprecate Dart, or TypeScript development completely. 
Nobody/nothing's ever going to deprecate D, if anything you'll 
only see the smarter devs being less afraid to pick it up and 
bring it further.


over p2p. Browsers will never be appropriate because it will 
always have to slow down the applications and filter 
everything for security.


IMHO: In the long term time consuming tasks might be offloaded 
to some simplified replacement for OpenCL.


I was talking more about being able to operate a website or web 
application that has been censored or sabotaged. If something 
happens in the coming years to the free web as we know it, people 
will have to turn to custom computer programs and p2p to help 
open up their web services. I'm not talking about the NSA 
censoring stuff. I'm talking about companies being 
anti-competitive. This seems to be becoming more and more likely 
as they (Godaddy, Google, Mozilla, Facebook, Amazon, Apple, 
Microsoft, Oracle, ISPs etc) become greedy and start to play 
rough with each-other and newcomers, using "security" as an 
excuse. It can way too easy to flip the switch on a website or 
technology (eg the flash player incidents over the years). The 
only solution I see is to stop relying on them so much!

Re: Where will D sit in the web service space?

2015-07-18 Thread Paulo Pinto via Digitalmars-d


On Saturday, 18 July 2015 at 14:07:30 UTC, Etienne Cimon wrote:

[..]

We're done with desktop UI. The problem domain has shifted with 
SPA (single page applications) revolution on the web and 
angularjs.




Only for CRUD applications, anything serious is only playing 
catchup with native OS features.


Thankfully mobiles are putting the web into its place.

And yes, I do web development gigs  as well and feel the pain of 
the web in 2015 still playing catchup with desktop development 
practices of the 90's.


My last customers were all doing native desktop applications for 
data visualization.


--
Paulo

Re: Where will D sit in the web service space?

2015-07-18 Thread Paulo Pinto via Digitalmars-d

On Saturday, 18 July 2015 at 15:14:05 UTC, Ola Fosheim Grøstad 
wrote:

On Saturday, 18 July 2015 at 14:13:49 UTC, Adam D. Ruppe wrote:

On Saturday, 18 July 2015 at 14:07:30 UTC, Etienne Cimon wrote:
StackOverflow is an excellent resource, I've had trouble 
finding answers on it for D though because the D.learn forums 
contain all the Q&A. I wish we could mirror those on stack 
overflow or even channel it there instead. We're stuck in the 
90's using NNTP+forums.


We could encourage people to ask again on SO. Or we could ask 
our own things and answer it again as archive. (I sometimes 
consider doing that actually, I'm just lazy.)


What I dislike about C++ is that the answers I find on SO 
sometimes are out-of-date and applies to C++98, meaning there 
might be better solutions for C++14.


So reaching stability before focusing on SO is rather important 
IMO.


Bjarne shares your feelings, although he already came to realise 
you can only change mentalities via new generations. Hence why he 
always makes sure his students get to modern C++, before seeing C 
code compiled with a C++ compiler.


https://www.youtube.com/watch?v=2egL4y_VpYg

Re: Where will D sit in the web service space?

2015-07-18 Thread Paulo Pinto via Digitalmars-d

On Saturday, 18 July 2015 at 15:25:25 UTC, Ola Fosheim Grøstad 
wrote:

On Saturday, 18 July 2015 at 14:06:43 UTC, Kagamin wrote:

[...]


Not when you are engineering a new framework. Then you should 
look at the alternatives, perhaps build some pilots and pick 
the best platform in terms of technology and market.


Learning a new language is a relatively small cost, compared to 
the long term costs of not picking the best platform.



[...]


No. Because it provides robustness features most other 
languages don't. It was trashed and open sourced by Ericsson in 
1998.


That isn't the whole story, and having Erlang Solutions helped a 
lot.

Re: Where will D sit in the web service space?

2015-07-18 Thread Kagamin via Digitalmars-d

On Saturday, 18 July 2015 at 15:25:25 UTC, Ola Fosheim Grøstad 
wrote:
Not when you are engineering a new framework. Then you should 
look at the alternatives, perhaps build some pilots and pick 
the best platform in terms of technology and market.


Learning a new language is a relatively small cost, compared to 
the long term costs of not picking the best platform.


If you don't have experience with an unfamilar language, you pick 
wrong decisions for the framework, which results in both 
short-term and long-term costs. To design a framework, you need 
years of experience with the ecosystem.



Ask yourself: why did a weird language like Erlang grow?


Because it was a commercial project?


No. Because it provides robustness features most other 
languages don't.


Even Ada?
You mean contracts? Erlang was praised and chosen for projects 
for different reasons, though.

Re: Where will D sit in the web service space?


On Saturday, 18 July 2015 at 14:06:43 UTC, Kagamin wrote:
On Friday, 17 July 2015 at 12:06:08 UTC, Ola Fosheim Grøstad 
wrote:
There is always a relatively small set of best solutions for a 
given problem. One needs to find a rational and obvious answer 
to the question:


For what domain is D the best choice?


That's an incorrect question. The previous one was correct: 
"which platform is attractive". Sometimes the best choice is 
the platform you mastered, i.e. if you want the result quickly.


Not when you are engineering a new framework. Then you should 
look at the alternatives, perhaps build some pilots and pick the 
best platform in terms of technology and market.


Learning a new language is a relatively small cost, compared to 
the long term costs of not picking the best platform.



Ask yourself: why did a weird language like Erlang grow?


Because it was a commercial project?


No. Because it provides robustness features most other languages 
don't. It was trashed and open sourced by Ericsson in 1998.

Re: Where will D sit in the web service space?

2015-07-18 Thread Kagamin via Digitalmars-d

On Saturday, 18 July 2015 at 13:19:19 UTC, Ola Fosheim Grøstad 
wrote:
In the 1990s it could take me half an hour or more to learn 
that something was not possible or too much trouble by browsing 
manuals...  References tell you what is possible, not what 
isn't possible, hard to do, buggy, workarounds… (but that is 
often just as important)


SO as a workaround for PR censorship, lol.

Re: Where will D sit in the web service space?

2015-07-18 Thread rsw0x via Digitalmars-d

On Saturday, 18 July 2015 at 15:14:05 UTC, Ola Fosheim Grøstad 
wrote:

On Saturday, 18 July 2015 at 14:13:49 UTC, Adam D. Ruppe wrote:

On Saturday, 18 July 2015 at 14:07:30 UTC, Etienne Cimon wrote:

[...]


We could encourage people to ask again on SO. Or we could ask 
our own things and answer it again as archive. (I sometimes 
consider doing that actually, I'm just lazy.)


What I dislike about C++ is that the answers I find on SO 
sometimes are out-of-date and applies to C++98, meaning there 
might be better solutions for C++14.


So reaching stability before focusing on SO is rather important 
IMO.


This is just a problem of SO, they lock everything so a lot of 
answers are years out of date.


It's going to kill SO if they don't fix it.

Re: Where will D sit in the web service space?


On Saturday, 18 July 2015 at 14:07:30 UTC, Etienne Cimon wrote:
We're done with desktop UI. The problem domain has shifted with 
SPA (single page applications) revolution on the web and 
angularjs.


I write custom web SPAs... I agree that is the way it is going 
for regular applications than can live with the 100ms delay of a 
network connection.


But the audio-visual desktop applications I pointed to earlier, 
are difficult to do well on the web stack, and will be so for at 
least a few more years. Even simple animations are difficult to 
well on the current version of Chrome. Firefox is better. But 
these things take time to mature, because current web 
applications drive browser performance-tuning and new 
applications target the worst widespread web browser.


Fortunately IE9 and IE10 are quickly dying, and Firefox and 
Chrome tend to run on the last few versions. So modern versions 
of IE/Chrome/Firefox/Safari are realistic targets in the near 
future. And that will change the entire web eco system.


However, I currently don't see much advantage in having the same 
language on client and server, so I'll probably stick to 
TypeScript/Dart, Angular2/Polymer in the near future because of 
debugging and tooling.



Nothing is as elegant and completely featured like D in the 
natively compiled world.


I like your vision, but to get multithreading in modern browsers 
you need a different model than what D uses today.


https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers


over p2p. Browsers will never be appropriate because it will 
always have to slow down the applications and filter everything 
for security.


IMHO: In the long term time consuming tasks might be offloaded to 
some simplified replacement for OpenCL.

Re: Where will D sit in the web service space?


On Saturday, 18 July 2015 at 14:13:49 UTC, Adam D. Ruppe wrote:

On Saturday, 18 July 2015 at 14:07:30 UTC, Etienne Cimon wrote:
StackOverflow is an excellent resource, I've had trouble 
finding answers on it for D though because the D.learn forums 
contain all the Q&A. I wish we could mirror those on stack 
overflow or even channel it there instead. We're stuck in the 
90's using NNTP+forums.


We could encourage people to ask again on SO. Or we could ask 
our own things and answer it again as archive. (I sometimes 
consider doing that actually, I'm just lazy.)


What I dislike about C++ is that the answers I find on SO 
sometimes are out-of-date and applies to C++98, meaning there 
might be better solutions for C++14.


So reaching stability before focusing on SO is rather important 
IMO.

Re: Where will D sit in the web service space?


On Saturday, 18 July 2015 at 14:13:29 UTC, rsw0x wrote:

On Saturday, 18 July 2015 at 14:07:30 UTC, Etienne Cimon wrote:
We're done with desktop UI. The problem domain has shifted 
with SPA (single page applications) revolution on the web and 
angularjs.


yep, and it's the reason I can't load a 'modern' web page 
without it bringing my 16 core xeon server to a 4-5 second stop.


we've gone backwards.


That's because they are written to be single threaded and work 
with IE9. WebWorkers allow multi-threading.

Re: Where will D sit in the web service space?

2015-07-18 Thread Etienne via Digitalmars-d


On Saturday, 18 July 2015 at 14:13:29 UTC, rsw0x wrote:

On Saturday, 18 July 2015 at 14:07:30 UTC, Etienne Cimon wrote:
We're done with desktop UI. The problem domain has shifted 
with SPA (single page applications) revolution on the web and 
angularjs.


yep, and it's the reason I can't load a 'modern' web page 
without it bringing my 16 core xeon server to a 4-5 second stop.


we've gone backwards.


I've seen a linear search do that in C. I admit that most js 
coders are bad, but people still find google docs practical. 
What's your point?

Re: Where will D sit in the web service space?

2015-07-18 Thread Adam D. Ruppe via Digitalmars-d


On Saturday, 18 July 2015 at 14:07:30 UTC, Etienne Cimon wrote:
StackOverflow is an excellent resource, I've had trouble 
finding answers on it for D though because the D.learn forums 
contain all the Q&A. I wish we could mirror those on stack 
overflow or even channel it there instead. We're stuck in the 
90's using NNTP+forums.


We could encourage people to ask again on SO. Or we could ask our 
own things and answer it again as archive. (I sometimes consider 
doing that actually, I'm just lazy.)

Re: Where will D sit in the web service space?

2015-07-18 Thread rsw0x via Digitalmars-d


On Saturday, 18 July 2015 at 14:07:30 UTC, Etienne Cimon wrote:
We're done with desktop UI. The problem domain has shifted with 
SPA (single page applications) revolution on the web and 
angularjs.


yep, and it's the reason I can't load a 'modern' web page without 
it bringing my 16 core xeon server to a 4-5 second stop.


we've gone backwards.

Re: Where will D sit in the web service space?

2015-07-18 Thread Kagamin via Digitalmars-d

On Friday, 17 July 2015 at 12:06:08 UTC, Ola Fosheim Grøstad 
wrote:
There is always a relatively small set of best solutions for a 
given problem. One needs to find a rational and obvious answer 
to the question:


For what domain is D the best choice?


That's an incorrect question. The previous one was correct: 
"which platform is attractive". Sometimes the best choice is the 
platform you mastered, i.e. if you want the result quickly.


Just a single, well argued answer that stands up to scrutiny. 
Without it, few people will feel like endorsing it. (loss of 
marketing effect)


If you mean purely social issues, they are probably not very tied 
to technical aspects, it's more a question of PR.



Ask yourself: why did a weird language like Erlang grow?


Because it was a commercial project?
Wait, you mean it doesn't grow anymore?

Re: Where will D sit in the web service space?

2015-07-18 Thread Etienne Cimon via Digitalmars-d

On Saturday, 18 July 2015 at 11:19:45 UTC, Ola Fosheim Grøstad 
wrote:
StackOverflow has become the de-facto documentation resource 
for software engineers. It saves me insane amounts of time, 
many other programmers say the same thing. Google has been 
known to shut down it's own support-forums in order to get 
higher activity on StackOverflow.


StackOverflow is an excellent resource, I've had trouble finding 
answers on it for D though because the D.learn forums contain all 
the Q&A. I wish we could mirror those on stack overflow or even 
channel it there instead. We're stuck in the 90's using 
NNTP+forums.



I see basically 4 reasons to use languages like C++/D/Rust:

1. Low level hardware/OS access
2. Throughput
3. Lowered memory usage
4. Detailed control over execution patterns.


We're done with desktop UI. The problem domain has shifted with 
SPA (single page applications) revolution on the web and 
angularjs.


Nothing is as elegant and completely featured like D in the 
natively compiled world. I say natively, because that's the only 
way to resolve the "interpreter war", seeing your interpreter 
banned just like firefox did you flash.


Other languages have too much legacy to carry or have started 
with the wrong language design and will be eventually dropped 
just like lisp and perl.


WebRTC, bitcoins and torrenting have only scratched the surface 
for future web applications. I can guarantee you that there will 
be an era where desktop applications are p2p downloaded, 
installed, displayed on in a browser and all resources shared 
over p2p. Browsers will never be appropriate because it will 
always have to slow down the applications and filter everything 
for security.


With time, over the years, we will see these primitives being 
developed and the world will turn to the language that allows 
them to accomplish this, because it will be the only solution to 
web neutrality.

Re: Where will D sit in the web service space?


On Saturday, 18 July 2015 at 13:04:20 UTC, Russel Winder wrote:
Not is it possible to ignore the insanely appalling editorial 
behaiour on StackOverflow that almost, but not quite, 
completely undermines its entire usefulness.


Like Wikipedia, it is not perfect and it is biased, but it is 
usually a good starting point for C++, iOS, Python, Javascript, 
Go etc. And you get valuable information about workarounds.


In the 1990s it could take me half an hour or more to learn that 
something was not possible or too much trouble by browsing 
manuals...  References tell you what is possible, not what isn't 
possible, hard to do, buggy, workarounds… (but that is often just 
as important)

Re: Where will D sit in the web service space?

2015-07-18 Thread Russel Winder via Digitalmars-d

On Sat, 2015-07-18 at 11:19 +, via Digitalmars-d wrote:
> […]
> 
> StackOverflow has become the de-facto documentation resource for 
> software engineers. It saves me insane amounts of time, many 
> other programmers say the same thing. Google has been known to 
> shut down it's own support-forums in order to get higher activity 
> on StackOverflow.
> 
> You cannot gloss over the importance of this.

Not is it possible to ignore the insanely appalling editorial behaiour on
StackOverflow that almost, but not quite, completely undermines its entire
usefulness.

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


signature.asc
Description: This is a digitally signed message part

Re: Where will D sit in the web service space?


On Saturday, 18 July 2015 at 10:29:20 UTC, Laeeth Isharc wrote:
accurate understanding of reality to do so.  The propensity to 
put things on github and for people to ask questions on 
stackoverflow varies according to the problem domain.


StackOverflow has become the de-facto documentation resource for 
software engineers. It saves me insane amounts of time, many 
other programmers say the same thing. Google has been known to 
shut down it's own support-forums in order to get higher activity 
on StackOverflow.


You cannot gloss over the importance of this.

Large scale batch-processing cannot drive adoption. 
Specialized solutions like Chapel and C++/extensions will take 
the batch-throughput market.


I didn't say anything about batch processing.  It's also very 
intriguing to see you believe you know my problem domain better 
than me.


I have no interest in your problem domain, but you say that 
throughput is important for you.


I see basically 4 reasons to use languages like C++/D/Rust:

1. Low level hardware/OS access
2. Throughput
3. Lowered memory usage
4. Detailed control over execution patterns.

In the 80s lots of software was close to theoretical 
throughput. Today, almost no software is anywhere close, 
because it is wy too expensive in terms of developer time 
as code base sizes increase.


We are speaking of shifts at the margin from where we start 
today, and about the future, not historical trends over the 
past decade or two.


The trend in consumer hardware is that GPUs share memory with the 
CPU or have fast paths. So efficiency means GPGPU programming, 
Metal, Vulkan..


The trend is that those few that can pay for throughput moves 
towards FPGA and other specialized solutions where it matters.


The trend in performant server-hardware is that CPUs have local 
memory.


The historical trend is that those expensive solutions become 
commoditized in one way or another over time. Meaning, consumer 
hardware adopt some features from high-end specialized hardware 
over time.

Re: Where will D sit in the web service space?

2015-07-18 Thread Laeeth Isharc via Digitalmars-d

On Saturday, 18 July 2015 at 08:17:50 UTC, Ola Fosheim Grøstad 
wrote:

On Saturday, 18 July 2015 at 02:45:54 UTC, Laeeth Isharc wrote:
On Friday, 17 July 2015 at 12:06:08 UTC, Ola Fosheim Grøstad 
wrote:

For what domain is D the best choice?


You are switching the question without recognizing this - some 
kind of fallacy of composition.


There is no fallacy here.


We are each entitled to our judgement about whether D being in 
some Platonic sense the best single option for an entire domain 
has much to do with whether it is practicably speaking a sensible 
choice made by commercially pragmatic people operating within a 
certain set of uses.  We are entitled to our views about the 
usefulness of thinking in terms of global optimality amidst 
uncertainty and local constraints.  I shall not say more as there 
are diminishing returns to what is generative.


You cannot compete until you have something that is the best 
possible starting point for a range of commercially- or 
community-backed frameworks.


You don't have growth until you have clearly increasing 
presence on Github and StackOverflow.


We are each of us entitled to our judgement about whether it's 
healthy to think in that way, and whether it leads to an accurate 
understanding of reality to do so.  The propensity to put things 
on github and for people to ask questions on stackoverflow varies 
according to the problem domain.  In web development, it's common 
to open-source things and to ask questions on stackoverflow.  In 
some other sectors I am familiar with that have a decent share of 
technology spending overall it's rather less common, and this is 
not a capricious cultural trait but is the result of the 
application of common sense by commercial people.  Liquidity 
tends to concentrate in certain places - for D, I wouldn't 
suggest anyone goes to stackoverflow if they want a good and 
quick answer to their question.  It's healthy that liquidity is 
concentrated.


Large scale batch-processing cannot drive adoption. Specialized 
solutions like Chapel and C++/extensions will take the 
batch-throughput market.


I didn't say anything about batch processing.  It's also very 
intriguing to see you believe you know my problem domain better 
than me.



The work of Austrian economists on entrepreneurship 
demonstrate that it simply is not possible to know which 
people will use a product and how.  The future is unknown, if 
not unimaginable.


It isn't. The historical success-stories within the domain of 
programming languages are pretty clear.


And there has been no change to the terrain, and so the lessons 
of the past can be applied without careful thought to present 
conditions that are different?  I certainly won't dream of 
arguing further with you.



If you presume programmer productivity is the only thing that 
matters and treat efficiency like a free resource, it's a dead 
cert that at some point efficiency will no longer be free.


More and more problems are solved by less and less efficiency. 
Development time, reliability, maintainability, evolution and 
perceived responsiveness are the most important factors.


mmm.

In the 80s lots of software was close to theoretical 
throughput. Today, almost no software is anywhere close, 
because it is wy too expensive in terms of developer time 
as code base sizes increase.


We are speaking of shifts at the margin from where we start 
today, and about the future, not historical trends over the past 
decade or two.



D has a chance to gain adoption by picking a direction

so you tend to assert.

focusing on improving the process. But it is a long road, that 
also requires some cleanup of language.

sure.  hard to find anyone that wouldn't agree with the above.

Re: Where will D sit in the web service space?


On Saturday, 18 July 2015 at 02:45:54 UTC, Laeeth Isharc wrote:
On Friday, 17 July 2015 at 12:06:08 UTC, Ola Fosheim Grøstad 
wrote:

For what domain is D the best choice?


You are switching the question without recognizing this - some 
kind of fallacy of composition.


There is no fallacy here.

You cannot compete until you have something that is the best 
possible starting point for a range of commercially- or 
community-backed frameworks.


You don't have growth until you have clearly increasing presence 
on Github and StackOverflow.



time and location.  There aren't only a few sensible choices 
for hedge fund data processing generally.  It's a big world, 
and there are many more variations between the needs of 
different teams than it is possible to imagine.


Large scale batch-processing cannot drive adoption. Specialized 
solutions like Chapel and C++/extensions will take the 
batch-throughput market.



The work of Austrian economists on entrepreneurship demonstrate 
that it simply is not possible to know which people will use a 
product and how.  The future is unknown, if not unimaginable.


It isn't. The historical success-stories within the domain of 
programming languages are pretty clear.



The bigger picture is not D in a death match with any 
identifiable languages.


All languages are on a long-tail death match against all the 
other languages. History is pretty clear on that too.


It is long-tail because legacy source code bases will keep the 
languages alive until the product is replaced.



If you presume programmer productivity is the only thing that 
matters and treat efficiency like a free resource, it's a dead 
cert that at some point efficiency will no longer be free.


More and more problems are solved by less and less efficiency. 
Development time, reliability, maintainability, evolution and 
perceived responsiveness are the most important factors.


In the 80s lots of software was close to theoretical throughput. 
Today, almost no software is anywhere close, because it is wy 
too expensive in terms of developer time as code base sizes 
increase.


D's primary selling point is that it is more familiar to C++ 
programmers than Rust. But there are other C++-like languages 
that are getting to the same technical quality (thanks to LLVM).



probably at that point, and that Facebook's experience with 
tradeoffs is not an edge case, but a leading edge for what more 
people will experience in future.


No, in the future the processor will be integrated with RAM. 
You'll have lots and lots and lots of local processing power. The 
bottleneck will be communication between compute-nodes. (It 
already is, in many settings.)



Furthermore, just rhetorically, gentle and constructive 
suggestions for improvement that come from within are likely to


D has a chance to gain adoption by picking a direction and 
focusing on improving the process. But it is a long road, that 
also requires some cleanup of language.

Re: Where will D sit in the web service space?

2015-07-17 Thread Laeeth Isharc via Digitalmars-d

On Friday, 17 July 2015 at 12:06:08 UTC, Ola Fosheim Grøstad 
wrote:

On Friday, 17 July 2015 at 11:23:28 UTC, Kagamin wrote:
An attractive platform is which gets the job done, not the 
best one, which doesn't actually exist (if it existed, there 
wouldn't be a list of options). And it's not like D has 
nothing to show, one must consider requirements for his task 
to decide which tool to choose and there's no single answer 
that suits everyone.


There is always a relatively small set of best solutions for a 
given problem. One needs to find a rational and obvious answer 
to the question:


For what domain is D the best choice?


You are switching the question without recognizing this - some 
kind of fallacy of composition.  There may be only a few sensible 
choices in a given hedge fund team at a particular time and 
location.  There aren't only a few sensible choices for hedge 
fund data processing generally.  It's a big world, and there are 
many more variations between the needs of different teams than it 
is possible to imagine.


The work of Austrian economists on entrepreneurship demonstrate 
that it simply is not possible to know which people will use a 
product and how.  The future is unknown, if not unimaginable.  
Who would have imagined a couple of East German PhDs would have 
had such success building a company based on D in a domain that 
didn't quite exist in that form at the time they began, 
particularly given all the complaints about the garbage 
collector.  (The fact that they built their own has no bearing on 
my point).


So it's a spurious question, and would be spurious even if D were 
a product that were sold by a corporation like a manufactured 
product, rather than what it is, which is an organically 
developing language and ecosystem that is heavily influenced by 
its originators yet not controlled by them.


The bigger picture is not D in a death match with any 
identifiable languages.  As Peter Thiel says, thinking of 
yourself as competing is an extremely destructive mindset for 
operating in business.  One wants to carve out a monopoly that is 
earned by doing some set of things uniquely reasonably well.  
Aesthetics matter for programming languages, since programming is 
for the time being a human activity, and so there doesn't even 
need to be a technical superiority (although I think there is).  
The context for all of this is the economics shifting in the 
longer-term towards native code.  If you presume programmer 
productivity is the only thing that matters and treat efficiency 
like a free resource, it's a dead cert that at some point 
efficiency will no longer be free.  I think we are probably at 
that point, and that Facebook's experience with tradeoffs is not 
an edge case, but a leading edge for what more people will 
experience in future.


Furthermore, just rhetorically, gentle and constructive 
suggestions for improvement that come from within are likely to 
be more effective than those that seem to some not to grant D its 
due even when it's difficult to argue from any perspective that 
there's an area it has gotten right.  I do not think I am the 
only one with this sense.


Just a single, well argued answer that stands up to scrutiny. 
Without it, few people will feel like endorsing it. (loss of 
marketing effect)


Opinions are like noses.  Everyone has one.  Not everyone has 
earned the right to speak with authority on every topic.  You 
make an empirical statement about what will happen if things are 
not done your way.  I personally doubt your empirical statement 
because it doesn't align with how things are done in my small 
(and in aggregate not so small) patch of the world, and these 
things must compose for what you say to be true.  Nobody cares 
about whether in theory D is good for an industry; they care 
about whether it solves the particular problems at hand (human, 
cultural, and tacit knowledge questions being an unavoidable 
component of what defines the problem set).  I am not the only 
one in my sector to think that it does, so if I cared about 
social proof - which I do not - I'd feel comfortable enough with 
the decision.

Re: Where will D sit in the web service space?

2015-07-17 Thread via Digitalmars-d


On Friday, 17 July 2015 at 11:23:28 UTC, Kagamin wrote:
An attractive platform is which gets the job done, not the best 
one, which doesn't actually exist (if it existed, there 
wouldn't be a list of options). And it's not like D has nothing 
to show, one must consider requirements for his task to decide 
which tool to choose and there's no single answer that suits 
everyone.


There is always a relatively small set of best solutions for a 
given problem. One needs to find a rational and obvious answer to 
the question:


For what domain is D the best choice?

Just a single, well argued answer that stands up to scrutiny. 
Without it, few people will feel like endorsing it. (loss of 
marketing effect)


Ask yourself: why did a weird language like Erlang grow?

Re: Where will D sit in the web service space?

2015-07-17 Thread Kagamin via Digitalmars-d

On Thursday, 16 July 2015 at 11:25:11 UTC, Ola Fosheim Grøstad 
wrote:

On Thursday, 16 July 2015 at 11:00:19 UTC, Paulo  Pinto wrote:

Well, there are lots of Geometry Wars clones in XNA and LibGDX.


The point is more this: the majority of interactive 
applications you can do easily in Java/C#/Swift/Javascript are 
going to be written in those languages for _very_ good reasons. 
I would too.


If desktop applications are a target then you need a feature 
set that makes it easier to write those applications that are 
difficult to do well in Java/C#/Swift/Javascript.


That makes you an attractive platform for new application 
frameworks.


An attractive platform is which gets the job done, not the best 
one, which doesn't actually exist (if it existed, there wouldn't 
be a list of options). And it's not like D has nothing to show, 
one must consider requirements for his task to decide which tool 
to choose and there's no single answer that suits everyone.

Re: Where will D sit in the web service space?


On Thursday, 16 July 2015 at 20:20:54 UTC, Tofu Ninja wrote:

On Thursday, 16 July 2015 at 11:00:19 UTC, Paulo  Pinto wrote:

Well, there are lots of Geometry Wars clones in XNA and LibGDX.

As for Vulkan, I have the strong feeling it is DOA, with 
Apple, Sony, Nintendo, Microsoft favoring they own APIs.


Its even worse because its not obvious if apple will even 
support vulkan...


Yes, there is always the mention of them being in the planning 
board, but that doesn't mean anything.


They invented OpenCL, yet as I can understand from forum 
discussions their implementation is not that good nor up to the 
latest versions.

Re: Where will D sit in the web service space?


On Thursday, 16 July 2015 at 19:01:10 UTC, Paulo Pinto wrote:
[...]
Starting at 00:06:40, game engines support and OpenGL 
replacement on the graphics stack (00:07:20).


Thanks for pointing to the time segments! Looks like they have 
put some effort into transitioning shaders from GLSL to Metal. I 
agree they sell it as a "this is it" solution by how they talk 
about it. Can't tell what is spin, and what is the future... It 
would be silly for Apple to make it hard to port CAD applications 
etc to OSX... Then again, they no longer have Steve Jobs... :-/

Re: Where will D sit in the web service space?

2015-07-16 Thread Tofu Ninja via Digitalmars-d


On Thursday, 16 July 2015 at 11:00:19 UTC, Paulo  Pinto wrote:

Well, there are lots of Geometry Wars clones in XNA and LibGDX.

As for Vulkan, I have the strong feeling it is DOA, with Apple, 
Sony, Nintendo, Microsoft favoring they own APIs.


Its even worse because its not obvious if apple will even support 
vulkan...

Re: Where will D sit in the web service space?

On Thursday, 16 July 2015 at 16:58:45 UTC, Ola Fosheim Grøstad 
wrote:

On Thursday, 16 July 2015 at 16:37:44 UTC, Paulo Pinto wrote:

However if you watch "Graphics and Games" talks

https://developer.apple.com/videos/wwdc/2015/

It is all about Metal support, OpenGL being replaced by Metal 
and OpenGL being available for the iDevices that aren't Metal 
capable, as well as, backwards compatibility.


Thanks, I am interested in this. Do you remember which one of 
the nine videos?




SceneKit transition to Metal, comparing it with OpenGL ES, 
starting on 00:22:30.


https://developer.apple.com/videos/wwdc/2015/?id=606

Metal is now the default renderer for SceneKit, OpenGL needs to 
be opted-in.


Starting at 00:06:40, game engines support and OpenGL replacement 
on the graphics stack (00:07:20).


https://developer.apple.com/videos/wwdc/2015/?id=603

Then you can watch how a few known companies in the industry 
praise Apple for Metal and how they replaced their OpenGL stack 
with Metal.


--
Paulo

Re: Where will D sit in the web service space?


On Thursday, 16 July 2015 at 16:37:44 UTC, Paulo Pinto wrote:

However if you watch "Graphics and Games" talks

https://developer.apple.com/videos/wwdc/2015/

It is all about Metal support, OpenGL being replaced by Metal 
and OpenGL being available for the iDevices that aren't Metal 
capable, as well as, backwards compatibility.


Thanks, I am interested in this. Do you remember which one of the 
nine videos?


From money point of view, I don't think it makes sense to spend 
one year paying developers to port Metal to OSX, replace OpenGL 
in OS X/iOS frameworks and developer tools, for doing the same 
again when Vulkan comes out.


But they don't pay as much for the Vulkan drivers... GPU vendors 
write them anyway.


I think I found out why Metal is coming for OSX now and not 
earlier. Apparently the programming model used in Metal is 
targeting hardware from 2012 or newer.

Re: Where will D sit in the web service space?

On Thursday, 16 July 2015 at 13:56:14 UTC, Ola Fosheim Grøstad 
wrote:

On Thursday, 16 July 2015 at 13:17:43 UTC, Paulo  Pinto wrote:
Apple has officially dropped OpenGL support at WWDC, if you 
care to watch the presentations and early release 
documentation.


Are you sure they have _dropped_ OpenGL and not just got 
switched away from using OpenGL as their low level layer for 
Cocoa?


https://developer.apple.com/opengl/
https://developer.apple.com/opencl/


Those are the current information.

However if you watch "Graphics and Games" talks

https://developer.apple.com/videos/wwdc/2015/


It is all about Metal support, OpenGL being replaced by Metal and 
OpenGL being available for the iDevices that aren't Metal 
capable, as well as, backwards compatibility.



Then if you have a Mac developer account, you can check the "OS X 
El Capitan v10.11" document with zero references to OpenGL, other 
than Metal being the default render.


The OpenGL version support is still based on 4.1.


https://developer.apple.com/metal/

They might change their mind and surprise the world, but that 
is how things stand.


AFAIK they are on the Vulkan working group, but probably don't 
view Vulkan as ready for consumption. They needed Metal on iOS 
because GPUs on iPads/iPhones are weak. That happend before 
Vulkan came along.


Sony is also and they don't use OpenGL, except for Android and 
WebGL on the PS4 dashboard.




So it makes sense to move Metal to OS-X while waiting for 
Vulkan to mature on their hardware (or rather waiting for older 
GPUs to be irrelevant). They have a compatibility interest in 
keeping developers on Metal until iPhones/iPads are ready for 
Vulkan.



From money point of view, I don't think it makes sense to spend 
one year paying developers to port Metal to OSX, replace OpenGL 
in OS X/iOS frameworks and developer tools, for doing the same 
again when Vulkan comes out.




So who cares if Intel, AMD, and Valve are heavily invested in 
Vulkan?


Intel, AMD, NVIDIA and Imagination are all in on Vulkan, aren't 
they?


Everybody cares about what they do because they write the 
drivers for next gen GPUs. It makes sense to focus 
Vulkan-effort on next generation of hardware for vendors 
(profit motive).


They also write drivers for DirectX and Metal.



It is not at all obvious that Apple will want to keep writing 
and maintaining their own low level drivers once GPU vendors 
ship solid Vulkan implementations.


Of course, Apple cannot tell the public that Metal will become 
irrelevant in a few years... They have a story to sell.


According to the WWDC talks Apple also did engage with GPU 
vendors on Metal

for their systems, they aren't doing it alone.

Apple might prove me wrong, lets see.

--
Paulo

Re: Where will D sit in the web service space?


On Thursday, 16 July 2015 at 14:07:29 UTC, rsw0x wrote:
for Microsoft - never.) 6-7 android phones are selling per iOS 
phone, and this is projected to keep going up thanks to 
developing countries entering the market and Apple's popularity 
falling amongst western demographics.


No, Vulkan will _not_ be DOA.


Exactly. Apple usually avoid making announcements until they are 
certain that products will be ready for consumption. So being 
silent about Vulkan is business as usual. Apple don't do public 
roadmaps like Intel/AMD...


Having Metal on OSX is just another step in harmonizing iOS and 
OSX apis. Probably happens now due the desktop GPU situation. We 
need to keep in mind that iOS units have different GPUs.

Re: Where will D sit in the web service space?


On Thursday, 16 July 2015 at 14:07:29 UTC, rsw0x wrote:

On Thursday, 16 July 2015 at 13:17:43 UTC, Paulo  Pinto wrote:

[...]


PC game revenue outpaced console game revenue in 2012 or 
2013("...PC gaming segment is already twice the size of the 
console gaming market – and growing. ",) Sony and Microsoft 
haven't seen profits from their consoles in over a decade(and 
for Microsoft - never.) 6-7 android phones are selling per iOS 
phone, and this is projected to keep going up thanks to 
developing countries entering the market and Apple's popularity 
falling amongst western demographics.


[...]


Sure, but in what concerns PC games, DirectX rules.

Also Google hasn't shown any interest into adding Vulkan support 
to Android.


They don't even support OpenCL, pushing instead for Renderscript.

Re: Where will D sit in the web service space?

2015-07-16 Thread rsw0x via Digitalmars-d

On Thursday, 16 July 2015 at 13:17:43 UTC, Paulo Pinto wrote:

On Thursday, 16 July 2015 at 11:08:52 UTC, rsw0x wrote:

On Thursday, 16 July 2015 at 11:00:19 UTC, Paulo Pinto wrote:

[...]

Sure, if they can convince the major graphics vendors to care
about their proprietary vendor lock-in crap. The only one of
those that will exist in 5 years is probably DirectX.

Intel, AMD, and Valve are heavily invested in Vulkan. It will
definitely not be DOA.

Apple has officially dropped OpenGL support at WWDC, if you
care to watch the presentations and early release documentation.

On those presentations OpenGL has referred as backward
compatibility only.

All the Mac OS X and iOS frameworks that used OpenGL, now have
a Metal layer.

They might change their mind and surprise the world, but that
is how things stand.

In the console market, no one cares about OpenGL. Sony [0],
Nintendo, Microsoft and even Sega, never cared for it.

So who cares if Intel, AMD, and Valve are heavily invested in
Vulkan?

The platform vendors that matter to games developers are not.

[0] OpenGL ES 1.0 on the PS 3 wasn't really that usable,
everyone went native PS3 instead.

PC game revenue outpaced console game revenue in 2012 or
2013("...PC gaming segment is already twice the size of the
console gaming market – and growing. ",) Sony and Microsoft
haven't seen profits from their consoles in over a decade(and for
Microsoft - never.) 6-7 android phones are selling per iOS phone,
and this is projected to keep going up thanks to developing
countries entering the market and Apple's popularity falling
amongst western demographics.

No, Vulkan will _not_ be DOA.

http://www.forbes.com/sites/chuckjones/2015/04/06/apples-worldwide-iphone-market-share-declining-except-in-china/
http://www.forbes.com/sites/jasonevangelho/2014/04/28/as-global-pc-game-revenue-surpasses-consoles-how-long-should-console-makers-keep-fighting/
http://www.forbes.com/sites/marcochiappetta/2014/07/14/the-console-war-is-over-the-pc-already-won/

Re: Where will D sit in the web service space?


On Thursday, 16 July 2015 at 13:17:43 UTC, Paulo  Pinto wrote:
Apple has officially dropped OpenGL support at WWDC, if you 
care to watch the presentations and early release documentation.


Are you sure they have _dropped_ OpenGL and not just got switched 
away from using OpenGL as their low level layer for Cocoa?


https://developer.apple.com/opengl/
https://developer.apple.com/opencl/
https://developer.apple.com/metal/

They might change their mind and surprise the world, but that 
is how things stand.


AFAIK they are on the Vulkan working group, but probably don't 
view Vulkan as ready for consumption. They needed Metal on iOS 
because GPUs on iPads/iPhones are weak. That happend before 
Vulkan came along.


So it makes sense to move Metal to OS-X while waiting for Vulkan 
to mature on their hardware (or rather waiting for older GPUs to 
be irrelevant). They have a compatibility interest in keeping 
developers on Metal until iPhones/iPads are ready for Vulkan.


So who cares if Intel, AMD, and Valve are heavily invested in 
Vulkan?


Intel, AMD, NVIDIA and Imagination are all in on Vulkan, aren't 
they?


Everybody cares about what they do because they write the drivers 
for next gen GPUs. It makes sense to focus Vulkan-effort on next 
generation of hardware for vendors (profit motive).


It is not at all obvious that Apple will want to keep writing and 
maintaining their own low level drivers once GPU vendors ship 
solid Vulkan implementations.


Of course, Apple cannot tell the public that Metal will become 
irrelevant in a few years... They have a story to sell.

Re: Where will D sit in the web service space?


On Thursday, 16 July 2015 at 12:44:22 UTC, Wyatt wrote:
Personally, I've dealt with perl, ruby, python, java, and php 
in the web space and as far as I'm concerned they're all 
unmaintainable trash.  (perl, ironically, gave me the best 
experience of the five!)


What advantage can perl possibly have over Python? I ditched perl 
over 10 years ago and never looked back.


If I ever decide I'm masochistic enough to attempt something in 
that vein again, D is at least as strong a contender for me 
because it offers fast iteration, solid performance, and a type 
system that doesn't make me want to punch small animals.


Well, the development-server-framework I use reload automatically 
whenever I save a file, so I am for now happy with iteration 
speed as I don't perceive any delays worth thinking about.


With PyCharm I also get debugger/web server integration and the 
PyCharm background-sanitizer gets pretty close to having static 
typing actually. Impressive for a dynamic language! Wish I had 
picked it up earlier!


If you go node.js, you get static typing with typescript if you 
want + same language on the browser, debuggable.


If you go Dart you get static typing if you want  + same language 
the browser, debuggable.


But in terms of programmer-productivity I think Python is hard to 
match in the webspace (for a wide range of reasons).


So I think you need to look at what exists _TODAY_ in the 
webspace, not what you used >3 years ago. That's history.


Go and Rust, for all their "theoretical superiority" in one 
place or another, _don't feel good_.  Go is to C what Plan 9 is 
to Unix, which is to say it's a thoroughly unimaginitive, 
ideologically hampered, overly-conservative iteration from Rob 
Pike.  Rust might be intriguing if it ever catches up to D in 
being pleasant to use.


I haven't used Go or Rust fulltime for the amount of time needed 
to get fully familiar with them (I guess that would take me 1-2 
months fulltime or so).


So I can't really say whether what I feel as "oddities" now will 
persist. I felt that Cs syntax was odd too, when I came to it 
from Pascal/asm.


So I am more concerned about the feature set, my brain can 
usually get around "unusual" choices if there is syntactical and 
semantic consistency.

Re: Where will D sit in the web service space?


On Thursday, 16 July 2015 at 11:08:52 UTC, rsw0x wrote:

On Thursday, 16 July 2015 at 11:00:19 UTC, Paulo  Pinto wrote:

Well, there are lots of Geometry Wars clones in XNA and LibGDX.

As for Vulkan, I have the strong feeling it is DOA, with 
Apple, Sony, Nintendo, Microsoft favoring they own APIs.


Sure, if they can convince the major graphics vendors to care 
about their proprietary vendor lock-in crap. The only one of 
those that will exist in 5 years is probably DirectX.


Intel, AMD, and Valve are heavily invested in Vulkan. It will 
definitely not be DOA.


Apple has officially dropped OpenGL support at WWDC, if you care 
to watch the presentations and early release documentation.


On those presentations OpenGL has referred as backward 
compatibility only.


All the Mac OS X and iOS frameworks that used OpenGL, now have a 
Metal layer.


They might change their mind and surprise the world, but that is 
how things stand.


In the console market, no one cares about OpenGL. Sony [0], 
Nintendo, Microsoft and even Sega, never cared for it.


So who cares if Intel, AMD, and Valve are heavily invested in 
Vulkan?


The platform vendors that matter to games developers are not.


[0] OpenGL ES 1.0 on the PS 3 wasn't really that usable, everyone 
went native PS3 instead.

Re: Where will D sit in the web service space?

2015-07-16 Thread Wyatt via Digitalmars-d

On Sunday, 12 July 2015 at 17:54:02 UTC, Ola Fosheim Grøstad 
wrote:

On Sunday, 12 July 2015 at 12:32:32 UTC, Peter Alexander wrote:

Web servers: Why not?


Mostly because there is no real visible direction towards 
making D a competitor that directly addresses specific needs of 
web programming.



So what?

Personally, I've dealt with perl, ruby, python, java, and php in 
the web space and as far as I'm concerned they're all 
unmaintainable trash.  (perl, ironically, gave me the best 
experience of the five!)


If I ever decide I'm masochistic enough to attempt something in 
that vein again, D is at least as strong a contender for me 
because it offers fast iteration, solid performance, and a type 
system that doesn't make me want to punch small animals.


Go and Rust, for all their "theoretical superiority" in one place 
or another, _don't feel good_.  Go is to C what Plan 9 is to 
Unix, which is to say it's a thoroughly unimaginitive, 
ideologically hampered, overly-conservative iteration from Rob 
Pike.  Rust might be intriguing if it ever catches up to D in 
being pleasant to use.


-Wyatt

Re: Where will D sit in the web service space?

2015-07-16 Thread Wyatt via Digitalmars-d


On Thursday, 16 July 2015 at 11:48:59 UTC, ponce wrote:

Notch goes pretty fast with Eclipse.


Nitpicking, but notch hasn't been involved with Minecraft in 
years. *g*


-Wyatt

Re: Where will D sit in the web service space?

2015-07-16 Thread ponce via Digitalmars-d


On Thursday, 16 July 2015 at 10:58:08 UTC, rsw0x wrote:

On Thursday, 16 July 2015 at 10:29:54 UTC, Kagamin wrote:

Like minecraft?


Minecraft runs absolutely horrible, the earlier versions of 
minecraft used to allocate 2-300mb of data per second that was 
near instantly marked garbage.


OTOH, Minecraft Desktop benefits from a single build that work in 
Linux/Mac/Windows, has a web start page, and Notch goes pretty 
fast with Eclipse.

Re: Where will D sit in the web service space?


On Thursday, 16 July 2015 at 11:08:52 UTC, rsw0x wrote:
Intel, AMD, and Valve are heavily invested in Vulkan. It will 
definitely not be DOA.


Paulo probably referred to Apple announcing Metal for Os-X. So 
you might need to support both as Metal might be better optimized 
for by Apple even if Apple announce Vulkan support. All 
speculations...

Re: Where will D sit in the web service space?