On Fri, 2015-03-13 at 20:12 -0700, Andrei Alexandrescu via Digitalmars-d wrote:
> On 3/13/15 5:54 PM, deadalnix wrote:
> > On Saturday, 14 March 2015 at 00:34:35 UTC, Ziad Hatahet wrote:
> >> On Fri, Mar 13, 2015 at 6:45 AM, Russel Winder via Digitalmars-d < digitalmars-d@puremagic.com> wrote:
> >>
> >>> The removal of shared memory multi-threading in favour of using processes and channels should never be underestimated as a Really Good Thing™ that other native code languages (*) have failed to do anything about. Thus Go wins, others lose.
> >>>
> >>
> >> Except that Go does not really remove shared memory multithreading; it is
> >> still possible to get data races (which is why they have a race
> >> detector).
> >> They provide channels, but nothing is preventing races other than
> >> convention. On the other hand, Rust (a native code language) offers a
> >> much
> >> superior solution, with compile-time enforcement of data sharing.

Rust may indeed be superior to Go on this. It will be interesting to see if Rust, once formally released to world, makes an impression on the rise of Go. I certainly hope so, since writing Rust code is nicer than writing Go code.

I suspect not. Go marketed itself as a "better C" (as C++ did originally), and got some Python folk and a lot of PHP folk to switch: Go's main traction is in the Internet, networking, Web applications arena despite claiming to be a systems programming language. Rust is pitching against C++ as D does. C++ folk appear to be locked-in in a way that means Rust and D need to rethink the pitch.

> >
> > How very true, but, by the time you run into data races, you are pretty much commited to go.
> >
> > Sad.

Why? In any CSP-like system, it is possible to get deadlock, livelock and races. However "debugging" them is nigh on trivial compared to the effort required with shared-memory multi threading.

PyCSP and Python-CSP as well as Go show this.

> I'm surprised Russel fell for it. -- Andrei

Fell for what?

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Sat, 2015-03-14 at 09:09 +0000, weaselcat via Digitalmars-d wrote: […]

> I've never seen Go praised for its error handling, it is always the opposite.
> 
> Go error handling is verbose and ugly. http://blog.golang.org/error-handling-and-go

Go's mechanism of error handling is for me a horrible regression to 1960's programming. However, the feedback from those who really have "drunk the Kool-Aid" is interesting: the tension between the way of working and number of error in released systems does appear to indicate that they may be getting many fewer errors. However some of the tortuous argumentation about how the coding of error is the right way forward does smack a bit of Stockholm Syndrome.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Fri, 2015-03-13 at 00:22 -0700, Walter Bright via Digitalmars-d wrote:
> On 3/12/2015 11:57 PM, Russel Winder via Digitalmars-d wrote:
> > How about lining up some features for removal.
> 
> Easier said than done. I've proposed a couple things for removal, but got a lot of pushback. Some things have been successfully removed:

Pushback can be ignored, and indeed should in some cases.

Java is going to come to this battle when primitive types finally get removed from the language.

> . octal literals

C should be incinerated for the 0777 abomination. At least 0o777 can work reasonably.

> . 'bit' data type
> . builtin complex numbers

Electronics folk love these. Many people use Python exactly for this type.

> . NCEG floating point comparison
> . typedef
> . local operators new & delete
> 
> 
> > C++, Fortran, and Java are big, complicated languages, that keep getting bigger and more complicated because of the obsession with backward compatibility. D is already a big, complicated language. If people like straighforward (not necessarily simple) languages, then the inference is quite easy.
> 
> Has any language been successful at abandoning their user base (i.e. existing code)? Going from D1 to D2 nearly destroyed D. I'm not eager to try that again.

The war is being played out in the Python 2/3 arena certainly. Interestingly though there are fewer and fewer Python 2 hold outs. Their holding out has made Python 3 change a little, and for the better in my view – even though I refuse to write any Python 2 specific code.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Russel Winder:

> (*) IPython grew out of Python and become the de facto system, but was a mess structurally. IPython is splitting into IPython
> the original thing and Jupyter all the UI related stuff

Jupyter looks like a nice idea and a nice project. I'd like to understand how Jupyter compared to Sage.

Bye,
bearophile

On Saturday, 14 March 2015 at 09:03:11 UTC, Russel Winder wrote:
> On Fri, 2015-03-13 at 07:55 -0700, Andrei Alexandrescu via Digitalmars-d
> wrote:
>> On 3/13/15 6:45 AM, Russel Winder via Digitalmars-d wrote:
>> > The removal of shared memory multi-threading in favour of using
>> > processes and channels should never be underestimated as a Really Good
>> > Thing™ that other native code languages (*) have failed to do anything
>> > about. Thus Go wins, others lose.
>> 
>> That's a marketing success as well. Go didn't "remove" shared memory multi-threading, it just unrecommends it. That's quite unremarkable from a programming language design standpoint, but as discussed that's not always crucial for success. -- Andrei
>
> I think you need to show a bit of Go code that uses threads to be able
> to back up that claim.

No, that is the classical "prove that god do not exist" trick. This is up to Go to prove it is safe. Hint: it isn't.

On Saturday, 14 March 2015 at 09:12:31 UTC, Russel Winder wrote:
> Why? In any CSP-like system, it is possible to get deadlock, livelock
> and races. However "debugging" them is nigh on trivial compared to the
> effort required with shared-memory multi threading.
>
> PyCSP and Python-CSP as well as Go show this.

