www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - =?UTF-8?Q?Top_Five_World=e2=80=99s_Most_Underrated_Programming_Lang?=

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Of possible interest:

https://www.technotification.com/2019/01/most-underrated-programming-languages.html
Jan 14
next sibling parent Carl Sturtivant <sturtivant gmail.com> writes:
On Monday, 14 January 2019 at 20:21:25 UTC, Andrei Alexandrescu 
wrote:
 Of possible interest:

 https://www.technotification.com/2019/01/most-underrated-programming-languages.html
What's interesting here is the language nim, which perhaps has some lessons for D. https://nim-lang.org/
Jan 17
prev sibling next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
Gotta laugh at Ruby being listed as "Underrated", though.

--bb

On Mon, Jan 14, 2019 at 12:25 PM Andrei Alexandrescu via
Digitalmars-d-announce <digitalmars-d-announce puremagic.com> wrote:

 Of possible interest:


 https://www.technotification.com/2019/01/most-underrated-programming-languages.html
Jan 17
parent Meta <jared771 gmail.com> writes:
On Friday, 18 January 2019 at 01:15:06 UTC, Bill Baxter wrote:
 Gotta laugh at Ruby being listed as "Underrated", though.

 --bb

 On Mon, Jan 14, 2019 at 12:25 PM Andrei Alexandrescu via 
 Digitalmars-d-announce <digitalmars-d-announce puremagic.com> 
 wrote:

 Of possible interest:


 https://www.technotification.com/2019/01/most-underrated-programming-languages.html
I get the feeling that Ruby's popularity is waning with the rise of Node.js and the broad ecosystem of Javascript-based web application frameworks. At one time it probably came close to rivaling Python in popularity and sheer volume of new development, but I think that's firmly in the past now (not that it is dead, by any means).
Jan 17
prev sibling parent reply Brian <zoujiaqing gmail.com> writes:
On Monday, 14 January 2019 at 20:21:25 UTC, Andrei Alexandrescu 
wrote:
 Of possible interest:

 https://www.technotification.com/2019/01/most-underrated-programming-languages.html
Because no software can use it. examples: 1. Docker use golang. 2. Middleware system use java. 3. Shell use python. 4. AI use python and R. 5. Desktop application use QT / C#. 6. Web framework & database use php's laravel and java's sprint-boot. 7. Web use Javascript / typescript.
Jan 17
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Friday, 18 January 2019 at 03:41:38 UTC, Brian wrote:
 On Monday, 14 January 2019 at 20:21:25 UTC, Andrei Alexandrescu 
 wrote:
 Of possible interest:

 https://www.technotification.com/2019/01/most-underrated-programming-languages.html
Because no software can use it. examples: 1. Docker use golang. 2. Middleware system use java. 3. Shell use python. 4. AI use python and R. 5. Desktop application use QT / C#. 6. Web framework & database use php's laravel and java's sprint-boot. 7. Web use Javascript / typescript.
Google is using Go for gVisor and Fuchsia, MIT for Biscuit, TUM (Munich) for userspache high performance network drivers, in spite of the naysayers regarding Go and systems programming. Apparently Google is ramping up the use of Rust in Fuchsia and hiring quite a few devs. Azure IoT Edge uses a mix of C# and Rust. C# support for low level systems programing is looking better every release since they started integrated Midori lessons into it, while making it beat TechEmpower and working closely with Unity. Now C# support is started to be a thing all AAA devs wish for on their game engines, even if only for gameplay scripts, while Unity is betting down in improving C# AOT compilation via their HPC# subset (C#'s -betterC in IL2CPP). D really needs its killer use case if it is to move away from that list.
Jan 18
next sibling parent reply JN <666total wp.pl> writes:
On Friday, 18 January 2019 at 08:55:23 UTC, Paulo Pinto wrote:
 Apparently Google is ramping up the use of Rust in Fuchsia and 
 hiring quite a few devs.

 Azure IoT Edge uses a mix of C# and Rust.
