www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Where will D sit in the web service space?

reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
I've been thinking a bit about where languages fit in the web 
service space. Both mobile app and web services are likely 
candidates for typed and efficient languages. I'm not at all 
happy with the "prolific" choices that are available. Yet, D is 
currently not in a strong position for mobile apps or web 
servers. So what does the competition look like?


JAVA is big and a strong player, but also heavy and resource 
demanding. I don't consider it for my use due to the resource 
requirements. I want something more nimble.

- Java is for those who already have invested in the language or 
need a framework written in it.



"Microsoft" taint (for good and bad).


products.


GO is nimble, but the language is a bit annoying. On the good 
side it has a low latency GC, but with a performance penalty. 
Google are now also fully supporting Go on Google App Engine 
(together with Java and Python)
https://sourcegraph.com/blog/live/gophercon2015/123574706480
https://groups.google.com/forum/#!topic/google-appengine-go/as9wUqT77YU

- Go is an alternative for those who want to write a light server 
from scratch and/or integrate with Google Cloud. It has a very 
quickly gained a lot of web related frameworks and 3rd party APIs.


RUST was never meant for the web servers, but people seem to have 
taken to writing frameworks for it lately. Rust is like Go a bit 
annoying, but with some strong non-GC semantics.

- Rust is difficult to place, but seems like an emerging TCP/HTTP 
alternative where better-speed-than-GC is a requirement. Might 
become an alternative to C++/Java for game-servers?


C++ offers everything needed, but unfortunately writing safe code 
in C++ is tedious and difficult.

- I'm not really sure why anyone would want to write a server in 
C++. Seems like a "last resort" language for this purpose. What 
you fall back on when the alternatives don't cut it, or don't 
integrate with required libraries, at the cost of development 
time.

HASKELL is used to some extent. In theory a functional language 
should be a perfect match for a web service, but is it? Not sure, 
but I am not likely to use it for web programming for the same 
reason I would not choose C++. I am afraid it will become tedious.

PONY is an upcoming actor based, non-GC language that might be 
worth watching. Not production ready, a fringe language, but the 
actor based programming model might be suitable.

Maybe you know some other statically typed languages worth 
mentioning?

To me it seems like C++ and Rust are the most likely targets for 
D to compete with. Yet, to me those languages are on the fringe 
of web-service programming. More suitable for specialised 
services like image rescaling or game servers.


advantages that makes them difficult targets. They all have 
integration advantages not provided by other languages.

What do you think about the future for D in the web service space?
Jul 12 2015
next sibling parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Sunday, 12 July 2015 at 12:14:31 UTC, Ola Fosheim Grøstad 
wrote:

 Yet, D is currently not in a strong position for mobile apps or 
 web servers.


Mobile apps: I agree.

Web servers: Why not?



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


It seems like a space where D has a lot of potential to succeed. 
Compared to mobile and desktop, server-side integration should be 
easy for D since (at least for Linux servers) most the important 
integration points are through C APIs, which D supports well. 
Server side is generally more forgiving to new technology since 
it is generally all open source, and there aren't really any 
hoops to jump through.
Jul 12 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Sunday, 12 July 2015 at 12:32:32 UTC, Peter Alexander wrote:

 On Sunday, 12 July 2015 at 12:14:31 UTC, Ola Fosheim Grøstad 
 wrote:

 Yet, D is currently not in a strong position for mobile apps 
 or web servers.


 Mobile apps: I agree.

 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.

For Go it is all about frameworks, low latency GC, integration 
with Cloud and fast edit/compile/run cycle. Take a look at the 
curated awesome list for Go and you get the idea how the eco 
system is expanding:

https://github.com/avelino/awesome-go

Rust as a web-service language it is incidental, but IMO strongly 
related to linear typing/the memory model which allows you to 
avoid memory leaks on long running processes. The profile of the 
Rust eco system is a little different:

https://github.com/kud1ing/awesome-rust

I think there might be very little overlap between projects 
choosing between Go and Rust for web services. Want fast and low 
memory usage, use Rust. Want nippy,  easy memory management and a 
webish eco system, use Go.

With D, we are somewhere in the middle. A GC that hogs all 
processes are not ok, and without it you don't get Go's 
convenience, but also not Rusts linear typing guarantees.

I think it is about time D makes a commitment towards at least 
one application domain. It is important that  D can be really 
good a solving problems within at least one sizeable domain in 
order to be a "noticeable language".


 succeed. Compared to mobile and desktop, server-side 
 integration should be easy for D since (at least for Linux 
 servers) most the important integration points are through C 
 APIs, which D supports well. Server side is generally more 
 forgiving to new technology since it is generally all open 
 source, and there aren't really any hoops to jump through.


Yes, I agree that Linux servers might be a good target.
Jul 12 2015
next sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
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?
Jul 12 2015
next sibling parent reply "Brad Anderson" <eco gnuk.net> writes:
On Sunday, 12 July 2015 at 18:53:35 UTC, weaselcat wrote:

 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?


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.
Jul 12 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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).
Jul 13 2015
next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
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).



The reason I am become silent is that I came to realize my posts 
between compilations and commuting, just had noise with no value. 
As none of our
customers would use D over their current languages. Don't want to 
discuss
why, this is not a flame war post.

And for dabbling/private gigs outside work, my focus has switched 
to ML like languages, given that they are finally starting to be 
used in the industry.

Regarding D, there needs to be a story to be sold (e.g Docker, 
Rails, next Firefox,iOS, Android, WP...) why the language matters.

On my little world, customers choose programming languages 
because they want to
use tool X, framework Y or target operating system Z.

So which tool will make them choose D?

Check the languages Microsoft considered important to offer 
support out of the box,

https://code.visualstudio.com/Docs/languages

Sorry for the noise,
Paulo
Jul 13 2015
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 13 July 2015 at 07:32:57 UTC, Paulo  Pinto wrote:

 On my little world, customers choose programming languages 
 because they want to
 use tool X, framework Y or target operating system Z.


I currently get to pick my own languages, but ready-to-use 
easy-integration with a specific target platform is the key 
characteristic I am looking for, yes.

So IMO supporting all-platforms-somewhat is less attractive than 
supporting only-one-platform-really-well.


 So which tool will make them choose D?


I think you need to aim for people writing their own tools first, 
but then you need a special set of characteristics that cuts down 
on development time for that area.


 Check the languages Microsoft considered important to offer 
 support out of the box,

 https://code.visualstudio.com/Docs/languages


Thanks, I wasn't aware they supported Go and Rust of the of the 
box. Quite interesting list.
Jul 13 2015
prev sibling parent reply "Kagamin" <spam here.lot> writes:
On Monday, 13 July 2015 at 07:32:57 UTC, Paulo  Pinto wrote:

 Regarding D, there needs to be a story to be sold (e.g Docker, 
 Rails, next Firefox,iOS, Android, WP...) why the language 
 matters.

 On my little world, customers choose programming languages 
 because they want to
 use tool X, framework Y or target operating system Z.


Doesn't that mean the language doesn't matter?
Jul 13 2015
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 13 July 2015 at 15:10:08 UTC, Kagamin wrote:

 On Monday, 13 July 2015 at 07:32:57 UTC, Paulo  Pinto wrote:

 Regarding D, there needs to be a story to be sold (e.g Docker, 
 Rails, next Firefox,iOS, Android, WP...) why the language 
 matters.

 On my little world, customers choose programming languages 
 because they want to
 use tool X, framework Y or target operating system Z.


 Doesn't that mean the language doesn't matter?


I guess you didn't get my point.

iOS app => Objective-C. Eventually Swift.



Hadoop => Java

Android => Java

JSF => Java



....

That is how we get to choose languages. The elected one is a 
consequence of the ecosystem being chosen, not the other way 
around.
Jul 13 2015
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 13-Jul-2015 18:55, Paulo Pinto wrote:

 On Monday, 13 July 2015 at 15:10:08 UTC, Kagamin wrote:

 On Monday, 13 July 2015 at 07:32:57 UTC, Paulo  Pinto wrote:

 Regarding D, there needs to be a story to be sold (e.g Docker, Rails,
 next Firefox,iOS, Android, WP...) why the language matters.

 On my little world, customers choose programming languages because
 they want to
 use tool X, framework Y or target operating system Z.


 Doesn't that mean the language doesn't matter?


 I guess you didn't get my point.

 iOS app => Objective-C. Eventually Swift.



  in Objective-C (superset of plain C). LUA is quite popular.




 Hadoop => Java

 Android => Java

 JSF => Java


JVM more preciesly I think.




 ....

 That is how we get to choose languages. The elected one is a consequence
 of the ecosystem being chosen, not the other way around.


That is a valid point to a certain degree.

-- 
Dmitry Olshansky
Jul 13 2015
parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 13 July 2015 at 16:13:08 UTC, Dmitry Olshansky wrote:

 On 13-Jul-2015 18:55, Paulo Pinto wrote:

 On Monday, 13 July 2015 at 15:10:08 UTC, Kagamin wrote:

 On Monday, 13 July 2015 at 07:32:57 UTC, Paulo  Pinto wrote:

 Regarding D, there needs to be a story to be sold (e.g 
 Docker, Rails,
 next Firefox,iOS, Android, WP...) why the language matters.

 On my little world, customers choose programming languages 
 because
 they want to
 use tool X, framework Y or target operating system Z.


 Doesn't that mean the language doesn't matter?


 I guess you didn't get my point.

 iOS app => Objective-C. Eventually Swift.



 fit a VM
  in Objective-C (superset of plain C). LUA is quite popular.




 Hadoop => Java

 Android => Java

 JSF => Java


 JVM more preciesly I think.




 ....

 That is how we get to choose languages. The elected one is a 
 consequence
 of the ecosystem being chosen, not the other way around.


 That is a valid point to a certain degree.


I am speaking of my experience in the enterprise world and really 
meant the languages I have written, not your alternatives.

We seldom do greenfield projects.

We get to pick where the previous contractors left the project, 
as well as, the next ones get to pick where we left it.

So customers choose the ecosystems official languages to minimise 
attrition, and not what might work as well.
Jul 13 2015
prev sibling next sibling parent reply "Kagamin" <spam here.lot> writes:
On Monday, 13 July 2015 at 07:11:35 UTC, Ola Fosheim Grøstad 
wrote:

 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.


Would you call python a gamedev language?
Jul 15 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 15 July 2015 at 08:34:36 UTC, Kagamin wrote:

 Would you call python a gamedev language?


No, Python is a scripting language.
Jul 15 2015
parent reply "Kagamin" <spam here.lot> writes:
On Wednesday, 15 July 2015 at 08:50:31 UTC, Ola Fosheim Grøstad 
wrote:

 No, Python is a scripting language.