I am not sure if CSP alone is the main reason for why people use Go for micro services. I guess it is the combined focus on high concurrency, simplicity and stability that makes it suitable for the kind of things you would use a new language for: smaller projects with specific demands.

>> I'm surprised Russel fell for it. -- Andrei
>
> Fell for what?

Andrei doesn't grok that Go has an overall better infrastructure for writing high concurrency applications that are bottle necked by network traffic.

D lacks:
1. stack protection for fibers
2. non-hogging GC
3. a simple language that makes it easy to read external library code
4. channels

And that' only to get started competing, add infrastructure adoption and eco system and the competition is already lost.

D+vibe.d is a nice offering, but not a winning horse if comes down to a race. Competing on Go's terms will not lead anywhere.

D would be better off going for a "free" niche, like game servers, non-C++ game programming etc.

On Sat, 2015-03-14 at 09:44 +0000, deadalnix via Digitalmars-d wrote: […]
> No, that is the classical "prove that god do not exist" trick. This is up to Go to prove it is safe. Hint: it isn't.

This could go on ad nauseam. It is up to C, C++, D, Rust, Fortran, Java, Python, Ruby, etc., etc. to prove they are safe. Hint: they aren't. The closest there is is Spark Ada, and that has problems.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Saturday, 14 March 2015 at 09:00:11 UTC, Russel Winder wrote:

>
> If D is to compete in the financial computing arena where Python and R
> currently rule, there needs to be all the libraries for doing time
> series analysis, and rendering them graphically. There also needs to be
> a workflow that fits the users of the domain. The market leader is
> currently Jupyter (*) in the finance places I have connection with.

D can gain popularity by doing what Rcpp has done, by making it easy to embed C++ code inside R. Rcpp is currently the most common dependency among all R packages. I have done the same with D though it's not yet in a form that others can really use it (https://bitbucket.org/bachmeil/dmdinline).

The best thing to happen to D was the ability to create shared libraries on Linux. You can add D to your existing codebase incrementally. That is, in my opinion, D's "killer application". And D has an advantage over C++. R users will write C++ because they have to, whereas D is a language they'll use because they want to.

On Friday, 13 March 2015 at 13:18:03 UTC, Dicebot wrote:
> In my opinion it is better to focus on tempting users with D strong bits than oversell it by trying it compete in topics it has inherent disadvantage. There is not point in try to compete with Go on topic of simplicity - they have crippled the language tremendeously to get that simplicity. Simple D has no value - I would simply prefer Go instead of it as it has head start advantage in toolchain.
>
> Instead it is better to focus on explaining users that they don't want what they think they want, akin to that Bjarne quote. And don't be afraid to admit to certain users that D is not a best choice for them. It doesn't mean that such valuable feedback should be ignore - there is indeed a lot that can be improved in the learning curve. But trying to fight for user who makes choice with "trendy" and "simplicity" in mind is a battle lost from the very beginning.

this.
imo D's feature set is awesome and still it is reasonably easy to get a start with just a simple subset
of D.
one thing Go did really well was focusing on getting a complete set of basic libraries.
a foundation with support of most protocols.

i did two small projects for work within the last month, one in D (a multithreaded crawler that hammered a json API) and a uploader that can upload to S3 or Openstack Swift in Go.

So here goes my personal list:

D:
+ speed
+ the language itself and its features. i love how you can write pretty dense code with
UFCS, lambdas and ranges.
- stdlib. lots of missing pieces (e.g. email parsing, native http client)
- iv'e also spent a lot of time fighting with external libraries, reading their code (especially vibe-d as i used its http client and concurrency features). sometimes it was the missing documentation, sometimes just the complexity.
- debugging and tracing (osx/linux, and to be fair, i haven't tried with Go)

Go
+ libraries, yes the hipster factor also produces a lot of crap. but still, i needed to get stuff done yesterday. documentation/apis are often straight forward, i rarely had to look into the sources.
+ support: documentation, build tools, formatting. "it just works" (just today i discovered the awesome dfmt. this should come with dmd...).
there is also sites that just explain a couple of concepts, e.g. http://www.golangpatterns.info . very helpful
- the language itself. the code just looks ugly and shoehorned around their simple concepts
- error handling...

something that would have helped me would be a nice guide on how to setup a whole development chain:
- list of utilities needed (e.g. dmd, vim, DCD, dfmt...) and their configuration
- build tools (dub),
- debugging, tracing
- code organization best practices.

in general the current "D crowd" seems mostly game and language people.
Distributed systems, databases and high performance web services is something i
think D would really shine. Not sure on how to better serve this market though.

I suspect most of the reason these IDE vs editor debates even happen is because the editors by default don't do what IDEs do, but can. All you've mentioned is possible in Emacs and has been for basically forever.

Atila

On Friday, 13 March 2015 at 08:53:16 UTC, JN wrote:
> On Friday, 13 March 2015 at 06:58:59 UTC, Russel Winder wrote:
>> On Thu, 2015-03-12 at 17:20 -0700, Andrei Alexandrescu via Digitalmars-d
>> wrote:
>> […]
>>> - no good IDE
>>
>> Not entirely true, there are Emacs, VIM, LiteIDE, and others for Go
>> development.
>
> Never heard of LiteIDE, but Emacs and VIM aren't really IDEs,
> they are just glorified text editors. When people say IDE, they
> not only mean the text editing part, but the management of the
> build process and visual debugging, including watches,
> breakpoints, step-by-step debugging etc.