Rust has lately got a lot of attention from game developers. Several game studios announced they are switching from C++ to Rust. I think the developing compile to WebAssembly story is helping with that as well, because people can compile their games to web platform.
Jan 18
parent Atila Neves <atila.neves gmail.com> writes:
On Friday, 18 January 2019 at 10:23:03 UTC, JN wrote:
 On Friday, 18 January 2019 at 08:55:23 UTC, Paulo Pinto wrote:
 Apparently Google is ramping up the use of Rust in Fuchsia and 
 hiring quite a few devs.

 Azure IoT Edge uses a mix of C# and Rust.
Rust has lately got a lot of attention from game developers. Several game studios announced they are switching from C++ to Rust.
Wait until they realise they're going to have to debug their game running at 1FPS if that: https://atilanevesoncode.wordpress.com/2018/12/31/comparing-pythagorean-triples-in-c-d-and-rust/
Jan 23
prev sibling next sibling parent germandiago <germandiago gmail.com> writes:
On Friday, 18 January 2019 at 08:55:23 UTC, Paulo Pinto wrote:
 D really needs its killer use case if it is to move away from 
 that list.
For me those would be superior metaprogramming and ability to interface with C++, Objective-C and C in superior ways. But some project must show those strong points. I think migrating the critical point to migrate to another language is usually compatibility. D does many things well and compatibility and metaprogramming are two of those. But I think it is more a matter of bad marketing than the fact that it does not do it well.
Jan 22
prev sibling parent reply Bienlein <ffm2002 web.de> writes:
On Friday, 18 January 2019 at 08:55:23 UTC, Paulo Pinto wrote:
 D really needs its killer use case if it is to move away from 
 that list.
D is a lot like Scala on the JVM: Both language have myriads of language features and bells and whistles, but there is no killer feature in the language itself. Rust and Go have that: Rust has safe manual memory management and Go has an excellent threading model with communicating sequential processes (aka goroutines). Scala didn't make it anywhere until Akka came along beind developed in Scala. Then came Play, Spark and Kafka - all developed in Scala. Either the language has a killer feature or there must be a killer application written in it. For D the latter applies as it does not have a killer feature in the language. Build CSP into D or manual memory management as in Rust. CSP without a GC is difficult (that's one reason why Go has a GC) and Go has a very good GC. I don't think marketing is a requirement. Rust and Go also received no big marketing. Their respective killer feature paved the way as those things were needed. Then people just take it and use it.
Jan 23
parent reply Sebastiaan Koppe <mail skoppe.eu> writes:
On Wednesday, 23 January 2019 at 09:14:18 UTC, Bienlein wrote:
 On Friday, 18 January 2019 at 08:55:23 UTC, Paulo Pinto wrote:
 D really needs its killer use case if it is to move away from 
 that list.
D is a lot like Scala on the JVM: Both language have myriads of language features and bells and whistles, but there is no killer feature in the language itself.
For me the killer feature is meta-programming. No other language comes close. Take the wasm-reader [1] library I recently wrote for instance. While not feature complete - nor a fair direct comparison - it is far less code than anything in C++ [2] or Rust [3]. [1] https://github.com/skoppe/wasm-reader/blob/master/source/wasm_reader/reader.d [2] https://github.com/WebAssembly/binaryen/blob/master/src/wasm/wasm-binary.cpp [3] https://github.com/rustwasm/twiggy/blob/master/parser/wasm_parse/mod.rs
Jan 23
parent reply Bienlein <ffm2002 web.de> writes:
On Wednesday, 23 January 2019 at 09:58:05 UTC, Sebastiaan Koppe 
wrote:
 On Wednesday, 23 January 2019 at 09:14:18 UTC, Bienlein wrote:
 On Friday, 18 January 2019 at 08:55:23 UTC, Paulo Pinto wrote:
 D really needs its killer use case if it is to move away from 
 that list.
