Re: Go 1.9
On Tuesday, 4 July 2017 at 03:41:35 UTC, jmh530 wrote:
I just gave it a try. Got an error. As far as I can tell, the
problem is that my user name has a space in it
(firstname[space]lastname).
library(embedrwin)
setwd("C:\\test\\")
compile("librtest",
"C:\\D\\ldc2\\ldc2-1.3.0-beta1-win64-msvc\\bin")
[1]
"\"C:\\D\\ldc2\\ldc2-1.3.0-beta1-win64-msvc\\bin\\ldmd2.exe\"
-shared -m64 librtest.d
C:/Users/firstname[space]lastname/Documents/R/win-library/3.3/embedrwin\\embedrwin\\r.d -version=inline R.lib"
[1] "Error: module firstname is in file
'C:\\Users\\firstname.d' which cannot be read"
[2] "import path[0] =
C:\\D\\ldc2\\LDC2-1~1.0-B\\bin\\..\\import\\ldc"
[3] "import path[1] =
C:\\D\\ldc2\\LDC2-1~1.0-B\\bin\\..\\import"
Thanks. I forgot a pair of quotes.
It's probably better to file issues on Bitbucket or use Gitter[1]
if possible. Or send an email to me at the address here[2].
Someone will get upset with me for using this mailing list for my
package.
[1] https://gitter.im/dlang-embedr/Lobby
[2] http://www.k-state.edu/economics/staff/bios/bachmeier.html
Re: Go 1.9
On Friday, 30 June 2017 at 20:36:47 UTC, bachmeier wrote:
On Tuesday, 27 June 2017 at 02:40:37 UTC, jmh530 wrote:
On Tuesday, 27 June 2017 at 02:38:31 UTC, bachmeier wrote:
I'll post here after updating and testing the embedr package.
Great. I'll give it a go again when it's ready.
An update. It looks like I will be able to get all of my
research programs to work on Windows. It might be easier to use
D in R packages on Windows than to use C/C++/Fortran because
there is no need to mess with R tools, which many end users
find confusing. The final piece of the puzzle would be an LDC
installer for Windows that puts it in the path. Then it would
definitely be easier to use D than C/C++/Fortran.
I just gave it a try. Got an error. As far as I can tell, the
problem is that my user name has a space in it
(firstname[space]lastname).
library(embedrwin)
setwd("C:\\test\\")
compile("librtest",
"C:\\D\\ldc2\\ldc2-1.3.0-beta1-win64-msvc\\bin")
[1] "\"C:\\D\\ldc2\\ldc2-1.3.0-beta1-win64-msvc\\bin\\ldmd2.exe\"
-shared -m64 librtest.d
C:/Users/firstname[space]lastname/Documents/R/win-library/3.3/embedrwin\\embedrwin\\r.d -version=inline R.lib"
[1] "Error: module firstname is in file 'C:\\Users\\firstname.d'
which cannot be read"
[2] "import path[0] =
C:\\D\\ldc2\\LDC2-1~1.0-B\\bin\\..\\import\\ldc"
[3] "import path[1] = C:\\D\\ldc2\\LDC2-1~1.0-B\\bin\\..\\import"
attr(,"status")
[1] 1
Error in inDL(x, as.logical(local), as.logical(now), ...) :
unable to load shared object 'C:/test/librtest.dll':
LoadLibrary failure: The specified module could not be found.
In addition: Warning messages:
1: In file.copy(paste0(loc, "/embedr/R.lib"), getwd()) :
problem copying
C:\Users\firstname[space]lastname\Documents\R\win-library\3.3\embedrwin\embedr\R.lib to C:\test\R.lib: No such file or directory
2: running command
'"C:\D\ldc2\ldc2-1.3.0-beta1-win64-msvc\bin\ldmd2.exe" -shared
-m64 librtest.d
C:/Users/firstname[space]lastname/Documents/R/win-library/3.3/embedrwin\embedrwin\r.d -version=inline R.lib' had status 1
Re: Go 1.9
On Friday, 30 June 2017 at 20:36:47 UTC, bachmeier wrote: An update. It looks like I will be able to get all of my research programs to work on Windows. It might be easier to use D in R packages on Windows than to use C/C++/Fortran because there is no need to mess with R tools, which many end users find confusing. The final piece of the puzzle would be an LDC installer for Windows that puts it in the path. Then it would definitely be easier to use D than C/C++/Fortran. Cool. I still need to give embedrwin a try...
Re: Go 1.9
On Tuesday, 27 June 2017 at 02:40:37 UTC, jmh530 wrote: On Tuesday, 27 June 2017 at 02:38:31 UTC, bachmeier wrote: I'll post here after updating and testing the embedr package. Great. I'll give it a go again when it's ready. An update. It looks like I will be able to get all of my research programs to work on Windows. It might be easier to use D in R packages on Windows than to use C/C++/Fortran because there is no need to mess with R tools, which many end users find confusing. The final piece of the puzzle would be an LDC installer for Windows that puts it in the path. Then it would definitely be easier to use D than C/C++/Fortran.
Re: Go 1.9
On Tuesday, 27 June 2017 at 02:40:37 UTC, jmh530 wrote: On Tuesday, 27 June 2017 at 02:38:31 UTC, bachmeier wrote: I'll post here after updating and testing the embedr package. Great. I'll give it a go again when it's ready. You can try this: https://bitbucket.org/bachmeil/embedrwin It's not in any sense a release. This is for early testing and everything will be added to embedr in the future. It works for me, so hopefully it will work for you.
Re: Go 1.9
On Tuesday, 27 June 2017 at 02:38:31 UTC, bachmeier wrote: I'll post here after updating and testing the embedr package. Great. I'll give it a go again when it's ready.
Re: Go 1.9
On Monday, 26 June 2017 at 12:20:02 UTC, jmh530 wrote: [...] I might make another effort on this after work if I have time. I think this will be fairly easily handled within the embedr R package. I should be able to put R.lib inside the package. R knows where to find R.dll. The only thing that remains is to find the LDC installation. I don't know how to automate that, but the user could give the path as input. I'll post here after updating and testing the embedr package.
Re: Go 1.9
On Mon, 2017-06-26 at 16:30 +, jmh530 via Digitalmars-d wrote: > […] > I don't know how well dub will handle it as my dub projects never > get this complicated. I haven't used SCons, but might make sense. > Reggae is another choice (though I haven't used that either). Although I have been quite involved with SCons for a while, I am not sure it is the future of build. Systems such as Meson/Ninja are much nicer to work with. Reggae is very much in the same camp as Meson. The difference is that Meson has a big community giving it traction. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +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: Go 1.9
On Monday, 26 June 2017 at 13:10:17 UTC, bachmeier wrote: Thanks for giving it a try. I have a feeling that this is a job for Dub, SCons, or more likely, an R package that figures out this stuff. Windows development seems to have more moving parts. An R package on Linux requires adding a Makefile with one line. I don't know how well dub will handle it as my dub projects never get this complicated. I haven't used SCons, but might make sense. Reggae is another choice (though I haven't used that either).
Re: Go 1.9
On Sunday, 25 June 2017 at 17:21:06 UTC, Michael wrote: I think the problem with this is that compilation speed being the no. 1 selling point requires people to invest in large projects in order to reap the benefits. However, if you fail to draw them in to begin with, then they're not going to commit to a large enough project to benefit enough from improved compilation speed. I don't know where you're getting this idea that fast compile times only help for large projects. I reap the benefits every time I use rdmd for my scripts. I reap the benefits every time the compilation is near instant when tweaking+debugging my libraries or when unit testing my projects.
Re: Go 1.9
On Monday, 26 June 2017 at 12:20:02 UTC, jmh530 wrote: [...] Then, this caused a problem because it used my 2017 Visual Studio instead of the Visual Studio 12.0. So I gave up, for now, at this point. I might make another effort on this after work if I have time. Thanks for giving it a try. I have a feeling that this is a job for Dub, SCons, or more likely, an R package that figures out this stuff. Windows development seems to have more moving parts. An R package on Linux requires adding a Makefile with one line.
Re: Go 1.9
On Monday, 26 June 2017 at 01:31:43 UTC, bachmeier wrote: [snip] 3. Windows requires R.lib for compilation, so I created that by installing the MinGW pexports.exe utility. C:\MinGW\bin\pexports.exe R.dll > R.def You might make reference to cd to the folder that R.dll for x64 is in, for me it was C:\Program Files\R\R-3.3.3\bin\x64 I also got access denied, so used administrative cmd. RTools hadn't installed pexports, so I installed a new MinGW. Then create the .lib using Visual Studio: "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\lib.exe" /def:R.def /out:R.lib /machine:x64 I have Visual Studio 2017 installed, so I used "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.10.25017\bin\HostX86\x64\lib.exe" /def:R.def /out:R.lib /machine:x64 but got the error LINK : fatal error LNK1171: unable to load mspdb140.dll (error code: 126) So I tried to use my Visual Studio 12 (did not have 14 installed). That seemed to work. 4. Create librtest.dll using LDC: "C:\Users\lance\ldc64\ldc2-1.3.0-beta2-win64-msvc\bin\ldmd2.exe" -shared -m64 librtest.d r.d -version=inline R.lib Path adjusted for my location of ldc2. Also, I had ldc2-1.3.0-beta1. Also, first you need to cd back to the original location. Then, this caused a problem because it used my 2017 Visual Studio instead of the Visual Studio 12.0. So I gave up, for now, at this point. I might make another effort on this after work if I have time.
Re: Go 1.9
On Monday, 26 June 2017 at 06:47:53 UTC, Ola Fosheim Grøstad wrote: But you need a focus, figure out what you are good at and go with it. For which domain is your language the best option? Decent doesn (Hit tab by mistake, why would tab+space be a sensible key sequence for sending a message? Have experienced the same issue in gmail.) Anyway, decent doesn't cut it, you have to focus on the areas where your language can become the hands down best option. Which is why throwing in some libraries for various domains won't work. If you don't have good integration with one of the best physics engines, then you can't really compete in the area of games in the general case. C++, Rust, Swift and Go have some very clear areas where they are the best option if you evaluate the available options based on your project's requirement spec. Which is why they have traction. It isn't really a question of individual language features or libraries making things possible. Those things attract individual programmers, but it doesn't directly affect the cost/feasibility analysis for a project where you evaluate options for something very specific. Scripting-like programming is different, there you often want one flexible language that can do a little of everything, but it doesn't have to master any particular area or do it particularly well. E.g. Python.
Re: Go 1.9
On Sunday, 25 June 2017 at 10:50:17 UTC, Igor wrote: percent of developers needing memory management. The games industry is growing like crazy [1][2] and after all these years C++ is still the main language for that except that today 99% of those developers have many bad things to say about it. I think the number of games are increasing because people now can write games in other languages than C++. Unfortunately it is my impression many of those games are the same game-engine being redressed with differently themed graphics + some tweaks. article [3] has it explained nicely, except that it seems to me language should be marketed as general but have strong libraries (or game engines) for specific purposes through which it should market itself as something specialized. But you need a focus, figure out what you are good at and go with it. For which domain is your language the best option? Decent doesn
Re: Go 1.9
On Saturday, 24 June 2017 at 23:05:58 UTC, jmh530 wrote:
On Saturday, 24 June 2017 at 19:17:24 UTC, bachmeier wrote:
Just this morning I got things working on Windows. Now that
all three major platforms have support, it is as reasonable to
create an R package with D functions as C, C++ or Fortran.
Anyone can write up a library of D functions and put a package
on Bitbucket or Github. The R user doesn't even need to know
which language the functions are written in.
Music to my ears! Please put something up on announce when you
release it.
It will probably take a while to put together a formal release.
In the meantime, you can test it if you want. Here's an example
that works for me on 64-bit Windows (it's obviously not the only
way to do this).
1. Create the D file with the functions you want to call from R.
Save this in librtest.d:
import embedr.r;
mixin(createRLibrary("rtest"));
import std.math;
export extern(C) {
Robj transform(Robj rx) {
auto x = RVector(rx);
double[] y = [log(x[0]), log(x[1])];
double result = y[0] + y[1];
return result.robj;
}
}
2. Download embedr to that same directory
https://bitbucket.org/bachmeil/embedr/raw/89797bc39030a8433839119cfcdf7de6e8d7007c/inst/embedr/r.d
3. Windows requires R.lib for compilation, so I created that by
installing the MinGW pexports.exe utility.
C:\MinGW\bin\pexports.exe R.dll > R.def
Then create the .lib using Visual Studio:
"C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\bin\lib.exe" /def:R.def /out:R.lib /machine:x64
4. Create librtest.dll using LDC:
"C:\Users\lance\ldc64\ldc2-1.3.0-beta2-win64-msvc\bin\ldmd2.exe"
-shared -m64 librtest.d r.d -version=inline R.lib
5. Open 64-bit R, load the library, and test it out:
dyn.load("librtest.dll")
.Call("transform", c(2.0, 3.0))
Disclaimer: I don't know much about Windows development. It would
be nice to have others test this out and identify problems. I
would like to figure out how to make R packages with D code on
Windows before doing a release.
Re: Go 1.9
On Monday, 19 June 2017 at 15:07:12 UTC, Jack Stouffer wrote: On Monday, 19 June 2017 at 13:24:00 UTC, Russel Winder wrote: The former is not a problem for D, but the latter… Disagree. One of D's biggest competitive advantages is fast compilation of fast code. If other languages become as fast or faster than DMD in compilation speed then that's a big problem. I think the problem with this is that compilation speed being the no. 1 selling point requires people to invest in large projects in order to reap the benefits. However, if you fail to draw them in to begin with, then they're not going to commit to a large enough project to benefit enough from improved compilation speed.
Re: Go 1.9
Maybe I am wrong but I get a feeling from posts in this thread that some people are greatly underestimating the size of some segments, like mentioning niche C++ programmers and only 0.01% percent of developers needing memory management. The games industry is growing like crazy [1][2] and after all these years C++ is still the main language for that except that today 99% of those developers have many bad things to say about it. Imagine how D adoption would jump if someone created something on par with Unity or Unreal engine, or even Cocos engine in D. And I think D is already up to that task, with biggest pain points being only cross platform support, especially for Android and iOS. Also regarding the question whether D should be marketed as general purpose or some special purpose language I find this article [3] has it explained nicely, except that it seems to me language should be marketed as general but have strong libraries (or game engines) for specific purposes through which it should market itself as something specialized. [1] http://kotaku.com/nearly-40-of-all-steam-games-were-released-in-2016-1789535450 [2] http://www.gamasutra.com/view/news/267645/Over_500_games_now_submitted_to_iOS_App_Store_every_day.php [3] https://simpleprogrammer.com/2017/06/19/generalists-specialists/
Re: Go 1.9
On Saturday, 24 June 2017 at 19:17:24 UTC, bachmeier wrote: Just this morning I got things working on Windows. Now that all three major platforms have support, it is as reasonable to create an R package with D functions as C, C++ or Fortran. Anyone can write up a library of D functions and put a package on Bitbucket or Github. The R user doesn't even need to know which language the functions are written in. Music to my ears! Please put something up on announce when you release it. On my agenda next are interoperability with Julia and Octave (which isn't that popular, but would make a lot of Matlab code available inside D). I honestly don't know if this will bring in new D users, but for the most part I don't care, because I'm doing it for my own research. Nonetheless, I think the potential to expand the D userbase is there. I write less Matlab code these days than I used to, but I'm sure that would be valuable as well. There's a lot of Matlab code out there.
Re: Sponsorship [Re: Go 1.9]
On Saturday, 24 June 2017 at 21:56:20 UTC, Andrei Alexandrescu wrote: On 6/24/17 1:11 PM, Wulfklaue wrote: [snip] Thanks, this is a good point. The bountysource has been tried by Facebook (with D and other projects) and was deemed unsuccessful. It may be the time for trying a new angle on bountysource though. The issue with pure bounties is that while they may incentive people if the work vs reward is good. But unfortunately, when reading the bounties currently posted, a lot seem to be major amount of time vs little pay. That is why Nim / Crystal simply work with collecting money to pay developers for specific bounties or pay for full time people. It does not prevent people from doing there own bounties if they want. We'll look into defining a page listing existing sponsors (though the majority by monies are anonymous) and a simple method to donate on the website. As seen with Nim, Crystal, ... there are plenty of people who do not have a issue given a name or nickname. I think the current reason for a lot of anonymous donation is simply there is no real "advantage" for that person to have his/her name known. People are competitive animals. If you see what amount of money people sometimes donate to ( small ) youtube'rs. Sometimes thousand of dollars. All for being grateful by the person receiving the money and being the top donater. What other methods of payments do you have in mind? Germany: www.sofort.com Netherlands: www.ideal.nl ... Those are all popular in there respected countries. At times bigger then paypal etc... Nevertheless we need to update that. Might be interesting to also move the donation a bit more "visual" on the website. Its not the first time that issues regarding the website have been mentioned. * The library still using the horrible phobos/index.html 101 page library. There is now a link to the library/index.html that is way better. But its something that most people will overlook. * Tutorials: I found the old: https://www.tutorialspoint.com/d_programming/d_programming_associative_arrays.htm A more interesting spot to actually learn D examples, then the D website /spec/class.html. It more messy and finding out about sometimes as simply as associative_arrays, only to discover that its buried somewhere. * It might also be interesting to do a "Rust" and have Ali's D book provided as a standard free D book ( and maybe pay him something per download ). Now it already requires some searching or forum knowledge to find out the book is also available for free. Make it a prominent feature item on the website. Worth a extra blog post = free publicity again. :) * Local language websites. As somebody with family relations in China, i can say that there is a thriving Go community in China, where most Go related documentation got translated. Unfortunately, its a bit of "western" thinking, that everybody speaks / reads on a good level English. By not having localized language versions of major markets, D loses out on target audience. Go had the luxury that a lot of people comited time to do the translations and was rewarded with a large Go community in China. Something that most western developer do not even realize how big Go is in China. The idea that every software developer knows (any/good ) English is sometimes a bit exaggerated. So this is again a overlooked potential focus point. ... Plenty of topics regarding the website around ;) My biggest advice is to find or hire a community director. Somebody who's job is community management, media management, to focus resources etc. Some of the things that i mention seem to have been mentioned a lot of times before.
Sponsorship [Re: Go 1.9]
On 6/24/17 1:11 PM, Wulfklaue wrote: [snip] Thanks, this is a good point. The bountysource has been tried by Facebook (with D and other projects) and was deemed unsuccessful. It may be the time for trying a new angle on bountysource though. We'll look into defining a page listing existing sponsors (though the majority by monies are anonymous) and a simple method to donate on the website. Electronic wire transfer or bank check *bwahaaha*. What are we: 1980? What other methods of payments do you have in mind? Even worse, "Wire transfer information will be announced soon.". How long as that text been there??? That's not much to worry about - we did have a few wire transfers; it's not like people who want to wire us money have difficulty reaching us for details. Nevertheless we need to update that. Thanks, Andrei
Re: Go 1.9
On Saturday, 24 June 2017 at 17:43:36 UTC, Laeeth Isharc wrote: R is done (thanks bachmeier) Integration with R is largely complete, but the missing piece has always been lack of Windows support, which meant it wasn't an option for most users. Just this morning I got things working on Windows. Now that all three major platforms have support, it is as reasonable to create an R package with D functions as C, C++ or Fortran. Anyone can write up a library of D functions and put a package on Bitbucket or Github. The R user doesn't even need to know which language the functions are written in. This could possibly lead to wider adoption of D. Right now Rcpp is the most popular dependency for R packages (over 1000 at last check). And that's only a tiny fraction of overall Rcpp usage; many users write their own C++ code but don't upload a package to CRAN. It is my belief that these statisticians and econometricians and biologists - few of whom have a C++ background or know what a GC is - are open to a language like D. I plan to write a post on my website demonstrating usage soon. On my agenda next are interoperability with Julia and Octave (which isn't that popular, but would make a lot of Matlab code available inside D). I honestly don't know if this will bring in new D users, but for the most part I don't care, because I'm doing it for my own research. Nonetheless, I think the potential to expand the D userbase is there.
Re: Go 1.9
On Saturday, 24 June 2017 at 11:18:10 UTC, Ecstatic Coder wrote: On Saturday, 24 June 2017 at 10:34:07 UTC, Ola Fosheim Grøstad wrote: On Saturday, 24 June 2017 at 09:35:56 UTC, Ecstatic Coder wrote: I'm assuming that D is for general purpose programming as well. That seems to be where it is heading. I don't think D stands a chance in that domain, but we'll see. With all due respect, on the contrary I think that promoting D as a general purpose programming language could be its only chance to really improve its popularity, and thus significantly grow its current user base. I know that in certain other sectors, people have high expectations of growth, but I really am at a loss to know what it is that people might expect significant growth to be when we already have some pretty impressive developments in the numbers that we do have. http://erdani.com/d/downloads.daily.png Daily unique dmd downloads in Jan 2013 were 150-200 much of the time. This year they have been between 1200 and 1700. What kind of growth would it take for you to be satisfied - I am curious? Bearing in mind that the availability of all three compilers via distributions has been improving over time. And it seems to be unlikely to be a mere artefact of some sort because it lines up with what one observes in the forums, in what one hears about dconf lately versus prior years (I only went to the past couple) and more importantly in development activity - commercial and organic. Weka.io hadn't even heard of D about three years ago and now they have one of the largest D projects there is. 3.5 years ago me neither - and soon I will be paying for about 4.5 full time equivalent people to work on D (maybe a bit more than that in time). This little web company called eBay seems to be using it - never heard of them before, but they seem pretty smart. Remedy Games released Quantum Leap, which I guess sold millions of copies - it used D for scripting and they will be using D much more throughout the firm shortly. It's used by a $20+bn hedge fund for their trading systems, and will gain greater adoption within a $3.5bn hedge fund quite soon. https://dlang.org/orgs-using-d.html And somebody else remarked to me: "just look at code.dlang.org these days - some interesting libraries and I don't know even half the names that wrote them". D doesn't need to persuade most C++ users to switch over to succeed. It doesn't need to persuade anyone you know to succeed. It's at a stage where it's easy to keep growing without anything particularly dramatic happening. All it needs to do is appeal just that little bit more to people who are already minded to use D, or for whom people who are in pain and looking for an answer (which D might be in part) to find out about the language - as happened recently with Weka. And if I compare the documentation, libraries, and general quality of things today compared to 2014 when I started looking at the language, it's improving much faster than just a little bit every year. One doesn't notice such change necessarily quickly. I agree, but it will be hard for D to beat C++, because people who *need* to use C++ as a "systems programming language" won't use D for the same reasons they don't use C#, Java or Go. Finance is still one of the larger spenders as an industry. C++ is used quite broadly within it for analytics. Not because people want a system language and need to use malloc and free and freely drop down to assembly, but because there isn't an adequate alternative that's widely known about for now. In 3-5 years time, I think number of users in finance of D will be higher, because it's the solution to pain. Also, people tend to have end-users working in many different languages. Writing separate clients for each one isn't ideal, and wrapping automatically makes much more sense. SWIG works, after a fashion, but D offers some more pleasant and more maintainable alternatives. R is done (thanks bachmeier); Python is done (PyD); Excel is done (me, Stefan + Atila); C/C++ is easy enough; C# will be done shortly, and I have already done some work on Java. If you say that finance guys will never consider adopting D, I beg to differ because I think I know that world quite well. And that's just a world I am familiar with, and there are plenty of others. The web guys get the attention because they are doing interesting things, have particular challenges, and can afford to talk - because their edge doesn't mostly come from code, which is why they open-source so much of it. It's a mistake to think that the people who talk are a good representation of the total number of lines of code that are written each year, let alone the total code that exists. Visual Basic for Applications (Excel) programmers for example do not tend to get much attention - yet there's still a lot of code in VBA, a lot of new code being written each year.
Re: Go 1.9
On Saturday, 24 June 2017 at 12:11:29 UTC, Wulfklaue wrote: I never considered that D has a bountysource account. Its way, wy at the bottom of the monthly listing page. It did not even show up until 3 days ago. It was somewhat active for a while a couple years ago, but I found it to be simply offensive and a demotivator. They (including a large corporation that you've heard of having gigabucks) attached $50 bounties to bugs that would take several days of work to fix... then, of course, you have to go though the review process which has an indeterminate wait and frequently shifts goalposts. If any other client treated me like that, I'd walk away and never look back. (Heck, if any other client offered me what amounted to maybe $5 / hour, I'm not even sure that I'd waste my time actually telling them no - I might just ignore their emails as being a bad joke.) Bountysource has changed since then, and now has the salt program, but I think I'm not the only one who found it counterproductive in its early iteration and finds the brand damaged. If we wanted to revive it, it'd have to be clearly done differently than it was before. Electronic wire transfer or bank check *bwahaaha*. What are we: 1980? That's the way big donors actually prefer do business. Avoids having x% of their donation go to some for-profit middleman, and is easier accounting with the IRS. (D, being a legally incorporated not-for-profit organization, is required by US law to keep track of its financial information and publish an open report each year. Also, individuals and businesses donating to it can list that as a tax-deductible expense on their own annual returns - provided they have the necessary documentation.) There is no focus on raising funds. I talked about D Foundation being obscure but this blow my mind. Perhaps we need a new director of development!
Re: Go 1.9
On 24/06/2017 1:11 PM, Wulfklaue wrote: snip And sorry for the strong language but this is the truth! The fact that i as a newcomer needs to point this out is just ridiculous. Its easy to see why Nim and Crystal out fund D on bountysource. It's fine. You're not attacking anyone and not swearing for the sake of swearing :) My recommendation is to fund specific people or donate directly to the D foundation. If there were people willing to fund specific people, it'll pick up in time. As it stands it is mostly behind closed doors and going straight to the people. How to improve this without a giant wad of cash idk.
Re: Go 1.9
On Saturday, 24 June 2017 at 10:21:50 UTC, rikki cattermole wrote: What on earth are you talking about[0]? [0] https://www.bountysource.com/teams/d *wow* ... Call me amazed and dumbstruck. I never considered that D has a bountysource account. Its way, wy at the bottom of the monthly listing page. It did not even show up until 3 days ago. This is just ... /lost for words and that is a first. There is like one contribution 3 days ago and the last activity is 8 months. No open contributions in the last 2+ years. *wow* ... just *wow* ... Now i understand why some people complained that people if they wanted something, that they needed to pay for it. Expect people forgot to mention every time WHERE to put the payment. FFS ... i had people tell me several times pay for whatever feature and not a single person mention that D has a bountysource account. Where is it even on the website Other sites: Nim, one click on sponsors ( Top Page ) shows the sponsors and amounts or a big donate button ( bottom page ). https://nim-lang.org/sponsors.html Crystal, one click ( Top Page ) shows the sponsors and amounts. https://crystal-lang.org/sponsors/ D, ... press Community, then press Donate. Already two clicks, hidden in the drop down menu. https://dlang.org/donate.html A big wall of text, no mention of donators, there amount. And then paypal but no bountysource... Electronic wire transfer or bank check *bwahaaha*. What are we: 1980? Even worse, "Wire transfer information will be announced soon.". How long as that text been there??? Does the D team even look at there own website??? No offense but frankly, this is the equivalent of not having a bountysource account. Its simply hidden. There is no sponsors list, there is no motivation if people donate like "hey, my name is on the sponsor list". Or "hey, look, i am the top sponsor this month". For your information, i am still on the Nim list ;) I was under the impression that D with a bountysource account was going to be able to raise monthly funds on a higher level then Crystal and Nim. I really do not know what to say. No wonder when most new people do not even know its exists and the lack of acknowledgment on the website only reinforces this. There is no focus on raising funds. I talked about D Foundation being obscure but this blow my mind. Talk about lost opportunities on the website and general marketing. A community project that wants to grow but does not take its fundraising seriously... No no!!! Do not give me the party line: if you want it solved, then enhance the website. This is part of the core team there job. Its frankly the D Foundation there core job to ensure every left and right way money can be gained, so more people can be hired. And sorry for the strong language but this is the truth! The fact that i as a newcomer needs to point this out is just ridiculous. Its easy to see why Nim and Crystal out fund D on bountysource.
Re: Go 1.9
On Saturday, 24 June 2017 at 10:17:16 UTC, Wulfklaue wrote: On Saturday, 24 June 2017 at 09:35:56 UTC, Ecstatic Coder wrote: With all due respect, on the contrary I think that promoting D as a general purpose programming language could be its only chance to really improve its popularity, and thus significantly grow its current user base. I'm sorry to repeat myself once again on this forum, but it's obvious to me that D's strongest feature at the moment is that it has the best syntax on the market. I personally will not go that far. Syntax is more about preference. Rust looks dog ugly to me and yet some people find it beautiful. Personally i find Swift / Kotlin a nicer looking syntax then D. Reference types, strings, maps, slices, arrays, UFCS, etc, everything is made so that the most obvious and readable code will work both safely and efficiently. There is absolutely zero syntactic noise, the code is crystal clear. So instead of losing many potential users by focusing on a niche market (unhappy C++ programmers), D should focus on its major strengths, which already now make it stand high above its competition. Agrees with that. The problem with a language trying to scope away a specific group of developers, from a existing ecosystem is that your fighting the entire ecosystem, not just the language. That is a mistake that many new languages make. Why switch over from C++ to D? Language => Sure. Tooling => No. Libraries => No. Editors => No. ... That has been the dilemma that not only D has faced. Until you get critical mass where people start writing a massive amount of your ecosystem, its hard to get people to switch over. For instance, all these programmer-friendly features make D even more convenient for scripting than scripting languages themselves. True but the same can be said about Go. And Go is even more friendly and has the ecosystem now. You want to write something more exotic. There is big change that somebody wrote a module/package in Go. That is not going on with D. Sure, you can take a existing c library and transform it into D but it still takes work and is not always 100% idiomatic D. That is the main difference between D and lets say Kotlin. Kotlin build on top of Java and you can native imports all the libraries. There is less effort involved. Maybe this was mentioned before but a lot of programmers prefer to lazy program. They want to write there code, move forward with there project and not spend time on trying to get "things" to import/convert/work. D has more people who have no issue doing things the "hard" way. I applaud that resolve, i really do. But at the same time its a barrier, a attitude that makes it hard to accept those lazy people like me :) IMHO, trying to compete directly with C++, C# and Java, with the current state of the language and of its ecosystem, is simply choosing the hardest path to success... See above. Some people prefer the hard way. The masochists *haha*. I know the angle where your coming from Ecstatic but its hard to convince people. Especially when there is a manpower shortage. Frankly, i think the best way to go about moving D to popularity, is simply money. More fully time programmers but that requires money. I do not understand why D does not have a BountySource account ( salt.bountysource.com ). Look at nim ( $1,896 last month ) /crystal ( $2,345 this month ): They publish there fund raising. They motivate people by pointing out the backers. Their income is a extra full time developer ( who wants to work for cheap :) ). The whole D foundation is nice and well but to me it feels like cloak and daggers. It something hiding in the background, something obscure. Maybe i am not expressing myself good again but D its fund raising seems to be largely corporate focused but they seem to lose a big market potential. Corporate funding is harder to get then a lot of small donations. Its just my two cents but if D wants to grow, it needs full time developers. Not just volunteer work. People who can do the grunt work that volunteers do not want to do ( because its just not sexy ). I agree with all that you said. Just about Go, I must say that language is a bit rude, and actually less convenient and versatile than D. Many convenient features are missing (true reference classes, member function polymorphism, generics, etc). IMHO, Go is lagging somewhere between C and D. Kotlin is a better contender, especially with is LLVM implementation. And with its current ecosystem, I'm sorry to say that indeed Kotlin native is becoming de factor the best alternative to D.
Re: Go 1.9
On Saturday, 24 June 2017 at 10:34:07 UTC, Ola Fosheim Grøstad wrote: On Saturday, 24 June 2017 at 09:35:56 UTC, Ecstatic Coder wrote: I'm assuming that D is for general purpose programming as well. That seems to be where it is heading. I don't think D stands a chance in that domain, but we'll see. With all due respect, on the contrary I think that promoting D as a general purpose programming language could be its only chance to really improve its popularity, and thus significantly grow its current user base. Most programming languages are technically "general purpose", but when projects look for tooling they aren't looking for something generic, they are looking for a solution to a specific domain. So, for a language to succeed you need to provide the best solution to something specific. I agree, but it will be hard for D to beat C++, because people who *need* to use C++ as a "systems programming language" won't use D for the same reasons they don't use C#, Java or Go. Just its GC keeps many C++ developers away from it, whether is justified or not, despite D is as low level and performant. But a GC is rarely a problem for a scripter, because most scripting language already work this way. So I think promoting D as a "systems programming language" won't help in improving its popularity, as its GC doesn't make it the best solution on this market.
Re: Go 1.9
On Saturday, 24 June 2017 at 09:35:56 UTC, Ecstatic Coder wrote: I'm assuming that D is for general purpose programming as well. That seems to be where it is heading. I don't think D stands a chance in that domain, but we'll see. With all due respect, on the contrary I think that promoting D as a general purpose programming language could be its only chance to really improve its popularity, and thus significantly grow its current user base. Most programming languages are technically "general purpose", but when projects look for tooling they aren't looking for something generic, they are looking for a solution to a specific domain. So, for a language to succeed you need to provide the best solution to something specific.
Re: Go 1.9
On 24/06/2017 11:17 AM, Wulfklaue wrote: snip Frankly, i think the best way to go about moving D to popularity, is simply money. More fully time programmers but that requires money. I do not understand why D does not have a BountySource account ( salt.bountysource.com ). What on earth are you talking about[0]? [0] https://www.bountysource.com/teams/d
Re: Go 1.9
On Saturday, 24 June 2017 at 09:35:56 UTC, Ecstatic Coder wrote: With all due respect, on the contrary I think that promoting D as a general purpose programming language could be its only chance to really improve its popularity, and thus significantly grow its current user base. I'm sorry to repeat myself once again on this forum, but it's obvious to me that D's strongest feature at the moment is that it has the best syntax on the market. I personally will not go that far. Syntax is more about preference. Rust looks dog ugly to me and yet some people find it beautiful. Personally i find Swift / Kotlin a nicer looking syntax then D. Reference types, strings, maps, slices, arrays, UFCS, etc, everything is made so that the most obvious and readable code will work both safely and efficiently. There is absolutely zero syntactic noise, the code is crystal clear. So instead of losing many potential users by focusing on a niche market (unhappy C++ programmers), D should focus on its major strengths, which already now make it stand high above its competition. Agrees with that. The problem with a language trying to scope away a specific group of developers, from a existing ecosystem is that your fighting the entire ecosystem, not just the language. That is a mistake that many new languages make. Why switch over from C++ to D? Language => Sure. Tooling => No. Libraries => No. Editors => No. ... That has been the dilemma that not only D has faced. Until you get critical mass where people start writing a massive amount of your ecosystem, its hard to get people to switch over. For instance, all these programmer-friendly features make D even more convenient for scripting than scripting languages themselves. True but the same can be said about Go. And Go is even more friendly and has the ecosystem now. You want to write something more exotic. There is big change that somebody wrote a module/package in Go. That is not going on with D. Sure, you can take a existing c library and transform it into D but it still takes work and is not always 100% idiomatic D. That is the main difference between D and lets say Kotlin. Kotlin build on top of Java and you can native imports all the libraries. There is less effort involved. Maybe this was mentioned before but a lot of programmers prefer to lazy program. They want to write there code, move forward with there project and not spend time on trying to get "things" to import/convert/work. D has more people who have no issue doing things the "hard" way. I applaud that resolve, i really do. But at the same time its a barrier, a attitude that makes it hard to accept those lazy people like me :) IMHO, trying to compete directly with C++, C# and Java, with the current state of the language and of its ecosystem, is simply choosing the hardest path to success... See above. Some people prefer the hard way. The masochists *haha*. I know the angle where your coming from Ecstatic but its hard to convince people. Especially when there is a manpower shortage. Frankly, i think the best way to go about moving D to popularity, is simply money. More fully time programmers but that requires money. I do not understand why D does not have a BountySource account ( salt.bountysource.com ). Look at nim ( $1,896 last month ) /crystal ( $2,345 this month ): They publish there fund raising. They motivate people by pointing out the backers. Their income is a extra full time developer ( who wants to work for cheap :) ). The whole D foundation is nice and well but to me it feels like cloak and daggers. It something hiding in the background, something obscure. Maybe i am not expressing myself good again but D its fund raising seems to be largely corporate focused but they seem to lose a big market potential. Corporate funding is harder to get then a lot of small donations. Its just my two cents but if D wants to grow, it needs full time developers. Not just volunteer work. People who can do the grunt work that volunteers do not want to do ( because its just not sexy ).
Re: Go 1.9
I'm assuming that D is for general purpose programming as well. That seems to be where it is heading. I don't think D stands a chance in that domain, but we'll see. With all due respect, on the contrary I think that promoting D as a general purpose programming language could be its only chance to really improve its popularity, and thus significantly grow its current user base. I'm sorry to repeat myself once again on this forum, but it's obvious to me that D's strongest feature at the moment is that it has the best syntax on the market. Reference types, strings, maps, slices, arrays, UFCS, etc, everything is made so that the most obvious and readable code will work both safely and efficiently. There is absolutely zero syntactic noise, the code is crystal clear. So instead of losing many potential users by focusing on a niche market (unhappy C++ programmers), D should focus on its major strengths, which already now make it stand high above its competition. For instance, all these programmer-friendly features make D even more convenient for scripting than scripting languages themselves. Just add the instant compilation, and you actually have the perfect language for scripters and learning/inexperienced programmers who currently choose JavaScript, Python, Ruby because they don't know that the perfect language for their needs is actually D. I strongly believe that D has the potential to be the killer "general purpose" language if : 1/ it is also promoted with this target in mind 2/ a few additional pre-installed libraries (web + ui) would make it as easy to develop cross-platform connected applications. IMHO, trying to compete directly with C++, C# and Java, with the current state of the language and of its ecosystem, is simply choosing the hardest path to success...
Re: Go 1.9
On Friday, 23 June 2017 at 14:45:12 UTC, Bienlein wrote: I'm assuming that D is for general purpose programming as well. That seems to be where it is heading. I don't think D stands a chance in that domain, but we'll see.
Re: Go 1.9
On Friday, 23 June 2017 at 22:38:29 UTC, Paulo Pinto wrote: On Friday, 23 June 2017 at 21:31:00 UTC, Araq wrote: ... That's just "I looked at the websites, never used these tools in practice but found them convincing" phrased differently to pretend you have an argument. The success of Go strongly indicates people generally don't connect Java/C# to "native code" or "slim binaries without dependencies", whom are you kidding here. You are right, it was a mistake to come back to these forums, after the GDC announcement. Looking forward to see blazing fast D applications on the Windows store. Just FYI, Araq is the author of Nim (https://nim-lang.org/), so I'm sure he didn't have any intention in making D look good ;) On the other hand, I think he made good technical arguments, (leaving aside his Ad Hominem way of expressing, which I think was out of place) which I think you should actually consider.
Re: Go 1.9
On Friday, 23 June 2017 at 22:35:04 UTC, Paulo Pinto wrote: On Friday, 23 June 2017 at 20:25:10 UTC, Joakim wrote: C# lost out internally at Microsoft precisely because of how bloated it made everything, with signs that native is ascendant again in recent years: https://hackernoon.com/what-really-happened-with-vista-4ca7ffb5a1a C# lost the Longhorn/Vista battle, but won the Windows 10 UWP one. I wouldn't say C# won, UWP is implemented in C++ and supports C++. Of course, UWP is so unpopular that they eventually allowed Win32 apps into their store: https://arstechnica.com/information-technology/2016/09/desktop-apps-make-their-way-into-the-windows-store/ Now they are so desparate for people to use it that they just released a version of Windows that will only install UWP apps, Windows 10 S: https://arstechnica.com/information-technology/2017/05/microsoft-takes-on-chrome-os-with-new-windows-10-s/ Try to find the C++ talks. https://channel9.msdn.com/Events/Build/2017 You seem to have missed the bit where I said C# lost _internally_. Their plan, as detailed in the Vista link, was to move all their own apps to C#, which has yet to happen. I hear C# has been very successful for corporate LoB apps, which are developed quickly and not used widely enough to spend much time on optimizing for performance. On Friday, 23 June 2017 at 22:38:29 UTC, Paulo Pinto wrote: Looking forward to see blazing fast D applications on the Windows store. Why? The Windows Store is a ghost town, with google not even bothering to package Chrome on there, despite their browser being the most installed and used app on Windows.
Re: Go 1.9
On Friday, 23 June 2017 at 21:31:00 UTC, Araq wrote: ... That's just "I looked at the websites, never used these tools in practice but found them convincing" phrased differently to pretend you have an argument. The success of Go strongly indicates people generally don't connect Java/C# to "native code" or "slim binaries without dependencies", whom are you kidding here. You are right, it was a mistake to come back to these forums, after the GDC announcement. Looking forward to see blazing fast D applications on the Windows store.
Re: Go 1.9
On Friday, 23 June 2017 at 20:25:10 UTC, Joakim wrote: On Friday, 23 June 2017 at 16:49:54 UTC, Kagamin wrote: On Friday, 23 June 2017 at 06:41:26 UTC, Bienlein wrote: Java, Kotlin, C# are still Jit compiled languages, with the memory footprint to prove it :) The memory footprint doesn't matter. Those times are OVER :-). Do you want D to compete in enterprise domain? Of 16 programs running on my machine 13 are native. Not only that, but the majority of use of Java and soon Kotlin is on Android, where efficiency and memory footprint matters a lot, hence Java moving to AoT-compilation when Android 5.0 released three years ago and adding a concurrent GC: https://arstechnica.com/gadgets/2014/11/android-5-0-lollipop-thoroughly-reviewed/3/#h2 C# lost out internally at Microsoft precisely because of how bloated it made everything, with signs that native is ascendant again in recent years: https://hackernoon.com/what-really-happened-with-vista-4ca7ffb5a1a Bienlein may be right that there are niches where memory footprint doesn't matter and there were years where it wasn't a big deal, but it's back now. RAM is really cheap today, but latency and power efficiency are the big issues. You could put 8 GBs of RAM in every smartphone right now, and there are some models which do (http://www.gsmarena.com/oneplus_5-8647.php), but the only reason most don't is because it'd suck a lot more power. C# lost the Longhorn/Vista battle, but won the Windows 10 UWP one. Try to find the C++ talks. https://channel9.msdn.com/Events/Build/2017
Re: Go 1.9
On Friday, 23 June 2017 at 20:13:15 UTC, Paulo Pinto wrote: ExcelsiorJET is quite easy to figure out, you can download their open source version. So in other words, you do not have used these products and only read their websites, got it. Some products go the static linking way, others map .jars into shared libraries. And how does the tool know which .jars to compile to shared libraries without running the code first? It can't. Which is why Excelsior ships with a JIT: From https://www.excelsiorjet.com/ "First, the AOT compiler turns your jar and class files into a conventional binary executable. That executable is fully interoperable with our JVM, which includes a JIT compiler to handle any classes that were not precompiled." Nice how you overlook the fact that .NET Native requires static linking, hence why there are such issues. AOT compiling to native code with either NGEN or Windows 8 MDIL compiler doesn't have such issues, because dynamic linking is used instead. Again, how can you compile ahead-of-time when you don't know the dependencies before running the program? You can't which is why every such tool is at a fight with how these languages work. In any case, even if native compilation toolchains for Java and C# aren't perfect, they make it less appealing to try out D if you don't come up with a solid history to go against them, that make people actually curious to try out D. That's just "I looked at the websites, never used these tools in practice but found them convincing" phrased differently to pretend you have an argument. The success of Go strongly indicates people generally don't connect Java/C# to "native code" or "slim binaries without dependencies", whom are you kidding here.
Re: Go 1.9
On Friday, 23 June 2017 at 16:49:54 UTC, Kagamin wrote: On Friday, 23 June 2017 at 06:41:26 UTC, Bienlein wrote: Java, Kotlin, C# are still Jit compiled languages, with the memory footprint to prove it :) The memory footprint doesn't matter. Those times are OVER :-). Do you want D to compete in enterprise domain? Of 16 programs running on my machine 13 are native. Not only that, but the majority of use of Java and soon Kotlin is on Android, where efficiency and memory footprint matters a lot, hence Java moving to AoT-compilation when Android 5.0 released three years ago and adding a concurrent GC: https://arstechnica.com/gadgets/2014/11/android-5-0-lollipop-thoroughly-reviewed/3/#h2 C# lost out internally at Microsoft precisely because of how bloated it made everything, with signs that native is ascendant again in recent years: https://hackernoon.com/what-really-happened-with-vista-4ca7ffb5a1a Bienlein may be right that there are niches where memory footprint doesn't matter and there were years where it wasn't a big deal, but it's back now. RAM is really cheap today, but latency and power efficiency are the big issues. You could put 8 GBs of RAM in every smartphone right now, and there are some models which do (http://www.gsmarena.com/oneplus_5-8647.php), but the only reason most don't is because it'd suck a lot more power.
Re: Go 1.9
On Friday, 23 June 2017 at 19:27:56 UTC, Araq wrote: On Thursday, 22 June 2017 at 11:27:47 UTC, Paulo Pinto wrote: Java is AOT compiled to native code via Excelsior JET, IBM J9, IBM Websphere RealTime, JamaicaVM, SubstrateVM, Android ART and eventually Java 10. Have you used one of these products? How do they deal with dynamic class loading? I know how JamaicaVM does it, no thanks. ExcelsiorJET is quite easy to figure out, you can download their open source version. Some products go the static linking way, others map .jars into shared libraries. C# is AOT compiled to native code since day 1, via NGEN, althouth it isn't an optimizing compiler and only supports dynamic linking. From https://docs.microsoft.com/en-us/dotnet/framework/net-native/net-native-and-compilation "Because the .NET Native tool chain links implementation code into your app only if it knows that your app actually invokes that code, either the metadata or the implementation code required in the following scenarios may not be included with your app: * Reflection. * Dynamic or late-bound invocation. * Serialization and deserialization. * COM interop. If the necessary metadata or implementation code is absent at runtime, the .NET Native runtime throws an exception. You can prevent these exceptions, and ensure that the .NET Native tool chain includes the required metadata and implementation code, by using a runtime directives file, an XML file that designates the program elements whose metadata or implementation code must be available at runtime and assigns a runtime policy to them. The following is the default runtime directives file that is added to a Windows Store project that is compiled by the .NET Native tool chain: ..." Better learn what the competition is actually doing. Reflection and dynamic class loading are essential parts of C# and Java and do not work well with AOT compilation and never will. Money can't patch over design mistakes. Nice how you overlook the fact that .NET Native requires static linking, hence why there are such issues. AOT compiling to native code with either NGEN or Windows 8 MDIL compiler doesn't have such issues, because dynamic linking is used instead. Also .NET Native is still kind of work in progress, as they still try to bring more features from System C# into regular .NET toolchain. With every Windows 10 SDK release there are new improvement made to it. In any case, even if native compilation toolchains for Java and C# aren't perfect, they make it less appealing to try out D if you don't come up with a solid history to go against them, that make people actually curious to try out D.
Re: Go 1.9
On Thursday, 22 June 2017 at 11:27:47 UTC, Paulo Pinto wrote: Java is AOT compiled to native code via Excelsior JET, IBM J9, IBM Websphere RealTime, JamaicaVM, SubstrateVM, Android ART and eventually Java 10. Have you used one of these products? How do they deal with dynamic class loading? I know how JamaicaVM does it, no thanks. C# is AOT compiled to native code since day 1, via NGEN, althouth it isn't an optimizing compiler and only supports dynamic linking. From https://docs.microsoft.com/en-us/dotnet/framework/net-native/net-native-and-compilation "Because the .NET Native tool chain links implementation code into your app only if it knows that your app actually invokes that code, either the metadata or the implementation code required in the following scenarios may not be included with your app: * Reflection. * Dynamic or late-bound invocation. * Serialization and deserialization. * COM interop. If the necessary metadata or implementation code is absent at runtime, the .NET Native runtime throws an exception. You can prevent these exceptions, and ensure that the .NET Native tool chain includes the required metadata and implementation code, by using a runtime directives file, an XML file that designates the program elements whose metadata or implementation code must be available at runtime and assigns a runtime policy to them. The following is the default runtime directives file that is added to a Windows Store project that is compiled by the .NET Native tool chain: ..." Better learn what the competition is actually doing. Reflection and dynamic class loading are essential parts of C# and Java and do not work well with AOT compilation and never will. Money can't patch over design mistakes.
Re: Go 1.9
On Friday, 23 June 2017 at 06:41:26 UTC, Bienlein wrote: Java, Kotlin, C# are still Jit compiled languages, with the memory footprint to prove it :) The memory footprint doesn't matter. Those times are OVER :-). Do you want D to compete in enterprise domain? Of 16 programs running on my machine 13 are native.
Re: Go 1.9
On Fri, 2017-06-23 at 13:14 +, Wulfklaue via Digitalmars-d wrote: > On Monday, 19 June 2017 at 16:13:20 UTC, Russel Winder wrote: > > I'd be more bothered by Kotlin native that Scala native. > > Well, Kotlin/Native just came out with version 0.3. And it > includes Windows support. Take that Apple/Swift ;) > > Its impressive how fast things are being developer by Jetbrain. > > There first release ( 0.1 ) on 31 March 2017. > Then Coroutines ( 0.2 ) on 11 May 2017. > Now Windows support ( 0.3 ) on June 23 2017. I suspect this is a tribute to LLVM as well as the Kotlin Native team. Like LDC takes DMD frontend and injects into the LLVM backend, so Kotlin Native takes the Kotlin frontend and injects into LLVM. Sadly they currently just use the GTK C API directly, rather than having a Kotlin idiomatic binding. Not competition for D in the GTK GStreamer arena just yet. I have however put in issues. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +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: Go 1.9
On Friday, 23 June 2017 at 14:07:09 UTC, Ola Fosheim Grøstad wrote: On Friday, 23 June 2017 at 11:15:40 UTC, Bienlein wrote: I have not done any manual memory management at work for the last 25 years. But are you doing any programming for the low end of the hardware spectrum? It has been the low end hardware limitations that have the standard for memory consumption… I'm assuming that D is for general purpose programming as well.
Re: Go 1.9
On Friday, 23 June 2017 at 11:15:40 UTC, Bienlein wrote: I have not done any manual memory management at work for the last 25 years. But are you doing any programming for the low end of the hardware spectrum? It has been the low end hardware limitations that have the standard for memory consumption…
Re: Go 1.9
On Monday, 19 June 2017 at 16:13:20 UTC, Russel Winder wrote: I'd be more bothered by Kotlin native that Scala native. Well, Kotlin/Native just came out with version 0.3. And it includes Windows support. Take that Apple/Swift ;) Its impressive how fast things are being developer by Jetbrain. There first release ( 0.1 ) on 31 March 2017. Then Coroutines ( 0.2 ) on 11 May 2017. Now Windows support ( 0.3 ) on June 23 2017.
Re: Go 1.9
On Friday, 23 June 2017 at 08:57:04 UTC, Ola Fosheim Grøstad wrote: On Friday, 23 June 2017 at 06:41:26 UTC, Bienlein wrote: Java, Kotlin, C# are still Jit compiled languages, with the memory footprint to prove it :) The memory footprint doesn't matter. Those times are OVER :-). People said that 30 years ago too... It is still an issue, though. Not as much as it was, but still relevant. Programmers seem to be able to suck up whatever RAM is available on the low-end by adding frameworks, bloated libraries and runtimes, or just bugs… I have not done any manual memory management at work for the last 25 years. Did some C++ programming at college and a bit at home where I had to take care of memory myself. That was it. Till I retire in 20 years I will also not have been doing any manual memory management. That kind of stuff only survives in very special areas where 0.1% of all software developers work. That being said let me repeat that D needs a decent GC for being able to create any traction, because those 99.9% of the share are the far bigger market.
Re: Go 1.9
On Friday, 23 June 2017 at 06:41:26 UTC, Bienlein wrote: Java, Kotlin, C# are still Jit compiled languages, with the memory footprint to prove it :) The memory footprint doesn't matter. Those times are OVER :-). People said that 30 years ago too... It is still an issue, though. Not as much as it was, but still relevant. Programmers seem to be able to suck up whatever RAM is available on the low-end by adding frameworks, bloated libraries and runtimes, or just bugs…
Re: Go 1.9
On Friday, 23 June 2017 at 06:41:26 UTC, Bienlein wrote: Java, Kotlin, C# are still Jit compiled languages, with the memory footprint to prove it :) The memory footprint doesn't matter. Those times are OVER :-). Here are some references: http://benchmarksgame.alioth.debian.org/u64q/go.html http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=gcc There you can see how little memory Go uses compared to C and Java. Java will also get better as it will also get value types in some upcoming JDK.
Re: Go 1.9
Java, Kotlin, C# are still Jit compiled languages, with the memory footprint to prove it :) The memory footprint doesn't matter. Those times are OVER :-).
Re: Go 1.9
On Thursday, 22 June 2017 at 10:23:37 UTC, Russel Winder wrote: On Thu, 2017-06-22 at 10:00 +, Paulo Pinto via Digitalmars-d wrote: […] They were all about Swift, Java, Kotlin, C#. Isn't Swift a native code language? Just like Java when one uses any commercial JDK or C# when targeting UWP or Windows 8.x devices.
Re: Go 1.9
On Thursday, 22 June 2017 at 11:11:01 UTC, Wulfklaue wrote: On Thursday, 22 June 2017 at 10:23:37 UTC, Russel Winder wrote: On Thu, 2017-06-22 at 10:00 +, Paulo Pinto via Digitalmars-d wrote: […] They were all about Swift, Java, Kotlin, C#. Those are also the major players in the market. C# Microsoft, Swift Apple, Java Oracle... so there is more focus on them naturally. Isn't Swift a native code language? Yep ... Its it uses LLVM. Java, Kotlin, C# are still Jit compiled languages, with the memory footprint to prove it :) Java is AOT compiled to native code via Excelsior JET, IBM J9, IBM Websphere RealTime, JamaicaVM, SubstrateVM, Android ART and eventually Java 10. Sun was the only one religilous against any kind of AOT support, all major commercial JDKs always supported AOT compilation. C# is AOT compiled to native code since day 1, via NGEN, althouth it isn't an optimizing compiler and only supports dynamic linking. C# and VB.NET for Windows 8 and Windows 8.1 only support AOT compilation to native code via a format called MDIL (Machine Dependent Intermediate Language), basically native code with symbolic labels, linked on the devices at installation time. C# and VB.NET for UWP are always AOT compiled to native code and static linking is used. Better learn what the competition is actually doing.
Re: Go 1.9
On Thursday, 22 June 2017 at 10:23:37 UTC, Russel Winder wrote: On Thu, 2017-06-22 at 10:00 +, Paulo Pinto via Digitalmars-d wrote: […] They were all about Swift, Java, Kotlin, C#. Those are also the major players in the market. C# Microsoft, Swift Apple, Java Oracle... so there is more focus on them naturally. Isn't Swift a native code language? Yep ... Its it uses LLVM. Java, Kotlin, C# are still Jit compiled languages, with the memory footprint to prove it :) C# may change to a native compiled language with CoreRT ( This translates C# to C++ code and then compiles it. A bit like Haxe (C++ target) or Nim(C target) ).
Re: Go 1.9
On Thu, 2017-06-22 at 10:00 +, Paulo Pinto via Digitalmars-d wrote: > […] > > They were all about Swift, Java, Kotlin, C#. > Isn't Swift a native code language? > -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +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: Go 1.9
On Thursday, 22 June 2017 at 07:15:26 UTC, Bienlein wrote: I suspect though that like Go took Python more than C folk, Kotlin Native will take more Java that C++, Go and Rust folks. But speculation rarely turn out quite as speculated. In Java development there is almost no C or C++ and no Rust or D at all. Memory is no problem. Some server needs 256 GB RAM or maybe 512 GB? That's not an issue anywhere. As long as you get the performance through parallelisation there is no need for C or C++. You won't meet any Java EE archtitecture that will do anything else than fight against calling C, C++ routines from Java. That is only done in some very exceptional cases. This includes how Android developers see the use of the NDK, and I quote: """ Squeeze extra performance out of a device to achieve low latency or run computationally intensive applications, such as games or physics simulations. Reuse your own or other developers' C or C++ libraries. """ https://developer.android.com/ndk/guides/index.html Anything else is frowned upon and only available to Java, requiring JNI calls to access the features from C and C++. They even pivoted Brillo from a being a simplified Android with C++ Framework, to a simplified Android where even user space drivers can be written in Java. https://developer.android.com/things/sdk/drivers/index.html The days of languages for systems programming are over. There are only very few people that need such a language. That is why D really needs a decent GC, otherwise it won't find any users that would do production systems with it. This was quite visible at this year's WWDC, Google IO and BUILD. They were all about Swift, Java, Kotlin, C#. There were hardly any meaningful talks with C or C++ content related to actual software development on their OSes, other than to share the latest improvements in compiler/IDE tooling and ANSI C++ compliance.
Re: Go 1.9
On Thu, 2017-06-22 at 07:15 +, Bienlein via Digitalmars-d wrote: > > […] > In Java development there is almost no C or C++ and no Rust or D > at all. Memory is no problem. Some server needs 256 GB RAM or > maybe 512 GB? That's not an issue anywhere. As long as you get > the performance through parallelisation there is no need for C or > C++. The whole "Just add more memory" approach of JVM installations leads to some really crap programs and programming. And what is worse, they do not even do parallelism properly. Whenever I did Java workshops, I was always dreadfully disappointed how bad at programming the lower 50% of programmers were. I.e. the average Java programmer is really not very good. A fairly good metric in the UK is, if a supposed Java programmer hasn't heard of DevoxxUK or JAXLondon or has heard of them but doesn't want to go, then they are not a Java programmer, they are just robots turning out Java code, disinterested in their profession.. > You won't meet any Java EE archtitecture that will do anything > else than fight against calling C, C++ routines from Java. That > is only done in some very exceptional cases. Same goes for people sensibly avoiding Java EE and using Springboot or container-base system, even those using Tomcat. JNI is horrible, to be used only if absolutely necessary. Hence JNA, JNR, etc. all designed to make FFI easier with the JVM. The next round of Charlie Nutter's assault on JVM FFI may make things a lot better. > The days of languages for systems programming are over. There are > only very few people that need such a language. That is why D > really needs a decent GC, otherwise it won't find any users that > would do production systems with it. It depends what you mean by systems programming. Go folk for example seems to thing anything to do with The Web is systems programming. Whilst many people see The Web as the only thing that programmers do, I bet that most software has nothing to do with it. JVM-based system account for a lot, but it is nearly all Web oriented. Python has hegemony currently (but not for long I'll wager) in AI and machine learning. Many, including some Scala and Kotlin folk see the constraints of the JVM (that containers, Docker, and Kubernetes have quite nicely highlighted) – native code is resurgent. But yes, there are different forms of native code, and I agree, there are places where a GC cannot be used (hard real time currently, but people are working on that, again cf. Go folk), and the rest where GC is a good thing. But only a good GC is a good thing – this lesson comes from 20 years of JVM. The JVM has encouraged research and implementation of GCs. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +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: Go 1.9
On Thursday, 22 June 2017 at 07:32:51 UTC, Wulfklaue wrote: On Thursday, 22 June 2017 at 07:15:26 UTC, Bienlein wrote: In Java development there is almost no C or C++ and no Rust or D at all. Memory is no problem. Some server needs 256 GB RAM or maybe 512 GB? That is just sloppy... There is this bad trend in the industry, it has been going on for years. Performance issue, trow more hardware at the problem. Optimizations? Trow more hardware at the issue. The problem being that it has becomes a constantly lowering expectations bar. Hire some basic programmers, use php/ruby/python and performance issues are simply overlooked as part of the job. In my daily job seeing php import scripts that suck up a GB just for some basic work, is considered almost normal. Let the client pay for more performing servers. Our developers need to write more code, faster, be ready before the deadline so we can bill the client for the fast work. That's not an issue anywhere. As long as you get the performance through parallelisation there is no need for C or C++. And while this works on a local server, the moment you start with clusters, master-slave configurations etc, things get complicated fast. Especially with latency issues. You won't meet any Java EE archtitecture that will do anything else than fight against calling C, C++ routines from Java. That is only done in some very exceptional cases. That same applies to just about every other language. Native will always be prioritized before external calls. The days of languages for systems programming are over. There are only very few people that need such a language. That is why D really needs a decent GC, otherwise it won't find any users that would do production systems with it. Technically, with Go, Rust, Crystal etc more about those high performing languages, then before. Before it was all about scripting languages, slowly you see a trend backing away from them. Massive relative price shocks can be important in shaping trends in the use of technology. Storage prices drop 40% annually, Moore'a Law isn't what it was, and dram latency isn't improving nearly as fast as data sets are increasing in size. Intel non volatile storage technology upsets all our assumptions about where the bottlenecks are, and there seems a decent chance that as you say the tilt away from slow languages is only just beginning. https://www.quora.com/Why-is-Python-so-popular-despite-being-so-slow/answer/Laeeth-Isharc?share=5ebdf91a&srid=35gE Acam paper linked at the end of this.
Re: Go 1.9
On Thursday, 22 June 2017 at 07:15:26 UTC, Bienlein wrote: In Java development there is almost no C or C++ and no Rust or D at all. Memory is no problem. Some server needs 256 GB RAM or maybe 512 GB? That is just sloppy... There is this bad trend in the industry, it has been going on for years. Performance issue, trow more hardware at the problem. Optimizations? Trow more hardware at the issue. The problem being that it has becomes a constantly lowering expectations bar. Hire some basic programmers, use php/ruby/python and performance issues are simply overlooked as part of the job. In my daily job seeing php import scripts that suck up a GB just for some basic work, is considered almost normal. Let the client pay for more performing servers. Our developers need to write more code, faster, be ready before the deadline so we can bill the client for the fast work. That's not an issue anywhere. As long as you get the performance through parallelisation there is no need for C or C++. And while this works on a local server, the moment you start with clusters, master-slave configurations etc, things get complicated fast. Especially with latency issues. You won't meet any Java EE archtitecture that will do anything else than fight against calling C, C++ routines from Java. That is only done in some very exceptional cases. That same applies to just about every other language. Native will always be prioritized before external calls. The days of languages for systems programming are over. There are only very few people that need such a language. That is why D really needs a decent GC, otherwise it won't find any users that would do production systems with it. Technically, with Go, Rust, Crystal etc more about those high performing languages, then before. Before it was all about scripting languages, slowly you see a trend backing away from them.
Re: Go 1.9
I suspect though that like Go took Python more than C folk, Kotlin Native will take more Java that C++, Go and Rust folks. But speculation rarely turn out quite as speculated. In Java development there is almost no C or C++ and no Rust or D at all. Memory is no problem. Some server needs 256 GB RAM or maybe 512 GB? That's not an issue anywhere. As long as you get the performance through parallelisation there is no need for C or C++. You won't meet any Java EE archtitecture that will do anything else than fight against calling C, C++ routines from Java. That is only done in some very exceptional cases. The days of languages for systems programming are over. There are only very few people that need such a language. That is why D really needs a decent GC, otherwise it won't find any users that would do production systems with it.
Re: Go 1.9
On Mon, 2017-06-19 at 19:07 +, Ecstatic Coder via Digitalmars-d wrote: > […] > > But Go still doesn't have proper generics, which keeps it > light-years behind D in terms of expressivity. Go doesn't have, and likely will never have, generics in the C++, D, Chapel sense, but then Rust doesn't either. Go has two routes for achieving the goal that C++ generics (and hence D and Chapel generics) were intended for. You have to use the idiomatic approach for the language. Saying Go is behind D is missing the point that the languages are different and have to be used differently to achieve the same goal. > Still time to convince people to use D instead of Go then... The only way of doing this is to have lots of problems programmed idiomatically in D, Go, Rust, Kotlin, with unbiased compare and contrast notes. You end up finding different languages are best in different problems. Which is hardly a surprise. Generally it is the libraries that are the truly key factors. And do not underestimate personal choice, different language gel with different people (though there is some Stockholm Syndrome effect with some people). For me just now, D beats C++ for working with Gtk and GStreamer. For other problems I go with Go, or partake of Python. C++17, or more likely C++20, may make C++ interesting again. I though C++11 had, but in the end it didn't. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +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: Go 1.9
On Monday, 19 June 2017 at 16:13:20 UTC, Russel Winder wrote: I'd be more bothered by Kotlin native that Scala native. Thanks, did not even know that Jetbrain is also going for a native LLVM version. It even seems they are in contact with the Scala-native team. Looks like everybody is jumping on the native LLVM compilation bandwagon.
Re: Go 1.9
On Monday, 19 June 2017 at 13:24:00 UTC, Russel Winder wrote: Go gets parallel compilation, at last, and better garbage collection. The former is not a problem for D, but the latter… Indeed a faster garbage collector will be a good selling point for Go. But Go still doesn't have proper generics, which keeps it light-years behind D in terms of expressivity. Still time to convince people to use D instead of Go then...
Re: Go 1.9
On Mon, 2017-06-19 at 15:44 +, bpr via Digitalmars-d wrote: > On Monday, 19 June 2017 at 13:24:00 UTC, Russel Winder wrote: > > Go gets parallel compilation, at last, and better garbage > > collection. The former is not a problem for D, but the latter… > > > > > > It should also be noted that, even though it's still a research > project, Scala native just recently upgraded it's Boehm GC to an > Immix based one. Scala native would be yet another language > competing with D, and might compete in even more domains than Go > would. I'd be more bothered by Kotlin native that Scala native. Scala did a lot for the JVM in terms of getting "functional" accepted as a word that wasn't a swear word. However it is a very complicated language. Kotlin is a great "half way house" in replacing Java but not being as complicated as Scala but with the same "functional objects" approach that Scala started and championed. Scala trieed as yet.d to be and now Kotlin has become the language of choice for the discerning JVM-oriented Android developer. With Kotlin Native now announced and going great guns, it may be that C++, D, Rust, and Go, get a challenge that Scala Native has not managed. I suspect though that like Go took Python more than C folk, Kotlin Native will take more Java that C++, Go and Rust folks. But speculation rarely turn out quite as speculated. -- 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: Go 1.9
On Monday, 19 June 2017 at 15:44:47 UTC, bpr wrote: It should also be noted that, even though it's still a research project, Scala native just recently upgraded it's Boehm GC to an Immix based one. Scala native would be yet another language competing with D, and might compete in even more domains than Go would. Immix has a very impressive speed compared to default Boehm. http://img.phperz.com/data/img/20170616/1497580303_4280.png
Re: Go 1.9
On Monday, 19 June 2017 at 13:24:00 UTC, Russel Winder wrote: Go gets parallel compilation, at last, and better garbage collection. The former is not a problem for D, but the latter… It should also be noted that, even though it's still a research project, Scala native just recently upgraded it's Boehm GC to an Immix based one. Scala native would be yet another language competing with D, and might compete in even more domains than Go would.
Re: Go 1.9
On Monday, 19 June 2017 at 13:24:00 UTC, Russel Winder wrote: The former is not a problem for D, but the latter… Disagree. One of D's biggest competitive advantages is fast compilation of fast code. If other languages become as fast or faster than DMD in compilation speed then that's a big problem.
Re: Go 1.9
On Monday, 19 June 2017 at 13:24:00 UTC, Russel Winder wrote: Go gets parallel compilation, at last, and better garbage collection. The former is not a problem for D, but the latter… Right, D2 has a problem with the GC. It cannot be put to reasonable speed, because of initial design decisions with D memory management. If there is a reason for D3, then it is to make the required changes so that the GC can be made faster. The GC is in my opinion very important for the success of D. Go is the best example that a programming language for "system-like" programming can have a huge success out there in the real world. If using the GC were problem free in D, a lot of projects that chose Go might have gone with D. And there are tons of applications out there that are the flag ship product of some startup company that are written in Go. So the best thing that can happen to D, IMHO, is that the GC issue is resolved even if that required a move from D2 to D3.