What's your estimation of a number of games written in python 
compared to a number of AAA shooters that can't live without 
realtime requirements?
Jul 15 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 15 July 2015 at 09:01:25 UTC, Kagamin wrote:

 What's your estimation of a number of games written in python 
 compared to a number of AAA shooters that can't live without 
 realtime requirements?


I have no estimate. For games it is used as a scripting 
language... Seriously, you cannot do anything in Python without 
C-counterparts.

More games are written in Lua… doesn't make Lua a game dev 
language. It is still a scripting language.

What point are you trying to make?
Jul 15 2015
parent reply "Kagamin" <spam here.lot> writes:
On Wednesday, 15 July 2015 at 09:09:57 UTC, Ola Fosheim Grøstad 
wrote:

 I have no estimate. For games it is used as a scripting 
 language... Seriously, you cannot do anything in Python without 
 C-counterparts.

 More games are written in Lua… doesn't make Lua a game dev 
 language. It is still a scripting language.

 What point are you trying to make?


You're probably extending shooters stereotypes to other genres of 
games. But then it would matter how sizeable is shooters market 
compared to other genres of games, which don't need C as badly. 
It's true, that you can't do anything without C, but it's true 
for all applications, not just games.
Jul 15 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 15 July 2015 at 12:30:39 UTC, Kagamin wrote:

 You're probably extending shooters stereotypes to other genres 
 of games. But then it would matter how sizeable is shooters 
 market compared to other genres of games, which don't need C as 
 badly. It's true, that you can't do anything without C, but 
 it's true for all applications, not just games.


When I say "game dev", I actually mean engines for demanding 
interactive audio-visual applications for mobile and desktop.

That could be custom sound editors, video editors, paint 
programs, computer games, art installations, information kiosk 
applications, interactive simulations, educational software etc.
Jul 15 2015
parent reply "Kagamin" <spam here.lot> writes:
On Wednesday, 15 July 2015 at 12:34:18 UTC, Ola Fosheim Grøstad 
wrote:

 When I say "game dev", I actually mean engines for demanding 
 interactive audio-visual applications for mobile and desktop.

 That could be custom sound editors, video editors, paint 
 programs, computer games, art installations, information kiosk 
 applications, interactive simulations, educational software etc.


Though they are not as demanding interactive as shooters (maybe 
except for realtime interframe, but that's a video playback, not 
an editor). So what's true for shooters may be not true for other 
games. My point is if you care about market adoption you should 
look at numbers and should not overlook sizeable targetable parts 
of the market.

On Wednesday, 15 July 2015 at 09:05:07 UTC, Ola Fosheim Grøstad 
wrote:

 Yes, I think one only need a local GC for gameworld 
 objects/NPCs/AI/scripting, so a GC could be limited to a 
 specific graph/allocator right after execution when the memory 
 is hot (programmer guaranteeing that there are no unregistered 
 external pointers). It could indeed complete quickly for many 
 game worlds.


This would work for request-response services too. Notice that 
memory allocated during request usually doesn't live longer than 
the request and requests are independent. But it's less pleasant 
than jvm and .net that just work in most realistic scenarios and 
do it reliably.
Jul 15 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 15 July 2015 at 13:04:55 UTC, Kagamin wrote:

 Though they are not as demanding interactive as shooters (maybe 
 except for realtime interframe, but that's a video playback, 
 not an editor). So what's true for shooters may be not true for 
 other games. My point is if you care about market adoption you 
 should look at numbers and should not overlook sizeable 
 targetable parts of the market.


Well, we are just talking about the language feature set, not 
that the frameworks should be built into the language.

You have deadlines or you miss frames in graphics, you have 
deadlines in audio, you have memory subsystem requirements that 
are similar, you also want to tap into the coprocessor (which we 
now think of as GPU) for all kinds of application areas: 3D 
sculpting, photo editors, audio workstations, photon based 
tracers, real time ray tracers, 3D scan browsers… I don't think 
shooters are all that special.

I think basically any interactive desktop application that you 
cannot do easily in Java is a candidate that could benefit from 
the same feature set.
Jul 15 2015
next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Wednesday, 15 July 2015 at 14:57:35 UTC, Ola Fosheim Grøstad 
wrote:

 On Wednesday, 15 July 2015 at 13:04:55 UTC, Kagamin wrote:

 Though they are not as demanding interactive as shooters 
 (maybe except for realtime interframe, but that's a video 
 playback, not an editor). So what's true for shooters may be 
 not true for other games. My point is if you care about market 
 adoption you should look at numbers and should not overlook 
 sizeable targetable parts of the market.


 Well, we are just talking about the language feature set, not 
 that the frameworks should be built into the language.

 You have deadlines or you miss frames in graphics, you have 
 deadlines in audio, you have memory subsystem requirements that 
 are similar, you also want to tap into the coprocessor (which 
 we now think of as GPU) for all kinds of application areas: 3D 
 sculpting, photo editors, audio workstations, photon based 
 tracers, real time ray tracers, 3D scan browsers… I don't think 
 shooters are all that special.

 I think basically any interactive desktop application that you 
 cannot do easily in Java is a candidate that could benefit from 
 the same feature set.




One is an application for live visualization of digital 
microscopes like these ones.

http://www.leica-microsystems.com/products/digital-microscopes/


processing. C++ and Assembly were used for hot loops, basically 
some image filters. Also integration of legacy code from the 
previous Win32 generation of the software, which was being 


Another is an application for processing data for biologic 
measurements and controlling the robots performing the experiment.

https://www.thermoscientific.com/en/products/laboratory-robotics.html

C++ was only used at the lowest level in the robot drivers and 
their firmware.

Both links are just examples, my NDAs prevent me to say which 
products were really used, they are just examples of two fields 
with resource constraints that have been slowly moving to GC 
languages for their work.

Assembly, C++ and C are being pushed down the stack to the hot 
paths that cannot be optimized any further by doing all sorts of 


--
Paulo
Jul 15 2015
prev sibling parent reply "Kagamin" <spam here.lot> writes:
On Wednesday, 15 July 2015 at 14:57:35 UTC, Ola Fosheim Grøstad 
wrote:

 You have deadlines or you miss frames in graphics, you have 
 deadlines in audio, you have memory subsystem requirements that 
 are similar, you also want to tap into the coprocessor (which 
 we now think of as GPU) for all kinds of application areas: 3D 
 sculpting, photo editors, audio workstations, photon based 
 tracers, real time ray tracers, 3D scan browsers… I don't think 
 shooters are all that special.


And there are tasks which benefit from being written in 
assembler. What's your point? And what the topic was about? Maybe 
I didn't understand it well? And what missed frames have to do 
with audio workstations and photo editors?


 I think basically any interactive desktop application that you 
 cannot do easily in Java is a candidate that could benefit from 
 the same feature set.


Like minecraft?
Jul 16 2015
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 16 July 2015 at 10:29:54 UTC, Kagamin wrote:

 Maybe I didn't understand it well? And what missed frames have 
 to do with audio workstations and photo editors?


Real time audio workstations are very sensitive to missed 
audio-frames, much more so than any other desktop-application I 
can think of. They are used for live performances.

Next gen photo/video-editors require easy CPU/GPU integration. 
Excellent Vulcan-support might become a key feature there.


 Like minecraft?


No, like Pong.
Jul 16 2015
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Thursday, 16 July 2015 at 10:50:02 UTC, Ola Fosheim Grøstad 
wrote:

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

 Maybe I didn't understand it well? And what missed frames have 
 to do with audio workstations and photo editors?


 Real time audio workstations are very sensitive to missed 
 audio-frames, much more so than any other desktop-application I 
 can think of. They are used for live performances.

 Next gen photo/video-editors require easy CPU/GPU integration. 
 Excellent Vulcan-support might become a key feature there.


 Like minecraft?


 No, like Pong.


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.
Jul 16 2015
next sibling parent reply "rsw0x" <anonymous anonymous.com> writes:
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.
Jul 16 2015
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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...
Jul 16 2015
prev sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
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.
Jul 16 2015
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.
Jul 16 2015
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
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
Jul 16 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.
Jul 16 2015
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
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
Jul 16 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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... :-/
Jul 16 2015
prev sibling parent reply "rsw0x" <anonymous anonymous.com> writes:
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/
Jul 16 2015
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.
Jul 16 2015
prev sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
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.
Jul 16 2015
parent "rsw0x" <anonymous anonymous.com> writes:
On Thursday, 16 July 2015 at 14:26:27 UTC, Paulo  Pinto wrote:

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


official vulkan support announced
http://android-developers.blogspot.com/2015/08/low-overhead-rendering-with-vulkan.html
;)
Aug 10 2015
prev sibling next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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 

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 


That makes you an attractive platform for new application 
frameworks.


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


It takes years before you get full adoption after standardization.

Vulkan/Metal does not matter. What matters is that you do better 
CPU/GPU integration for common hardware than the competing 
solutions. It could be just latest generation of iOS/OSX for a 
start. That alone is a pretty big market.
Jul 16 2015
parent reply "Kagamin" <spam here.lot> writes:
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 

 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 


 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.
Jul 17 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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?
Jul 17 2015
next sibling parent reply "Laeeth Isharc" <laeethnospam nospamlaeeth.com> writes:
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.
Jul 17 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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 waaaay 
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.
Jul 18 2015
parent reply "Laeeth Isharc" <laeethnospam nospamlaeeth.com> writes:
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 waaaay 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.
Jul 18 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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 waaaay 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.
Jul 18 2015
next sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sat, 2015-07-18 at 11:19 +0000, via Digitalmars-d wrote:

 [=E2=80=A6]
=20
 StackOverflow has become the de-facto documentation resource for=20
 software engineers. It saves me insane amounts of time, many=20
 other programmers say the same thing. Google has been known to=20
 shut down it's own support-forums in order to get higher activity=20
 on StackOverflow.
=20
 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.