D is a lot like Scala on the JVM: Both language have myriads of language features and bells and whistles, but there is no killer feature in the language itself.
For me the killer feature is meta-programming. No other language comes close.
It's a nice feature, but won't make any startup company choose D or any other company as the language for their next software product.
Jan 23
parent reply JN <666total wp.pl> writes:
On Wednesday, 23 January 2019 at 11:42:24 UTC, Bienlein wrote:
 On Wednesday, 23 January 2019 at 09:58:05 UTC, Sebastiaan Koppe 
 wrote:
 On Wednesday, 23 January 2019 at 09:14:18 UTC, Bienlein wrote:
 On Friday, 18 January 2019 at 08:55:23 UTC, Paulo Pinto wrote:
 D really needs its killer use case if it is to move away 
 from that list.
D is a lot like Scala on the JVM: Both language have myriads of language features and bells and whistles, but there is no killer feature in the language itself.
For me the killer feature is meta-programming. No other language comes close.
It's a nice feature, but won't make any startup company choose D or any other company as the language for their next software product.
Well, the truth is, people don't come to a language because of a killer feature. Sometimes it's even the opposite. Java and Dart are familiar to some extent because of lack of killer features. But what they might lack in "expressiveness", they make up for with amazing ecosystem and IDE support (which is usually inversely proportional to language expressiveness). I can't think of any language that is popular just because of language features. Python? Not really, it has a great standard library, a broad ecosystem of libraries for networking, science etc. Rust? Not really. While their memory management features are cool, many people flock to Rust because of its rapidly growing ecosystem and a good strategy/project scope management.
Jan 23
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 24/01/2019 1:20 AM, JN wrote:
 Well, the truth is, people don't come to a language because of a killer 
 feature. Sometimes it's even the opposite. Java and Dart are familiar to 
 some extent because of lack of killer features.
Actually that isn't quite true. Java's killer feature is consistent simplicity. That is how it was originally sold to great success. The ecosystem and tooling came later. Also as an FYI, Rust has had significant marketing effort put into it. Consider its home page, it tells a story to get you into developing code fast. D's doesn't. It is much better and I think it might be time to have a complete rethink of D's because the last redesign wasn't all that different to what it was prior.
Jan 23
next sibling parent reply Bienlein <ffm2002 web.de> writes:
On Wednesday, 23 January 2019 at 12:26:02 UTC, rikki cattermole 
wrote:
 Java's killer feature is consistent simplicity. That is how it 
 was originally sold to great success. The ecosystem and tooling 
 came later.
Also, the Internet was Java's killer application. No other language had the libraries for accessing the Internet easily. Then there is dynamic class loading. This made things a little bit more unsafe at runtime but in general developer productivity rose sharply, comparable to Smalltalk and by order of magnitude compared to C++. At that time the competition for Java was only Smalltalk and C++. Performance was nevertheless good, because of runtime code optimization (HotSpot), which was a new thing (albeit taken from Strongtalk, some Smalltalk high performance variant)
Jan 23
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 23 January 2019 at 13:03:18 UTC, Bienlein wrote:
 Also, the Internet was Java's killer application. No other 
 language had the libraries for accessing the Internet easily. 
 Then there is dynamic class loading. This made things a little 
 bit more unsafe at runtime but in general developer 
 productivity rose sharply, comparable to Smalltalk and by order 
 of magnitude compared to C++. At that time the competition for 
 Java was only Smalltalk and C++. Performance was nevertheless 
 good, because of runtime code optimization (HotSpot), which was 
 a new thing (albeit taken from Strongtalk, some Smalltalk high 
 performance variant)
