On Saturday, 27 January 2018 at 13:56:35 UTC, rjframe wrote:
> If you use an IDE or analysis/lint tool, you'll get type checking. The interpreter will happily ignore those annotations.

You need to use a type checker to get type checking... No surprise there, but without standard type annotations the type checker isn't all that useful.  Only in past few years have typing stubs become available for libraries, and that makes a difference,

On Sat, 27 Jan 2018 22:59:17 +0000, Ola Fosheim Grostad wrote:

> On Saturday, 27 January 2018 at 13:56:35 UTC, rjframe wrote:
>> If you use an IDE or analysis/lint tool, you'll get type checking. The interpreter will happily ignore those annotations.
> 
> You need to use a type checker to get type checking... No surprise there, but without standard type annotations the type checker isn't all that useful.  Only in past few years have typing stubs become available for libraries, and that makes a difference,

My point is that the interpreter ignores information that I give it, when that information clearly proves that I have a bug. Python 3.6 gives you an explicit type system when you want/need it, but stops just short of making it actually useful without secondary tools.

Granted, everybody should be using those tools on decent-sized projects anyway, but the interpreter shouldn't be ignoring obvious issues. If I explicitly label a type, implicit casts/overrides/replacements should not be accepted, no matter how dynamic the type system. The feature was designed for tools; they failed to design it for programmers as well.

On Saturday, 27 January 2018 at 20:15:51 UTC, aberba wrote:
> There have been several complaints about tools, and certain important stuff missing in the standard library (HTTP/HTTP2, rpc, etc) and no 'official' response or some blog post from them about it (whether they even care).

The community will have to do this. If Walter and Andrei were interested in it, they'd have been working on it long ago. They have way too much to do the way it is, and as soon as it becomes official, there are rules and rules about rules and six levels of bureaucracy.

On Sunday, 28 January 2018 at 00:31:18 UTC, rjframe wrote:
> On Sat, 27 Jan 2018 22:59:17 +0000, Ola Fosheim Grostad wrote:
>
>> On Saturday, 27 January 2018 at 13:56:35 UTC, rjframe wrote:
>>> If you use an IDE or analysis/lint tool, you'll get type checking. The interpreter will happily ignore those annotations.
>> 
>> You need to use a type checker to get type checking... No surprise there, but without standard type annotations the type checker isn't all that useful.  Only in past few years have typing stubs become available for libraries, and that makes a difference,
>
> My point is that the interpreter ignores information that I give it, when that information clearly proves that I have a bug. Python 3.6 gives you an explicit type system when you want/need it, but stops just short of making it actually useful without secondary tools.

The reference interpreter doesn't make much use of static type information. I think it makes sense to have separate type checkers until this new aspect of Python has reached maturity. That doesn't prevent third parties to implement interpreters that makes use of type information.

Professionals won't shy away from using additional tools anyway, so the only reason to build it into the interpreter is for optimization at this point.

On Sun, 28 Jan 2018 11:44:05 +0000, Ola Fosheim Grøstad wrote:

> The reference interpreter doesn't make much use of static type information. I think it makes sense to have separate type checkers until this new aspect of Python has reached maturity. That doesn't prevent third parties to implement interpreters that makes use of type information.
> 
> Professionals won't shy away from using additional tools anyway, so the only reason to build it into the interpreter is for optimization at this point.

I should be specific about speaking of the reference implementation. I just think comments that look like code (which is basically what this is) is always a bad idea.

On Friday, 26 January 2018 at 09:02:03 UTC, Ola Fosheim Grøstad wrote:
> While this analysis of language popularity on Github is enlightening:
>
> http://www.benfrederickson.com/ranking-programming-languages-by-github-users/
>
> I found the older analysis of how programmers transition (or adopt new languages) more interesting:
>
> https://blog.sourced.tech/post/language_migrations/
>
> Like how people move from Rust to Go. And from Go to Python:
>
> https://blog.sourced.tech/post/language_migrations/sum_matrix_22lang_eig.svg
>
>
> Also the growth of Java is larger than I would anticipate:
>
> https://blog.sourced.tech/post/language_migrations/eigenvect_stack_22lang.png
>
> Granted, Java has gotten quite a few convenience features over the years.

I find it fascinating that C# is in the "languages to avoid" section, because from my perspective it's receiving more and more adoption as the modern alternative to Java, in a way that Go and Rust are not. Different markets and all of that. So I can't see why C# would be seen as a language that is dropping in popularity (though I don't use it myself).

I do worry that, having been using D for about 3 1/2 years now, that the perceptions of D outside of this community don't seem to be changing much. It does seem to make a huge difference to have a big company behind a language, purely for the "free advertisement". Most people at my university, outside of the computer science department, that are using languages like Python and R and MATLAB the most, are very aware of Rust and Go, but not D. I wonder if we do need to pay more attention to attracting new users just to get people talking about it.