[=E2=80=A6]
--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder     t:+44 20 7585 2200   voip:sip:
russel.winder ekiga.net
41 Buckmaster Road   m:+44 7770 465 077   xmpp:russel winder.org.uk
London SW11 1EN, UK  w: www.russel.org.uk skype:russel_winder
Jul 18 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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)
Jul 18 2015
parent "Kagamin" <spam here.lot> writes:
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.
Jul 18 2015
prev sibling parent reply "Etienne Cimon" <etcimon gmail.com> writes:
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.
Jul 18 2015
next sibling parent reply "rsw0x" <anonymous anonymous.com> writes:
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.
Jul 18 2015
next sibling parent "Etienne" <etcimon gmail.com> writes:
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?
Jul 18 2015
prev sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.
Jul 18 2015
prev sibling next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
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.)
Jul 18 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.
Jul 18 2015
next sibling parent "rsw0x" <anonymous anonymous.com> writes:
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.
Jul 18 2015
prev sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
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
Jul 18 2015
prev sibling next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.
Jul 18 2015
parent reply "Etienne Cimon" <etcimon gmail.com> writes:
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!
Jul 18 2015
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.
Jul 18 2015
prev sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.
Jul 18 2015
parent reply "rsw0x" <anonymous anonymous.com> writes:
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?
Jul 18 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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).
Jul 18 2015
parent reply "Etienne" <etcimon gmail.com> writes:
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.
Jul 18 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.
Jul 18 2015
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
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
Jul 18 2015
prev sibling parent "yawniek" <dlang srtnwz.com> writes:
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.
Jul 22 2015
prev sibling next sibling parent reply "Kagamin" <spam here.lot> writes:
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?
Jul 18 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.
Jul 18 2015
next sibling parent "Kagamin" <spam here.lot> writes:
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.
Jul 18 2015
prev sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
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.
Jul 18 2015
prev sibling parent reply "Joakim" <dlang joakim.fea.st> writes:
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.
Jul 22 2015
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.


 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.


 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.
Jul 23 2015
next sibling parent reply "Joakim" <dlang joakim.fea.st> writes:
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.
Jul 23 2015
parent reply "Tofu Ninja" <emmons0 purdue.edu> writes:
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.
Jul 23 2015
next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
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
Jul 23 2015
parent "Tofu Ninja" <emmons0 purdue.edu> writes:
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.
Jul 23 2015
prev sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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...
Jul 23 2015
prev sibling parent reply "Kagamin" <spam here.lot> writes:
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
Jul 24 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.
Jul 24 2015
prev sibling parent reply "Laeeth Isharc" <laeethnospam nospamlaeeth.com> writes:
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.
Jul 23 2015
parent reply "Etienne" <etcimon gmail.com> writes:
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.
Jul 23 2015
parent reply "Joakim" <dlang joakim.fea.st> writes:
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.
Jul 23 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.
Jul 23 2015
parent reply "Joakim" <dlang joakim.fea.st> writes:
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.
Jul 24 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.
Jul 24 2015
next sibling parent reply "Joakim" <dlang joakim.fea.st> writes:
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.
Jul 24 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.
Jul 24 2015
parent "Joakim" <dlang joakim.fea.st> writes:
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.
Jul 24 2015
prev sibling parent reply "Joakim" <dlang joakim.fea.st> writes:
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.
Jul 24 2015
next sibling parent David Gileadi <gileadis NSPMgmail.com> writes:
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.
Jul 24 2015
prev sibling parent reply "Etienne" <etcimon gmail.com> writes:
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..
Jul 24 2015
parent reply "Joakim" <dlang joakim.fea.st> writes:
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.
Jul 24 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.
Jul 24 2015
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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++...
Jul 24 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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%.
Jul 24 2015
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
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.
Jul 24 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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
Jul 24 2015
prev sibling parent reply "Joakim" <dlang joakim.fea.st> writes:
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.
Jul 25 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.
Jul 25 2015
parent reply "Joakim" <dlang joakim.fea.st> writes:
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.
Jul 25 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.
Jul 25 2015
next sibling parent reply "David Nadlinger" <code klickverbot.at> writes:
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
Jul 25 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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).
Jul 25 2015
prev sibling parent "Joakim" <dlang joakim.fea.st> writes:
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.
Jul 25 2015
prev sibling parent reply "Tofu Ninja" <emmons0 purdue.edu> writes:
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...
Jul 16 2015
parent "Paulo Pinto" <pjmlp progtools.org> writes:
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.
Jul 16 2015
prev sibling parent reply "rsw0x" <anonymous anonymous.com> writes:
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.
Jul 16 2015
parent reply "ponce" <contact gam3sfrommars.fr> writes:
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.
Jul 16 2015
parent "Wyatt" <wyatt.epp gmail.com> writes:
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
Jul 16 2015
prev sibling parent reply "karabuta" <karabutaworld gmail.com> writes:
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 ....
Aug 12 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.
Aug 12 2015
parent reply "rsw0x" <anonymous anonymous.com> writes:
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.
Aug 12 2015
next sibling parent Rikki Cattermole <alphaglosined gmail.com> writes:
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?
Aug 12 2015
prev sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.
Aug 13 2015
prev sibling next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Sunday, 12 July 2015 at 18:53:35 UTC, weaselcat wrote:

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


Yes, why not? I would love that too, but I suspect it would 
require a change of direction in order to gain traction. E.g. 
better SIMD support, inlining, builtin SOA and maybe Vulkan 
support. And you would also need compiler/runtime support for 
iOS, Android, asm.js&co.

I'm not convinced that the "shared" and "thread local globals" 
models sit well with some game devs. And you probably need to 
deal with ownership in a way that is C++-ish.

(The reason I focused on web services is that I think there is a 
change of direction towards compiled typed languages like Go and 
Rust. At least it looks like it based on the eco systems they are 
gaining on github.)
Jul 12 2015
prev sibling parent "karabuta" <karabutaworld gmail.com> writes:
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?


+30000000
Aug 12 2015
prev sibling parent reply "Wyatt" <wyatt.epp gmail.com> writes:
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
Jul 16 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.
Jul 16 2015
parent reply "karabuta" <karabutaworld gmail.com> writes:
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)
Aug 13 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 13 August 2015 at 14:31:10 UTC, karabuta wrote:

 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)


How is that different from D/asm?
Aug 13 2015
next sibling parent reply "Mint" <mintie wute.com> writes:
On Thursday, 13 August 2015 at 14:31:10 UTC, karabuta wrote:

 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)


Oh! Someone thinks D is a programming language. D runs on which 
processor? D just transpiles into ASM after all.

Oh! Someone thinks ASM is a programming language. ASM runs on 
which processor? x86 just transpiles into the processor's native 
instruction set.

CPUs haven't actually executed x86 directly in the better part of 
a decade.
Aug 18 2015
next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tuesday, 18 August 2015 at 18:22:09 UTC, Mint wrote:

 Oh! Someone thinks D is a programming language. D runs on which 
 processor? D just transpiles into ASM after all.


dmd doesn't actually produce asm... :)
Aug 18 2015
prev sibling parent reply "lobo" <swamplobo gmail.com> writes:
On Tuesday, 18 August 2015 at 18:22:09 UTC, Mint wrote:

 On Thursday, 13 August 2015 at 14:31:10 UTC, karabuta wrote:

 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)


 Oh! Someone thinks D is a programming language. D runs on which 
 processor? D just transpiles into ASM after all.

 Oh! Someone thinks ASM is a programming language. ASM runs on 
 which processor? x86 just transpiles into the processor's 
 native instruction set.

 CPUs haven't actually executed x86 directly in the better part 
 of a decade.


x86 CPUs never directly executed x86 bytecode, they're all CISC 
architectures.
Aug 18 2015
parent reply "rsw0x" <anonymous anonymous.com> writes:
On Tuesday, 18 August 2015 at 23:25:47 UTC, lobo wrote:

 On Tuesday, 18 August 2015 at 18:22:09 UTC, Mint wrote:

 On Thursday, 13 August 2015 at 14:31:10 UTC, karabuta wrote:

 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)


 Oh! Someone thinks D is a programming language. D runs on 
 which processor? D just transpiles into ASM after all.

 Oh! Someone thinks ASM is a programming language. ASM runs on 
 which processor? x86 just transpiles into the processor's 
 native instruction set.

 CPUs haven't actually executed x86 directly in the better part 
 of a decade.


 x86 CPUs never directly executed x86 bytecode, they're all CISC 
 architectures.


I believe they're referring to x86 decoding CISC to RISC 
micro-ops behind the scenes.
Aug 18 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 18 August 2015 at 23:32:38 UTC, rsw0x wrote:

 I believe they're referring to x86 decoding CISC to RISC 
 micro-ops behind the scenes.


Well, not RISC, but microcode (or micro-ops as Intel call them). 
The basic idea behind RISC is that the decoding is embedded 
directly in the instruction bits. CISC used to be the norm until 
the 90s. But embedding the decoding in the instruction is kind of 
tricky when your needs change (like memory-bus bottlenecks).
Aug 19 2015
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 08/13/2015 10:35 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 On Thursday, 13 August 2015 at 14:31:10 UTC, karabuta wrote:

 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)


 How is that different from D/asm?


Although I haven't used typescript specifically, any time I have used a 
source translation tool (ex, Haxe), I frequently wind up (for various 
reasons) needing to deal with both the input and generates languages, 
flip between the two, etc.

I nearly never need to do that with a bytecode/machinecode based language.
Aug 18 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 18 August 2015 at 20:27:53 UTC, Nick Sabalausky wrote:

 Although I haven't used typescript specifically, any time I 
 have used a source translation tool (ex, Haxe), I frequently 
 wind up (for various reasons) needing to deal with both the 
 input and generates languages, flip between the two, etc.

 I nearly never need to do that with a bytecode/machinecode 
 based language.


Typescript is a mix of ECMAScript 5 and 6 with typing, that helps 
with catching mistakes when editing and also gives you better 
code completion (when using WebStorm at least). So the code is 
quite similar, except you get automatic binding of the "this" 
reference variable when you use closure syntax for functions.

So the semantics are close and you get to see TypeScript in the 
browser-debugger if you use source maps (that map line numbers 
between source files).

You basically get structural typing of most of the Javascript 
functions and Object types that exists in the browser at compile 
time (but not at runtime).
Aug 18 2015
prev sibling next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 13/07/2015 12:14 a.m., "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 I've been thinking a bit about where languages fit in the web service
 space. Both mobile app and web services are likely candidates for typed
 and efficient languages. I'm not at all happy with the "prolific"
 choices that are available. Yet, D is currently not in a strong position
 for mobile apps or web servers. So what does the competition look like?


 JAVA is big and a strong player, but also heavy and resource demanding.
 I don't consider it for my use due to the resource requirements. I want
 something more nimble.

 - Java is for those who already have invested in the language or need a
 framework written in it.



 taint (for good and bad).




 GO is nimble, but the language is a bit annoying. On the good side it
 has a low latency GC, but with a performance penalty. Google are now
 also fully supporting Go on Google App Engine (together with Java and
 Python)
 https://sourcegraph.com/blog/live/gophercon2015/123574706480
 https://groups.google.com/forum/#!topic/google-appengine-go/as9wUqT77YU

 - Go is an alternative for those who want to write a light server from
 scratch and/or integrate with Google Cloud. It has a very quickly gained
 a lot of web related frameworks and 3rd party APIs.


 RUST was never meant for the web servers, but people seem to have taken
 to writing frameworks for it lately. Rust is like Go a bit annoying, but
 with some strong non-GC semantics.

 - Rust is difficult to place, but seems like an emerging TCP/HTTP
 alternative where better-speed-than-GC is a requirement. Might become an
 alternative to C++/Java for game-servers?


 C++ offers everything needed, but unfortunately writing safe code in C++
 is tedious and difficult.

 - I'm not really sure why anyone would want to write a server in C++.
 Seems like a "last resort" language for this purpose. What you fall back
 on when the alternatives don't cut it, or don't integrate with required
 libraries, at the cost of development time.

 HASKELL is used to some extent. In theory a functional language should
 be a perfect match for a web service, but is it? Not sure, but I am not
 likely to use it for web programming for the same reason I would not
 choose C++. I am afraid it will become tedious.

 PONY is an upcoming actor based, non-GC language that might be worth
 watching. Not production ready, a fringe language, but the actor based
 programming model might be suitable.

 Maybe you know some other statically typed languages worth mentioning?

 To me it seems like C++ and Rust are the most likely targets for D to
 compete with. Yet, to me those languages are on the fringe of
 web-service programming. More suitable for specialised services like
 image rescaling or game servers.


 that makes them difficult targets. They all have integration advantages
 not provided by other languages.

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