I would think that dynamic class loading is something that could be bolted on to C++ (and presumably D as well), albeit awkwardly.
Jan 23
parent Bienlein <ffm2002 web.de> writes:
On Wednesday, 23 January 2019 at 15:04:00 UTC, jmh530 wrote:
 I would think that dynamic class loading is something that 
 could be bolted on to C++ (and presumably D as well), albeit 
 awkwardly.
Dynamic class loading means there is no more link step.
Jan 23
prev sibling next sibling parent reply bachmeier <no spam.net> writes:
On Wednesday, 23 January 2019 at 12:26:02 UTC, rikki cattermole 
wrote:

 Also as an FYI, Rust has had significant marketing effort put 
 into it. Consider its home page, it tells a story to get you 
 into developing code fast. D's doesn't. It is much better and I 
 think it might be time to have a complete rethink of D's 
 because the last redesign wasn't all that different to what it 
 was prior.
I've made this comparison many times before, but I'll do it again... Look at what Rust offers as documentation for Cargo: https://doc.rust-lang.org/cargo/index.html This is what you get with Dub: https://dub.pm/getting_started One is professional documentation, the other was something hacked together by a sixth grader over the weekend. The Dub documentation is good through the part demonstrating `dub init`, then it falls apart. It talks about two configuration file formats - not one, but two ("use whichever you prefer") and I have no idea there is even a discussion of configuration file formats at that point. Then there's a link to this word dump https://dub.pm/package-format-json.html. Noticeably absent: how I'm supposed to *use* Dub. Where do I put my source files? How do I add dependencies? Have you ever heard of an example? Then a little below that is a link to this page: https://dub.pm/publish.html. I wonder what that is for. Can't make heads or tails out of that. This is *introduction to the language*. If someone sees that and doesn't run away, there's something wrong. I most definitely would have gone with Rust if it had been usable when I started using D. The Dub documentation makes it really hard to bring in users - and makes Rust look like a sane language in comparison.
Jan 23
parent reply Bienlein <ffm2002 web.de> writes:
On Wednesday, 23 January 2019 at 14:14:06 UTC, bachmeier wrote:
 I've made this comparison many times before, but I'll do it 
 again...

 Look at what Rust offers as documentation for Cargo:
 https://doc.rust-lang.org/cargo/index.html

 This is what you get with Dub:
 https://dub.pm/getting_started

 One is professional documentation, the other was something 
 hacked together by a sixth grader over the weekend. The Dub 
 documentation is good through the part demonstrating `dub 
 init`, then it falls apart. It talks about two configuration 
 file formats - not one, but two ("use whichever you prefer") 
 and I have no idea there is even a discussion of configuration 
 file formats at that point. Then there's a link to this word 
 dump https://dub.pm/package-format-json.html.

 Noticeably absent: how I'm supposed to *use* Dub. Where do I 
 put my source files? How do I add dependencies? Have you ever 
 heard of an example?

 Then a little below that is a link to this page: 
 https://dub.pm/publish.html. I wonder what that is for. Can't 
 make heads or tails out of that.

 This is *introduction to the language*. If someone sees that 
 and doesn't run away, there's something wrong. I most 
 definitely would have gone with Rust if it had been usable when 
 I started using D. The Dub documentation makes it really hard 
 to bring in users - and makes Rust look like a sane language in 
 comparison.
This is all true, but you need to keep in mind that Go had no real package manager for a long time. There was the "go get" command which loaded the code from some github repo in the state it was at the time when being loaded. There was no version control. Nobody really cared (the vendor stuff in Go was added with Go 1.10 or 1.11). Goroutines were the killer feature of the language that paved the way, because this was badly needed for writing server-side software. I don't think D will have some killer app in the mid-term future. So what is left is to put a killer feature into the language like CSP or safe manual memory management or something.
Jan 23
parent reply Neia Neutuladh <neia ikeran.org> writes:
On Wed, 23 Jan 2019 14:37:30 +0000, Bienlein wrote:
 This is all true, but you need to keep in mind that Go had no real
 package manager for a long time. There was the "go get" command which
 loaded the code from some github repo in the state it was at the time
 when being loaded. There was no version control. Nobody really cared
 (the vendor stuff in Go was added with Go 1.10 or 1.11). Goroutines were
 the killer feature of the language that paved the way, because this was
 badly needed for writing server-side software.
