Re: Vision for the first semester of 2016
Some of this apparently off-topic, but I will get back on-topic by the end. On Tue, 2016-01-26 at 21:17 +1300, Rikki Cattermole via Digitalmars-d- announce wrote: > I wasn't going to reply, until you tweeted. Sorry for wrongly assigning geography. > No just no. Yes, oh yes, oh yes. > When dealing with tertiary institutions especially New Zealand ones, > you've got to understand they have massive pressure to get through > content. Every single class is standardized nationally, by law. Sounds like the NZ system is not as good a tertiary education system as it should be. Having guidelines for curriculum and examination is fine, but to stadardize at the class level is definitely too low. UK universities went through this debate in the 1980 and managed to escape from legal enforcement. > You're all worried about doing things best practice in an eco-system. > That is just not the case here. In these courses they are not meant > to > be teaching a language. But instead use said language to teach with. There should also be classes in applications construction. Clearly classes on specification, compilers, etc. the language is tool only and workflow and best practice of programming are irrelevant. > The most time a student gets in ANY language is 2 semesters. By the > time > they reach third year (last) they only have 1 per language. > In these classes the concern is teaching some other relevant concept > such as design patterns. Design patterns are not language agnostic. GoF patterns are 23 year old and many totally irrelevant with certain programming languages. However that is a different debate for a different place. > So you're pushing limited class time for the purpose of teaching > actual > class content instead of non required information for assignments. > Its a balancing act. It sounds like the law makers are getting it wrong then. If there is no time for teaching programming best practice then graduates from the programme are not ready for employment without first doing an apprenticeship of some sort. > But you've got to understand that most of the students going through > it, > are just not interested in going much further then the assignments. > Simple things like trying OpenGL are beyond them and this is ok. > They > have a lot of things to learn and have real life requirements outside > of > study. From my time in academia (20 years) I can pretty much agree that most computing students didn't actually give a shit about computing. Certainly 40% of them couldn't program. But because of the curriculum they get degrees, get jobs as programmers and we end up with the mass of crap code we currently have in the world. > The average person learning to program is not spending half the time > most D developers do on a slow week. Again this is ok. But we need > to > acknowledge that they won't be anywhere near us or our expectations > normally. Which gets on to a huge hobby horse of mine. If degrees are about knowledge then there has to be a follow on before people are employed. Medics do this: three year degree, two or three years on the job training. Effectively an apprenticeship. Sadly in computing, most employers assume graduates have the knowledge and the work practice skills. Clearly they do not. It seems NZ is enshrining this in law. UK it is jsut what happens. Of course most university computing academic staff cannot program either. > To assume the average person will play around and learn pip ext. is > just > ridiculous. Especially when they have most if not all the code they > need > already available to them via the distribution. Ridiculous is the wrong word to use here. All Python programmers should know about pip and PyPI. You are talking about students using Python to code up answers to exercises. If the academic ensures there is no need of anything other than the standard distribution, then that is a fine compromise, in that situation. But a person off that course should never claim they can program in Python, nor should tehy be considered for Python programming jobs without further training. > These are the same people who we may barely convince to try D out. > If > they struggle to do basic things or at least perceived basic things > then > they won't bother and just say 'too hard'. > If we can make them happy, most developers over all will be happy. > Even > the average D developer will be glad for it. Mostly because they cannot be arsed. Academic's have a responsibility here to configure things for the students. We did this with C++, Scheme, Miranda, Java, etc. Part of the initial pack for each course were detailed tested instructions for students to set up. They didn't have to think, they just had to follow the recipe. > At the end of the day, the least amount of steps to do what is > perceived > as basic tasks without any conflicting arguments the better. True. 1. Download Dub. 2. Dub install standard-distribution should do it. > I keep
Re: GDC Explorer Site Update
On Tuesday, 26 January 2016 at 07:22:36 UTC, Iain Buclaw wrote: On Tuesday, 26 January 2016 at 02:44:56 UTC, maik klein wrote: On Monday, 25 January 2016 at 23:08:32 UTC, Iain Buclaw wrote: Hi, After a much needed rebuild of the server running various GDC-related hosted services [http://forum.dlang.org/post/zrnqcfhvyhlfjajtq...@forum.dlang.org] - I've gotten round to updating the compiler disassembler. http://explore.dgnu.org/ Now supports 12 different architectures from ARM to SystemZ! (not including -m32 or any -march options) Enjoy. Iain. This is awesome, I think I am going to use this to finally learn some assembly. But I am not quite sure though what the output is, is it x86 or x64? The first is x64. You can switch to x86 using -m32. However I could just add an extra compiler to do this automatically. Iain. Done. Also made the target names more clear. Iain.
Re: GDC Explorer Site Update
On Monday, 25 January 2016 at 23:08:32 UTC, Iain Buclaw wrote: http://explore.dgnu.org/ Nice! Is there a way to override the default '-Og'? It seems that now Currently I cannot see any difference Now supports 12 different architectures from ARM to SystemZ! (not including -m32 or any -march options) BTW, dunno how it's now, but about a year ago GDC was able to compile for AVR after removing two asserts in the frontend (checking if the pointer size is at least 32 bits or the like).
Re: GDC Explorer Site Update
On Tuesday, 26 January 2016 at 10:17:37 UTC, Adrian Matoga wrote: Nice! Is there a way to override the default '-Og'? It seems that now Currently I cannot see any difference Oops, pressed "Send" too quickly. Should be: I cannot see any difference in the output when I enter various optimization options.
Re: GDC Explorer Site Update
On Tuesday, 26 January 2016 at 10:17:37 UTC, Adrian Matoga wrote:
On Monday, 25 January 2016 at 23:08:32 UTC, Iain Buclaw wrote:
http://explore.dgnu.org/
Nice!
Is there a way to override the default '-Og'? It seems that now
Currently I cannot see any difference
Ah, I left that test option in by accident. Removed. :-)
Now supports 12 different architectures from ARM to SystemZ!
(not including -m32 or any -march options)
BTW, dunno how it's now, but about a year ago GDC was able to
compile for AVR after removing two asserts in the frontend
(checking if the pointer size is at least 32 bits or the like).
The situation should be exactly the same. You may notice that
not all targets hosted are able to compile
std.stdio.writeln("Hello World"). I hope that giving awareness
that these exist will help finish off the druntime ports for
these platforms.
Iain
Re: Ever want to compile D on your Android phone? Well, now you can!
On Wednesday, 27 January 2016 at 06:04:43 UTC, Laeeth Isharc wrote: https://www.reddit.com/r/programming/comments/42w404/dlang_llvmbacked_compiler_alpha_release_for/ Thanks, I wondered if it had been posted, as it's the kind of oddity they might enjoy. :) On Wednesday, 27 January 2016 at 07:01:30 UTC, Vadim Lopatin wrote: On Sunday, 24 January 2016 at 15:12:30 UTC, Joakim wrote: An alpha release of ldc, the llvm-based D compiler, for Android devices is now available. It is best used with the excellent Termux app (https://play.google.com/store/apps/details?id=com.termux=en) and a bluetooth keyboard. ;) Updated test runners, that run most tests from the standard library on any Android device, are also available (results have been reported for everything from a TomTom BRIDGE GPS navigation device to a Huawei Watch): https://github.com/joakim-noah/android/releases/tag/polish Cannot build ldc for Android according to instructions http://wiki.dlang.org/Build_LDC_for_Android git clone --recursive https://github.com/ldc-developers/ldc.git cd ldc/ git submodule update curl -O https://gist.githubusercontent.com/joakim- noah/63693ead3aa62216e1d9/raw/b89d77d66a80206b4dd3d78bb10d83a7e368f3d4/ldc_android_arm git apply ldc_android_arm Patch cannot be applied to current ~master I've tried to checkout several recent tagged versions - doesn't work too. Probably it's applicable only to some particular LDC version. What version of ldc should I checkout to apply this patch? (Building LDC on Windows) It's not hard to figure out, as 'git apply ldc_android_arm' says it fails on dmd2/root/port.c and 'git log dmd2/root/port.c' shows this recent change to master: https://github.com/ldc-developers/ldc/commit/556e3a691f72b97cce31d85740e8dc12cafc9f53#diff-2268700876655bdfa9d178b9cc466277 I've updated the gist and wiki page to take that change into account; simply download the new gist, as shown on a reloaded wiki page. Also, I haven't tried cross-compiling from Windows, so you may run into other problems there. The main one I can think of is that the test runner targets I added to CMake may have an issue, but there could be additional incompatibilities that I simply haven't run into on linux. Hopefully, it just works. :) Anyway, this is a good reason to get all this stuff merged soon, which is what I was looking into now anyway, although that particular change is from Kai's long-unmerged longdouble2 branch.
Re: Ever want to compile D on your Android phone? Well, now you can!
On Sunday, 24 January 2016 at 15:12:30 UTC, Joakim wrote: An alpha release of ldc, the llvm-based D compiler, for Android devices is now available. It is best used with the excellent Termux app (https://play.google.com/store/apps/details?id=com.termux=en) and a bluetooth keyboard. ;) Updated test runners, that run most tests from the standard library on any Android device, are also available (results have been reported for everything from a TomTom BRIDGE GPS navigation device to a Huawei Watch): https://github.com/joakim-noah/android/releases/tag/polish You can install a test runner app or run a command-line binary. Please report your results in this thread in the ldc forum, which requires no registration, with the info and format requested there, particularly for Android 4.1 or earlier: https://forum.dlang.org/thread/bafrkjfwmoyriyhmq...@forum.dlang.org If you try out the native compiler, take a look at the README that comes with it for instructions. If you have a D/OpenGL app you'd like to port to Android and submit to the Play Store, let me know if I can help with that process. https://www.reddit.com/r/programming/comments/42w404/dlang_llvmbacked_compiler_alpha_release_for/
Re: New DCD and dfmt betas
On 2016-01-26 21:57, Brian Schott wrote: Fixed: https://github.com/Hackerpilot/dfmt/issues/226 Thanks. -- /Jacob Carlborg
Re: Vision for the first semester of 2016
I wasn't going to reply, until you tweeted. No just no. When dealing with tertiary institutions especially New Zealand ones, you've got to understand they have massive pressure to get through content. Every single class is standardized nationally, by law. You're all worried about doing things best practice in an eco-system. That is just not the case here. In these courses they are not meant to be teaching a language. But instead use said language to teach with. The most time a student gets in ANY language is 2 semesters. By the time they reach third year (last) they only have 1 per language. In these classes the concern is teaching some other relevant concept such as design patterns. So you're pushing limited class time for the purpose of teaching actual class content instead of non required information for assignments. Its a balancing act. But you've got to understand that most of the students going through it, are just not interested in going much further then the assignments. Simple things like trying OpenGL are beyond them and this is ok. They have a lot of things to learn and have real life requirements outside of study. The average person learning to program is not spending half the time most D developers do on a slow week. Again this is ok. But we need to acknowledge that they won't be anywhere near us or our expectations normally. To assume the average person will play around and learn pip ext. is just ridiculous. Especially when they have most if not all the code they need already available to them via the distribution. These are the same people who we may barely convince to try D out. If they struggle to do basic things or at least perceived basic things then they won't bother and just say 'too hard'. If we can make them happy, most developers over all will be happy. Even the average D developer will be glad for it. At the end of the day, the least amount of steps to do what is perceived as basic tasks without any conflicting arguments the better. I keep saying about perceived basic tasks. Psychology. A fourteen year old today was born in 2002. I learned to program when I was 14. In 2001 XP was just released. The people learning programming now expect GUI's and perceive it as basic. We may know better but at the end of the day, how can we appeal to them realistically?
Re: New DCD and dfmt betas
On 2016-01-26 03:18, Brian Schott wrote: https://github.com/Hackerpilot/dfmt/releases/tag/v0.5.0-beta2 This version of dfmt includes several whitespace and indentation fixes. There is also some fine-tuning in the line wrap calculation algorithm and a new option to control the formatting of template constraints. In general, what can we assume of the line wrapping? What can we assume it will handle? -- /Jacob Carlborg
Re: Vision for the first semester of 2016
On 2016-01-25 22:15, Iain Buclaw via Digitalmars-d-announce wrote: With respect, I'm not sure whether anyone in core would have the slightless hint of knowing how UI works. (Not that I speak for anyone but myself :-) And you think that I have the slightest idea of what I'm doing ;) -- /Jacob Carlborg
Re: New DCD and dfmt betas
On 2016-01-26 10:05, Brian Schott wrote:
I recently ran dfmt on itself. You can get a pretty good idea of its
default output by looking at the source.
I'm asking because it doesn't manage to line break this code at all:
void main()
{
auto a = 1234567890 + 1234567890 + 1234567890 + 1234567890 +
1234567890 + 1234567890 + 1234567890 + 1234567890 + 1234567890 +
1234567890 + 1234567890 + 1234567890 + 1234567890 + 1234567890 +
1234567890 + 1234567890 + 1234567890 + 1234567890;
}
The line with "auto a" is actually one line. Not sure how it will show
up in the newsgroup.
Should I report a bug?
--
/Jacob Carlborg
Re: Vision for the first semester of 2016
On 2016-01-26 13:38, Andrei Alexandrescu wrote: Thanks for answering. I want to be convinced, and even if not, to gather a more precise view. The rhetoric is appreciated. What would be helpful here in addition to it are a few links to evidence. You make lofty claims either of status quo in different languages, or major shifts in strategy. They definitely must have left a trail on the Internet. Any chance you'd substantiate these specific claims below with evidence? I don't really have an opinion but I found this [1] for Ruby. [1] https://redmine.ruby-lang.org/projects/ruby/wiki/StdlibGem -- /Jacob Carlborg
Re: Vision for the first semester of 2016
On Tuesday, 26 January 2016 at 10:52:17 UTC, Russel Winder wrote: Design patterns are not language agnostic. GoF patterns are 23 year old and many totally irrelevant with certain programming languages. However that is a different debate for a different place. I found GoF underwhelming when I first read it as I had discovered many/most of those patterns on my own, but then someone said that the usefulness was in giving the pattern names. And that made sense.
Re: Ever want to compile D on your Android phone? Well, now you can!
On Sunday, 24 January 2016 at 15:12:30 UTC, Joakim wrote: If you have a D/OpenGL app you'd like to port to Android and submit to the Play Store, let me know if I can help with that process. I'm going to port DlangUI on Android in nearest future.
Re: DlangIDE update
On Monday, 25 January 2016 at 20:00:57 UTC, Basile B. wrote:
On Tuesday, 8 December 2015 at 15:58:43 UTC, Vadim Lopatin
wrote:
- integration of DML GUI builder (Delphi like)
Can you explain me how do you think it can be done while there
is even no official object streaming for D ?
Just one thing: "@widget" is not enough.
I don't know how to explain you the problem. But let's say you
have an object inspector that displays the properties of an
object. The D way doesn't work (templates). You won't be able
to assign an untyped Object to an inspector if your object
doesn't store runtime informations. It's just impossible.
Furthemore properties are not just for the visual things...
You won't be able to make a good run-time designer "à la
Delphi" until the D standard library gets a serialization
library. And when this will happen, you won't be able to use
this serialization library because it won't work at run-time
(object inspectors, property bindings, etc.).
It won't work.
Currently it's being done by adding lines like following into
modules which contain widgets to publish:
import dlangui.widgets.metadata;
mixin(registerWidgets!(Widget, TextWidget, ScrollBar,
CanvasWidget)());
Unless widgets are registered, it's impossible to create them
from DML like this:
auto layout = parseDML!VerticalLayout(q{
VerticalLayout {
layoutWidth: fill; layoutHeight: fill; backgroundColor:
#FF8080
TextWidget { text: "Input text here" }
EditLine { id: edName }
}
});
Sample DML editor:
dub run dlangui:dmledit
Re: Ever want to compile D on your Android phone? Well, now you can!
On Tuesday, 26 January 2016 at 15:54:17 UTC, Vadim Lopatin wrote: On Sunday, 24 January 2016 at 15:12:30 UTC, Joakim wrote: If you have a D/OpenGL app you'd like to port to Android and submit to the Play Store, let me know if I can help with that process. I'm going to port DlangUI on Android in nearest future. Great! Let me know if you need anything from me.
Re: Vision for the first semester of 2016
On Tuesday, 26 January 2016 at 12:46:23 UTC, Ola Fosheim Grøstad wrote: On Monday, 25 January 2016 at 08:57:44 UTC, Rory McGuire wrote: Ouch yes, seen that before. I just would prefer the base library to be exactly that a base. I agree. Imagine if all the effort put into Phobos' extras was put into the compiler and tooling... It's not like you could just reallocate all the effort that goes into Phobos towards the compiler and stuff. Especially with the compiler itself, most people are unqualified or uninterested in working on it. If it were suddenly announced that Phobos was "finished", I guarantee a lot of volunteers would just walk away (likely including myself).
Re: Vision for the first semester of 2016
On Tuesday, 26 January 2016 at 20:38:16 UTC, tsbockman wrote: It's not like you could just reallocate all the effort that goes into Phobos towards the compiler and stuff. My impression is that the majority of the contributors to Phobos are capable D programmers. DMD is implemented in D now, no longer C++, so with refactoring and documentation I think a lot more programmers are qualified to hack on the compiler.
Re: New DCD and dfmt betas
On Tuesday, 26 January 2016 at 13:37:45 UTC, Jacob Carlborg wrote: I'm asking because it doesn't manage to line break this code at all: Fixed: https://github.com/Hackerpilot/dfmt/issues/226
Re: Vision for the first semester of 2016
On Tuesday, 26 January 2016 at 21:03:01 UTC, tsbockman wrote: Also, you skipped past the "uninterested" part - this is a volunteer project, remember? I didn't think it was a relevant argument as you can still write libraries for distribution. Keep in mind that the standard library has to be maintained and API's cannot easily be redesigned because of backwards compatibility. Even if C/C++ have small standard libraries they provide a depressing amount of low quality functionality that one should avoid. But it is kept in for backwards compatibility and sometimes even updated and extended... That not a good thing.
Re: Vision for the first semester of 2016
On Tuesday, 26 January 2016 at 21:47:41 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 26 January 2016 at 21:03:01 UTC, tsbockman wrote: Also, you skipped past the "uninterested" part - this is a volunteer project, remember? I didn't think it was a relevant argument as you can still write libraries for distribution. Keep in mind that the standard library has to be maintained and API's cannot easily be redesigned because of backwards compatibility. Even if C/C++ have small standard libraries they provide a depressing amount of low quality functionality that one should avoid. But it is kept in for backwards compatibility and sometimes even updated and extended... That not a good thing. There are certainly disadvantages to the standard library model of distribution and maintenance. On the other hand: 1) The prospect of getting something into the standard library is a huge motivator for (at least some) potential contributors. Why? Because building a library that no one knows about/trusts is wasted effort. Getting something into `std` is among the most effective forms of marketing available, and requires little non-programming-related skill or effort on the part of the contributor. 2) Standard libraries don't enforce backwards compatibility (and high code quality in general) just for the sake of bureaucracy - they do so because these are highly desirable characteristics for basic infrastructure. People shouldn't have to rewrite their entire stack every 6 months just because someone thought of a better API for some low-level component. Making it through D's formal review process typically raises code quality quite a lot, and the knowledge that backwards compatibility is a high priority makes outsiders much more likely to invest in actually using a library module. In short, while you make some valid points, your analysis seems very lopsided; it completely glosses over all of the positives associated with the status quo.
Re: Vision for the first semester of 2016
On Tuesday, 26 January 2016 at 22:33:32 UTC, tsbockman wrote: 1) The prospect of getting something into the standard library is a huge motivator for (at least some) potential contributors. I am not sure if that is the right motivation. Sounds like recipe for bloat. Good libraries evolve from being used in real applications. Many applications. characteristics for basic infrastructure. People shouldn't have to rewrite their entire stack every 6 months just because someone thought of a better API for some low-level component. Then don't use libraries from unreliable teams. Making it through D's formal review process typically raises code quality quite a lot, and the knowledge that backwards compatibility is a high priority makes outsiders much more likely to invest in actually using a library module. Code quality is one thing, but if it has not been used in many applications, how can you then know if the abstraction is particularly useful? There is nothing wrong with having a set of recommended libraries, e.g. a DSP library with FFT. But having things like FFT in the standard library is just crap. Even Apple does not do that, they have a separate library called Accelerate for such things. There is no way you can have the same interface for FFT across platforms. The structure of the data is different, the accuracy is different, all for max performance. In general the standard library should just be the most basic things, even file system support is tricky for a system level programming language. For instance, on some cloud platforms you don't get to read/write parts of a file. You do it as one big atomic write/read.
Re: Vision for the first semester of 2016
On Tuesday, 26 January 2016 at 22:48:23 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 26 January 2016 at 22:33:32 UTC, tsbockman wrote: characteristics for basic infrastructure. People shouldn't have to rewrite their entire stack every 6 months just because someone thought of a better API for some low-level component. Then don't use libraries from unreliable teams. Just using the standard library whenever possible is a simple and efficient way of accomplishing this - if the standard library actually has anything in it... Making it through D's formal review process typically raises code quality quite a lot, and the knowledge that backwards compatibility is a high priority makes outsiders much more likely to invest in actually using a library module. Code quality is one thing, but if it has not been used in many applications, how can you then know if the abstraction is particularly useful? This is why requiring modules to spend some time on DUB and/or in `std.experimental` before freezing the API is important. In general the standard library should just be the most basic things, even file system support is tricky for a system level programming language. For instance, on some cloud platforms you don't get to read/write parts of a file. You do it as one big atomic write/read. Targeting 100% generality with APIs is pretty much always a bad idea. Standard libary modules should endeavor to meet the needs of at least, say, 80% of potential users; they're not supposed to completely eliminate the need for specialized third-party libraries entirely. This is OK, because if you don't use a module, the compiler won't include it in the final executable.
Re: Vision for the first semester of 2016
On Tuesday, 26 January 2016 at 23:04:57 UTC, tsbockman wrote: This is why requiring modules to spend some time on DUB and/or in `std.experimental` before freezing the API is important. Well, there aren't enough D applications written to ensure the usefulness of the API. Just take a look at widely adopted frameworks, they are "the one true thing" for a few years with 100s or 1000s of applications using them. However as applications grow problems emerge. What happens? The entire framework is scrapped and replaced with something else. Targeting 100% generality with APIs is pretty much always a bad idea. Making a system level programming library based on what a current PC operating systems offers is also a bad idea. On Apple systems you are supposed to no longer use paths, but switch to URLs for files. Ok, you can do that by requiring URLs on all platforms, but what if you designed the API 10 years ago? Operating systems changes, hardware changes. System level programming languages shouldn't provide an abstract machine, unlike the JVM. I'm not at all convinced that D isn't tied too heavily to x86/POSIX/Windows. It isn't obvious that future systems will bother with POSIX.
Re: Vision for the first semester of 2016
Or let me put it this way. If the standard library requires POSIX, then it isn't really a standard library, but a POSIX abstraction library...
Re: Ever want to compile D on your Android phone? Well, now you can!
On Sunday, 24 January 2016 at 15:12:30 UTC, Joakim wrote: An alpha release of ldc, the llvm-based D compiler, for Android devices is now available. It is best used with the excellent Termux app (https://play.google.com/store/apps/details?id=com.termux=en) and a bluetooth keyboard. ;) Updated test runners, that run most tests from the standard library on any Android device, are also available (results have been reported for everything from a TomTom BRIDGE GPS navigation device to a Huawei Watch): [...] Good work! Atila
Re: New DCD and dfmt betas
On Tuesday, 26 January 2016 at 08:37:10 UTC, Jacob Carlborg wrote: On 2016-01-26 03:18, Brian Schott wrote: https://github.com/Hackerpilot/dfmt/releases/tag/v0.5.0-beta2 This version of dfmt includes several whitespace and indentation fixes. There is also some fine-tuning in the line wrap calculation algorithm and a new option to control the formatting of template constraints. In general, what can we assume of the line wrapping? What can we assume it will handle? I recently ran dfmt on itself. You can get a pretty good idea of its default output by looking at the source.
Re: Vision for the first semester of 2016
On Monday, 25 January 2016 at 08:57:44 UTC, Rory McGuire wrote: Ouch yes, seen that before. I just would prefer the base library to be exactly that a base. I agree. Imagine if all the effort put into Phobos' extras was put into the compiler and tooling...
Re: Vision for the first semester of 2016
On 01/25/2016 11:26 AM, Russel Winder via Digitalmars-d-announce wrote: On Mon, 2016-01-25 at 07:44 -0500, Andrei Alexandrescu via Digitalmars- d-announce wrote: Could you please back up that assertion a little bit? From all I see, standard libraries of most languages grow very fast with each release. What are your facts? -- Andrei Thanks for answering. I want to be convinced, and even if not, to gather a more precise view. The rhetoric is appreciated. What would be helpful here in addition to it are a few links to evidence. You make lofty claims either of status quo in different languages, or major shifts in strategy. They definitely must have left a trail on the Internet. Any chance you'd substantiate these specific claims below with evidence? Go has a very small core, if you want anything else you write a library and publish it. There is a massive and vibrant activity writing many versions of stuff most of which wither by lack of use. Some, usually one or two, in each domain thrive and become the de facto standard. Everything depends on Git, Mercurial, Bazaar, and go get. I look at https://golang.org/pkg/ and see a quite substantial standard library, including things that some people argue shouldn't be part of a standard library: archives and compression, cryptography, databases, character encodings (including json and xml!), html templating, image processing, suffix arrays (sic), logging, networking, regexp, testing, tokenization. This list is _after_ I eliminated topics that I believe should be part of a standard library, such as I/O, time, and even unicode, etc. I'd like to believe our stdlib covers a few areas that Go's doesn't, but it is obvious to me Go's stdlib does (and reportedly very well) cover a bunch of areas that we haven't set foot in yet. This doesn't quite align quite at all with your view that Go is barebones and anyone who wants anything builds it. From what I can tell, Go comes with plenty. (It is of course relative; Go's stdlib may be small compared to externally available libraries, owing to its popularity which the Go team deserves due credit for.) Rust threw out large tracts of what was in the original library, including all concurrency and parallelism things, in favour of separate crates. There is a massive and vibrant activity writing many versions of stuff most of which wither by lack of use. Some, usually one or two, in each domain thrive and become the de facto standard. Everything depends on crates.io and Cargo. Do you have reference to relevant material (core team blog posts, forum discussions, articles) documenting the shift, boundaries, strategy, motivation etc? A look at https://doc.rust-lang.org/std/ does support your view that Rust's stdlib is minimal. Python used to be batteries included, then they moved to having a core to which only Python committers have access. There is a massive and vibrant activity writing many versions of stuff most of which wither by lack of use. Some, usually one or two, in each domain thrive and become the de facto standard. Everything depends on PyPI, pip, and virtualenv. Or Anaconda. Again, a few links to evidence supporting these statements would be awesome. I am sorry for my being incult; I know of pip and used it a couple of times but know nothing about all else. At the same time you'll appreciate I can't just form an opinion on your authority. There are many facts out there favouring distributed over centralized for everything except the language itself and the runtime system, you just have to look. Calling for an explicit, detailed catalogue is not a way forward in this debate. I am truly sorry but is appealing to your own authority a better alternative? Dub needs to be front and centre, it represents D, not DMD, LDC, GDC, druntime, Phobos. The core of a D distribution is Dub. In this D is like Rust, Ceylon, Python, and JVM. And unlike Go. Go is too libertarian in my view. Rust, Ceylon, Python, JVM have the right view for me: centralized repository and management of distributed projects. What Rust and Ceylon are missing that PyPI has is an highly opinionated metric that helps you decide what is good and what is dross. Of course Dub needs a better story around executables rather than library packages. Go (go install) and Rust (Cargo build) do this so much better. But then Go has a project structure model, and Rust uses TOML. I do agree with Dub's importance. What's unclear to me is what are reasonable criteria for including some given functionality within the stdlib vs. an external one. Andrei
