Re: Where will D sit in the web service space?
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).
Re: Where will D sit in the web service space?
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.
Re: Where will D sit in the web service space?
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.
Re: Where will D sit in the web service space?
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... :)
Re: Where will D sit in the web service space?
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).
Re: Where will D sit in the web service space?
On 08/13/2015 10:35 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= " 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.
Re: Where will D sit in the web service space?
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.
Re: Where will D sit in the web service space?
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?
Re: Where will D sit in the web service space?
On Thursday, 16 July 2015 at 13:34:32 UTC, Ola Fosheim Grøstad wrote: If you go node.js, you get static typing with typescript if you want + same language on the browser, debuggable. If you go Dart you get static typing if you want + same language the browser, debuggable. Oh! someone thinks typescript is a programming language. Typescript runs in which browser? :) (Because when I use typescript, I worry about two things in my development process, .js and .ts)
Re: Where will D sit in the web service space?
On Tuesday, 14 July 2015 at 16:25:29 UTC, Ola Fosheim Grøstad wrote: I think neither, but what I have alluded to in this thread. A lack of decision making regarding picking an application domain that is large enough to sustain an ecosystem of libraries, and going 100% for honing the feature set towards that domain. "Possible" is not good enough. I think the rest comes when you have the best feature set for a particular domain and a polished compiler/runtime. So yeah, maybe Game clients is the best bet, since you don't have to change the semantics too much (low latency GC and linear typing would take time to work in) and games benefits from C++/iOS interop. Indie games have low adoption threshold and could work as marketing. The Gaming industry is quiet a path to go on. Expecially since no language actually focus on that area. For now, I see some new projects making good moves to writing gaming tools (I dislike bindings to C++).
Re: Where will D sit in the web service space?
On Wednesday, 15 July 2015 at 06:57:36 UTC, Sebastiaan Koppe wrote: When I think about Web services and D, I don't think about just repeating what people do in other languages, but more about anticipating the future in web services. With my humble knowledge of the field that would be something with micro services and containers. If D can do something cool with that, e.g. a web application framework where services sit behind a vibe-d web server, and where they can be easily developed, tested, deployed and upgraded - with 0 downtime - that would be great. Combine it with a knowledgeable community and some good practices (e.g. 12factor apps) and you can have a honey-pot. I don't think people care as much about the other stuff (gc, etc). Yeah, no one cares about GC considering the benefits and uplifted burden :)
Re: Where will D sit in the web service space?
On Tuesday, 14 July 2015 at 15:17:13 UTC, Sebastiaan Koppe wrote: On Sunday, 12 July 2015 at 12:14:31 UTC, Ola Fosheim Grøstad wrote: What do you think about the future for D in the web service space? What about this question: in 5 years from now what would be the reason D failed? These come to my mind: Tooling Marketing Talent Pool (companies not willing to adopt) That is not going to happen. Maturity is the priority here. After that, boom!
Re: Where will D sit in the web service space?
On Wednesday, 12 August 2015 at 22:17:11 UTC, rsw0x wrote: Rust is also backed by a major organization. I(and others from what it seemed) was hoping Facebook using D internally and hiring major D developers would have Facebook promote/champion D a bit, but this did not happen. D needs a major corporation to champion it. Yes, well. Java caught on because it was heavily marketed as THE web-programming language by SUN. That might not be how it is used today, but that is what got it attention and traction. C++ was essentially a cost-free upgrade for existing C-code bases that provided more scalable abstraction mechanisms. So C++/OO was heavily pushed by magazines as the next big thing (this was before templates). Maybe you need an organization, not sure. If it is commercial then people might not want to contribute so it can work both ways. I think people have been quite reluctant to jump in on Google-owned open source projects. Mozilla is perceived as a non-profit, so it's good. So, I think being the best tool in your domain makes people more inclined to contribute. It makes business sense to improve the tooling you use in production. Most languages that are "recognized as serious" had a domain where they were perceived as the only good option when they got picked up: - C++ had existing C code bases as their domain. - Java had the web as their domain. - Ada had government contractors as their domain. - Javascript had browsers as their domain. - Lua had game scripting as the domain. - Delphi had rapid prototyping/development as a domain. - Haskell had language research as the domain. etc.
Re: Where will D sit in the web service space?
On 13/08/2015 10:17 a.m., rsw0x wrote: On Wednesday, 12 August 2015 at 22:10:18 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 12 August 2015 at 21:16:28 UTC, karabuta wrote: Not long ago, C++ was the perfect programming language that everybody was running to. Then came ~ Java, Well, C++ was never considered a good language by anyone. It was shunned at universities by lecturers. Java was basically Simula67 with a different syntax and some adjustments. But the demand of the past shifted to the web and now the worst p. language rules the web (Sorry if you love JS too much but there is too much bugs). Now we are stuck in it, who knows until when before the world rushes to a new domain. I am actually starting to kinda like TypeScript 1.5… And next gen EcmaScript will have comprehensions… maturing, and I see it maturing like gold. When D grows up (even though it is doing powerful things in its infancy), you and I will appreciate that it did not rush into any domain. The contributor list to Rust1.2 claims 180 people were involved... http://blog.rust-lang.org/2015/08/06/Rust-1.2.html If you focus on a domain more people will have a significant interest in making it work better. Rust is also backed by a major organization. I(and others from what it seemed) was hoping Facebook using D internally and hiring major D developers would have Facebook promote/champion D a bit, but this did not happen. D needs a major corporation to champion it. Even so, D at Facebook is like D kinda still in it's infancy. Anyway. Do we really want newbies who think OOP is the best thing since sliced bread to come and try D out just because Facebook is using it?
Re: Where will D sit in the web service space?
On Wednesday, 12 August 2015 at 22:10:18 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 12 August 2015 at 21:16:28 UTC, karabuta wrote: Not long ago, C++ was the perfect programming language that everybody was running to. Then came ~ Java, Well, C++ was never considered a good language by anyone. It was shunned at universities by lecturers. Java was basically Simula67 with a different syntax and some adjustments. But the demand of the past shifted to the web and now the worst p. language rules the web (Sorry if you love JS too much but there is too much bugs). Now we are stuck in it, who knows until when before the world rushes to a new domain. I am actually starting to kinda like TypeScript 1.5… And next gen EcmaScript will have comprehensions… maturing, and I see it maturing like gold. When D grows up (even though it is doing powerful things in its infancy), you and I will appreciate that it did not rush into any domain. The contributor list to Rust1.2 claims 180 people were involved... http://blog.rust-lang.org/2015/08/06/Rust-1.2.html If you focus on a domain more people will have a significant interest in making it work better. Rust is also backed by a major organization. I(and others from what it seemed) was hoping Facebook using D internally and hiring major D developers would have Facebook promote/champion D a bit, but this did not happen. D needs a major corporation to champion it.
Re: Where will D sit in the web service space?
On Wednesday, 12 August 2015 at 21:16:28 UTC, karabuta wrote: Not long ago, C++ was the perfect programming language that everybody was running to. Then came ~ Java, Well, C++ was never considered a good language by anyone. It was shunned at universities by lecturers. Java was basically Simula67 with a different syntax and some adjustments. But the demand of the past shifted to the web and now the worst p. language rules the web (Sorry if you love JS too much but there is too much bugs). Now we are stuck in it, who knows until when before the world rushes to a new domain. I am actually starting to kinda like TypeScript 1.5… And next gen EcmaScript will have comprehensions… maturing, and I see it maturing like gold. When D grows up (even though it is doing powerful things in its infancy), you and I will appreciate that it did not rush into any domain. The contributor list to Rust1.2 claims 180 people were involved... http://blog.rust-lang.org/2015/08/06/Rust-1.2.html If you focus on a domain more people will have a significant interest in making it work better.
Re: Where will D sit in the web service space?
On Monday, 13 July 2015 at 07:11:35 UTC, Ola Fosheim Grøstad wrote: On Sunday, 12 July 2015 at 19:02:23 UTC, Brad Anderson wrote: I'd consider D a failure if it couldn't fill both of these roles. D is a general purpose systems programming language. It doesn't and shouldn't care about what you are using it for. There is plenty of overlap in what you need for high performance web backends and high performance gamedev. Here's the deal: there is no such thing as a general purpose (system) language in the empirical sense. We might have been lead to believe that C or C++ were general purpose, but that only happend because there were no visible viable alternatives. C is more and more becoming a kernel/embedded language, C++ is more and more becoming a legacy/niche language. C++ is only a game dev language after you add various extensions (e.g. simd). It is only a number-crunching language after you add some other extensions. So you need a direction in the feature set towards an application area. When you get new languages that cut down on development time (like Rust and Go) the C/C++ application domain will leak over to those niches based on the desired feature set. But the feature set needs to be complete for that application area (e.g. GC with the right characteristics, inlining/simd, GPU programming etc). D needs to complete the feature set for some sizeable domain in order to compete in this emerging market of "many languages" (thanks to LLVM). Not long ago, C++ was the perfect programming language that everybody was running to. Then came ~ Java, What I am saying is people do not know what they want at times. They get up everyday and they have a new idea on what D should be. Follow such comments and you will make some bad decisions. Currently, we are in a world where p. languages are driven by the demands of today. Who knew that JavaScipt will become the language for the web? But the demand of the past shifted to the web and now the worst p. language rules the web (Sorry if you love JS too much but there is too much bugs). Now we are stuck in it, who knows until when before the world rushes to a new domain. Now back to D: The absence of certain tools and frameworks does not mean D is not picking up (not catching interests). The language is still maturing, and I see it maturing like gold. When D grows up (even though it is doing powerful things in its infancy), you and I will appreciate that it did not rush into any domain. With extensions, D can fit in any domain and this obviously takes time. I am so tired(:>;) of seeing them (rust, Go, Pony, Cat, ..) everywhere, if one thinks rust rust OR JavaScript is the language they are planing to use for your next record-breaking kernel, . Because D cannot be them all. The comparison war a bad chakra
Re: Where will D sit in the web service space?
On Sunday, 12 July 2015 at 18:53:35 UTC, weaselcat wrote: On Sunday, 12 July 2015 at 17:54:02 UTC, Ola Fosheim Grøstad wrote: On Sunday, 12 July 2015 at 12:32:32 UTC, Peter Alexander wrote: [...] Mostly because there is no real visible direction towards making D a competitor that directly addresses specific needs of web programming. [...] And suckerpunch everyone that has zero interest in a web language? There's how many mature web languages? 10? 20? Why not dedicate D as a game programming language, am area that is completely untouched? +3000
Re: Where will D sit in the web service space?
On Saturday, 25 July 2015 at 14:49:36 UTC, David Nadlinger wrote: Why would that be so? You can still e.g. keep vector instructions in the IR and specialize according to the actual hardware width when you generate the binary. You have several rather peculiar SIMD instructions that reflect the specifics of the CPU pipeline that can shave off quite a few cycles for specific algorithms. Different CPUs have different penalties for alignments, ARM can do rather well with misalignments. Different CPUs have different primitives, e.g. on ARM complex functions like sincos can be broken down into simpler primitives, so you can do less exact calculations (fewer iterations than on x86).
Re: Where will D sit in the web service space?
On Saturday, 25 July 2015 at 14:35:18 UTC, Ola Fosheim Grøstad wrote: On Saturday, 25 July 2015 at 14:20:28 UTC, Joakim wrote: The IR is only for Apple, they're still compiling it and distributing ASM to the device. Yes, but if they go down that road it means you cannot target SIMD instructions. So you cannot get serious performance. Most apps do not care about "serious performance" from SIMD, as you yourself pointed out. But if they can get good performance from native languages, that is worth it.
Re: Where will D sit in the web service space?
On Saturday, 25 July 2015 at 14:35:18 UTC, Ola Fosheim Grøstad wrote: Yes, but if they go down that road it means you cannot target SIMD instructions. Why would that be so? You can still e.g. keep vector instructions in the IR and specialize according to the actual hardware width when you generate the binary. — David
Re: Where will D sit in the web service space?
On Saturday, 25 July 2015 at 14:20:28 UTC, Joakim wrote: The IR is only for Apple, they're still compiling it and distributing ASM to the device. Yes, but if they go down that road it means you cannot target SIMD instructions. So you cannot get serious performance.
Re: Where will D sit in the web service space?
On Saturday, 25 July 2015 at 08:00:32 UTC, Ola Fosheim Grøstad wrote: On Saturday, 25 July 2015 at 07:18:23 UTC, Joakim wrote: Given the trend towards native/AoT compilation and that Dart doesn't fit in, I don't see it. I have no idea, it is all about tooling, ease of development and end user experience. And iOS appears to be moving away from ASM and towards using an intermediate representation that is hardware independent. So not a strict trend towards native. The trend over the past 5 years appears to be going towards vendor specific solutions. The IR is only for Apple, they're still compiling it and distributing ASM to the device.
Re: Where will D sit in the web service space?
On Saturday, 25 July 2015 at 07:18:23 UTC, Joakim wrote: In fact, I now see that Apple announced that they will be contributing a linux port when they open-source it later this year, so it won't even be tied to Apple's platform soon. GNUStep has existed for decades. And gone nowhere. What does that have to do with Swift getting a linux port? It's a lot easier to port and reuse a programming language than something like GNUStep. I somehow doubt that anyone outside those already using Objective-C/Foundation will pick up Swift. Time will show. As your subsequent posts show, it can easily be made to be almost as fast as C++, since it's a native language. Well, those were not obvious tweaks in my book. Maybe Swift will improve in the future, I don't know. For apps that are mostly GUI code, this may be true. Still, google felt Java itself was enough of a bottleneck that they switched it from JIT compilation to AoT. It did at least save them some memory and start up/warm-up time? cross-platform. Since the native GUIs can always be called from other languages, you could simply design a different GUI for each platform, by calling the native GUI APIs from one non-default language, say D, and use that same non-default language for all non-GUI code. Yes, people do that. Anyway, your point seems to be that native mobile is only taking off for superficial GUI reasons, but this ignores the fact that every mobile platform moved from higher-level and less efficient languages to lower-level native languages over time, from iOS's initial web sdk that was quickly ditched for Obj-C to the recent move by google to AoT-compile all the Java apps since Android 5. I guess they all did this for no reason at all. All I really can say is that many scripting languages are fast enough for the typical logic you need in a regular mobile app... But both Google/Apple need a lock-in strategy to get unique apps on their platform. What killed Mosync as a project was IMHO the diverging GUIs and the competing cross platform solutions based on scripting-languages. Performance? Arguable, for apps that are mostly GUI code. Battery life? No way. Few developers care about battery life when the app is actively used. It's not like end users will say "When I use the weather app my battery gets drained faster". What matters are things like not doing frequent work when the app is idle. Now, vendors might care and have many reasons for pushing their own platform. Given the trend towards native/AoT compilation and that Dart doesn't fit in, I don't see it. I have no idea, it is all about tooling, ease of development and end user experience. And iOS appears to be moving away from ASM and towards using an intermediate representation that is hardware independent. So not a strict trend towards native. The trend over the past 5 years appears to be going towards vendor specific solutions.
Re: Where will D sit in the web service space?
On Saturday, 25 July 2015 at 06:21:50 UTC, Ola Fosheim Grøstad wrote: On Saturday, 25 July 2015 at 03:44:23 UTC, Joakim wrote: No, Swift is already general-purpose because it isn't highly optimized for a single purpose or feature and it's a fairly low-level native language which could be used to write everything from hardware drivers to webapps. Hardware drivers? Why not? If you can get FFT within 10% of C++, you could probably disable ARC, turn off dynamic dispatch, and write something reasonably fast. It is a native language after all, just like D. In fact, I now see that Apple announced that they will be contributing a linux port when they open-source it later this year, so it won't even be tied to Apple's platform soon. GNUStep has existed for decades. And gone nowhere. What does that have to do with Swift getting a linux port? It's a lot easier to port and reuse a programming language than something like GNUStep. As for Apple's "subconscious gratifications," considering I bought my first and last Apple product, a Powerbook G4, a decade ago and would never buy any of their products since, because of their crazy patent stance, that certainly doesn't describe me. Ola brought up Swift as some sort of exception to the "general-purpose native languages on mobile" trend and I'm simply pointing out that's not true. http://www.primatelabs.com/blog/2014/12/swift-performance/ Swift is 24x slower than C++ for FFT… As your subsequent posts show, it can easily be made to be almost as fast as C++, since it's a native language. Standard apps on Android, iOS and in browsers rely heavily upon the builtin rendering/animation engines of their platforms (written in C/C++). The bottleneck for Javascript apps on mobile is the animation engine and emulating the native GUI. For the vast majority of apps Javascript itself performs well enough. For apps that are mostly GUI code, this may be true. Still, google felt Java itself was enough of a bottleneck that they switched it from JIT compilation to AoT. For many mobile apps 80% of the code is GUI code. That means you pay a high price for not using the default language and TOOLING for the platform. As I've pointed out cross platform GUI is no longer a realistic option since the Apple/Google have differentiated their GUIs on purpose in order to make it harder. Even if 80% is GUI code, the remaining 20% can slow you down. You don't have to use the default language and tooling in order to call the native GUI APIs, as you yourself pointed out with your MoSync example. As for cross-platform GUIs, an app's GUI doesn't need to be the _same_ across platforms in order to be cross-platform. Since the native GUIs can always be called from other languages, you could simply design a different GUI for each platform, by calling the native GUI APIs from one non-default language, say D, and use that same non-default language for all non-GUI code. That way, you save some re-implementation time in each default platform language for the non-GUI code, at least. Anyway, your point seems to be that native mobile is only taking off for superficial GUI reasons, but this ignores the fact that every mobile platform moved from higher-level and less efficient languages to lower-level native languages over time, from iOS's initial web sdk that was quickly ditched for Obj-C to the recent move by google to AoT-compile all the Java apps since Android 5. I guess they all did this for no reason at all. From a performance perspective you could probably do most mobile apps in Javascript/V8 with no noticeable impact. Performance? Arguable, for apps that are mostly GUI code. Battery life? No way. Btw, Dart has picked up the null-related-operators from Swift. It also has async syntax sugar over Futures. It might eventually be positioned as a mobile language for Android, through Sky SDK and Material Design widgets. Given the trend towards native/AoT compilation and that Dart doesn't fit in, I don't see it.
Re: Where will D sit in the web service space?
On Saturday, 25 July 2015 at 06:54:09 UTC, Paulo Pinto wrote: On Saturday, 25 July 2015 at 06:27:29 UTC, Ola Fosheim Grøstad wrote: On Saturday, 25 July 2015 at 06:24:57 UTC, Ola Fosheim Grøstad wrote: On Saturday, 25 July 2015 at 06:21:50 UTC, Ola Fosheim Grøstad wrote: Swift is 24x slower than C++ for FFT… http://www.primatelabs.com/blog/2015/02/swift-performance-updated/ With some optimizations it is now down to… 10x the execution time of C++... Nnngh, typo. With latest version of Swift it is down to 10x the execution time and with careful programmer optimizations that more or less sidesteps the default semantics you can get within 10%. Already outdated given the performance improvements in Swift 2.0 toolchain. I think those are <20%? Or? https://github.com/vsco/swift-benchmarks
Re: Where will D sit in the web service space?
On Saturday, 25 July 2015 at 06:27:29 UTC, Ola Fosheim Grøstad wrote: On Saturday, 25 July 2015 at 06:24:57 UTC, Ola Fosheim Grøstad wrote: On Saturday, 25 July 2015 at 06:21:50 UTC, Ola Fosheim Grøstad wrote: Swift is 24x slower than C++ for FFT… http://www.primatelabs.com/blog/2015/02/swift-performance-updated/ With some optimizations it is now down to… 10x the execution time of C++... Nnngh, typo. With latest version of Swift it is down to 10x the execution time and with careful programmer optimizations that more or less sidesteps the default semantics you can get within 10%. Already outdated given the performance improvements in Swift 2.0 toolchain.
Re: Where will D sit in the web service space?
On Saturday, 25 July 2015 at 06:24:57 UTC, Ola Fosheim Grøstad wrote: On Saturday, 25 July 2015 at 06:21:50 UTC, Ola Fosheim Grøstad wrote: Swift is 24x slower than C++ for FFT… http://www.primatelabs.com/blog/2015/02/swift-performance-updated/ With some optimizations it is now down to… 10x the execution time of C++... Nnngh, typo. With latest version of Swift it is down to 10x the execution time and with careful programmer optimizations that more or less sidesteps the default semantics you can get within 10%.
Re: Where will D sit in the web service space?
On Saturday, 25 July 2015 at 03:44:23 UTC, Joakim wrote: No, Swift is already general-purpose because it isn't highly optimized for a single purpose or feature and it's a fairly low-level native language which could be used to write everything from hardware drivers to webapps. Hardware drivers? In fact, I now see that Apple announced that they will be contributing a linux port when they open-source it later this year, so it won't even be tied to Apple's platform soon. GNUStep has existed for decades. And gone nowhere. As for Apple's "subconscious gratifications," considering I bought my first and last Apple product, a Powerbook G4, a decade ago and would never buy any of their products since, because of their crazy patent stance, that certainly doesn't describe me. Ola brought up Swift as some sort of exception to the "general-purpose native languages on mobile" trend and I'm simply pointing out that's not true. http://www.primatelabs.com/blog/2014/12/swift-performance/ Swift is 24x slower than C++ for FFT… Standard apps on Android, iOS and in browsers rely heavily upon the builtin rendering/animation engines of their platforms (written in C/C++). The bottleneck for Javascript apps on mobile is the animation engine and emulating the native GUI. For the vast majority of apps Javascript itself performs well enough. For many mobile apps 80% of the code is GUI code. That means you pay a high price for not using the default language and TOOLING for the platform. As I've pointed out cross platform GUI is no longer a realistic option since the Apple/Google have differentiated their GUIs on purpose in order to make it harder. From a performance perspective you could probably do most mobile apps in Javascript/V8 with no noticeable impact. Btw, Dart has picked up the null-related-operators from Swift. It also has async syntax sugar over Futures. It might eventually be positioned as a mobile language for Android, through Sky SDK and Material Design widgets.
Re: Where will D sit in the web service space?
On Saturday, 25 July 2015 at 06:21:50 UTC, Ola Fosheim Grøstad wrote: Swift is 24x slower than C++ for FFT… http://www.primatelabs.com/blog/2015/02/swift-performance-updated/ With some optimizations it is now down to… 10x the execution time of C++...
Re: Where will D sit in the web service space?
On Friday, 24 July 2015 at 17:22:14 UTC, Etienne wrote: On Friday, 24 July 2015 at 16:57:04 UTC, Joakim wrote: On Friday, 24 July 2015 at 14:50:23 UTC, Ola Fosheim Grøstad wrote: ART. Of course Metal isn't general-purpose, nobody said it is, but I don't see why you'd say Swift isn't. Swift is clearly designed around Objective-C and Cocoa. Oh, and I didn't respond to this because I didn't even know what you meant, think I got it now. You're now saying Swift isn't general-purpose simply because it's initially designed around Apple's Cocoa OS APIs? Being tied to a single platform doesn't make a language any less general-purpose, and since they announced that they're open-sourcing Swift later this year, it will be ported to other platforms, just as Obj-C has. Apple has become such a taboo subject. They've invested so much on subconscious gratifications that nobody can discuss the company objectively. I mean, Swift is general purpose because the holy masters of computer culture "want" to open source it, and open source can become general purpose, right? Eh.. No, Swift is already general-purpose because it isn't highly optimized for a single purpose or feature and it's a fairly low-level native language which could be used to write everything from hardware drivers to webapps. In fact, I now see that Apple announced that they will be contributing a linux port when they open-source it later this year, so it won't even be tied to Apple's platform soon. As for Apple's "subconscious gratifications," considering I bought my first and last Apple product, a Powerbook G4, a decade ago and would never buy any of their products since, because of their crazy patent stance, that certainly doesn't describe me. Ola brought up Swift as some sort of exception to the "general-purpose native languages on mobile" trend and I'm simply pointing out that's not true.
Re: Where will D sit in the web service space?
On 7/24/15 9:57 AM, Joakim wrote: On Friday, 24 July 2015 at 14:50:23 UTC, Ola Fosheim Grøstad wrote: ART. Of course Metal isn't general-purpose, nobody said it is, but I don't see why you'd say Swift isn't. Swift is clearly designed around Objective-C and Cocoa. Oh, and I didn't respond to this because I didn't even know what you meant, think I got it now. You're now saying Swift isn't general-purpose simply because it's initially designed around Apple's Cocoa OS APIs? Being tied to a single platform doesn't make a language any less general-purpose, and since they announced that they're open-sourcing Swift later this year, it will be ported to other platforms, just as Obj-C has. I've been doing a lot of Swift programming recently, and here are my impressions: Yes, it's heavily designed around Objective-C and Cocoa, but it's a nice language on its own. It feels like the designers are working for an all-Swift future, and are discarding some Objective-C/Cocoa-isms along the way. As for the language itself I really like the syntax and many of the constructs. The nil/non-nil typing tends to intrude a bit too often for my liking (like D's const does but more pervasive). And I miss the things that D lets me do, particularly its fantastic metaprogramming and ability to go low-level. I don't love Swift like I love D, but it's a nice language to work with.
Re: Where will D sit in the web service space?
On Friday, 24 July 2015 at 16:57:04 UTC, Joakim wrote: On Friday, 24 July 2015 at 14:50:23 UTC, Ola Fosheim Grøstad wrote: ART. Of course Metal isn't general-purpose, nobody said it is, but I don't see why you'd say Swift isn't. Swift is clearly designed around Objective-C and Cocoa. Oh, and I didn't respond to this because I didn't even know what you meant, think I got it now. You're now saying Swift isn't general-purpose simply because it's initially designed around Apple's Cocoa OS APIs? Being tied to a single platform doesn't make a language any less general-purpose, and since they announced that they're open-sourcing Swift later this year, it will be ported to other platforms, just as Obj-C has. Apple has become such a taboo subject. They've invested so much on subconscious gratifications that nobody can discuss the company objectively. I mean, Swift is general purpose because the holy masters of computer culture "want" to open source it, and open source can become general purpose, right? Eh..
Re: Where will D sit in the web service space?
On Friday, 24 July 2015 at 14:50:23 UTC, Ola Fosheim Grøstad wrote: ART. Of course Metal isn't general-purpose, nobody said it is, but I don't see why you'd say Swift isn't. Swift is clearly designed around Objective-C and Cocoa. Oh, and I didn't respond to this because I didn't even know what you meant, think I got it now. You're now saying Swift isn't general-purpose simply because it's initially designed around Apple's Cocoa OS APIs? Being tied to a single platform doesn't make a language any less general-purpose, and since they announced that they're open-sourcing Swift later this year, it will be ported to other platforms, just as Obj-C has.
Re: Where will D sit in the web service space?
On Friday, 24 July 2015 at 15:06:31 UTC, Ola Fosheim Grøstad wrote: On Friday, 24 July 2015 at 14:55:59 UTC, Joakim wrote: So Obj-C/Swift aren't as efficient as C/C++, but nobody is using those as the main language on any mobile platform- for very good reasons, including that nobody other than game developers wants to deal with them- and as native languages, Obj-C and Swift are still much more efficient than the JIT-ed or interpreted, non-native languages, which is why Android finally switched from JIT-ing Java to AoT/native compilation recently. People have used C++ for both native mobile development (symbian?) and for cross-platform development (e.g. mosync). Symbian is dead, therefore "nobody is using" it. As for MoSync, they went out of business a couple years ago and their toolkit is no longer maintained, nor was it ever the "main language" on any platform. However Android and iOS deliberately set out to kill off cross-platform development a few years ago by making GUI kits incompatible and tool-based. So writing GUIs in other languages than Obj-C/Java became tedious. I don't think that's the reason, as their GUI APIs can be called from other languages, Java is fairly cross-platform, and the Android GUI is open source and can always be ported, as it has been. Perhaps nobody has bothered to build a single GUI toolkit that normalizes across the GUI APIs of each OS, but that doesn't mean it can't be done. I found it much easier to use Mosync-C++ than Objective-C, to be honest. But it is now a dead technology. What does this have to do with the original point, which is that native/AoT-compiled languages are having a resurgence on mobile? You made the point that some native languages are more efficient than others, which is irrelevant when they are all much more efficient than the non-native languages.
Re: Where will D sit in the web service space?
On Friday, 24 July 2015 at 14:55:59 UTC, Joakim wrote: So Obj-C/Swift aren't as efficient as C/C++, but nobody is using those as the main language on any mobile platform- for very good reasons, including that nobody other than game developers wants to deal with them- and as native languages, Obj-C and Swift are still much more efficient than the JIT-ed or interpreted, non-native languages, which is why Android finally switched from JIT-ing Java to AoT/native compilation recently. People have used C++ for both native mobile development (symbian?) and for cross-platform development (e.g. mosync). However Android and iOS deliberately set out to kill off cross-platform development a few years ago by making GUI kits incompatible and tool-based. So writing GUIs in other languages than Obj-C/Java became tedious. I found it much easier to use Mosync-C++ than Objective-C, to be honest. But it is now a dead technology.
Re: Where will D sit in the web service space?
On Friday, 24 July 2015 at 14:50:23 UTC, Ola Fosheim Grøstad wrote: On Friday, 24 July 2015 at 14:44:54 UTC, Joakim wrote: What is not "efficiency focused" about Obj-C and Swift? Objective-C uses a rather expensive reference counting model and a dynamic dispatch mechanism. So Obj-C/Swift aren't as efficient as C/C++, but nobody is using those as the main language on any mobile platform- for very good reasons, including that nobody other than game developers wants to deal with them- and as native languages, Obj-C and Swift are still much more efficient than the JIT-ed or interpreted, non-native languages, which is why Android finally switched from JIT-ing Java to AoT/native compilation recently.
Re: Where will D sit in the web service space?
On Friday, 24 July 2015 at 14:44:54 UTC, Joakim wrote: What is not "efficiency focused" about Obj-C and Swift? Objective-C uses a rather expensive reference counting model and a dynamic dispatch mechanism. ART. Of course Metal isn't general-purpose, nobody said it is, but I don't see why you'd say Swift isn't. Swift is clearly designed around Objective-C and Cocoa.
Re: Where will D sit in the web service space?
On Friday, 24 July 2015 at 06:02:12 UTC, Ola Fosheim Grøstad wrote: On Friday, 24 July 2015 at 05:19:08 UTC, Joakim wrote: Yep, I specifically mentioned the mobile and server domains as places where general-purpose native/AoT-compiled languages are having a resurgence, obviously for the efficiency reasons Etienne lists. In theory. Objective-C and Swift are AoT, but not efficiency focused and geared towards interactive apps. I wouldn't call Swift+Metal general purpose. What is not "efficiency focused" about Obj-C and Swift? iOS apps are known for their much better battery life and responsiveness, which is why google finally started AoT-compiling Java with Android 5 and added a concurrent GC in ART. Of course Metal isn't general-purpose, nobody said it is, but I don't see why you'd say Swift isn't. de-emphasized as a result. However, with the rise of mobile and webapps not doing as well there, for a variety of reasons, native development is coming back for many apps, at least on the client side for networked apps. For most apps it is mostly about UI look-and-feel, not really performance. That is the dumb reason that many people do native mobile apps, no question, but performance is a big part of the equation also, which is why some big HTML5 mobile apps ended up switching to native mobile instead.
Re: Where will D sit in the web service space?
On Friday, 24 July 2015 at 08:24:45 UTC, Kagamin wrote: Domain is the same, it's feature overlap, which is small. Nope. Domain is not the same. Feature set is not at all the same. You would not write a web browser in Go. - Rust is more like C++ and D, abstractions closer to current hardware, stricter typing at the cost of complexity, no GC. - Go use abstractions more detatched from current hardware, simplicity over advanced mechanisms, fully based on GC.
Re: Where will D sit in the web service space?
On Thursday, 23 July 2015 at 07:05:16 UTC, Ola Fosheim Grøstad wrote: But I think Rust and Go are focusing on specific domains. I think people pick languages now looking for specific characteristics that match their domain. I think the overlap between Rust and Go is rather small. Domain is the same, it's feature overlap, which is small. Highly concurrent chat service? Yeah http://nbaksalyar.github.io/2015/07/10/writing-chat-in-rust.html
Re: Where will D sit in the web service space?
On Friday, 24 July 2015 at 05:19:08 UTC, Joakim wrote: Yep, I specifically mentioned the mobile and server domains as places where general-purpose native/AoT-compiled languages are having a resurgence, obviously for the efficiency reasons Etienne lists. In theory. Objective-C and Swift are AoT, but not efficiency focused and geared towards interactive apps. I wouldn't call Swift+Metal general purpose. de-emphasized as a result. However, with the rise of mobile and webapps not doing as well there, for a variety of reasons, native development is coming back for many apps, at least on the client side for networked apps. For most apps it is mostly about UI look-and-feel, not really performance.
Re: Where will D sit in the web service space?
On Thursday, 23 July 2015 at 17:44:59 UTC, Etienne wrote: On Thursday, 23 July 2015 at 17:03:31 UTC, Laeeth Isharc wrote: But some of us think general-purpose, native languages are coming back, Yes. Now why do you think this is the case? I tried to articulate it as best I could for now, but Ola has all these _reasons_ why this isn't the case, which may mean he is right, but might not. Native languages are more efficient, they use less power. This is increasingly important to reduce the greenhouse gas emissions, to improve battery duration on mobile devices or to reduce server costs in general. Yep, I specifically mentioned the mobile and server domains as places where general-purpose native/AoT-compiled languages are having a resurgence, obviously for the efficiency reasons Etienne lists. Being general-purpose simply means that you wouldn't be limited to one of those domains, and could quickly bridge over to even newer domains that spring up. One big trend over the last decade and a half has been the rise of webapps, where native desktop apps, which are still predominantly written in native languages, have been de-emphasized as a result. However, with the rise of mobile and webapps not doing as well there, for a variety of reasons, native development is coming back for many apps, at least on the client side for networked apps. On the server, as long as you don't really need to scale out, you have a lot of choices for your tech. But the moment you need to scale, you'll probably want to go native, at least for your backend.
Re: Where will D sit in the web service space?
On Thursday, 23 July 2015 at 17:03:31 UTC, Laeeth Isharc wrote: But some of us think general-purpose, native languages are coming back, Yes. Now why do you think this is the case? I tried to articulate it as best I could for now, but Ola has all these _reasons_ why this isn't the case, which may mean he is right, but might not. Native languages are more efficient, they use less power. This is increasingly important to reduce the greenhouse gas emissions, to improve battery duration on mobile devices or to reduce server costs in general. The language design is also more modern, the compile times shorter, the errors more comprehensible, which makes interpreted languages less appealing for those who care about learning the alternatives. The gap in complexity is closing up. Finally, I answered an interview in This week in D about how I thought D in general had an excellent way to bind multiple components together, from other languages, thus making it not only general purpose but also a "glue", a centralized hub from which every team can build its interface on top of, whichever technology is used. After all, it was developed very late in the "language wars" with clear attempts to open itself up to the legacy software left behind by other languages.
Re: Where will D sit in the web service space?
On Wednesday, 22 July 2015 at 21:38:14 UTC, Joakim wrote: The finance guys seem to be coming on board, the Dconf '15 talk by the fund guy, Smith, probably helps. Yes - that's my impression, too, and I am doing my little bit to encourage people to consider the benefits of D. People are sometimes more open to hearing something from a practitioner and business person who knows a little technology than from a pure tech guy. Finance is a funny area because the stakes are high, but people are much more open-minded in some parts of it to trying things (it's not always as enterprisey as more stodgey firms in this respect). There's a crisis in the use of technology in finance. Citadel (large US hedge fund where I worked in London) used to tell people that the firm was almost more of a technology firm than a finance firm, and I am not going to comment on that. Similarly, the banks also conceive of themselves as leading in technology. The reality (in the general case, and without wishing to comment on specific firms) is that things are a mess - fragmented, siloed operations with significant costs from legacy approaches that no longer fit the new needs of the business. I agree with Dicebot that I haven't found an alternative to D that has high productivity, decent speed and power, and suitability for multiple problem domains. Innovation requires the ability to iterate rapidly, and to get an answer to questions quickly. In theory when cloud power is free, efficiency doesn't matter, but it's not that easy in practice. Despite the theoretically big budget, being able to produce a workable proof of concept quickly without needing budget approval has tremendous value. Thanks for the rest of your post - I agree very much with what you write, and it carries weight as you know the problem domain well. And as I've said before, focusing on a domain means you optimize for it, which inevitably means you become less general. Quite! Optimization creates brittleness to things you don't optimize for, and nobody can know at this stage what the important things might ultimately be. Central planning has its downsides, even if the way that planning occurs through polycentric activity in a community seems less rational and pure. Hayek had something to say about this. But some of us think general-purpose, native languages are coming back, Yes. Now why do you think this is the case? I tried to articulate it as best I could for now, but Ola has all these _reasons_ why this isn't the case, which may mean he is right, but might not.
Re: Where will D sit in the web service space?
On Thursday, 23 July 2015 at 10:16:02 UTC, Tofu Ninja wrote: Also game dev does not really have a go to language other than C or C++, so D could really make progress in there as it already trying to be a C++ replacement. I don't see go or rust being used seriously in game dev either, so less competition. I agree with this. The real competition there is language combinations like: C++ combined with Swift, C++ combined with some scripting language...
Re: Where will D sit in the web service space?
On Thursday, 23 July 2015 at 10:24:18 UTC, Rikki Cattermole wrote: On 23/07/2015 10:16 p.m., Tofu Ninja wrote: [...] Though it seems like D is already be moving in that direction. Color and image being worked on, We need image for a lot more then just game dev. Without it, we will never get a GUI toolkit. Web dev will also suffer, barcode generation anyone? allocators and less reliance on GC, and all the Any high performance program including web development requires allocators and friends. In fact, right now allocators are the only way to do web development in D properly. With having each request able to allocate things temporarily and have it auto deallocate without the GC being a burden. Thats the great part about focusing on game dev, is that it's needs are so applicable to other domains. Gl3n, we need to get that into Phobos. My knowledge of math isn't good enough to do it. But it should already be pretty reliable on that side of things. It just need to be modified to Phobos standards/requirements. It's an old library, but a damn good one. We would be stupid to not get it in. People are remaking it poorly as it is. https://github.com/Dav1dde/gl3n Yeah, even I have my own personal matrix lib, but like you said, a poor remake.
Re: Where will D sit in the web service space?
On 23/07/2015 10:16 p.m., Tofu Ninja wrote: [...] Though it seems like D is already be moving in that direction. Color and image being worked on, We need image for a lot more then just game dev. Without it, we will never get a GUI toolkit. Web dev will also suffer, barcode generation anyone? allocators and less reliance on GC, and all the Any high performance program including web development requires allocators and friends. In fact, right now allocators are the only way to do web development in D properly. With having each request able to allocate things temporarily and have it auto deallocate without the GC being a burden. great game dev related packages in dub, D is already moving towards good game dev. Some basic vector math in phobos would really be a great addition as well. Gl3n, we need to get that into Phobos. My knowledge of math isn't good enough to do it. But it should already be pretty reliable on that side of things. It just need to be modified to Phobos standards/requirements. It's an old library, but a damn good one. We would be stupid to not get it in. People are remaking it poorly as it is. https://github.com/Dav1dde/gl3n
Re: Where will D sit in the web service space?
On Thursday, 23 July 2015 at 08:16:11 UTC, Joakim wrote: [...] Yes, they both captured smaller markets and stopped there, unable to go further. D is aiming for a bigger market. Personally I think you both make good points, D really shines as a general purpose language, and I wouldn't want to change that. But getting D to be a go to language for a niche market would help D a lot in terms of adoption, and getting contributors. As others have said before in this thread, I think where D could actually make progress in is in game dev as it has such a massive set of needs. D covers a lot of its needs really well, and focusing on game dev would not make D itself very niche. Also game dev does not really have a go to language other than C or C++, so D could really make progress in there as it already trying to be a C++ replacement. I don't see go or rust being used seriously in game dev either, so less competition. Though it seems like D is already be moving in that direction. Color and image being worked on, allocators and less reliance on GC, and all the great game dev related packages in dub, D is already moving towards good game dev. Some basic vector math in phobos would really be a great addition as well.
Re: Where will D sit in the web service space?
On Thursday, 23 July 2015 at 07:05:16 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 22 July 2015 at 21:38:14 UTC, Joakim wrote: "[W]e've loved D so much that we're in the middle of a full rewrite from C++11 to D. The productivity boost is absolutely worth it." http://www.reddit.com/r/programming/comments/3cg1r0/lessons_learned_writing_a_filesystem_in_d/csvyxn8 But it doesn't say why. Did they evaluate Rust too? It's a reddit comment, not a blog post, understandable that they didn't get into all that. Granted, everyone can find several very good reasons to dislike C++, so any reasonable language that can replace it can be said to have an advantage if that dislike is present on a C++ team... Sounds like they love D more than simply disliking C++. But as far as C/C++ replacement languages go, there are several focusing on being more suitable than C++ for specific niches: Rust, Go, Chapel, Vala… The more generic ones like D, Loci, etc appears to be less used. I assume the lack of a specific edge over C++ matters. Perhaps, but are Chapel and Vala more used than D? I wouldn't think so. And as I've said before, focusing on a domain means you optimize for it, which inevitably means you become less general. Not really, you just focus your effort at making it work really well for a particular domain. Like C++ with extensions for a specific purpose. Resources are limited, so focusing on that domain usually means the other domains suffer. Worse, language design choices made to optimize for that domain can hamstring any attempt to turn the language more general-purpose later. Php has proven to be highly optimized for the web programming domain, in that it is highly successful at being chosen for many web projects, but almost nobody would want to use it for anything else, for a variety of reasons, but mainly that the qualities that make it successful on the web hurt it in other domains. Well, Php is quite horrible for web programming too, but they gained traction for many of the same reasons perl did: - It was easy to get started with when you needed 10-50 lines of scripting in 500 lines of HTML. - Provided library interfaces that was similar to Unix/C-libraries (really awful, but easy to get started) - Early adopters, there was no real competition outside perl - It got "bundled" with web-servers one way or the other. Right, all but the third are choices they took to do well in that niche, that don't translate to, say, writing a good native mobile app. If you want to be general-purpose, you have to put more thought into staying out of the trap of trying to be as simple as possible for scripting, because that will hurt you for heavier tasks. languages. Even if the pendulum doesn't swing all the way back as far as we think it will for general-purpose native languages, that's a very large niche, one with few choices- C, C++, D, Rust, Go (the first two legacy)- and well worth competing in. But I think Rust and Go are focusing on specific domains. I think people pick languages now looking for specific characteristics that match their domain. I think the overlap between Rust and Go is rather small. Even better for D if Rust and Go are ceding the general-purpose language niche, :) I only mentioned those two because they're the native languages with the most hype right now and are somewhat general-purpose. But Rust is supposedly aiming for the niche of large codebases written in a native language, such as a browser engine, and the ownership system they use to enable that turns off those not in that niche for being too complicated. Go aims for the network servers niche, but that means those who want generics are never going to consider it. Do you not see that there's a niche for a general-purpose programming language, in that it could theoretically be applied to everything from writing operating systems to webapps to scripts (even if it will rarely be used for the later two), one that C and C++ currently dominate? It may be hard to knock them off, particularly as they're not standing still, but that's a much larger niche than the small domains you list. roaring past D. If your only point is that it's done better than it has a right to because it has a very specific strength, I'd say that Erlang captured a market despite shortcoming because it was the only easy-way-out. And you probably could say that about PhP too. Yes, they both captured smaller markets and stopped there, unable to go further. D is aiming for a bigger market.
Re: Where will D sit in the web service space?
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.
Re: Where will D sit in the web service space?
On Friday, 17 July 2015 at 12:06:08 UTC, Ola Fosheim Grøstad wrote: On Friday, 17 July 2015 at 11:23:28 UTC, Kagamin wrote: An attractive platform is which gets the job done, not the best one, which doesn't actually exist (if it existed, there wouldn't be a list of options). And it's not like D has nothing to show, one must consider requirements for his task to decide which tool to choose and there's no single answer that suits everyone. There is always a relatively small set of best solutions for a given problem. One needs to find a rational and obvious answer to the question: For what domain is D the best choice? Just a single, well argued answer that stands up to scrutiny. Without it, few people will feel like endorsing it. (loss of marketing effect) The finance guys seem to be coming on board, the Dconf '15 talk by the fund guy, Smith, probably helps. I thought this was a nice endorsement recently, a reddit comment by a high-frequency trader which ended with: "[W]e've loved D so much that we're in the middle of a full rewrite from C++11 to D. The productivity boost is absolutely worth it." http://www.reddit.com/r/programming/comments/3cg1r0/lessons_learned_writing_a_filesystem_in_d/csvyxn8 While you may be right from a marketing and strategy perspective that D would be better off to focus on some carefully chosen niche and try to excel there to begin with, D is a general-purpose, native language developed by random volunteers from an online community of users. Even if the community agreed with your concept of focusing D on some domain, it's hard enough to get most people in a _company_ to agree on what that plan should actually be, let alone getting this free-floating community to agree on a domain. And as I've said before, focusing on a domain means you optimize for it, which inevitably means you become less general. Php has proven to be highly optimized for the web programming domain, in that it is highly successful at being chosen for many web projects, but almost nobody would want to use it for anything else, for a variety of reasons, but mainly that the qualities that make it successful on the web hurt it in other domains. So your superior marketing/business strategy has its technical and strategy downsides too, at least for a general-purpose language. Now, you can argue that the market for programming languages has become highly fragmented and that unless you are _the_ language for statistics, R, or concurrency, erlang, you cannot get anywhere. But some of us think general-purpose, native languages are coming back, with mobile made up only of native/AoT-compiled languages these days and successful web properties moving all their high-volume backend work to such languages. Even if the pendulum doesn't swing all the way back as far as we think it will for general-purpose native languages, that's a very large niche, one with few choices- C, C++, D, Rust, Go (the first two legacy)- and well worth competing in. Ask yourself: why did a weird language like Erlang grow? It has certainly had a resurgence in recent years, but has it really gone anywhere? Certain highly concurrent apps, like Whatsapp, have made good use of it, but it's not like it's roaring past D. If your only point is that it's done better than it has a right to because it has a very specific strength, I'll point out that it's also a good example of what I said above: focusing on one area can leave you significantly weaker in many other areas and doom you to that one niche.
Re: Where will D sit in the web service space?
i currently use vibe.d in a couple of productive apps. i think it really shines when it comes to low latency, traffic heavy backend/api services. its true that the ORM is missing and multi-thread scaling is not very good. but after some tuning i am very happy with single core performance. no immediate need for a full fledged web app with all the html stuff but rather a blazing fast api server that provides the realtime/streaming (websocket/http2) interfaces so that apps that keep state over requests can be built. the time of stateless webservices (REST in peace...) is coming to an end. further down that line it would be pretty amazing to be able to compile web assembly from d and push it out from the server to the client. ( voltframework.com is an interesting approach in that direction) once libasync compiles under ldc and hopefully enters the webframework benchmark it better beats the shit out of the competition. and if so, people who do this stuff in C/C++ now will start to use it. On Saturday, 18 July 2015 at 14:07:30 UTC, Etienne Cimon wrote: On Saturday, 18 July 2015 at 11:19:45 UTC, Ola Fosheim Grøstad wrote: Nothing is as elegant and completely featured like D in the natively compiled world. I say natively, because that's the only way to resolve the "interpreter war", seeing your interpreter banned just like firefox did you flash.
Re: Where will D sit in the web service space?
On Saturday, 18 July 2015 at 19:23:54 UTC, Etienne wrote: I wanted to develop the front end with dart but the final Js size ended up being too large and I evaluated that grunt and bower with webstorm are relatively more mature environments at the moment. I really do accept that these dev environments might change frequently at that level though, and I'm satisfied by the stability outlooks of D and underlying databases which make up for it. I think WebStorm is the recommended IDE for Dart now.
Re: Where will D sit in the web service space?
On Saturday, 18 July 2015 at 18:56:52 UTC, Ola Fosheim Grøstad wrote: On Saturday, 18 July 2015 at 18:51:01 UTC, rsw0x wrote: On Saturday, 18 July 2015 at 18:49:04 UTC, Ola Fosheim Grøstad wrote: On Saturday, 18 July 2015 at 16:55:23 UTC, Etienne Cimon wrote: [...] Btw, just found about this: https://github.com/dart-lang/dev_compiler/blob/master/STRONG_MODE.md Basically a typed subset of Dart that transpiles to clean Javascript (EcmaScript6). Not finished and production ready, but might be interesting to see if there is any help in there for transpiling other languages to Javascript. I thought dart already had a dart->js compiler? Yes, but the output is unreadable. Currently you develop for Dart by using a special version of Chromium with a Dart VM. Then compile to JS for release (with source map support, so you can still debug to some degree). I wanted to develop the front end with dart but the final Js size ended up being too large and I evaluated that grunt and bower with webstorm are relatively more mature environments at the moment. I really do accept that these dev environments might change frequently at that level though, and I'm satisfied by the stability outlooks of D and underlying databases which make up for it.
Re: Where will D sit in the web service space?
On Saturday, 18 July 2015 at 18:51:01 UTC, rsw0x wrote: On Saturday, 18 July 2015 at 18:49:04 UTC, Ola Fosheim Grøstad wrote: On Saturday, 18 July 2015 at 16:55:23 UTC, Etienne Cimon wrote: [...] Btw, just found about this: https://github.com/dart-lang/dev_compiler/blob/master/STRONG_MODE.md Basically a typed subset of Dart that transpiles to clean Javascript (EcmaScript6). Not finished and production ready, but might be interesting to see if there is any help in there for transpiling other languages to Javascript. I thought dart already had a dart->js compiler? Yes, but the output is unreadable. Currently you develop for Dart by using a special version of Chromium with a Dart VM. Then compile to JS for release (with source map support, so you can still debug to some degree).
Re: Where will D sit in the web service space?
On Saturday, 18 July 2015 at 18:49:04 UTC, Ola Fosheim Grøstad wrote: On Saturday, 18 July 2015 at 16:55:23 UTC, Etienne Cimon wrote: [...] Btw, just found about this: https://github.com/dart-lang/dev_compiler/blob/master/STRONG_MODE.md Basically a typed subset of Dart that transpiles to clean Javascript (EcmaScript6). Not finished and production ready, but might be interesting to see if there is any help in there for transpiling other languages to Javascript. I thought dart already had a dart->js compiler?
Re: Where will D sit in the web service space?
On Saturday, 18 July 2015 at 16:55:23 UTC, Etienne Cimon wrote: On Saturday, 18 July 2015 at 15:11:30 UTC, Ola Fosheim Grøstad wrote: However, I currently don't see much advantage in having the same language on client and server, so I'll probably stick to TypeScript/Dart, Angular2/Polymer in the near future because of debugging and tooling. I think these are very good choices. I prefer to really invest in learning and developing on D simply because the resulting code is more easily redistributable, because you get more bang for the buck when optimizing it, because the developers are generally better coming from the C++ world and being hobbyists, etc. And also, D is more promising. A lot of things can happen to deprecate Dart, or TypeScript development completely. Nobody/nothing's ever going to deprecate D, if anything you'll only see the smarter devs being less afraid to pick it up and bring it further. Btw, just found about this: https://github.com/dart-lang/dev_compiler/blob/master/STRONG_MODE.md Basically a typed subset of Dart that transpiles to clean Javascript (EcmaScript6). Not finished and production ready, but might be interesting to see if there is any help in there for transpiling other languages to Javascript.
Re: Where will D sit in the web service space?
On Saturday, 18 July 2015 at 16:55:23 UTC, Etienne Cimon wrote: I was talking more about being able to operate a website or web application that has been censored or sabotaged. If something happens in the coming years to the free web as we know it, people will have to turn to custom computer programs and p2p to help open up their web services. I'm not talking about the NSA censoring stuff. I'm talking about companies being anti-competitive. This seems to be becoming more and more likely as they (Godaddy, Google, Mozilla, Facebook, Amazon, Apple, Microsoft, Oracle, ISPs etc) become greedy and start to play rough with each-other and newcomers, using "security" as an excuse. It can way too easy to flip the switch on a website or technology (eg the flash player incidents over the years). The only solution I see is to stop relying on them so much! Interesting viewpoint. I think most certainly that Apple will try to constrain what we can do. With iWatch we are no longer allowed to distribute apps with machine language (SIMD?), but must use LLVM IR. It is very likely to happen across the board. I guess only Intel has a different interest. I can only upload my web servers in uncompiled form to Google AppEngine too (but that is actually an advantage). But I don't worry too much. I'm most worried about the "rent an application" trend. That everything becomes rented and nothing owned is problematic I think.
Re: Where will D sit in the web service space?
On Saturday, 18 July 2015 at 15:11:30 UTC, Ola Fosheim Grøstad wrote: However, I currently don't see much advantage in having the same language on client and server, so I'll probably stick to TypeScript/Dart, Angular2/Polymer in the near future because of debugging and tooling. I think these are very good choices. I prefer to really invest in learning and developing on D simply because the resulting code is more easily redistributable, because you get more bang for the buck when optimizing it, because the developers are generally better coming from the C++ world and being hobbyists, etc. And also, D is more promising. A lot of things can happen to deprecate Dart, or TypeScript development completely. Nobody/nothing's ever going to deprecate D, if anything you'll only see the smarter devs being less afraid to pick it up and bring it further. over p2p. Browsers will never be appropriate because it will always have to slow down the applications and filter everything for security. IMHO: In the long term time consuming tasks might be offloaded to some simplified replacement for OpenCL. I was talking more about being able to operate a website or web application that has been censored or sabotaged. If something happens in the coming years to the free web as we know it, people will have to turn to custom computer programs and p2p to help open up their web services. I'm not talking about the NSA censoring stuff. I'm talking about companies being anti-competitive. This seems to be becoming more and more likely as they (Godaddy, Google, Mozilla, Facebook, Amazon, Apple, Microsoft, Oracle, ISPs etc) become greedy and start to play rough with each-other and newcomers, using "security" as an excuse. It can way too easy to flip the switch on a website or technology (eg the flash player incidents over the years). The only solution I see is to stop relying on them so much!
Re: Where will D sit in the web service space?
On Saturday, 18 July 2015 at 14:07:30 UTC, Etienne Cimon wrote: [..] We're done with desktop UI. The problem domain has shifted with SPA (single page applications) revolution on the web and angularjs. Only for CRUD applications, anything serious is only playing catchup with native OS features. Thankfully mobiles are putting the web into its place. And yes, I do web development gigs as well and feel the pain of the web in 2015 still playing catchup with desktop development practices of the 90's. My last customers were all doing native desktop applications for data visualization. -- Paulo
Re: Where will D sit in the web service space?
On Saturday, 18 July 2015 at 15:14:05 UTC, Ola Fosheim Grøstad wrote: On Saturday, 18 July 2015 at 14:13:49 UTC, Adam D. Ruppe wrote: On Saturday, 18 July 2015 at 14:07:30 UTC, Etienne Cimon wrote: StackOverflow is an excellent resource, I've had trouble finding answers on it for D though because the D.learn forums contain all the Q&A. I wish we could mirror those on stack overflow or even channel it there instead. We're stuck in the 90's using NNTP+forums. We could encourage people to ask again on SO. Or we could ask our own things and answer it again as archive. (I sometimes consider doing that actually, I'm just lazy.) What I dislike about C++ is that the answers I find on SO sometimes are out-of-date and applies to C++98, meaning there might be better solutions for C++14. So reaching stability before focusing on SO is rather important IMO. Bjarne shares your feelings, although he already came to realise you can only change mentalities via new generations. Hence why he always makes sure his students get to modern C++, before seeing C code compiled with a C++ compiler. https://www.youtube.com/watch?v=2egL4y_VpYg
Re: Where will D sit in the web service space?
On Saturday, 18 July 2015 at 15:25:25 UTC, Ola Fosheim Grøstad wrote: On Saturday, 18 July 2015 at 14:06:43 UTC, Kagamin wrote: [...] Not when you are engineering a new framework. Then you should look at the alternatives, perhaps build some pilots and pick the best platform in terms of technology and market. Learning a new language is a relatively small cost, compared to the long term costs of not picking the best platform. [...] No. Because it provides robustness features most other languages don't. It was trashed and open sourced by Ericsson in 1998. That isn't the whole story, and having Erlang Solutions helped a lot.
Re: Where will D sit in the web service space?
On Saturday, 18 July 2015 at 15:25:25 UTC, Ola Fosheim Grøstad wrote: Not when you are engineering a new framework. Then you should look at the alternatives, perhaps build some pilots and pick the best platform in terms of technology and market. Learning a new language is a relatively small cost, compared to the long term costs of not picking the best platform. If you don't have experience with an unfamilar language, you pick wrong decisions for the framework, which results in both short-term and long-term costs. To design a framework, you need years of experience with the ecosystem. Ask yourself: why did a weird language like Erlang grow? Because it was a commercial project? No. Because it provides robustness features most other languages don't. Even Ada? You mean contracts? Erlang was praised and chosen for projects for different reasons, though.
Re: Where will D sit in the web service space?
On Saturday, 18 July 2015 at 14:06:43 UTC, Kagamin wrote: On Friday, 17 July 2015 at 12:06:08 UTC, Ola Fosheim Grøstad wrote: There is always a relatively small set of best solutions for a given problem. One needs to find a rational and obvious answer to the question: For what domain is D the best choice? That's an incorrect question. The previous one was correct: "which platform is attractive". Sometimes the best choice is the platform you mastered, i.e. if you want the result quickly. Not when you are engineering a new framework. Then you should look at the alternatives, perhaps build some pilots and pick the best platform in terms of technology and market. Learning a new language is a relatively small cost, compared to the long term costs of not picking the best platform. Ask yourself: why did a weird language like Erlang grow? Because it was a commercial project? No. Because it provides robustness features most other languages don't. It was trashed and open sourced by Ericsson in 1998.
Re: Where will D sit in the web service space?
On Saturday, 18 July 2015 at 13:19:19 UTC, Ola Fosheim Grøstad wrote: In the 1990s it could take me half an hour or more to learn that something was not possible or too much trouble by browsing manuals... References tell you what is possible, not what isn't possible, hard to do, buggy, workarounds… (but that is often just as important) SO as a workaround for PR censorship, lol.
Re: Where will D sit in the web service space?
On Saturday, 18 July 2015 at 15:14:05 UTC, Ola Fosheim Grøstad wrote: On Saturday, 18 July 2015 at 14:13:49 UTC, Adam D. Ruppe wrote: On Saturday, 18 July 2015 at 14:07:30 UTC, Etienne Cimon wrote: [...] We could encourage people to ask again on SO. Or we could ask our own things and answer it again as archive. (I sometimes consider doing that actually, I'm just lazy.) What I dislike about C++ is that the answers I find on SO sometimes are out-of-date and applies to C++98, meaning there might be better solutions for C++14. So reaching stability before focusing on SO is rather important IMO. This is just a problem of SO, they lock everything so a lot of answers are years out of date. It's going to kill SO if they don't fix it.
Re: Where will D sit in the web service space?
On Saturday, 18 July 2015 at 14:07:30 UTC, Etienne Cimon wrote: We're done with desktop UI. The problem domain has shifted with SPA (single page applications) revolution on the web and angularjs. I write custom web SPAs... I agree that is the way it is going for regular applications than can live with the 100ms delay of a network connection. But the audio-visual desktop applications I pointed to earlier, are difficult to do well on the web stack, and will be so for at least a few more years. Even simple animations are difficult to well on the current version of Chrome. Firefox is better. But these things take time to mature, because current web applications drive browser performance-tuning and new applications target the worst widespread web browser. Fortunately IE9 and IE10 are quickly dying, and Firefox and Chrome tend to run on the last few versions. So modern versions of IE/Chrome/Firefox/Safari are realistic targets in the near future. And that will change the entire web eco system. However, I currently don't see much advantage in having the same language on client and server, so I'll probably stick to TypeScript/Dart, Angular2/Polymer in the near future because of debugging and tooling. Nothing is as elegant and completely featured like D in the natively compiled world. I like your vision, but to get multithreading in modern browsers you need a different model than what D uses today. https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers over p2p. Browsers will never be appropriate because it will always have to slow down the applications and filter everything for security. IMHO: In the long term time consuming tasks might be offloaded to some simplified replacement for OpenCL.
Re: Where will D sit in the web service space?
On Saturday, 18 July 2015 at 14:13:49 UTC, Adam D. Ruppe wrote: On Saturday, 18 July 2015 at 14:07:30 UTC, Etienne Cimon wrote: StackOverflow is an excellent resource, I've had trouble finding answers on it for D though because the D.learn forums contain all the Q&A. I wish we could mirror those on stack overflow or even channel it there instead. We're stuck in the 90's using NNTP+forums. We could encourage people to ask again on SO. Or we could ask our own things and answer it again as archive. (I sometimes consider doing that actually, I'm just lazy.) What I dislike about C++ is that the answers I find on SO sometimes are out-of-date and applies to C++98, meaning there might be better solutions for C++14. So reaching stability before focusing on SO is rather important IMO.
Re: Where will D sit in the web service space?
On Saturday, 18 July 2015 at 14:13:29 UTC, rsw0x wrote: On Saturday, 18 July 2015 at 14:07:30 UTC, Etienne Cimon wrote: We're done with desktop UI. The problem domain has shifted with SPA (single page applications) revolution on the web and angularjs. yep, and it's the reason I can't load a 'modern' web page without it bringing my 16 core xeon server to a 4-5 second stop. we've gone backwards. That's because they are written to be single threaded and work with IE9. WebWorkers allow multi-threading.
Re: Where will D sit in the web service space?
On Saturday, 18 July 2015 at 14:13:29 UTC, rsw0x wrote: On Saturday, 18 July 2015 at 14:07:30 UTC, Etienne Cimon wrote: We're done with desktop UI. The problem domain has shifted with SPA (single page applications) revolution on the web and angularjs. yep, and it's the reason I can't load a 'modern' web page without it bringing my 16 core xeon server to a 4-5 second stop. we've gone backwards. I've seen a linear search do that in C. I admit that most js coders are bad, but people still find google docs practical. What's your point?
Re: Where will D sit in the web service space?
On Saturday, 18 July 2015 at 14:07:30 UTC, Etienne Cimon wrote: StackOverflow is an excellent resource, I've had trouble finding answers on it for D though because the D.learn forums contain all the Q&A. I wish we could mirror those on stack overflow or even channel it there instead. We're stuck in the 90's using NNTP+forums. We could encourage people to ask again on SO. Or we could ask our own things and answer it again as archive. (I sometimes consider doing that actually, I'm just lazy.)
Re: Where will D sit in the web service space?
On Saturday, 18 July 2015 at 14:07:30 UTC, Etienne Cimon wrote: We're done with desktop UI. The problem domain has shifted with SPA (single page applications) revolution on the web and angularjs. yep, and it's the reason I can't load a 'modern' web page without it bringing my 16 core xeon server to a 4-5 second stop. we've gone backwards.
Re: Where will D sit in the web service space?
On Friday, 17 July 2015 at 12:06:08 UTC, Ola Fosheim Grøstad wrote: There is always a relatively small set of best solutions for a given problem. One needs to find a rational and obvious answer to the question: For what domain is D the best choice? That's an incorrect question. The previous one was correct: "which platform is attractive". Sometimes the best choice is the platform you mastered, i.e. if you want the result quickly. Just a single, well argued answer that stands up to scrutiny. Without it, few people will feel like endorsing it. (loss of marketing effect) If you mean purely social issues, they are probably not very tied to technical aspects, it's more a question of PR. Ask yourself: why did a weird language like Erlang grow? Because it was a commercial project? Wait, you mean it doesn't grow anymore?
Re: Where will D sit in the web service space?
On Saturday, 18 July 2015 at 11:19:45 UTC, Ola Fosheim Grøstad wrote: StackOverflow has become the de-facto documentation resource for software engineers. It saves me insane amounts of time, many other programmers say the same thing. Google has been known to shut down it's own support-forums in order to get higher activity on StackOverflow. StackOverflow is an excellent resource, I've had trouble finding answers on it for D though because the D.learn forums contain all the Q&A. I wish we could mirror those on stack overflow or even channel it there instead. We're stuck in the 90's using NNTP+forums. I see basically 4 reasons to use languages like C++/D/Rust: 1. Low level hardware/OS access 2. Throughput 3. Lowered memory usage 4. Detailed control over execution patterns. We're done with desktop UI. The problem domain has shifted with SPA (single page applications) revolution on the web and angularjs. Nothing is as elegant and completely featured like D in the natively compiled world. I say natively, because that's the only way to resolve the "interpreter war", seeing your interpreter banned just like firefox did you flash. Other languages have too much legacy to carry or have started with the wrong language design and will be eventually dropped just like lisp and perl. WebRTC, bitcoins and torrenting have only scratched the surface for future web applications. I can guarantee you that there will be an era where desktop applications are p2p downloaded, installed, displayed on in a browser and all resources shared over p2p. Browsers will never be appropriate because it will always have to slow down the applications and filter everything for security. With time, over the years, we will see these primitives being developed and the world will turn to the language that allows them to accomplish this, because it will be the only solution to web neutrality.
Re: Where will D sit in the web service space?
On Saturday, 18 July 2015 at 13:04:20 UTC, Russel Winder wrote: Not is it possible to ignore the insanely appalling editorial behaiour on StackOverflow that almost, but not quite, completely undermines its entire usefulness. Like Wikipedia, it is not perfect and it is biased, but it is usually a good starting point for C++, iOS, Python, Javascript, Go etc. And you get valuable information about workarounds. In the 1990s it could take me half an hour or more to learn that something was not possible or too much trouble by browsing manuals... References tell you what is possible, not what isn't possible, hard to do, buggy, workarounds… (but that is often just as important)
Re: Where will D sit in the web service space?
On Sat, 2015-07-18 at 11:19 +, via Digitalmars-d wrote: > […] > > StackOverflow has become the de-facto documentation resource for > software engineers. It saves me insane amounts of time, many > other programmers say the same thing. Google has been known to > shut down it's own support-forums in order to get higher activity > on StackOverflow. > > You cannot gloss over the importance of this. Not is it possible to ignore the insanely appalling editorial behaiour on StackOverflow that almost, but not quite, completely undermines its entire usefulness. […] -- Russel. = Dr Russel Winder t:+44 20 7585 2200 voip:sip: russel.win...@ekiga.net 41 Buckmaster Road m:+44 7770 465 077 xmpp:rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype:russel_winder signature.asc Description: This is a digitally signed message part
Re: Where will D sit in the web service space?
On Saturday, 18 July 2015 at 10:29:20 UTC, Laeeth Isharc wrote: accurate understanding of reality to do so. The propensity to put things on github and for people to ask questions on stackoverflow varies according to the problem domain. StackOverflow has become the de-facto documentation resource for software engineers. It saves me insane amounts of time, many other programmers say the same thing. Google has been known to shut down it's own support-forums in order to get higher activity on StackOverflow. You cannot gloss over the importance of this. Large scale batch-processing cannot drive adoption. Specialized solutions like Chapel and C++/extensions will take the batch-throughput market. I didn't say anything about batch processing. It's also very intriguing to see you believe you know my problem domain better than me. I have no interest in your problem domain, but you say that throughput is important for you. I see basically 4 reasons to use languages like C++/D/Rust: 1. Low level hardware/OS access 2. Throughput 3. Lowered memory usage 4. Detailed control over execution patterns. In the 80s lots of software was close to theoretical throughput. Today, almost no software is anywhere close, because it is wy too expensive in terms of developer time as code base sizes increase. We are speaking of shifts at the margin from where we start today, and about the future, not historical trends over the past decade or two. The trend in consumer hardware is that GPUs share memory with the CPU or have fast paths. So efficiency means GPGPU programming, Metal, Vulkan.. The trend is that those few that can pay for throughput moves towards FPGA and other specialized solutions where it matters. The trend in performant server-hardware is that CPUs have local memory. The historical trend is that those expensive solutions become commoditized in one way or another over time. Meaning, consumer hardware adopt some features from high-end specialized hardware over time.
Re: Where will D sit in the web service space?
On Saturday, 18 July 2015 at 08:17:50 UTC, Ola Fosheim Grøstad wrote: On Saturday, 18 July 2015 at 02:45:54 UTC, Laeeth Isharc wrote: On Friday, 17 July 2015 at 12:06:08 UTC, Ola Fosheim Grøstad wrote: For what domain is D the best choice? You are switching the question without recognizing this - some kind of fallacy of composition. There is no fallacy here. We are each entitled to our judgement about whether D being in some Platonic sense the best single option for an entire domain has much to do with whether it is practicably speaking a sensible choice made by commercially pragmatic people operating within a certain set of uses. We are entitled to our views about the usefulness of thinking in terms of global optimality amidst uncertainty and local constraints. I shall not say more as there are diminishing returns to what is generative. You cannot compete until you have something that is the best possible starting point for a range of commercially- or community-backed frameworks. You don't have growth until you have clearly increasing presence on Github and StackOverflow. We are each of us entitled to our judgement about whether it's healthy to think in that way, and whether it leads to an accurate understanding of reality to do so. The propensity to put things on github and for people to ask questions on stackoverflow varies according to the problem domain. In web development, it's common to open-source things and to ask questions on stackoverflow. In some other sectors I am familiar with that have a decent share of technology spending overall it's rather less common, and this is not a capricious cultural trait but is the result of the application of common sense by commercial people. Liquidity tends to concentrate in certain places - for D, I wouldn't suggest anyone goes to stackoverflow if they want a good and quick answer to their question. It's healthy that liquidity is concentrated. Large scale batch-processing cannot drive adoption. Specialized solutions like Chapel and C++/extensions will take the batch-throughput market. I didn't say anything about batch processing. It's also very intriguing to see you believe you know my problem domain better than me. The work of Austrian economists on entrepreneurship demonstrate that it simply is not possible to know which people will use a product and how. The future is unknown, if not unimaginable. It isn't. The historical success-stories within the domain of programming languages are pretty clear. And there has been no change to the terrain, and so the lessons of the past can be applied without careful thought to present conditions that are different? I certainly won't dream of arguing further with you. If you presume programmer productivity is the only thing that matters and treat efficiency like a free resource, it's a dead cert that at some point efficiency will no longer be free. More and more problems are solved by less and less efficiency. Development time, reliability, maintainability, evolution and perceived responsiveness are the most important factors. mmm. In the 80s lots of software was close to theoretical throughput. Today, almost no software is anywhere close, because it is wy too expensive in terms of developer time as code base sizes increase. We are speaking of shifts at the margin from where we start today, and about the future, not historical trends over the past decade or two. D has a chance to gain adoption by picking a direction so you tend to assert. focusing on improving the process. But it is a long road, that also requires some cleanup of language. sure. hard to find anyone that wouldn't agree with the above.
Re: Where will D sit in the web service space?
On Saturday, 18 July 2015 at 02:45:54 UTC, Laeeth Isharc wrote: On Friday, 17 July 2015 at 12:06:08 UTC, Ola Fosheim Grøstad wrote: For what domain is D the best choice? You are switching the question without recognizing this - some kind of fallacy of composition. There is no fallacy here. You cannot compete until you have something that is the best possible starting point for a range of commercially- or community-backed frameworks. You don't have growth until you have clearly increasing presence on Github and StackOverflow. time and location. There aren't only a few sensible choices for hedge fund data processing generally. It's a big world, and there are many more variations between the needs of different teams than it is possible to imagine. Large scale batch-processing cannot drive adoption. Specialized solutions like Chapel and C++/extensions will take the batch-throughput market. The work of Austrian economists on entrepreneurship demonstrate that it simply is not possible to know which people will use a product and how. The future is unknown, if not unimaginable. It isn't. The historical success-stories within the domain of programming languages are pretty clear. The bigger picture is not D in a death match with any identifiable languages. All languages are on a long-tail death match against all the other languages. History is pretty clear on that too. It is long-tail because legacy source code bases will keep the languages alive until the product is replaced. If you presume programmer productivity is the only thing that matters and treat efficiency like a free resource, it's a dead cert that at some point efficiency will no longer be free. More and more problems are solved by less and less efficiency. Development time, reliability, maintainability, evolution and perceived responsiveness are the most important factors. In the 80s lots of software was close to theoretical throughput. Today, almost no software is anywhere close, because it is wy too expensive in terms of developer time as code base sizes increase. D's primary selling point is that it is more familiar to C++ programmers than Rust. But there are other C++-like languages that are getting to the same technical quality (thanks to LLVM). probably at that point, and that Facebook's experience with tradeoffs is not an edge case, but a leading edge for what more people will experience in future. No, in the future the processor will be integrated with RAM. You'll have lots and lots and lots of local processing power. The bottleneck will be communication between compute-nodes. (It already is, in many settings.) Furthermore, just rhetorically, gentle and constructive suggestions for improvement that come from within are likely to D has a chance to gain adoption by picking a direction and focusing on improving the process. But it is a long road, that also requires some cleanup of language.
Re: Where will D sit in the web service space?
On Friday, 17 July 2015 at 12:06:08 UTC, Ola Fosheim Grøstad wrote: On Friday, 17 July 2015 at 11:23:28 UTC, Kagamin wrote: An attractive platform is which gets the job done, not the best one, which doesn't actually exist (if it existed, there wouldn't be a list of options). And it's not like D has nothing to show, one must consider requirements for his task to decide which tool to choose and there's no single answer that suits everyone. There is always a relatively small set of best solutions for a given problem. One needs to find a rational and obvious answer to the question: For what domain is D the best choice? You are switching the question without recognizing this - some kind of fallacy of composition. There may be only a few sensible choices in a given hedge fund team at a particular time and location. There aren't only a few sensible choices for hedge fund data processing generally. It's a big world, and there are many more variations between the needs of different teams than it is possible to imagine. The work of Austrian economists on entrepreneurship demonstrate that it simply is not possible to know which people will use a product and how. The future is unknown, if not unimaginable. Who would have imagined a couple of East German PhDs would have had such success building a company based on D in a domain that didn't quite exist in that form at the time they began, particularly given all the complaints about the garbage collector. (The fact that they built their own has no bearing on my point). So it's a spurious question, and would be spurious even if D were a product that were sold by a corporation like a manufactured product, rather than what it is, which is an organically developing language and ecosystem that is heavily influenced by its originators yet not controlled by them. The bigger picture is not D in a death match with any identifiable languages. As Peter Thiel says, thinking of yourself as competing is an extremely destructive mindset for operating in business. One wants to carve out a monopoly that is earned by doing some set of things uniquely reasonably well. Aesthetics matter for programming languages, since programming is for the time being a human activity, and so there doesn't even need to be a technical superiority (although I think there is). The context for all of this is the economics shifting in the longer-term towards native code. If you presume programmer productivity is the only thing that matters and treat efficiency like a free resource, it's a dead cert that at some point efficiency will no longer be free. I think we are probably at that point, and that Facebook's experience with tradeoffs is not an edge case, but a leading edge for what more people will experience in future. Furthermore, just rhetorically, gentle and constructive suggestions for improvement that come from within are likely to be more effective than those that seem to some not to grant D its due even when it's difficult to argue from any perspective that there's an area it has gotten right. I do not think I am the only one with this sense. Just a single, well argued answer that stands up to scrutiny. Without it, few people will feel like endorsing it. (loss of marketing effect) Opinions are like noses. Everyone has one. Not everyone has earned the right to speak with authority on every topic. You make an empirical statement about what will happen if things are not done your way. I personally doubt your empirical statement because it doesn't align with how things are done in my small (and in aggregate not so small) patch of the world, and these things must compose for what you say to be true. Nobody cares about whether in theory D is good for an industry; they care about whether it solves the particular problems at hand (human, cultural, and tacit knowledge questions being an unavoidable component of what defines the problem set). I am not the only one in my sector to think that it does, so if I cared about social proof - which I do not - I'd feel comfortable enough with the decision.
Re: Where will D sit in the web service space?
On Friday, 17 July 2015 at 11:23:28 UTC, Kagamin wrote: An attractive platform is which gets the job done, not the best one, which doesn't actually exist (if it existed, there wouldn't be a list of options). And it's not like D has nothing to show, one must consider requirements for his task to decide which tool to choose and there's no single answer that suits everyone. There is always a relatively small set of best solutions for a given problem. One needs to find a rational and obvious answer to the question: For what domain is D the best choice? Just a single, well argued answer that stands up to scrutiny. Without it, few people will feel like endorsing it. (loss of marketing effect) Ask yourself: why did a weird language like Erlang grow?
Re: Where will D sit in the web service space?
On Thursday, 16 July 2015 at 11:25:11 UTC, Ola Fosheim Grøstad wrote: On Thursday, 16 July 2015 at 11:00:19 UTC, Paulo Pinto wrote: Well, there are lots of Geometry Wars clones in XNA and LibGDX. The point is more this: the majority of interactive applications you can do easily in Java/C#/Swift/Javascript are going to be written in those languages for _very_ good reasons. I would too. If desktop applications are a target then you need a feature set that makes it easier to write those applications that are difficult to do well in Java/C#/Swift/Javascript. That makes you an attractive platform for new application frameworks. An attractive platform is which gets the job done, not the best one, which doesn't actually exist (if it existed, there wouldn't be a list of options). And it's not like D has nothing to show, one must consider requirements for his task to decide which tool to choose and there's no single answer that suits everyone.
Re: Where will D sit in the web service space?
On Thursday, 16 July 2015 at 20:20:54 UTC, Tofu Ninja wrote: On Thursday, 16 July 2015 at 11:00:19 UTC, Paulo Pinto wrote: Well, there are lots of Geometry Wars clones in XNA and LibGDX. As for Vulkan, I have the strong feeling it is DOA, with Apple, Sony, Nintendo, Microsoft favoring they own APIs. Its even worse because its not obvious if apple will even support vulkan... Yes, there is always the mention of them being in the planning board, but that doesn't mean anything. They invented OpenCL, yet as I can understand from forum discussions their implementation is not that good nor up to the latest versions.
Re: Where will D sit in the web service space?
On Thursday, 16 July 2015 at 19:01:10 UTC, Paulo Pinto wrote: [...] Starting at 00:06:40, game engines support and OpenGL replacement on the graphics stack (00:07:20). Thanks for pointing to the time segments! Looks like they have put some effort into transitioning shaders from GLSL to Metal. I agree they sell it as a "this is it" solution by how they talk about it. Can't tell what is spin, and what is the future... It would be silly for Apple to make it hard to port CAD applications etc to OSX... Then again, they no longer have Steve Jobs... :-/
Re: Where will D sit in the web service space?
On Thursday, 16 July 2015 at 11:00:19 UTC, Paulo Pinto wrote: Well, there are lots of Geometry Wars clones in XNA and LibGDX. As for Vulkan, I have the strong feeling it is DOA, with Apple, Sony, Nintendo, Microsoft favoring they own APIs. Its even worse because its not obvious if apple will even support vulkan...
Re: Where will D sit in the web service space?
On Thursday, 16 July 2015 at 16:58:45 UTC, Ola Fosheim Grøstad wrote: On Thursday, 16 July 2015 at 16:37:44 UTC, Paulo Pinto wrote: However if you watch "Graphics and Games" talks https://developer.apple.com/videos/wwdc/2015/ It is all about Metal support, OpenGL being replaced by Metal and OpenGL being available for the iDevices that aren't Metal capable, as well as, backwards compatibility. Thanks, I am interested in this. Do you remember which one of the nine videos? SceneKit transition to Metal, comparing it with OpenGL ES, starting on 00:22:30. https://developer.apple.com/videos/wwdc/2015/?id=606 Metal is now the default renderer for SceneKit, OpenGL needs to be opted-in. Starting at 00:06:40, game engines support and OpenGL replacement on the graphics stack (00:07:20). https://developer.apple.com/videos/wwdc/2015/?id=603 Then you can watch how a few known companies in the industry praise Apple for Metal and how they replaced their OpenGL stack with Metal. -- Paulo
Re: Where will D sit in the web service space?
On Thursday, 16 July 2015 at 16:37:44 UTC, Paulo Pinto wrote: However if you watch "Graphics and Games" talks https://developer.apple.com/videos/wwdc/2015/ It is all about Metal support, OpenGL being replaced by Metal and OpenGL being available for the iDevices that aren't Metal capable, as well as, backwards compatibility. Thanks, I am interested in this. Do you remember which one of the nine videos? From money point of view, I don't think it makes sense to spend one year paying developers to port Metal to OSX, replace OpenGL in OS X/iOS frameworks and developer tools, for doing the same again when Vulkan comes out. But they don't pay as much for the Vulkan drivers... GPU vendors write them anyway. I think I found out why Metal is coming for OSX now and not earlier. Apparently the programming model used in Metal is targeting hardware from 2012 or newer.
Re: Where will D sit in the web service space?
On Thursday, 16 July 2015 at 13:56:14 UTC, Ola Fosheim Grøstad wrote: On Thursday, 16 July 2015 at 13:17:43 UTC, Paulo Pinto wrote: Apple has officially dropped OpenGL support at WWDC, if you care to watch the presentations and early release documentation. Are you sure they have _dropped_ OpenGL and not just got switched away from using OpenGL as their low level layer for Cocoa? https://developer.apple.com/opengl/ https://developer.apple.com/opencl/ Those are the current information. However if you watch "Graphics and Games" talks https://developer.apple.com/videos/wwdc/2015/ It is all about Metal support, OpenGL being replaced by Metal and OpenGL being available for the iDevices that aren't Metal capable, as well as, backwards compatibility. Then if you have a Mac developer account, you can check the "OS X El Capitan v10.11" document with zero references to OpenGL, other than Metal being the default render. The OpenGL version support is still based on 4.1. https://developer.apple.com/metal/ They might change their mind and surprise the world, but that is how things stand. AFAIK they are on the Vulkan working group, but probably don't view Vulkan as ready for consumption. They needed Metal on iOS because GPUs on iPads/iPhones are weak. That happend before Vulkan came along. Sony is also and they don't use OpenGL, except for Android and WebGL on the PS4 dashboard. So it makes sense to move Metal to OS-X while waiting for Vulkan to mature on their hardware (or rather waiting for older GPUs to be irrelevant). They have a compatibility interest in keeping developers on Metal until iPhones/iPads are ready for Vulkan. From money point of view, I don't think it makes sense to spend one year paying developers to port Metal to OSX, replace OpenGL in OS X/iOS frameworks and developer tools, for doing the same again when Vulkan comes out. So who cares if Intel, AMD, and Valve are heavily invested in Vulkan? Intel, AMD, NVIDIA and Imagination are all in on Vulkan, aren't they? Everybody cares about what they do because they write the drivers for next gen GPUs. It makes sense to focus Vulkan-effort on next generation of hardware for vendors (profit motive). They also write drivers for DirectX and Metal. It is not at all obvious that Apple will want to keep writing and maintaining their own low level drivers once GPU vendors ship solid Vulkan implementations. Of course, Apple cannot tell the public that Metal will become irrelevant in a few years... They have a story to sell. According to the WWDC talks Apple also did engage with GPU vendors on Metal for their systems, they aren't doing it alone. Apple might prove me wrong, lets see. -- Paulo
Re: Where will D sit in the web service space?
On Thursday, 16 July 2015 at 14:07:29 UTC, rsw0x wrote: for Microsoft - never.) 6-7 android phones are selling per iOS phone, and this is projected to keep going up thanks to developing countries entering the market and Apple's popularity falling amongst western demographics. No, Vulkan will _not_ be DOA. Exactly. Apple usually avoid making announcements until they are certain that products will be ready for consumption. So being silent about Vulkan is business as usual. Apple don't do public roadmaps like Intel/AMD... Having Metal on OSX is just another step in harmonizing iOS and OSX apis. Probably happens now due the desktop GPU situation. We need to keep in mind that iOS units have different GPUs.
Re: Where will D sit in the web service space?
On Thursday, 16 July 2015 at 14:07:29 UTC, rsw0x wrote: On Thursday, 16 July 2015 at 13:17:43 UTC, Paulo Pinto wrote: [...] PC game revenue outpaced console game revenue in 2012 or 2013("...PC gaming segment is already twice the size of the console gaming market – and growing. ",) Sony and Microsoft haven't seen profits from their consoles in over a decade(and for Microsoft - never.) 6-7 android phones are selling per iOS phone, and this is projected to keep going up thanks to developing countries entering the market and Apple's popularity falling amongst western demographics. [...] Sure, but in what concerns PC games, DirectX rules. Also Google hasn't shown any interest into adding Vulkan support to Android. They don't even support OpenCL, pushing instead for Renderscript.
Re: Where will D sit in the web service space?
On Thursday, 16 July 2015 at 13:17:43 UTC, Paulo Pinto wrote: On Thursday, 16 July 2015 at 11:08:52 UTC, rsw0x wrote: On Thursday, 16 July 2015 at 11:00:19 UTC, Paulo Pinto wrote: [...] Sure, if they can convince the major graphics vendors to care about their proprietary vendor lock-in crap. The only one of those that will exist in 5 years is probably DirectX. Intel, AMD, and Valve are heavily invested in Vulkan. It will definitely not be DOA. Apple has officially dropped OpenGL support at WWDC, if you care to watch the presentations and early release documentation. On those presentations OpenGL has referred as backward compatibility only. All the Mac OS X and iOS frameworks that used OpenGL, now have a Metal layer. They might change their mind and surprise the world, but that is how things stand. In the console market, no one cares about OpenGL. Sony [0], Nintendo, Microsoft and even Sega, never cared for it. So who cares if Intel, AMD, and Valve are heavily invested in Vulkan? The platform vendors that matter to games developers are not. [0] OpenGL ES 1.0 on the PS 3 wasn't really that usable, everyone went native PS3 instead. PC game revenue outpaced console game revenue in 2012 or 2013("...PC gaming segment is already twice the size of the console gaming market – and growing. ",) Sony and Microsoft haven't seen profits from their consoles in over a decade(and for Microsoft - never.) 6-7 android phones are selling per iOS phone, and this is projected to keep going up thanks to developing countries entering the market and Apple's popularity falling amongst western demographics. No, Vulkan will _not_ be DOA. http://www.forbes.com/sites/chuckjones/2015/04/06/apples-worldwide-iphone-market-share-declining-except-in-china/ http://www.forbes.com/sites/jasonevangelho/2014/04/28/as-global-pc-game-revenue-surpasses-consoles-how-long-should-console-makers-keep-fighting/ http://www.forbes.com/sites/marcochiappetta/2014/07/14/the-console-war-is-over-the-pc-already-won/
Re: Where will D sit in the web service space?
On Thursday, 16 July 2015 at 13:17:43 UTC, Paulo Pinto wrote: Apple has officially dropped OpenGL support at WWDC, if you care to watch the presentations and early release documentation. Are you sure they have _dropped_ OpenGL and not just got switched away from using OpenGL as their low level layer for Cocoa? https://developer.apple.com/opengl/ https://developer.apple.com/opencl/ https://developer.apple.com/metal/ They might change their mind and surprise the world, but that is how things stand. AFAIK they are on the Vulkan working group, but probably don't view Vulkan as ready for consumption. They needed Metal on iOS because GPUs on iPads/iPhones are weak. That happend before Vulkan came along. So it makes sense to move Metal to OS-X while waiting for Vulkan to mature on their hardware (or rather waiting for older GPUs to be irrelevant). They have a compatibility interest in keeping developers on Metal until iPhones/iPads are ready for Vulkan. So who cares if Intel, AMD, and Valve are heavily invested in Vulkan? Intel, AMD, NVIDIA and Imagination are all in on Vulkan, aren't they? Everybody cares about what they do because they write the drivers for next gen GPUs. It makes sense to focus Vulkan-effort on next generation of hardware for vendors (profit motive). It is not at all obvious that Apple will want to keep writing and maintaining their own low level drivers once GPU vendors ship solid Vulkan implementations. Of course, Apple cannot tell the public that Metal will become irrelevant in a few years... They have a story to sell.
Re: Where will D sit in the web service space?
On Thursday, 16 July 2015 at 12:44:22 UTC, Wyatt wrote: Personally, I've dealt with perl, ruby, python, java, and php in the web space and as far as I'm concerned they're all unmaintainable trash. (perl, ironically, gave me the best experience of the five!) What advantage can perl possibly have over Python? I ditched perl over 10 years ago and never looked back. If I ever decide I'm masochistic enough to attempt something in that vein again, D is at least as strong a contender for me because it offers fast iteration, solid performance, and a type system that doesn't make me want to punch small animals. Well, the development-server-framework I use reload automatically whenever I save a file, so I am for now happy with iteration speed as I don't perceive any delays worth thinking about. With PyCharm I also get debugger/web server integration and the PyCharm background-sanitizer gets pretty close to having static typing actually. Impressive for a dynamic language! Wish I had picked it up earlier! If you go node.js, you get static typing with typescript if you want + same language on the browser, debuggable. If you go Dart you get static typing if you want + same language the browser, debuggable. But in terms of programmer-productivity I think Python is hard to match in the webspace (for a wide range of reasons). So I think you need to look at what exists _TODAY_ in the webspace, not what you used >3 years ago. That's history. Go and Rust, for all their "theoretical superiority" in one place or another, _don't feel good_. Go is to C what Plan 9 is to Unix, which is to say it's a thoroughly unimaginitive, ideologically hampered, overly-conservative iteration from Rob Pike. Rust might be intriguing if it ever catches up to D in being pleasant to use. I haven't used Go or Rust fulltime for the amount of time needed to get fully familiar with them (I guess that would take me 1-2 months fulltime or so). So I can't really say whether what I feel as "oddities" now will persist. I felt that Cs syntax was odd too, when I came to it from Pascal/asm. So I am more concerned about the feature set, my brain can usually get around "unusual" choices if there is syntactical and semantic consistency.
Re: Where will D sit in the web service space?
On Thursday, 16 July 2015 at 11:08:52 UTC, rsw0x wrote: On Thursday, 16 July 2015 at 11:00:19 UTC, Paulo Pinto wrote: Well, there are lots of Geometry Wars clones in XNA and LibGDX. As for Vulkan, I have the strong feeling it is DOA, with Apple, Sony, Nintendo, Microsoft favoring they own APIs. Sure, if they can convince the major graphics vendors to care about their proprietary vendor lock-in crap. The only one of those that will exist in 5 years is probably DirectX. Intel, AMD, and Valve are heavily invested in Vulkan. It will definitely not be DOA. Apple has officially dropped OpenGL support at WWDC, if you care to watch the presentations and early release documentation. On those presentations OpenGL has referred as backward compatibility only. All the Mac OS X and iOS frameworks that used OpenGL, now have a Metal layer. They might change their mind and surprise the world, but that is how things stand. In the console market, no one cares about OpenGL. Sony [0], Nintendo, Microsoft and even Sega, never cared for it. So who cares if Intel, AMD, and Valve are heavily invested in Vulkan? The platform vendors that matter to games developers are not. [0] OpenGL ES 1.0 on the PS 3 wasn't really that usable, everyone went native PS3 instead.
Re: Where will D sit in the web service space?
On Sunday, 12 July 2015 at 17:54:02 UTC, Ola Fosheim Grøstad wrote: On Sunday, 12 July 2015 at 12:32:32 UTC, Peter Alexander wrote: Web servers: Why not? Mostly because there is no real visible direction towards making D a competitor that directly addresses specific needs of web programming. So what? Personally, I've dealt with perl, ruby, python, java, and php in the web space and as far as I'm concerned they're all unmaintainable trash. (perl, ironically, gave me the best experience of the five!) If I ever decide I'm masochistic enough to attempt something in that vein again, D is at least as strong a contender for me because it offers fast iteration, solid performance, and a type system that doesn't make me want to punch small animals. Go and Rust, for all their "theoretical superiority" in one place or another, _don't feel good_. Go is to C what Plan 9 is to Unix, which is to say it's a thoroughly unimaginitive, ideologically hampered, overly-conservative iteration from Rob Pike. Rust might be intriguing if it ever catches up to D in being pleasant to use. -Wyatt
Re: Where will D sit in the web service space?
On Thursday, 16 July 2015 at 11:48:59 UTC, ponce wrote: Notch goes pretty fast with Eclipse. Nitpicking, but notch hasn't been involved with Minecraft in years. *g* -Wyatt
Re: Where will D sit in the web service space?
On Thursday, 16 July 2015 at 10:58:08 UTC, rsw0x wrote: On Thursday, 16 July 2015 at 10:29:54 UTC, Kagamin wrote: Like minecraft? Minecraft runs absolutely horrible, the earlier versions of minecraft used to allocate 2-300mb of data per second that was near instantly marked garbage. OTOH, Minecraft Desktop benefits from a single build that work in Linux/Mac/Windows, has a web start page, and Notch goes pretty fast with Eclipse.
Re: Where will D sit in the web service space?
On Thursday, 16 July 2015 at 11:08:52 UTC, rsw0x wrote: Intel, AMD, and Valve are heavily invested in Vulkan. It will definitely not be DOA. Paulo probably referred to Apple announcing Metal for Os-X. So you might need to support both as Metal might be better optimized for by Apple even if Apple announce Vulkan support. All speculations...
Re: Where will D sit in the web service space?
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.