Go has several killer features: * It's got a GC and yet is endorsed by one of the major people behind C. This helps people get over their fear of garbage collection and into appreciating the benefits. * It's also got "pointers". They're actually references with pointer-ish syntax, but that makes people coming from C/C++ more comfortable. * It's not Java, and it's not slower than Java. * There was a team in Google that would rewrite old, crufty C++ code in Go. Was Go a benefit? Maybe in some ways, but the major benefit was a rewrite that the owning team didn't have to do. That earned goodwill among thousands of developers attached to Go as a language. * It's backed by Google (in large part because of that goodwill). I don't think fibers are all that important for Go's success. Maybe for people who would have looked at node.js but didn't want to use javascript?
Jan 23
parent reply bauss <jj_1337 live.dk> writes:
On Wednesday, 23 January 2019 at 16:47:04 UTC, Neia Neutuladh 
wrote:
 On Wed, 23 Jan 2019 14:37:30 +0000, Bienlein wrote:
 This is all true, but you need to keep in mind that Go had no 
 real package manager for a long time. There was the "go get" 
 command which loaded the code from some github repo in the 
 state it was at the time when being loaded. There was no 
 version control. Nobody really cared (the vendor stuff in Go 
 was added with Go 1.10 or 1.11). Goroutines were the killer 
 feature of the language that paved the way, because this was 
 badly needed for writing server-side software.
Go has several killer features: * It's got a GC and yet is endorsed by one of the major people behind C. This helps people get over their fear of garbage collection and into appreciating the benefits. * It's also got "pointers". They're actually references with pointer-ish syntax, but that makes people coming from C/C++ more comfortable. * It's not Java, and it's not slower than Java. * There was a team in Google that would rewrite old, crufty C++ code in Go. Was Go a benefit? Maybe in some ways, but the major benefit was a rewrite that the owning team didn't have to do. That earned goodwill among thousands of developers attached to Go as a language. * It's backed by Google (in large part because of that goodwill). I don't think fibers are all that important for Go's success. Maybe for people who would have looked at node.js but didn't want to use javascript?
Go is garbage and it's only popular because Google is behind it. It has absolutely nothing to do with the language itself.
Jan 23
parent reply bachmeier <no spam.net> writes:
On Wednesday, 23 January 2019 at 18:42:06 UTC, bauss wrote:

 Go is garbage and it's only popular because Google is behind it.

 It has absolutely nothing to do with the language itself.
I don't know if I'd agree that it's garbage - it has a lot of appeal to certain types of programmers, though not to me - but I do agree that it's popular (to whatever extent it is) because of Google. I remember when the language was first announced, there were a lot of people excited by the prospect that GOOGLE IS CREATING A LANGUAGE. IT HAS TO BE AWESOME. These were not people who tried the language and found it to be better than the alternatives. They were people who hadn't even seen it. That was back in the days when Microsoft was the devil and Google were the good guys. Of course, one could argue that it must have offered enough to keep some of them interested. They were able to get stuff done when they used it.
Jan 24
parent reply Ben <benny.luypaert rhysoft.com> writes:
On Thursday, 24 January 2019 at 14:44:07 UTC, bachmeier wrote:
 Of course, one could argue that it must have offered enough to 
 keep some of them interested. They were able to get stuff done 
 when they used it.
The build in and good performing http server hit the sweet spot. Never underestimate the desire of people to simply get going fast. As a developer, you can be assured that your Go HTTP server will survive a upgrade to a new major release version. That assurance is a bit less with D. ;) One of D its weak spots, that its so general positioned as a C++ replacement, that it lacks a identify for itself.
Jan 24
parent reply Martin Tschierschke <mt smartdolphin.de> writes:
On Thursday, 24 January 2019 at 23:02:07 UTC, Ben wrote:
 On Thursday, 24 January 2019 at 14:44:07 UTC, bachmeier wrote:
 Of course, one could argue that it must have offered enough to 
 keep some of them interested. They were able to get stuff done 
 when they used it.
The build in and good performing http server hit the sweet spot. Never underestimate the desire of people to simply get going fast. As a developer, you can be assured that your Go HTTP server will survive a upgrade to a new major release version. That assurance is a bit less with D. ;) One of D its weak spots, that its so general positioned as a C++ replacement, that it lacks a identify for itself.
Yes! The following idea was written by several posters: Keep std. small, but offer a special label "recommended by D Foundation" for some more packages available via code.dlang (DUB) This would mean, that some of them, currently under individual control are moved to the official D Foundation Git repository. So those could be kept up to date, to ensure no breakage when the language evolves. ( On my wish list at the top: An official D database connector. (MySql/MariaDB, Postgres, SQlite, MonetDB..) ) What about trying to find and to fund a maintainer for this purpose? (Next funding goal Mike Parker?)
Jan 25
parent reply Jacob Shtokolov <jacob.100205 gmail.com> writes:
On Friday, 25 January 2019 at 10:15:15 UTC, Martin Tschierschke 
wrote:
 ( On my wish list at the top: An official D database connector. 
 (MySql/MariaDB, Postgres, SQlite, MonetDB..) )

 What about trying to find and to fund a maintainer for this 
 purpose?
 (Next funding goal Mike Parker?)
I think it requires an official API specification like DB-API in Python. Being a general-purpose programming language, D introduces some fragmentation inside its community. For example, some people don't want to use the GC, but some people do. So the API probably need to take such points into consideration. And I could say the same for HTTP-related standards. Take a look at what PHP has: https://www.php-fig.org/psr/psr-7/ https://www.php-fig.org/psr/psr-18/ Regarding the killer feature: I have a strong feeling that D would perfectly fit the web application development scenario. The HTTP protocol is stateless by its nature, so it's theoretically possible to use a region-based allocation strategy for HTTP request handling. This is where the precise GC might play a better role, BTW. Also, D has much closer syntax to JavaScript, which means this may help to decrease frustration switching between different backend and frontend languages when you develop a web app (if I'm correct, this problem is solved only in Clojure/ClojureScript today). In addition, I guess that it's totally possible to write a TypeScript-like transpiler for D, which can help to bring type safety to the frontend.
Jan 25
parent Jacob Shtokolov <jacob.100205 gmail.com> writes:
On Friday, 25 January 2019 at 11:07:48 UTC, Jacob Shtokolov wrote:
 This is where the precise GC might play a better role, BTW.
Misspelling: not precise, conservative GC of course.
Jan 25
prev sibling parent Bienlein <jeti789 web.de> writes:
On Wednesday, 23 January 2019 at 12:26:02 UTC, rikki cattermole 
wrote:
 On 24/01/2019 1:20 AM, JN wrote:
 Well, the truth is, people don't come to a language because of 
 a killer feature. Sometimes it's even the opposite. Java and 
 Dart are familiar to some extent because of lack of killer 
 features.
Actually that isn't quite true. Java's killer feature is consistent simplicity. That is how it was originally sold to great success. The ecosystem and tooling came later.
Java is going to get CSP-style concurency as in Go probably in JDK13. It's called Project Loom. Here is a presentation by Mark Reinhold (Java project lead at Oracle) where he is presenting a preview of JDK13 and Project Loom: https://www.youtube.com/watch?time_continue=4125&v=nKJbDYRsO0s (starting at 1:08:47) This will create some competition for Go what the multi-threading model is concerned. Java is better than Go otherwise in every aspect except memory consumption.
Jan 23