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.


C# plays in the same category as Java, with the additional 
"Microsoft" taint (for good and bad).

- Like Java, C# is for those who need integration with 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.

  Java, C# and now Go seems to have strong infrastructure 
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. Windows desktop => Mostly C#. Some C++ and C++/CX. Hadoop => Java Android => Java JSF => Java Sharepoint => C# .... 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.
Well, there is Xamarin C#. And any scripting langauge once you fit a VM in Objective-C (superset of plain C). LUA is quite popular.
 Windows desktop => Mostly C#. Some C++ and C++/CX.

 Hadoop => Java

 Android => Java

 JSF => Java
JVM more preciesly I think.
 Sharepoint => C#

 ....

 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.
Well, there is Xamarin C#. And any scripting langauge once you fit a VM in Objective-C (superset of plain C). LUA is quite popular.
 Windows desktop => Mostly C#. Some C++ and C++/CX.

 Hadoop => Java

 Android => Java

 JSF => Java
JVM more preciesly I think.
 Sharepoint => C#

 ....

 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.
Two examples which I was involved with, but with C#. One is an application for live visualization of digital microscopes like these ones. http://www.leica-microsystems.com/products/digital-microscopes/ WPF application coded in C#, with bits of unsafe for image 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 progressively replaced by C# code. 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 tricks at C# level or driver related work. -- 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 you can do easily in Java/C#/Swift/Javascript are going to be written in those languages for _very_ good reasons. I would too. If desktop applications are a target then you need a feature set that makes it easier to write those applications that are difficult to do well in Java/C#/Swift/Javascript. That makes you an attractive platform for new application frameworks.
 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 applications you can do easily in Java/C#/Swift/Javascript are going to be written in those languages for _very_ good reasons. I would too. If desktop applications are a target then you need a feature set that makes it easier to write those applications that are difficult to do well in Java/C#/Swift/Javascript. That makes you an attractive platform for new application frameworks.
An attractive platform is which gets the job done, not the best one, which doesn't actually exist (if it existed, there wouldn't be a list of options). And it's not like D has nothing to show, one must consider requirements for his task to decide which tool to choose and there's no single answer that suits everyone.
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.


 C# plays in the same category as Java, with the additional "Microsoft"
 taint (for good and bad).

 - Like Java, C# is for those who need integration with 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.

   Java, C# and now Go seems to have strong infrastructure 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?
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.


 C# plays in the same category as Java, with the additional 
 "Microsoft" taint (for good and bad).

 - Like Java, C# is for those who need integration with 
 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.

  Java, C# and now Go seems to have strong infrastructure 
 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]
   Java, C# and now Go seems to have strong infrastructure 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?
IMHO D should fit right in between C++/Rust and Java/C# hopefully pressing both out of their segments eventually. That is D is lighter on resources and has greater control then C#/Java will ever have. And it's 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 only Java/C# are typed alternatives. That makes Go pretty strong 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 products using D than Rust/Go/Java/C# in a specific domain, then 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. Modern game development makes use of C#, Java and Erlang on 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.
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. Modern game development makes use of C#, Java and Erlang on 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.
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. Modern game development makes use of C#, Java and Erlang on 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