Controversial part: D is not very pleasant to write web services in 
currently.
BUT: I also do not consider any language/framework to fully hit the nail 
on the head. Although ruby on rails has some pretty neat ideas.

Currently I believe a D web server/front end for web service framework 
should be an web application server not a plain old web server.
The model for web servers is odd for D I think.

We have great potential here with web applications.
I personally have plans here but ugh, lets just say last night I started 
to rewrite my webserver and I'm now writing bindings for XED (x86 
encoding/decoding). Turns out, I kinda want a LISPy style configuration 
language *shrugs*.
Jul 12 2015
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sunday, 12 July 2015 at 12:48:25 UTC, Rikki Cattermole wrote:

 Controversial part: D is not very pleasant to write web 
 services in currently.
 [...] Although ruby on rails has some pretty neat ideas.


What's the gap you see? When I use RoR I find it pretty painful 
compared to D.
Jul 12 2015
parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 13/07/2015 12:57 a.m., Adam D. Ruppe wrote:

 On Sunday, 12 July 2015 at 12:48:25 UTC, Rikki Cattermole wrote:

 Controversial part: D is not very pleasant to write web services in
 currently.
 [...] Although ruby on rails has some pretty neat ideas.


 What's the gap you see? When I use RoR I find it pretty painful compared
 to D.


I believe the biggest problem for me is that I've been around the block 
in the web sphere a bit too much without actually using even a quarter 
of the popular frameworks.
So for example I at some point see some snippet of code and in this case 
RoR where the template is inline with the route function without 
anything special and I think ooo nice. I want that. Years later.. no 
longer supported or mentioned.

So I know what is possible, just not really willing to get it there 
100%. It's late where I am so this is mostly nonsense, little warning 
about that.
Jul 12 2015
prev sibling next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Sunday, 12 July 2015 at 12:48:25 UTC, Rikki Cattermole wrote:

 Currently I believe a D web server/front end for web service 
 framework should be an web application server not a plain old 
 web server.


Yes, I agree. Browsers are so capable now that you can put most 
of the logic in the client and keep the server more like a 
web-service delivering chunks of content rather than full pages.


 I personally have plans here but ugh, lets just say last night 
 I started to rewrite my webserver and I'm now writing bindings 
 for XED (x86 encoding/decoding). Turns out, I kinda want a 
 LISPy style configuration language *shrugs*.


Cool. :)
Jul 12 2015
prev sibling parent Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 2015-07-13 at 00:48 +1200, Rikki Cattermole via Digitalmars-d
wrote:

=20


[=E2=80=A6]

 Controversial part: D is not very pleasant to write web services in=20
 currently.
 BUT: I also do not consider any language/framework to fully hit the=20
 nail=20
 on the head. Although ruby on rails has some pretty neat ideas.
=20
 Currently I believe a D web server/front end for web service=20
 framework=20
 should be an web application server not a plain old web server.
 The model for web servers is odd for D I think.
=20
 We have great potential here with web applications.
 I personally have plans here but ugh, lets just say last night I=20
 started=20
 to rewrite my webserver and I'm now writing bindings for XED (x86=20
 encoding/decoding). Turns out, I kinda want a LISPy style=20
 configuration=20
 language *shrugs*.


Depending on what Web Services mean=E2=80=A6 most people I meet up with are
either using Go or Python with Flask or Django to receive and deliver
up JSON in RESTful style. This maybe just indicates something about me
rather than Web services.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Jul 13 2015
prev sibling next sibling parent reply "Etienne Cimom" <etcimon gmail.com> writes:
On Sunday, 12 July 2015 at 12:14:31 UTC, Ola Fosheim Grøstad 
wrote:

 I've been thinking a bit about where languages fit in the web 
 service space. Both mobile app and web services are likely 
 candidates for typed and efficient languages. I'm not at all 
 happy with the "prolific" choices that are available. Yet, D is 
 currently not in a strong position for mobile apps or web 
 servers. So what does the competition look like?

 [...]


For me at least, D has a lot more to offer because with the 
recent developments in vibe.d, it's the only language that offers 
the opportunity to write portable Web applications in the true 
sense, ie. The user interface being in a browser, the backend 
being a natively compiled service in the computer. With a 2 
megabytes packed PE that is. It may not seem useful, but to me 
it's revolutionary. Javascript user interfaces on the desktop are 
a very good replacement for the traditional GUI, and absolutely 
cross platform. I see nothing I need in other frameworks that I 
can't offer myself in D. We're already on top and we don't know 
it yet
Jul 12 2015
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Sunday, 12 July 2015 at 20:36:26 UTC, Etienne Cimom wrote:

 backend being a natively compiled service in the computer. With 
 a 2 megabytes packed PE that is. It may not seem useful, but to 
 me it's revolutionary.


What is "PE"?
Jul 12 2015
next sibling parent reply "Etienne Cimon" <etcimon gmail.com> writes:
On Sunday, 12 July 2015 at 21:13:35 UTC, Ola Fosheim Grøstad 
wrote:

 On Sunday, 12 July 2015 at 20:36:26 UTC, Etienne Cimom wrote:

 backend being a natively compiled service in the computer. 
 With a 2 megabytes packed PE that is. It may not seem useful, 
 but to me it's revolutionary.


 What is "PE"?


The idea here is a portable executable (PE), in vibe.d, as a 
service with daemonize, that compiles packed to < 2MB with TLS 
and a single TCP link using HTTP/2.

I haven't tried Golang but I'm sure if I did it would be a close 
call. The lack of template meta-programming / generics makes it 
much less convenient to use though, so it's no go for me :) C++ 
could also do it if a framework existed for it, but even then, 
the language isn't as safe/convenient. So, I guess D wins here 
where a simple dub build with the right packages will dump a nice 
executable with everything you need for a desktop webUI 
application.
Jul 12 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Sunday, 12 July 2015 at 21:20:21 UTC, Etienne Cimon wrote:

 The idea here is a portable executable (PE), in vibe.d, as a 
 service with daemonize, that compiles packed to < 2MB with TLS 
 and a single TCP link using HTTP/2.


Not sure what you mean. Do you mean that vibe.d is an application 
server and that you run a PNACL GUI client in the browser on the 
same machine as the server?

If so, you would be better off building the browser into the 
application and use shared memory?
Jul 13 2015
prev sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 13-Jul-2015 00:13, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 On Sunday, 12 July 2015 at 20:36:26 UTC, Etienne Cimom wrote:

 backend being a natively compiled service in the computer. With a 2
 megabytes packed PE that is. It may not seem useful, but to me it's
 revolutionary.


 What is "PE"?


I guess Portable Executable - or simply Windows exe binary.
Technically it's a foramt of binaries that has relatively obscure 
support for any bytecode or (more typically) any architecture for 
machine code. That's probably why it was called like that.

-- 
Dmitry Olshansky
Jul 12 2015
prev sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sunday, 12 July 2015 at 20:36:26 UTC, Etienne Cimom wrote:

 For me at least, D has a lot more to offer because with the 
 recent developments in vibe.d


I don't think I'd even use vibe for your use case - you'd never 
need to scale to 10,000 connections if it runs on localhost.

Perhaps a little-known part of my web.d is a few special parts 
for localhost work, including a synchronous javascript bridge 
back to your server side functions.

web.d's normal behavior is to provide web pages and async 
javascript access to your class methods:

D:
class Foo : ApiProvider {
   int add(int a, int b) { return a+b; }
}

Usage from javascript:

Foo.add(1, 2).get(function(sum) { alert(sum); } );

or in the browser, you can navigate to site/add and it presents a 
form asking for a and b, and the submit shows the answer.


But it also has sync JS support:


var sum = Foo.add(1, 2).getSync();


Which is nice because then you have linear flow. The bridge also 
translates D exceptions into JS exceptions here.


You wouldn't normally do that on the web since synchronous events 
can freeze up the browser from network lag. But doing it on 
localhost should be pretty reliable.


cgi.d's underlying threaded implementation is also fine here, as 
it will trivially scale to the small handful of connections you 
need for localhost.... and you can still use your ordinary other 
libraries to handle requests, e.g. C libraries that block, with 
no hassle (heck, you could even make a gui thread pop up a 
regular window to control the server with ease).


 We're already on top and we don't know it yet


I've felt that way for about five years now!
Jul 12 2015
prev sibling next sibling parent reply "ChangLong" <changlon gmail.com> writes:
On Sunday, 12 July 2015 at 12:14:31 UTC, Ola Fosheim Grøstad 
wrote:

 I've been thinking a bit about where languages fit in the web 
 service space. Both mobile app and web services are likely 
 candidates for typed and efficient languages. I'm not at all 
 happy with the "prolific" choices that are available. Yet, D is 
 currently not in a strong position for mobile apps or web 
 servers. So what does the competition look like?


 JAVA is big and a strong player, but also heavy and resource 
 demanding. I don't consider it for my use due to the resource 
 requirements. I want something more nimble.

 - Java is for those who already have invested in the language 
 or need a framework written in it.



 "Microsoft" taint (for good and bad).


 Microsoft products.


 GO is nimble, but the language is a bit annoying. On the good 
 side it has a low latency GC, but with a performance penalty. 
 Google are now also fully supporting Go on Google App Engine 
 (together with Java and Python)
 https://sourcegraph.com/blog/live/gophercon2015/123574706480
 https://groups.google.com/forum/#!topic/google-appengine-go/as9wUqT77YU

 - Go is an alternative for those who want to write a light 
 server from scratch and/or integrate with Google Cloud. It has 
 a very quickly gained a lot of web related frameworks and 3rd 
 party APIs.


 RUST was never meant for the web servers, but people seem to 
 have taken to writing frameworks for it lately. Rust is like Go 
 a bit annoying, but with some strong non-GC semantics.

 - Rust is difficult to place, but seems like an emerging 
 TCP/HTTP alternative where better-speed-than-GC is a 
 requirement. Might become an alternative to C++/Java for 
 game-servers?


 C++ offers everything needed, but unfortunately writing safe 
 code in C++ is tedious and difficult.

 - I'm not really sure why anyone would want to write a server 
 in C++. Seems like a "last resort" language for this purpose. 
 What you fall back on when the alternatives don't cut it, or 
 don't integrate with required libraries, at the cost of 
 development time.

 HASKELL is used to some extent. In theory a functional language 
 should be a perfect match for a web service, but is it? Not 
 sure, but I am not likely to use it for web programming for the 
 same reason I would not choose C++. I am afraid it will become 
 tedious.

 PONY is an upcoming actor based, non-GC language that might be 
 worth watching. Not production ready, a fringe language, but 
 the actor based programming model might be suitable.

 Maybe you know some other statically typed languages worth 
 mentioning?

 To me it seems like C++ and Rust are the most likely targets 
 for D to compete with. Yet, to me those languages are on the 
 fringe of web-service programming. More suitable for 
 specialised services like image rescaling or game servers.


 advantages that makes them difficult targets. They all have 
 integration advantages not provided by other languages.

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



I has use vibe.d for a small project recently,  after finish that 
I think the follow fact will 	
prevent many programmers use vibe.d in commercial projects:

1) Lack of successful open source project for real product
2) Multi thread performance is poor, scalability is not suit for 
big project
3) No Inversion of Control (aka: Dependency Injection) Concept
4) No mature ORM/ODM components
5) No Form/Validator/Translation/Locale Components
6) No modernize framework

Some company has successful story in D use no-GC solution, for 
example: Sociomantic,  Hedge Fund by Andy Smith,  weka.io...  And 
they all are close source.

There are thousands of web projects in development every day,  D 
is not use as development languages mainly because D is not ready 
yet.
Jul 12 2015
next sibling parent reply Faux Amis <faux amis.com> writes:
On Mon 13/07/2015 06:29, ChangLong wrote:

 On Sunday, 12 July 2015 at 12:14:31 UTC, Ola Fosheim Grøstad wrote:


-snip-

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



 I has use vibe.d for a small project recently,  after finish that I
 think the follow fact will
 prevent many programmers use vibe.d in commercial projects:

 1) Lack of successful open source project for real product
 2) Multi thread performance is poor, scalability is not suit for big
 project
 3) No Inversion of Control (aka: Dependency Injection) Concept
 4) No mature ORM/ODM components
 5) No Form/Validator/Translation/Locale Components
 6) No modernize framework

 Some company has successful story in D use no-GC solution, for example:
 Sociomantic,  Hedge Fund by Andy Smith,  weka.io...  And they all are
 close source.

 There are thousands of web projects in development every day,  D is not
 use as development languages mainly because D is not ready yet.


2) I have zero experience with going beyond one thread, but as far as I 
understand it multi-threading is not how vibe is supposed to scale. 
Start up another instance will you!

3) It has been work-in-progress for some time now:
http://vibed.org/features#load-balancing
Not sure what the status of this is though.

4) Dunno about that..

5) Well, there is this:
https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/utils/validation.d
and:
http://vibed.org/docs#web-localization

6) What is that?

In my experience, vibe.d is a beautiful alternative to node.js and it is 
not the immaturity of D that is holding it back, vibe.d just needs to 
grow a bit.
Jul 13 2015
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 13 July 2015 at 10:12:33 UTC, Faux Amis wrote:

 In my experience, vibe.d is a beautiful alternative to node.js 
 and it is not the immaturity of D that is holding it back, 
 vibe.d just needs to grow a bit.


But what about the memory model?
Do you think the D GC is sufficient?
Do you think that vibe.d-programming without GC is convenient 
enough?

(That is, compared to the alternatives.)
Jul 13 2015
next sibling parent reply Faux Amis <faux amis.com> writes:
On Mon 13/07/2015 13:26, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang gmail.com> wrote:

 On Monday, 13 July 2015 at 10:12:33 UTC, Faux Amis wrote:

 In my experience, vibe.d is a beautiful alternative to node.js and it
 is not the immaturity of D that is holding it back, vibe.d just needs
 to grow a bit.


 But what about the memory model?
 Do you think the D GC is sufficient?
 Do you think that vibe.d-programming without GC is convenient enough?

 (That is, compared to the alternatives.)


To me the GC is there for prototyping anf the moment we have performance 
issues we can strip out the lacking parts.
Jul 13 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 13 July 2015 at 12:39:51 UTC, Faux Amis wrote:

 To me the GC is there for prototyping anf the moment we have 
 performance issues we can strip out the lacking parts.


So in essence you think of D taking a position closer to Rust/C++ 
than Go/Java.
Jul 13 2015
parent reply Faux Amis <faux amis.com> writes:
On Mon 13/07/2015 16:58, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang gmail.com> wrote:

 On Monday, 13 July 2015 at 12:39:51 UTC, Faux Amis wrote:

 To me the GC is there for prototyping anf the moment we have
 performance issues we can strip out the lacking parts.


 So in essence you think of D taking a position closer to Rust/C++ than
 Go/Java.


Sadly, I have insignificant experience with Rust and Go.
Nowadays I am doing mostly frontend js.

Not sure on which aspects I should position D; use case, usage?

Does this help:

C++
learning curve: Wall after wall

Java
Stop forcing me!

Js
Easy to write bad code.

D
Easy to learn but slow until you optimize.
Jul 13 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 13 July 2015 at 15:58:03 UTC, Faux Amis wrote:

 On Mon 13/07/2015 16:58, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
 <ola.fosheim.grostad+dlang gmail.com> wrote:

 On Monday, 13 July 2015 at 12:39:51 UTC, Faux Amis wrote:

 To me the GC is there for prototyping anf the moment we have
 performance issues we can strip out the lacking parts.


 So in essence you think of D taking a position closer to 
 Rust/C++ than
 Go/Java.


 Sadly, I have insignificant experience with Rust and Go.
 Nowadays I am doing mostly frontend js.

 Not sure on which aspects I should position D; use case, usage?


The way I see it:

For a typical web service I usually want convenience and low 
development time. Meaning, I want automatic garbage collection 
(like GC), but I also want low latency so that clients can hammer 
the server requesting resources without significant delays. So 
the Go 1.5 GC seems suitable.

For a demanding functionality-limited web service (like image 
processing) I might want to conserve memory and avoid 
collections, but I also want to avoid issues like memory leaks.

If the D GC isn't good enough for typical web services it seem 
like D will be limited to the more narrow non-GC web services 
where high performance/low memory usage is important.

So Go/Java basically will take the big slice of the pie because 
they have low latency GCs, and C++/Rust/D takes the small slice? 
(Assuming that manual memory management is less convenient and 
takes more developer time.)
Jul 13 2015
parent reply "rsw0x" <anonymous anonymous.com> writes:
On Monday, 13 July 2015 at 16:24:07 UTC, Ola Fosheim Grøstad 
wrote:

 On Monday, 13 July 2015 at 15:58:03 UTC, Faux Amis wrote:

 On Mon 13/07/2015 16:58, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
 <ola.fosheim.grostad+dlang gmail.com> wrote:

 [...]


 Sadly, I have insignificant experience with Rust and Go.
 Nowadays I am doing mostly frontend js.

 Not sure on which aspects I should position D; use case, usage?


 The way I see it:

 For a typical web service I usually want convenience and low 
 development time. Meaning, I want automatic garbage collection 
 (like GC), but I also want low latency so that clients can 
 hammer the server requesting resources without significant 
 delays. So the Go 1.5 GC seems suitable.

 For a demanding functionality-limited web service (like image 
 processing) I might want to conserve memory and avoid 
 collections, but I also want to avoid issues like memory leaks.

 If the D GC isn't good enough for typical web services it seem 
 like D will be limited to the more narrow non-GC web services 
 where high performance/low memory usage is important.

 So Go/Java basically will take the big slice of the pie because 
 they have low latency GCs, and C++/Rust/D takes the small 
 slice? (Assuming that manual memory management is less 
 convenient and takes more developer time.)


*BSD and OSX could have a good concurrent GC implementation on D. 
When the Linux kernel devs feel like pulling their heads out of 
their asses and provide developers with useful VM APIs, it could 
too.

I plan on discussing this in a blog post if anyone cares.
Jul 13 2015
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 13 July 2015 at 16:59:42 UTC, rsw0x wrote:

 *BSD and OSX could have a good concurrent GC implementation on 
 D. When the Linux kernel devs feel like pulling their heads out 
 of their asses and provide developers with useful VM APIs, it 
 could too.

 I plan on discussing this in a blog post if anyone cares.


What kernel feature are you thinking about?
Jul 13 2015
parent reply "rsw0x" <anonymous anonymous.com> writes:
On Monday, 13 July 2015 at 17:08:47 UTC, Ola Fosheim Grøstad 
wrote:

 On Monday, 13 July 2015 at 16:59:42 UTC, rsw0x wrote:

 *BSD and OSX could have a good concurrent GC implementation on 
 D. When the Linux kernel devs feel like pulling their heads 
 out of their asses and provide developers with useful VM APIs, 
 it could too.

 I plan on discussing this in a blog post if anyone cares.


 What kernel feature are you thinking about?


if you want an idea, check out some of the issues redis, 
jemalloc, and Go have had on Linux. OSX had the blessing to be 
born from Mach, and the *BSDs have managed to ape most of Mach's 
memory management.
Jul 14 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 14 July 2015 at 12:20:18 UTC, rsw0x wrote:

 if you want an idea, check out some of the issues redis, 
 jemalloc, and Go have had on Linux. OSX had the blessing to be 
 born from Mach, and the *BSDs have managed to ape most of 
 Mach's memory management.


You know what, I think I'll go with Marc Schütz and say I'd love 
to see a thoughtful blogpost on the topic. Sounds like an 
interesting topic! :-)
Jul 14 2015
prev sibling parent "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Monday, 13 July 2015 at 16:59:42 UTC, rsw0x wrote:

 *BSD and OSX could have a good concurrent GC implementation on 
 D. When the Linux kernel devs feel like pulling their heads out 
 of their asses and provide developers with useful VM APIs, it 
 could too.

 I plan on discussing this in a blog post if anyone cares.


I'm interested. From time to time, proposals for the Linux kernel 
pop up that could be utilized for a GC, but they are usually not 
targeted at that purpose.
Jul 14 2015
prev sibling parent reply "Laeeth Isharc" <laeethnospam nospamlaeeth.com> writes:
On Monday, 13 July 2015 at 11:26:46 UTC, Ola Fosheim Grøstad 
wrote:

 On Monday, 13 July 2015 at 10:12:33 UTC, Faux Amis wrote:

 In my experience, vibe.d is a beautiful alternative to node.js 
 and it is not the immaturity of D that is holding it back, 
 vibe.d just needs to grow a bit.


 But what about the memory model?
 Do you think the D GC is sufficient?
 Do you think that vibe.d-programming without GC is convenient 
 enough?

 (That is, compared to the alternatives.)


I'm curious.

Today, one wouldn't want to build a business around depending on 
Andrei's allocator.  But in two years one can presume it will be 
relatively dependable (and probably less, given the profile of 
the project).  And the topic is about the future, not the next 
quarter.

So in which cases could one not use the allocator to manage 
memory comfortably enough?

And what kind of scale of web requests are you speaking about ?


Laeeth.
Jul 13 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 13 July 2015 at 18:32:11 UTC, Laeeth Isharc wrote:

 Today, one wouldn't want to build a business around depending 
 on Andrei's allocator.


Not really sure what you are referring to.


 So in which cases could one not use the allocator to manage 
 memory comfortably enough?


Allocators generally don't manage memory, they structure 
allocation patterns and may (or may not) provide initialization 
optimizations, release information and release optimizations.

To manage memory you need an ownership model:

- GC is the most comfortable way to handle ownership.

- Regular manual memory management is error prone, and ownership 
is ad hoc and informal.

- Strict linear typing is a more tedious alternative that 
requires you to structure things in a particular way (makes 
simple things like creating a doubly linked list difficult).

- Reference counting has performance overhead and special care 
has to be taken to avoid cycles.
Jul 13 2015
parent reply "Laeeth Isharc" <laeethnospam nospamlaeeth.com> writes:
On Tuesday, 14 July 2015 at 00:22:21 UTC, Ola Fosheim Grøstad 
wrote:

 On Monday, 13 July 2015 at 18:32:11 UTC, Laeeth Isharc wrote:

 Today, one wouldn't want to build a business around depending 
 on Andrei's allocator.


 Not really sure what you are referring to.


It will be dependable soon enough, so I wanted to head off any 
discussion centred around it not yet seasoned.


 So in which cases could one not use the allocator to manage 
 memory comfortably enough?


 Allocators generally don't manage memory, they structure 
 allocation patterns and may (or may not) provide initialization 
 optimizations, release information and release optimizations.


It's my understanding that in a language like D in the end the 
programmer is responsible for making choices about managing 
memory, but I certainly don't claim to be on top of many 
developments in computer science.

If I think about the concrete problems I myself might have to 
deal with (and these may well be simpler and easier than the 
things you have in mind, but it is what I am personally most 
familiar with) - reading a lot of bars in from somewhere, 
performing some kind of computation on them, and disposing of the 
bars and retaining the results: the allocator helps me a lot as I 
can allocate lots cheaply and free the whole lot - bang! - when I 
am done.  In addition there is instrumenting etc built into the 
allocators that I suppose will help track down many kinds of 
problems.

In this kind of problem, it strikes me as an unhelpful dichotomy 
to distinguish only between 'regular memory management' and 
everything else, because the former has connotations of having to 
remember to call free or delete that don't apply here (scope + 
depending on struct destructors being run).

I imagine it may be very different where you have shared 
ownership of lots of little objects and these aren't centralized 
in one place, but that isn't mostly my sort of problem.  I 
suppose implicitly from what you write it must be for web 
services on a large scale, and if you have anything you can point 
me to on this then I would be curious to see it.


Laeeth.
Jul 13 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 14 July 2015 at 05:00:47 UTC, Laeeth Isharc wrote:

 On Tuesday, 14 July 2015 at 00:22:21 UTC, Ola Fosheim Grøstad 
 wrote:

 On Monday, 13 July 2015 at 18:32:11 UTC, Laeeth Isharc wrote:

 Today, one wouldn't want to build a business around depending 
 on Andrei's allocator.


 Not really sure what you are referring to.


 It will be dependable soon enough, so I wanted to head off any 
 discussion centred around it not yet seasoned.


As I've written elsewhere. Ready-made-library-allocators don't 
solve any real world challenges I have.

I can make do with malloc and mmap where needed. I can write my 
own specialised allocator in 10-20 minutes, which I almost never 
need, and which is much more likely to perform well than a 
library solution since it is written for a specific scenario.

What makes D "need" library-allocators is that it was designed 
for having a GC and is perhaps over-focusing on generic 
programming that is agnostic to GC/non-GC. That may or may not be 
an interesting experiment, but it does not solve many real world 
problems. It might solve some problems D have aggregated by not 
addressing the GC issues at an early stage.



 bang! - when I am done.  In addition there is instrumenting etc 
 built into the allocators that I suppose will help track down 
 many kinds of problems.


If the language makes problems related to memory a likely issue, 
then you are already in a worse position than the competing 
solutions where such issues are very very unlikely. That means 
you are off-the-map.

There's a big advantage in having a coherent compiler-backed 
memory model and let the compiler optimize transparently based on 
static analysis, profiling and hints. That's basically what all 
high level languages should and do aim for.

(C is not a high level language)



 problem.  I suppose implicitly from what you write it must be 
 for web services on a large scale, and if you have anything you 
 can point me to on this then I would be curious to see it.


It applies to all scales. It has to do with having a system that 
is robust to modifications and affords agile evolutionary 
development over time.

Web services are updated, modified and extended several times 
every year over many years sometimes on short notice. Glitches, 
and especially hard to track down glitches, are very bad.

One good reason for going for a statically typed language with 
solid memory management is to get close to zero glitches with 
less development time spent on development, testing and debugging.

So if you cannot have a GC, then you need another solution that 
is equally robust, which is what new no-GC languages like Rust 
and Pony try to offer. That does give  them an advantage.


Client side game development has completely different 
requirements since you don't have to ship on a few hours notice 
if the architecture is reasonable. So I agree with weaselcat that 
D could be better of gearing itself towards that use scenario 
where linear typing is more likely to be a liability than an 
advantage.

But either way, you have to provide a feature set that maximise 
utility within a domain that is sizeable in order to grow an eco 
system. Otherwise you get all these libraries with 1-2 developers 
behind them that end up rotting because nobody are willing to 
maintain them long term.
Jul 14 2015
parent reply "Laeeth Isharc" <laeethnospam nospamlaeeth.com> writes:
On Tuesday, 14 July 2015 at 07:01:56 UTC, Ola Fosheim Grøstad 
wrote:

 As I've written elsewhere. Ready-made-library-allocators don't 
 solve any real world challenges I have.

 I can make do with malloc and mmap where needed. I can write my 
 own specialised allocator in 10-20 minutes, which I almost 
 never need, and which is much more likely to perform well than 
 a library solution since it is written for a specific scenario.


Good for you!  I am not sure that suggesting people roll their 
own as needed will be conducive to encouraging the adoption of D 
for web services - or any other use - though.


 What makes D "need" library-allocators is that it was designed 
 for having a GC


That doesn't appear to have been the rationale for the 
subsequently-diluted original idea for including custom 
allocators in the non-GC STL.  I should have thought allocators 
belong in the library because they are rather useful and most of 
us would rather not have to bother to roll our own.


 There's a big advantage in having a coherent compiler-backed 
 memory model and let the compiler optimize transparently based 
 on static analysis, profiling and hints. That's basically what 
 all high level languages should and do aim for.


Ok.  I don't see how the compiler can understand my problem 
domain better than me, especially at compile time.
Jul 14 2015
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 14 July 2015 at 09:05:59 UTC, Laeeth Isharc wrote:

 Good for you!  I am not sure that suggesting people roll their 
 own as needed will be conducive to encouraging the adoption of 
 D for web services - or any other use - though.


I think you got me wrong here.

In general you should do most work on the stack and avoid 
allocations for temporaries.

For long-lived data you should try to condense your data into 
reasonably sized units to avoid fragmenting the heap. If they 
have the same lifetime anyway.

In most cases a good model +  a good malloc implementation is 
sufficient to get decent performance.

Occasionally you might need to preallocate and preinitialize 
objects and have them on a free list.

Even more rarely you need a dedicated allocator (e.g. shared 
memory), and if you need that you probably are capable of writing 
your own in short order or have messed up your data-model.


 That doesn't appear to have been the rationale for the 
 subsequently-diluted original idea for including custom 
 allocators in the non-GC STL.  I should have thought allocators 
 belong in the library because they are rather useful and most 
 of us would rather not have to bother to roll our own.


STL is inflexible, memory fracturing, exception ridden, 
reallocating crap, I only use the most basic features of it 
(arrays). Custom allocators in STL are bloated crap that makes 
writing my own ADT a much better alternative. (I've tried both, 
thank you;)


 Ok.  I don't see how the compiler can understand my problem 
 domain better than me, especially at compile time.


The ideal is: You collect runtime data by profiling, the compiler 
do analysis, you provide metainformation/constraints 
(optimization hints).
Jul 14 2015
prev sibling parent reply "rsw0x" <anonymous anonymous.com> writes:
On Tuesday, 14 July 2015 at 09:05:59 UTC, Laeeth Isharc wrote:

 That doesn't appear to have been the rationale for the 
 subsequently-diluted original idea for including custom 
 allocators in the non-GC STL.  I should have thought allocators 
 belong in the library because they are rather useful and most 
 of us would rather not have to bother to roll our own.


suddenly I feel like std.allocators is going to be heavily abused.
Jul 14 2015
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/14/15 8:16 AM, rsw0x wrote:

 On Tuesday, 14 July 2015 at 09:05:59 UTC, Laeeth Isharc wrote:

 That doesn't appear to have been the rationale for the
 subsequently-diluted original idea for including custom allocators in
 the non-GC STL.  I should have thought allocators belong in the
 library because they are rather useful and most of us would rather not
 have to bother to roll our own.


 suddenly I feel like std.allocators is going to be heavily abused.


I'm missing some context - what abuse are you thinking of? -- Andrei
Jul 14 2015
prev sibling next sibling parent reply "ChangLong" <changlon gmail.com> writes:
On Monday, 13 July 2015 at 10:12:33 UTC, Faux Amis wrote:

 On Mon 13/07/2015 06:29, ChangLong wrote:

 On Sunday, 12 July 2015 at 12:14:31 UTC, Ola Fosheim Grøstad 
 wrote:


 -snip-

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



 I has use vibe.d for a small project recently,  after finish 
 that I
 think the follow fact will
 prevent many programmers use vibe.d in commercial projects:

 1) Lack of successful open source project for real product
 2) Multi thread performance is poor, scalability is not suit 
 for big
 project
 3) No Inversion of Control (aka: Dependency Injection) Concept
 4) No mature ORM/ODM components
 5) No Form/Validator/Translation/Locale Components
 6) No modernize framework

 Some company has successful story in D use no-GC solution, for 
 example:
 Sociomantic,  Hedge Fund by Andy Smith,  weka.io...  And they 
 all are
 close source.

 There are thousands of web projects in development every day,  
 D is not
 use as development languages mainly because D is not ready yet.


 2) I have zero experience with going beyond one thread, but as 
 far as I understand it multi-threading is not how vibe is 
 supposed to scale. Start up another instance will you!


multi instance will help. In my project the vibe.d is slow down 
after I open too much task(reptile network analysis).  Maybe 
LDC/GDC will help, but compare to nodejs or scale, scalability 
still is weakness point for vibe.d.


 3) It has been work-in-progress for some time now:
 http://vibed.org/features#load-balancing
 Not sure what the status of this is though.


load-balancing has nothing to do with Inversion of Control,
check this: https://en.wikipedia.org/wiki/Inversion_of_control



 4) Dunno about that..


ORM https://en.wikipedia.org/wiki/Object-relational_mapping
ODM is like ORM but with non-relation database


 5) Well, there is this:
 https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/utils/validation.d
 and:
 http://vibed.org/docs#web-localization


That is good start.


 6) What is that?


I mean like expressjs/sailsjs for nodejs,  rails for ruby, 
symfony/laravel for php.  vibe.d is not a framework but a 
infrastructure


 In my experience, vibe.d is a beautiful alternative to node.js 
 and it is not the immaturity of D that is holding it back, 
 vibe.d just needs to grow a bit.


Like I said, not ready yet.
Jul 13 2015
parent Faux Amis <faux amis.com> writes:
On Mon 13/07/2015 13:42, ChangLong wrote:

 On Monday, 13 July 2015 at 10:12:33 UTC, Faux Amis wrote:

 On Mon 13/07/2015 06:29, ChangLong wrote:

 On Sunday, 12 July 2015 at 12:14:31 UTC, Ola Fosheim Grøstad wrote:


 -snip-

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



 I has use vibe.d for a small project recently,  after finish that I
 think the follow fact will
 prevent many programmers use vibe.d in commercial projects:

 1) Lack of successful open source project for real product
 2) Multi thread performance is poor, scalability is not suit for big
 project
 3) No Inversion of Control (aka: Dependency Injection) Concept
 4) No mature ORM/ODM components
 5) No Form/Validator/Translation/Locale Components
 6) No modernize framework

 Some company has successful story in D use no-GC solution, for example:
 Sociomantic,  Hedge Fund by Andy Smith,  weka.io...  And they all are
 close source.

 There are thousands of web projects in development every day, D is not
 use as development languages mainly because D is not ready yet.


 2) I have zero experience with going beyond one thread, but as far as
 I understand it multi-threading is not how vibe is supposed to scale.
 Start up another instance will you!


 multi instance will help. In my project the vibe.d is slow down after I
 open too much task(reptile network analysis).  Maybe LDC/GDC will help,
 but compare to nodejs or scale, scalability still is weakness point for
 vibe.d.


 3) It has been work-in-progress for some time now:
 http://vibed.org/features#load-balancing
 Not sure what the status of this is though.


 load-balancing has nothing to do with Inversion of Control,
 check this: https://en.wikipedia.org/wiki/Inversion_of_control


Sorry, I was a bit too quick; thought you were talking about runtime 
code injection.

But I see Sönke is here (to the rescue)!


 4) Dunno about that..


 ORM https://en.wikipedia.org/wiki/Object-relational_mapping
 ODM is like ORM but with non-relation database


 5) Well, there is this:
 https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/utils/validation.d

 and:
 http://vibed.org/docs#web-localization


 That is good start.


 6) What is that?


 I mean like expressjs/sailsjs for nodejs,  rails for ruby,
 symfony/laravel for php.  vibe.d is not a framework but a infrastructure


 In my experience, vibe.d is a beautiful alternative to node.js and it
 is not the immaturity of D that is holding it back, vibe.d just needs
 to grow a bit.


 Like I said, not ready yet.
Jul 13 2015
prev sibling parent reply =?UTF-8?B?Ik3DoXJjaW8=?= Martins" <marcioapm gmail.com> writes:
On Monday, 13 July 2015 at 10:12:33 UTC, Faux Amis wrote:


 In my experience, vibe.d is a beautiful alternative to node.js 
 and it is not the immaturity of D that is holding it back, 
 vibe.d just needs to grow a bit.


My experience has been the opposite. While vibe.d is far from 
complete, in the same sense of completeness as other massive web 
frameworks, most of what's there works as advertised and there 
are no major problems with it. I also like that the vibed 
developers work on making vibed a good framework in general 
instead of working on a "scratching-my-own-itches" basis. Most 
issues with current features get fixed as they are reported, 
which really increases the feeling of quality, and the sense of 
security for it's users.

D is a great language, but in my opinion, it's ecosystem as a 
whole is not mature enough for serious development on a large 
scale.
Jul 13 2015
next sibling parent Faux Amis <faux amis.com> writes:
On Mon 13/07/2015 14:06, "Márcio Martins  <marcioapm gmail.com> wrote:

 On Monday, 13 July 2015 at 10:12:33 UTC, Faux Amis wrote:


 In my experience, vibe.d is a beautiful alternative to node.js and it
 is not the immaturity of D that is holding it back, vibe.d just needs
 to grow a bit.


 My experience has been the opposite. While vibe.d is far from complete,
 in the same sense of completeness as other massive web frameworks, most
 of what's there works as advertised and there are no major problems with
 it. I also like that the vibed developers work on making vibed a good
 framework in general instead of working on a "scratching-my-own-itches"
 basis. Most issues with current features get fixed as they are reported,
 which really increases the feeling of quality, and the sense of security
 for it's users.

 D is a great language, but in my opinion, it's ecosystem as a whole is
 not mature enough for serious development on a large scale.


I hope it grows up together with my project ;)
Jul 13 2015
prev sibling parent "Etienne" <etcimon gmail.com> writes:
On Monday, 13 July 2015 at 12:06:25 UTC, Márcio Martins wrote:

 D is a great language, but in my opinion, it's ecosystem as a 
 whole is not mature enough for serious development on a large 
 scale.


I think it's growing at a fast enough pace now that people can 
feel safe to invest their time and join/contribute to the 
ecosystem. Talking for myself, I like to be part of something 
that grows positively and incrementally where I can make a 
difference. A lot of other communities have many libraries and 
many community members but are stuck on performance/efficiency 
bottlenecks due to language design, nobody has the power to 
change it, and here we are with the solution in vibe.d, where the 
D community in general will probably not see this until decades 
from here.
Jul 13 2015
prev sibling parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 13.07.2015 um 06:29 schrieb ChangLong:

 I has use vibe.d for a small project recently,  after finish that I
 think the follow fact will
 prevent many programmers use vibe.d in commercial projects:

 1) Lack of successful open source project for real product


I don't know of any big front-end product, but it's used for a variety 
of smaller building blocks. Probably it would be a good idea to start 
collecting projects using vibe.d on a sub-page on vibed.org to get some 
mutual marketing boost.


 2) Multi thread performance is poor, scalability is not suit for big
 project


My guess is that this was caused by the GC. In the benchmarks I did, it 
scaled up more or less perfectly, but I was careful to not perform any 
per-request GC allocations there.

Using multi-process scaling may be a viable alternative if your project 
relies on the GC. Or, if the project partially performs CPU intensive 
computations, it may make sense to offload only those computations to 
worker thread, relying purely on async I/O concurrency in the main 
thread for network scaling.


 3) No Inversion of Control (aka: Dependency Injection) Concept


Since this is a broad term, on which level do you miss an explicit 
concept for this? Any concrete example?


 4) No mature ORM/ODM components


This can indeed be an issue. But, even if this isn't a full ORM, at 
least the MongoDB and Redis drivers in vibe.d support direct mapping to 
D types using the serialization module.


 5) No Form/Validator/Translation/Locale Components


See vibe.web.web: http://vibed.org/docs#web-interface-generator

There are still missing bits, but a lot is already there. Please let me 
know of anything particularly useful that is missing.


 6) No modernize framework


I've not heard of that term. Can you explain?
Jul 13 2015
parent reply "ChangLong" <changlon gmail.com> writes:
On Monday, 13 July 2015 at 10:49:16 UTC, Sönke Ludwig wrote:

 Am 13.07.2015 um 06:29 schrieb ChangLong:

 I has use vibe.d for a small project recently,  after finish 
 that I
 think the follow fact will
 prevent many programmers use vibe.d in commercial projects:

 1) Lack of successful open source project for real product


 I don't know of any big front-end product, but it's used for a 
 variety of smaller building blocks. Probably it would be a good 
 idea to start collecting projects using vibe.d on a sub-page on 
 vibed.org to get some mutual marketing boost.


 2) Multi thread performance is poor, scalability is not suit 
 for big
 project


 My guess is that this was caused by the GC. In the benchmarks I 
 did, it scaled up more or less perfectly, but I was careful to 
 not perform any per-request GC allocations there.

 Using multi-process scaling may be a viable alternative if your 
 project relies on the GC. Or, if the project partially performs 
 CPU intensive computations, it may make sense to offload only 
 those computations to worker thread, relying purely on async 
 I/O concurrency in the main thread for network scaling.


Thanks for the tips, for current I run a single thread vibe.d 
application with 20~80% CPU usage, the GC is the major problem 
for me.  I try parse httpclient result and save it in sqlite with 
like 32 task running concurrent.  Before I wrote a similar 
project using nodejs, performance is better


 3) No Inversion of Control (aka: Dependency Injection) Concept


 Since this is a broad term, on which level do you miss an 
 explicit concept for this? Any concrete example?


Like this: 
http://symfony.com/doc/current/book/service_container.html
It is easy to expand services and maintains application with many 
components
And it is also very good for business logic decoupling


 4) No mature ORM/ODM components


 This can indeed be an issue. But, even if this isn't a full 
 ORM, at least the MongoDB and Redis drivers in vibe.d support 
 direct mapping to D types using the serialization module.


I has read MongoDB but not use it yet, thank for the tips.


 5) No Form/Validator/Translation/Locale Components


 See vibe.web.web: http://vibed.org/docs#web-interface-generator


Seems the Translation and Locale is include:)  for Validator/Form 
it can be integration with ORM/ODM module.


 There are still missing bits, but a lot is already there. 
 Please let me know of anything particularly useful that is 
 missing.


 6) No modernize framework


 I've not heard of that term. Can you explain?


I am sorry for my poor english.   I mean like expressjs/sailsjs 
for nodejs,  rails for ruby, symfony/laravel for php.

With a good framework the code is more easier to maintain,  
faster development process, more easier to find and fix bug.  All 
in all, with higher productivity