On Sunday, 28 January 2018 at 13:50:03 UTC, Michael wrote:
> On Friday, 26 January 2018 at 09:02:03 UTC, Ola Fosheim Grøstad wrote:
>> [...]
>
> I find it fascinating that C# is in the "languages to avoid" section, because from my perspective it's receiving more and more adoption as the modern alternative to Java, in a way that Go and Rust are not. Different markets and all of that. So I can't see why C# would be seen as a language that is dropping in popularity (though I don't use it myself).
>
> [...]

Oh, I had confused Objective-C with C# in that graph. Forget the first part of my previous post.

On Sunday, 28 January 2018 at 13:50:03 UTC, Michael wrote:
> Most people at my university, outside of the computer science department, that are using languages like Python and R and MATLAB the most, are very aware of Rust and Go, but not D.

I'd say Julia is getting a lot more attention than Rust or Go for those users. And rightfully so.

> I wonder if we do need to pay more attention to attracting new users just to get people talking about it.

I'm not sure why those users would be interested in D at the moment. D presents itself as a C++ replacement, discussions are all about low-level stuff, garbage collection, and efficiency, and new users are told to use Dub and learn about Git submodules. That's not ever going to appeal to the R and Matlab crowd. I have gotten others to start using D, and it was quite easy. Just make an R package containing D code, they install it, and then they call D functions from R. Few in this community understand that style of programming though.

On Fri, 2018-01-26 at 20:31 +0000, John Gabriele via Digitalmars-d wrote:
> […]
> 
> With Rust's extra complexity (over D) of ownership/borrowing, lifetimes, and no GC, although we may currently see a push for more Rust in Gnome for system-level code, I think D may beat it for writing *applications*.

Being in the middle of rewriting a C++/GTK+ application in both Rust and D, both have pluses and minuses.

Documentation, and examples, for both D and Rust, are woefully inadequate, but Rust is getting better quite rapidly because it has something of a dedicated workforce.

The D and Rust architecture models are surprisingly similar in terms of mental model, however Rust's current lack of inheritance really is a pain: currently D wins on this hands down.  The gtk-rs people are looking to solve this by exposing the internal inheritance mechanism to the aPI users.

Rust/Cargo win hands down over D/Dub. This is a problem with Dub. One that seems unlikely to be addressed. This means using SCons and Meson for D code, which works surprisingly well, and yet has some huge problems.

D appears to be clumsier than Rust for error handling. I think this may be that the monad-based approach is working better for me just now. Of course there are irritants with the monads approach.

(Side bar: The Rust and D bindings are generated from the GTK gir files which is great, but the C++ API is hand crafted which leads to lots of inconsistencies with the underlying C API.)

> I'm planning on learning more D, then trying out GtkD to see how it compares with Python + PyGObject for some little apps.

Where Python and PyGobject (based on gir files) wins is you stop having to faff around with all the compile time types: the dynamic typing of Python has many huge benefits for writing GTK+ applications compared to C++, D, Rust.

For my application, I am using GStreamer. The GStreamer core team are backing Rust since it is the only language they trust with regard to managing memory. Clearly C is totally inadequate but if you code is in C you allow Stockholm Syndrome. C++ is also inadequate but more due to the pointer types being add ons and not really checked. Rust is clearly far superior to C++ in this respect, at the risk of the borrow checker sometimes being impossible to satisfy. The GStreamer people refuse to accept the existence of a garbage collector. On the other hand there is GStreamerD, but the problem is you have to deduce or infer how to use the D binding from the C API. And there is no work other than Mike Wey's in the GtkD suite (*).

If the D community think D is a Rust beater for GTK+ applications then get involved with keeping the GtkD binding up to date, do not assume Mike will do all the work.



(*) Huge vote of thanks to Mike for continuing to keep the GtkD suite
up to date.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Sun, 2018-01-28 at 15:36 +0000, bachmeier via Digitalmars-d wrote:
> 
[…]
> I'd say Julia is getting a lot more attention than Rust or Go for those users. And rightfully so.

I am still not sure Julia is getting traction outside a few communities. Python still seems to be the language of choice in data analysis visualisation.

> > I wonder if we do need to pay more attention to attracting new users just to get people talking about it.
> 
> I'm not sure why those users would be interested in D at the moment. D presents itself as a C++ replacement, discussions are all about low-level stuff, garbage collection, and efficiency, and new users are told to use Dub and learn about Git submodules. That's not ever going to appeal to the R and Matlab crowd. I have gotten others to start using D, and it was quite easy. Just make an R package containing D code, they install it, and then they call D functions from R. Few in this community understand that style of programming though.

Dub looked like it was going to be good, but somehow development stopped and it fails to deliver compared to Cargo.  Although Cargo is language specific, and thus inferior to SCons, Meson, CMake, etc., it works very well indeed for building and installing Rust codes. The Go system works well in the context of a workspace structured system.

Compared to the Rust and Go community, D is lacking a package system and build system that really works. Also, a JetBrains IDE for D is absent – though Samael and Francis are trying very hard to improve this. The problem is though that JetBrains are unlikely to pick up the plugin and make it official in the way that they did Rust and Go. Perhaps the Clojure plugin model as per Cursive might be in order, i.e. people pay an annual subscription for it within the free to use IntelliJ IDEA.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk