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 2019
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 2019
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 2019
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 2019
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.

6. Web framework & database use php's laravel and java's 
sprint-boot.
7. Web use Javascript / typescript.
Jan 17 2019
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.

 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.




every release since they started integrated Midori lessons into 
it, while making it beat TechEmpower and working closely with 
Unity.


their game engines, even if only for gameplay scripts, while 



D really needs its killer use case if it is to move away from 
that list.
Jan 18 2019
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.




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 2019
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.




 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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019