I know that in practice there are many negative examples of 
excessive dependence on the framework, but IMHO that only prove 
that the developers is not good programmer.

Vibe.d is great progress D has made in web development field. But 
compared to other languages disadvantages are also obvious: The 
use of the small number of small contributors, less community 
members, lake of success example ....
Jul 13 2015
parent reply "Kagamin" <spam here.lot> writes:
On Monday, 13 July 2015 at 12:12:22 UTC, ChangLong wrote:

 3) No Inversion of Control (aka: Dependency Injection) Concept


 Since this is a broad term, on which level do you miss an 
 explicit concept for this? Any concrete example?


 Like this: 
 http://symfony.com/doc/current/book/service_container.html
 It is easy to expand services and maintains application with 
 many components
 And it is also very good for business logic decoupling


There were some attempts at it

http://forum.dlang.org/post/fffrtzrwuwdbjfiprwgi forum.dlang.org
http://forum.dlang.org/post/xqsfpayquptholbfcogf forum.dlang.org
Jul 13 2015
parent "ChangLong" <changlon gmail.com> writes:
On Monday, 13 July 2015 at 15:57:41 UTC, Kagamin wrote:

 On Monday, 13 July 2015 at 12:12:22 UTC, ChangLong wrote:

 3) No Inversion of Control (aka: Dependency Injection) 
 Concept


 Since this is a broad term, on which level do you miss an 
 explicit concept for this? Any concrete example?


 Like this: 
 http://symfony.com/doc/current/book/service_container.html
 It is easy to expand services and maintains application with 
 many components
 And it is also very good for business logic decoupling


 There were some attempts at it

 http://forum.dlang.org/post/fffrtzrwuwdbjfiprwgi forum.dlang.org
 http://forum.dlang.org/post/xqsfpayquptholbfcogf forum.dlang.org


It is what I am looking for, thanks!
Jul 14 2015
prev sibling next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 12-Jul-2015 15:14, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 I've been thinking a bit about where languages fit in the web service
 space. Both mobile app and web services are likely candidates for typed
 and efficient languages. I'm not at all happy with the "prolific"
 choices that are available. Yet, D is currently not in a strong position
 for mobile apps or web servers. So what does the competition look like?


[snip]



 that makes them difficult targets. They all have integration advantages
 not provided by other languages.

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



pressing both out of their segments eventually. That is D is lighter on 

much much simpler/safer to write system code in D then in C++.

So at start D should aim to save people that can't do the thing in say 
Java but are really not looking forward to write it in C/C++.

Still D lacks stable and scalable Web Application server and any 
standard model for web applications (and frameworks) to follow. Be it "D 
Servlet" spec a-la Java or more simple like WSGI in Python/Perl/etc. it 
needs to be there.

Even if vibe.d might become that app server, the problem with D servlet 
spec missing is very real.

-- 
Dmitry Olshansky
Jul 13 2015
prev sibling next sibling parent "Saurabh Das" <saurabh.das gmail.com> writes:
On Sunday, 12 July 2015 at 12:14:31 UTC, Ola Fosheim Grøstad 
wrote:

 I've been thinking a bit about where languages fit in the web 
 service space. Both mobile app and web services are likely 
 candidates for typed and efficient languages. I'm not at all 
 happy with the "prolific" choices that are available. Yet, D is 
 currently not in a strong position for mobile apps or web 
 servers. So what does the competition look like?


<snip>

I've used Vibe.D for a personal project and it looks like a 
strong contender in this space. It is easy to use and absolutely 
no-nonsense, gets straight to the point.

It is not as feature complete as some of the competition, but as 
the community grows, it can get there.
Jul 13 2015
prev sibling parent reply "Sebastiaan Koppe" <mail skoppe.eu> writes:
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)
Jul 14 2015
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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?


It can't fail as long as Walter is having fun working on the 
compiler. :-)


 These come to my mind:

 Tooling
 Marketing
 Talent Pool (companies not willing to adopt)


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 don't think Golang would have a chance to sustain adoption 
without being vocal about focusing on a low latency GC. Right now 

despite oddities.

I don't think Rust would stand a chance without being very clear 
on high level feature set, system level access, single threaded 
friendly with safe cross-thread-exchange linear typing memory 
model. It "sounds" clean. Only C++ is the perceived alternative. 
That's enough to get a surprising number of people to figure out 
how to deal with a rather challenging memory model. Not sure if 
Rust can sustain it, but hey, they might develop "best practice 
patterns" that makes it work...

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.
Jul 14 2015
next sibling parent reply "Sebastiaan Koppe" <mail skoppe.eu> writes:
On Tuesday, 14 July 2015 at 16:25:29 UTC, Ola Fosheim Grøstad 
wrote:

 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?


 It can't fail as long as Walter is having fun working on the 
 compiler. :-)


I meant in web services, not in general.


 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 get what you mean about having a focused direction so that any 
energy/time spend isn't scattered in all directions. I failed 
that in our last startup and we did alot of stuff, but in the end 
everything was half-finished.

But I disagree about 'possible not being good enough'. In fact 
this property gives D the flexibility too accustom to pretty much 
anything.

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).
Jul 14 2015
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 15 July 2015 at 06:57:36 UTC, Sebastiaan Koppe 
wrote:

 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.


Ok, but then you need to focus on integration with at least one 
cloud service, like AWS and have a team that supports it on that 
cloud service. So I think that is starting in the wrong end.

If you have a feature set that makes it easier to support 

some startup will pick it up to gain an advantage and build "the 
next big thing". Then you get several frameworks more quickly 
because you have many hands. And the best ones survive.

If you need a single excellent framework as the main feature... 
then you have lowered your odds.


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


I am now writing in Go, despite the language feeling odd and less 
familiar than D, because:

1. I want a statically typed language to deal with increased 
complexity (but not if it means more work overall than using 
Python, on more servers).

2.  Google have announced that they have a low latency GC, so I 
feel confident that responsiveness is going to be OK and I don't 
have to deal with memory management at all.

3. Google are supporting it on their infrastructure, so I know it 
will interact well with Google Cloud and I don't have to worry 
about APIs.

4. There are web related 3rd party commercially supported 
libraries for interacting with commercial services. (Like Stripe 
for credit cards)

I don't think vibe.d can build this eco system. I think you need 
a feature set that makes some startup want to build their _own_ 
public available framework using D for good PR. Docker is 
basically what made Microsoft embrace Go AFAIK.
Jul 15 2015
prev sibling next sibling parent "Brian Rogoff" <brogoff gmail.com> writes:
On Wednesday, 15 July 2015 at 06:57:36 UTC, Sebastiaan Koppe 
wrote:

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


I think a lot of people do care about GC, and the D story there 
(problematic conservative GC used in libraries, with exceptions, 
etc.) is worse than the Go story (precise, concurrent, low 
latency GC with improvements planned) or the Rust story (no GC, 
like C++ but much safer).

There was some noise about a precise GC for D two years ago, with 
one poster claiming he'd write one over a summer, but nothing 
happened. Then the Higgs author posted her problems with GC here 
http://pointersgonewild.com/2014/09/09/ds-garbage-collector-problem/ and there
is still this perception in the world that GC is a problem with D.
Jul 15 2015
prev sibling parent "karabuta" <karabutaworld gmail.com> writes:
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 :)
Aug 13 2015
prev sibling next sibling parent reply "rsw0x" <anonymous anonymous.com> writes:
On Tuesday, 14 July 2015 at 16:25:29 UTC, Ola Fosheim Grøstad 
wrote:

 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.


I actuallly don't think low latency GCs are that great for 
gamedev because they not only have far lower throughput, but 
reduce the overall performance of the application.

They're great for e.g, networking where throughput and maximum 
performance really isn't a big deal but low latency is.

A high throughput GC that could complete in a few frames would 
probably be better, IMO.
Jul 15 2015
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 15 July 2015 at 08:43:53 UTC, rsw0x wrote:

 I actuallly don't think low latency GCs are that great for 
 gamedev because they not only have far lower throughput, but 
 reduce the overall performance of the application.


What I meant was:

1. Low latency GC are good for responsive web services that keep 
evolving over time. Makes development easy.

2. Linear typing is good for  focused low memory 
usage/computational demanding web services.  Makes memory related 
mistakes difficult/impossible.

It will probably take years to work either alternative into D. 
Thus:

3. A simpler memory model (like C++) is more realistic, but not 
really attractive for a web service as it is less robust. Yet, 
many game devs are used to it.

So maybe Weaselcat is right in saying that gamedev is the better 
"sizeable market" that D could aim for.

That was my point ;)


 A high throughput GC that could complete in a few frames would 
 probably be better, IMO.


Yes, I think one only need a local GC for gameworld 
objects/NPCs/AI/scripting, so a GC could be limited to a specific 
graph/allocator right after execution when the memory is hot 
(programmer guaranteeing that there are no unregistered external 
pointers). It could indeed complete quickly for many game worlds.
Jul 15 2015
prev sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Wednesday, 15 July 2015 at 08:43:53 UTC, rsw0x wrote:

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

 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.


 I actuallly don't think low latency GCs are that great for 
 gamedev because they not only have far lower throughput, but 
 reduce the overall performance of the application.

 They're great for e.g, networking where throughput and maximum 
 performance really isn't a big deal but low latency is.

 A high throughput GC that could complete in a few frames would 
 probably be better, IMO.


Games are much more than the code runs in a games console.


server side and engine tools.

Just like in the 80's Basic, C and Pascal were used for tools 
while real game code was Assembly.
Jul 15 2015
parent reply "rsw0x" <anonymous anonymous.com> writes:
On Wednesday, 15 July 2015 at 10:54:04 UTC, Paulo  Pinto wrote:

 On Wednesday, 15 July 2015 at 08:43:53 UTC, rsw0x wrote:

 [...]


 Games are much more than the code runs in a games console.


 server side and engine tools.

 Just like in the 80's Basic, C and Pascal were used for tools 
 while real game code was Assembly.


I was referring only to the actual client code where C++ is 
typically used now.
Jul 15 2015
parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Wednesday, 15 July 2015 at 10:57:55 UTC, rsw0x wrote:

 On Wednesday, 15 July 2015 at 10:54:04 UTC, Paulo  Pinto wrote:

 On Wednesday, 15 July 2015 at 08:43:53 UTC, rsw0x wrote:

 [...]


 Games are much more than the code runs in a games console.


 the server side and engine tools.

 Just like in the 80's Basic, C and Pascal were used for tools 
 while real game code was Assembly.


 I was referring only to the actual client code where C++ is 
 typically used now.


Ah ok, sorry for the noise then.
Jul 15 2015
prev sibling parent "karabuta" <karabutaworld gmail.com> writes:
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++).
Aug 13 2015
prev sibling parent "karabuta" <karabutaworld gmail.com> writes:
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!
Aug 13 2015