www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D vs Go in real life

reply "Atila Neves" <atila.neves gmail.com> writes:
So my buddy Jeff at work is a massive Go fan and goes on about it 
all the time. He even got me to try it once but I mostly hated 
it. To each his own. However, he laid down the gauntlet last 
Thursday saying his MQTT broker implementation in Go couldn't be 
beaten in performance. For those not in the know, MQTT is a 
publish/subscribe network protocol. And Go is all about parallel 
network programming, so what could beat it, right?

Always up for a challenge, I went ahead and implemented enough of 
an MQTT broker to handle the functionality required by the 
benchmark program he wrote to test his own code. In D of course, 
with the network code coming from vibe.d.

The result? 11% - 34% faster than the Go implementation depending 
on the workload (34%, 30%, 11%, 30%). The low end of that was 
with a higher number of connected clients, and that could always 
be me not using vibe.d well (I'd never used it before last 
Friday).

I also measured Mosquitto, an open-source C implementation. It 
mostly beat my D one, and went from 1% slower to 17% faster than 
the D/vibe.d combo depending on workload, with that 17% being an 
outlier (-1%, 5%, 17%, 3%, 3%).

I actually have error bars for all those values but thought it'd 
be too much to post them here. D FTW!

Atila

P.S. Not all was roses. Although getting to write D again was 
awesome (and I beat him), I ran into multiple problems:

- Trying to use dub to compile the project in release or profile 
mode flat out didn't work. I had to take the verbose output of 
dub, use it to compile vibe.d in debug mode into an object file 
and compile my own code separately and link it in. I believe this 
was a dmd regression. Speaking of which, why does dub recompile 
the world instead of tracking dependencies (I tried the rdmd 
option once but that didn't work, I can't remember why)?

- I ran into a dmd bug when I tried to use TaskPool.map with a 
delegate so I had to give up trying that possible optimisation.

- I ran into another dmd bug (it crashed) at one point if -inline 
was used.

- dub build with LDC and GDC failed miserably. I think it was 
because of vibe.d.
Nov 05 2013
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
Yeah, unfortunately there were lot of 2.063.2 bugs that vibe.d 
triggered during transition to 2.064, it was quite a mess for 
some time. I expect out-of-the-box experience to be much better 
at point of 2.064 release.
Nov 05 2013
parent reply "Dicebot" <public dicebot.lv> writes:
On Tuesday, 5 November 2013 at 13:11:26 UTC, Dicebot wrote:

 Yeah, unfortunately there were lot of 2.063.2 bugs that vibe.d 
 triggered during transition to 2.064, it was quite a mess for 
 some time. I expect out-of-the-box experience to be much better 
 at point of 2.064 release.


P.S. Also there are speculations about performance regressions,
once those are figured out it may yield even better results :)
Nov 05 2013
parent "Atila Neves" <atila.neves gmail.com> writes:
On Tuesday, 5 November 2013 at 13:12:33 UTC, Dicebot wrote:

 P.S. Also there are speculations about performance regressions,
 once those are figured out it may yield even better results :)


So I read while looking around for info on how to use vibe.d 
properly. I might revisit and remeasure once a see a post about 
it and rub it in my buddy's face again. :)
Nov 05 2013
prev sibling next sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Tuesday, 5 November 2013 at 13:05:21 UTC, Atila Neves wrote:

 So my buddy Jeff at work is a massive Go fan and goes on about 
 it all the time. He even got me to try it once but I mostly 
 hated it. To each his own. However, he laid down the gauntlet 
 last Thursday saying his MQTT broker implementation in Go 
 couldn't be beaten in performance. For those not in the know, 
 MQTT is a publish/subscribe network protocol. And Go is all 
 about parallel network programming, so what could beat it, 
 right?

 Always up for a challenge, I went ahead and implemented enough 
 of an MQTT broker to handle the functionality required by the 
 benchmark program he wrote to test his own code. In D of 
 course, with the network code coming from vibe.d.

 The result? 11% - 34% faster than the Go implementation 
 depending on the workload (34%, 30%, 11%, 30%). The low end of 
 that was with a higher number of connected clients, and that 
 could always be me not using vibe.d well (I'd never used it 
 before last Friday).

 I also measured Mosquitto, an open-source C implementation. It 
 mostly beat my D one, and went from 1% slower to 17% faster 
 than the D/vibe.d combo depending on workload, with that 17% 
 being an outlier (-1%, 5%, 17%, 3%, 3%).

 I actually have error bars for all those values but thought 
 it'd be too much to post them here. D FTW!

 Atila

 P.S. Not all was roses. Although getting to write D again was 
 awesome (and I beat him), I ran into multiple problems:

 - Trying to use dub to compile the project in release or 
 profile mode flat out didn't work. I had to take the verbose 
 output of dub, use it to compile vibe.d in debug mode into an 
 object file and compile my own code separately and link it in. 
 I believe this was a dmd regression. Speaking of which, why 
 does dub recompile the world instead of tracking dependencies 
 (I tried the rdmd option once but that didn't work, I can't 
 remember why)?

 - I ran into a dmd bug when I tried to use TaskPool.map with a 
 delegate so I had to give up trying that possible optimisation.

 - I ran into another dmd bug (it crashed) at one point if 
 -inline was used.

 - dub build with LDC and GDC failed miserably. I think it was 
 because of vibe.d.


this is with dmd? I wonder how those numbers would look if you 
could get ldc/gdc up and running.
Nov 05 2013
parent reply "Atila Neves" <atila.neves gmail.com> writes:
 this is with dmd? I wonder how those numbers would look if you 
 could get ldc/gdc up and running.


Yep, dmd. I mentioned the problems getting the whole thing 
(including vibe.d) to compile with ldc and gdc because I was 
trying those two exactly to try and eke more performance out. 
Neither worked with dub and I think running them manually got me 
into problems too.
Nov 05 2013
parent reply Alexandr Druzhinin <drug2004 bk.ru> writes:
05.11.2013 22:17, Atila Neves пишет:

 this is with dmd? I wonder how those numbers would look if you could
 get ldc/gdc up and running.


 Yep, dmd. I mentioned the problems getting the whole thing (including
 vibe.d) to compile with ldc and gdc because I was trying those two
 exactly to try and eke more performance out. Neither worked with dub and
 I think running them manually got me into problems too.


Did you try --compiler=ldmd2 to use ldc? May be it helps.
Nov 05 2013
parent "Atila Neves" <atila.neves gmail.com> writes:
 Did you try --compiler=ldmd2 to use ldc? May be it helps.


I tried every combination I could think of, including that one.
Nov 05 2013
prev sibling next sibling parent reply "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
So, is he writing D code now :D. Or did he complain about the 
syntax, all the types being on the left?
Nov 05 2013
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, November 05, 2013 16:27:39 Jesse Phillips wrote:

 So, is he writing D code now :D. Or did he complain about the
 syntax, all the types being on the left?


LOL. I doubt that someone who's that big a fan of Go would switch thanks to 
that (would you have switched to Go if the Go implementation had won?) - 
especially when Go and D are so dissimilar. In general, I would expect fans of 
Go to dislike D and fans of D to dislike Go simply because of how very 
different their designs are. But it _would_ show him that D can compete with Go 
for performance even in Go's area of expertise.

Go is on the list of languages that I'd like to spend more time becoming 
familiar with, because I think that it's good to know lots of programming 
languages, but the more I learn about it, the less I like it. Its design 
philosophies are just too different from my preferences.

- Jonathan M Davis
Nov 05 2013
next sibling parent reply "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Wednesday, 6 November 2013 at 05:38:54 UTC, Jonathan M Davis 
wrote:

 LOL. I doubt that someone who's that big a fan of Go would 
 switch thanks to
 that (would you have switched to Go if the Go implementation 
 had won?) -


Of course not, Go puts the types on the wrong side for me to 
switch. Had a coworker mention to me that I should look into the 
philosophy of Go amongst other points (not enough tech talk 
around). After a little bit of discussion (mostly not around Go) 
I let him know I was already aware of Go's philosophy and it 
didn't match my desires. Citing my attempt at Sorting Time[1] as 
an example. He agreed, lack of generics sucks.

1. http://he-the-great.livejournal.com/49072.html
Nov 05 2013
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, November 06, 2013 07:18:43 Jesse Phillips wrote:

 On Wednesday, 6 November 2013 at 05:38:54 UTC, Jonathan M Davis
 
 wrote:

 LOL. I doubt that someone who's that big a fan of Go would
 switch thanks to
 that (would you have switched to Go if the Go implementation
 had won?) -


 
 Of course not, Go puts the types on the wrong side for me to
 switch. Had a coworker mention to me that I should look into the
 philosophy of Go amongst other points (not enough tech talk
 around). After a little bit of discussion (mostly not around Go)
 I let him know I was already aware of Go's philosophy and it
 didn't match my desires. Citing my attempt at Sorting Time[1] as
 an example. He agreed, lack of generics sucks.
 
 1. http://he-the-great.livejournal.com/49072.html


Yikes. Sorting time in D is trivial. It would never occur to me that that 
would be hard.

But I'm so sold on D's way of doing things with ranges and generic code that 
most any other language is likely to seem worse in comparison.

- Jonathan M Davis
Nov 05 2013
parent reply "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Wednesday, 6 November 2013 at 07:02:20 UTC, Jonathan M Davis 
wrote:

 Yikes. Sorting time in D is trivial. It would never occur to me 
 that that would be hard.


I know, it's something I use. Something one probably expects to 
Just Work. I thought for sure Go would have provided the needed 
functions, but no they didn't.

While I was trying to find additional information I came across 
this blog[1] which had such a fitting quote, "The sort package in 
Go is pretty neat." Directly followed by "there are some specific 
functions for sort some of the basic types."

When trying to write a blog which centers around the sort 
packaging being *the* example of why Go's lack of generics sucks, 
reading that the package is "neat" was not something I expected.

1. http://blog.jessta.id.au/2012/06/gos-sort-package.html
Nov 06 2013
next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
06-Nov-2013 19:34, Jesse Phillips пишет:

 On Wednesday, 6 November 2013 at 07:02:20 UTC, Jonathan M Davis wrote:

 Yikes. Sorting time in D is trivial. It would never occur to me that
 that would be hard.


 I know, it's something I use. Something one probably expects to Just
 Work. I thought for sure Go would have provided the needed functions,
 but no they didn't.

 While I was trying to find additional information I came across this
 blog[1] which had such a fitting quote, "The sort package in Go is
 pretty neat." Directly followed by "there are some specific functions
 for sort some of the basic types."


I swear when I glanced at [1] I thought it was sarcasm. Reading it again 
- I see it wasn't :)


 When trying to write a blog which centers around the sort packaging
 being *the* example of why Go's lack of generics sucks, reading that the
 package is "neat" was not something I expected.

 1. http://blog.jessta.id.au/2012/06/gos-sort-package.html



-- 
Dmitry Olshansky
Nov 06 2013
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 06.11.2013 19:45, schrieb Dmitry Olshansky:

 06-Nov-2013 19:34, Jesse Phillips пишет:

 On Wednesday, 6 November 2013 at 07:02:20 UTC, Jonathan M Davis wrote:

 Yikes. Sorting time in D is trivial. It would never occur to me that
 that would be hard.


 I know, it's something I use. Something one probably expects to Just
 Work. I thought for sure Go would have provided the needed functions,
 but no they didn't.

 While I was trying to find additional information I came across this
 blog[1] which had such a fitting quote, "The sort package in Go is
 pretty neat." Directly followed by "there are some specific functions
 for sort some of the basic types."


 I swear when I glanced at [1] I thought it was sarcasm. Reading it again
 - I see it wasn't :)


You will find lots of similar explanations from Go devotees when reading 
gonuts mailing list. :)

--
Paulo
Nov 06 2013
prev sibling parent "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Wednesday, 6 November 2013 at 18:45:49 UTC, Dmitry Olshansky 
wrote:

 I swear when I glanced at [1] I thought it was sarcasm. Reading 
 it again - I see it wasn't :)


I know it. But I was already aware the author was very pro-Go 
from [2], "Interfaces in Go are very powerful, but their power 
comes from being generic."

FYI, the blogs are actually good for learning Go (in the small 
scale), but they didn't contain quite enough information that I 
needed to reference them (just reiterated less information than I 
already had).


 1. http://blog.jessta.id.au/2012/06/gos-sort-package.html




2. http://blog.jessta.id.au/2011/06/golang-interfaces.html
Nov 06 2013
prev sibling parent reply "Kagamin" <spam here.lot> writes:
On Wednesday, 6 November 2013 at 15:34:54 UTC, Jesse Phillips 
wrote:

 1. http://blog.jessta.id.au/2012/06/gos-sort-package.html


Hmm... if sort.Sort accepts a sortable interface, they could 
define those 3 methods for respective arrays so that they would 
satisfy the interface, and sort.Sort would accept them 
transparently. Well, if go allows extending array's interface.
Nov 06 2013
parent reply "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Wednesday, 6 November 2013 at 20:52:41 UTC, Kagamin wrote:

 On Wednesday, 6 November 2013 at 15:34:54 UTC, Jesse Phillips 
 wrote:

 1. http://blog.jessta.id.au/2012/06/gos-sort-package.html


 Hmm... if sort.Sort accepts a sortable interface, they could 
 define those 3 methods for respective arrays so that they would 
 satisfy the interface, and sort.Sort would accept them 
 transparently. Well, if go allows extending array's interface.


It does not. A specific type must be created and the functions 
defined for it. Was one of the first WTFs I hit. It doesn't solve 
the lack of generics problem, which is much more important.
Nov 06 2013
parent "Kagamin" <spam here.lot> writes:
Heh, from http://research.swtch.com/interfaces

 Among other metadata, the type description structure contains a 
 list of the methods implemented by that type. Similarly, the 
 compiler generates a (different) type description structure for 
 each interface type like Stringer; it too contains a method 
 list. The interface runtime computes the itable by looking for 
 each method listed in the interface type's method table in the 
 concrete type's method table.


So methods are tightly coupled with types after all. Doesn't look 
like what go claims about decoupling types and methods.
Nov 07 2013
prev sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Wednesday, 6 November 2013 at 05:38:54 UTC, Jonathan M Davis 
wrote:

 On Tuesday, November 05, 2013 16:27:39 Jesse Phillips wrote:

 So, is he writing D code now :D. Or did he complain about the
 syntax, all the types being on the left?


 LOL. I doubt that someone who's that big a fan of Go would 
 switch thanks to
 that (would you have switched to Go if the Go implementation 
 had won?) -
 especially when Go and D are so dissimilar. In general, I would 
 expect fans of
 Go to dislike D and fans of D to dislike Go simply because of 
 how very
 different their designs are. But it _would_ show him that D can 
 compete with Go
 for performance even in Go's area of expertise.

 Go is on the list of languages that I'd like to spend more time 
 becoming
 familiar with, because I think that it's good to know lots of 
 programming
 languages, but the more I learn about it, the less I like it. 
 Its design
 philosophies are just too different from my preferences.

 - Jonathan M Davis



I rather use D than Go, but it has more to do with Go's community 
with their religion decisions about generics, dynamic loading, 
exceptions, enumerations, package management than anything else.

The language follows the Pascal tradition of type declarations 
and safety before performance dirty tricks. I find quite 
appealing its Oberon and Alef/Lingo influences.

It is good enough for many cases where people, wrongly, still use 
C. For example, the complete UNIX user space.

Now for those of us that have become used to the niceties the 
mainstream languages have adopted from academia in the last 30 
years, Go feels a bit too light.

Anyway on my day job, we will not be moving away from JVM/.NET 
world any time soon.

--
Paulo
Nov 05 2013
next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 6 November 2013 at 07:26:42 UTC, Paulo Pinto wrote:

 The language follows the Pascal tradition of type declarations 
 and safety before performance dirty tricks. I find quite 
 appealing its Oberon and Alef/Lingo influences.


And still it is not quite safe.


 Anyway on my day job, we will not be moving away from JVM/.NET 
 world any time soon.


You may want to look at scala then.
Nov 05 2013
next sibling parent reply "Bienlein" <jeti789 web.de> writes:
Go is on the list of languages that I'd like to spend more time 
becoming familiar with, because I think that it's good to know 
lots of programming languages, but the more I learn about it, 
the less I like it. Its design philosophies are just too 
different from my preferences.


Go IMHO is a modernized C and there is nothing in addition from
what I can see (except CSP). It is what turns out if someone
nowadays did something exactly like C with modern means.


I rather use D than Go, but it has more to do with Go's 
community with their religion decisions about generics, dynamic 
loading,


I spent some time reading postings in the Go user forum. Go is
today what for us earlier was Basic or Pascal. Something very
exciting to get into all this stuff. People seem to be quite
religious about it in the sense that it feels holes of boredom in
your life by getting exciting about a programming language.


 You may want to look at scala then.


Then have a look at this thread in the Scala user forum:
https://groups.google.com/forum/?hl=de#!topic/scala-user/D9QDOnHSUu8
It is about build times in Scala not scaling up. One reply was
"Do you have very fast SSDs in your computer?". When I read that
I decided only to do a little spare time Scala project and that's
it. Might serve me to find a better Java job one day. D has
immutable objects and pure functions. I rather do D than Scala,
actually ...

Lightweight Threads in Go and Rust

What is a *BIG* plus for Go and Rust are lightweight threads. You
can spawn some thousand of them and it's no problem. I really
wished D had that kind of threads as well. For nowaydays
server-side development where applications need to bear heavy
load and load peaks this is an important thing.

-- Bienlein
Nov 06 2013
next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Wednesday, 6 November 2013 at 08:22:36 UTC, Bienlein wrote:

 ..
 Lightweight Threads in Go and Rust

 What is a *BIG* plus for Go and Rust are lightweight threads. 
 You
 can spawn some thousand of them and it's no problem. I really
 wished D had that kind of threads as well. For nowaydays
 server-side development where applications need to bear heavy
 load and load peaks this is an important thing.

 -- Bienlein


Which are also available in many JVM implementations and in .NET 
as tasks and asynch.

Although, it is nice PR for HN guys that ignore what these 
platforms offer.

--
Paulo
Nov 06 2013
parent reply "Bienlein" <jeti789 web.de> writes:
 Which are also available in many JVM implementations and in 
 .NET as tasks and asynch.

 Although, it is nice PR for HN guys that ignore what these 
 platforms offer.


I'm sure about that. When you block a thread in Java it is no
longer available for the thread pool and increasing the size of
it cannot be done at will, because creating new threads is not
lightweigt on the JVM.

There is a CSP implemention for Java made by some English
university: http://www.cs.kent.ac.uk/projects/ofa/jcsp/ Groovy
CSP makes use of it:
http://www.gpars.org/1.0.0/guide/guide/GroovyCSP.html But I
haven't tried what happens when you block threads.
Nov 06 2013
next sibling parent "Bienlein" <jeti789 web.de> writes:
On Wednesday, 6 November 2013 at 10:10:06 UTC, Bienlein wrote:

 Which are also available in many JVM implementations and in 
 .NET as tasks and asynch.

 Although, it is nice PR for HN guys that ignore what these 
 platforms offer.


 I'm sure about that. When you block a thread in Java it is no
 longer available for the thread pool and increasing the size of
 it cannot be done at will, because creating new threads is not
 lightweigt on the JVM.


Ah, unhappily Groovy CSP also can't do this: "Some
implementations (e.g. GoLang) can also detach the thread from the
CSP process when blocked on a channel." Source:
http://www.gpars.org/1.0.0/guide/guide/GroovyCSP.html So it's
basically non-blocking IO.

-- Bienlein
Nov 06 2013
prev sibling parent Russel Winder <russel winder.org.uk> writes:
On Wed, 2013-11-06 at 11:10 +0100, Bienlein wrote:
[…]

 I'm sure about that. When you block a thread in Java it is no
 longer available for the thread pool and increasing the size of
 it cannot be done at will, because creating new threads is not
 lightweigt on the JVM.


Anyone using thread management explicitly in Java is doing it wrong. The
one thing Go has totally right is "share data by passing messages" (*),
even the functional programming community know this one.

Kernel threads are not lightweight on any system, hence threads pools
and fibres (**).
    

 There is a CSP implemention for Java made by some English
 university: http://www.cs.kent.ac.uk/projects/ofa/jcsp/ Groovy
 CSP makes use of it:
 http://www.gpars.org/1.0.0/guide/guide/GroovyCSP.html But I
 haven't tried what happens when you block threads.


JCSP has many problems, not least it hasn't been formally released in
eons. People are still working on it but their concerns are academic
focussed rather than production focussed. Long story elided.

Groovy CSP is an integral part of GPars, but Václav Pech and I have been
wanting to create a new CSP realization in GPars directly rather than
using JCSP as a delegate. Sadly neither of us have the time these days.

The whole idea of even knowing about threads when using CSP, especially
Groovy CSP, and GPars in general, is total anathema. The whole point is
that the comutational model is about messages and the events they cause.
Threads are a hidden animating infrastructure. Programmers working with
CSP should never think about threads.





(*) There are some reasonable exceptions, but they are fewer and further
between than most people think.

(**) Which are really just threads from the 1970s and 1980s.

-- 
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
Nov 06 2013
prev sibling next sibling parent "qznc" <qznc web.de> writes:
On Wednesday, 6 November 2013 at 08:22:36 UTC, Bienlein wrote:

 Lightweight Threads in Go and Rust

 What is a *BIG* plus for Go and Rust are lightweight threads. 
 You
 can spawn some thousand of them and it's no problem. I really
 wished D had that kind of threads as well. For nowaydays
 server-side development where applications need to bear heavy
 load and load peaks this is an important thing.


Use std.parallelism.Task or core.thread.Fiber. This is also 
conveniently packaged in Vibe.d. They have some syntactic sugar, 
though.
Nov 06 2013
prev sibling parent reply "Daniel Davidson" <nospam spam.com> writes:
On Wednesday, 6 November 2013 at 08:22:36 UTC, Bienlein wrote:


 Then have a look at this thread in the Scala user forum:
 https://groups.google.com/forum/?hl=de#!topic/scala-user/D9QDOnHSUu8
 It is about build times in Scala not scaling up. One reply was
 "Do you have very fast SSDs in your computer?". When I read that
 I decided only to do a little spare time Scala project and 
 that's
 it. Might serve me to find a better Java job one day. D has
 immutable objects and pure functions. I rather do D than Scala,
 actually ...


Do you really make heavy use of immutable objects and pure 
functions and get benefit from it? I've been trying for quite a 
while and there are many many impediments. The fact that 
const/immutable and postblits don't mix is a big issue. The fact 
that many functions in the library are not pure that you might 
want to use in a pure context (.dup, text with doubles, etc) 
reduces pure's value in a viral manner. Hopefully there will be a 
solution for const/immutable members with mutable aliasing in 
structs. Hopefully what should be pure in the libraries will be 
made pure. Hopefully the inference of purity in functions like 
chain will improve. But when you describe immutable and purity as 
a plus, are you describing the idea of its use as positive (which 
I agree is) or the actual use of it (which I think needs work)?
Nov 06 2013
parent "Bienlein" <jeti789 web.de> writes:
 in functions like chain will improve. But when you describe 
 immutable and purity as a plus, are you describing the idea of 
 its use as positive (which I agree is) or the actual use of it 
 (which I think needs work)?


What I meant to say was that Scala wants to call itself
functional to a certain extend. But as a matter of fact a
language like D that doesn't claim to belong to the functional
camp has better support for FP than Scala. In case I do heavy
concurrent stuff immutable objects and pure functions are of
enourmous help. Did some heavy concurrent stuff for some years
and I can see that immutability has great value in that regards.
But I wouldn't make everything immutable. Only the objects I hand
over to some actor or to some parallel computation.

Yeah, the problem that in the end some C function is not const
and all your const correctnes in C++ becomes void I know. Again,
If I know something is happening concurrently I would take the
effort to copy the data into some immutable data structure just
to be on the save side that no other thread can mess around with
my data.
Nov 06 2013
prev sibling next sibling parent "Bienlein" <jeti789 web.de> writes:
 Anyway on my day job, we will not be moving away from JVM/.NET 
 world any time soon.


 You may want to look at scala then.


I fear the language on the JVM in 95% of all cases will be Java.
Sad, but I guess it is true. But it helps to talk about it ...
;-). You might have a look at Kotlin:
http://kotlin.jetbrains.org/ I like it very much: Scala without
the mistakes that were made in Scala. But it will take another
year till Kotlin turns 1.0.
Nov 06 2013
prev sibling next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Wednesday, 6 November 2013 at 07:33:54 UTC, deadalnix wrote:

 On Wednesday, 6 November 2013 at 07:26:42 UTC, Paulo Pinto 
 wrote:

 The language follows the Pascal tradition of type declarations 
 and safety before performance dirty tricks. I find quite 
 appealing its Oberon and Alef/Lingo influences.


 And still it is not quite safe.


 Anyway on my day job, we will not be moving away from JVM/.NET 
 world any time soon.


 You may want to look at scala then.


I do know Scala, but my co-workers do not.

When you work in large organizations, you are constrained to what 
everyone knows.

--
Paulo
Nov 06 2013
parent reply Russel Winder <russel winder.org.uk> writes:
On Wed, 2013-11-06 at 10:53 +0100, Paulo Pinto wrote:
[…]

 I do know Scala, but my co-workers do not.
 
 When you work in large organizations, you are constrained to what 
 everyone knows.


Or are willing to be trained in. The problem is not the status quo in
the organization, the problem is the intransigent inability to learn
that far too many programmers seem to display. People should be wanting
to use new technologies if available and appropriate. Of course the
current language is a candidate and may be the right choice, it just
shouldn't be assumed it is the only choice.


-- 
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
Nov 06 2013
next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Wednesday, 6 November 2013 at 14:06:19 UTC, Russel Winder 
wrote:

 On Wed, 2013-11-06 at 10:53 +0100, Paulo Pinto wrote:
 […]

 I do know Scala, but my co-workers do not.
 
 When you work in large organizations, you are constrained to 
 what everyone knows.


 Or are willing to be trained in. The problem is not the status 
 quo in
 the organization, the problem is the intransigent inability to 
 learn
 that far too many programmers seem to display. People should be 
 wanting
 to use new technologies if available and appropriate. Of course 
 the
 current language is a candidate and may be the right choice, it 
 just
 shouldn't be assumed it is the only choice.


It does not work on my field, because my employer does consulting 
for Fortune 500 companies usually multi-site with off-shoring 
component, where the technology stack is given by the customers 
themselves.

So unless Scala,D, Go, ... are requested, they won't be used.

--
Paulo
Nov 06 2013
parent reply "Bienlein" <jeti789 web.de> writes:
 It does not work on my field, because my employer does 
 consulting for Fortune 500 companies usually multi-site with 
 off-shoring component, where the technology stack is given by 
 the customers themselves.

 So unless Scala,D, Go, ... are requested, they won't be used.


I'm out of the consulting business for quite a while now. Now I'm
an internal employee and have to put up with what the architects
decide. And my company is not a large organization. The CTO
things you need an architect and then your software development
is fine. The architect is good at drawing system diagrams and
theoretical things. He doesn't care about languages, would never
talk to some developer, neither would the CTO. If you want a
change to JDK8 within 2020 you have to explain to the architect
what a closure is and why it is beneficial. I think it will be
very hard ... The problem is in general that company internal
development is not on a good technical level. You have to work
for some startup or a good technical company such as Google,
Facebook, Apple, Yahoo, etc. Those guys are out of the league of
most "ordinary" developers. So it will be Java and something else
in your spare time. Not wanting to be fatalistic, but this is how
I see the situation.

-- Bienlein
Nov 06 2013
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Wednesday, 6 November 2013 at 14:41:45 UTC, Bienlein wrote:

 It does not work on my field, because my employer does 
 consulting for Fortune 500 companies usually multi-site with 
 off-shoring component, where the technology stack is given by 
 the customers themselves.

 So unless Scala,D, Go, ... are requested, they won't be used.


 I'm out of the consulting business for quite a while now. Now 
 I'm
 an internal employee and have to put up with what the architects
 decide. And my company is not a large organization. The CTO
 things you need an architect and then your software development
 is fine. The architect is good at drawing system diagrams and
 theoretical things. He doesn't care about languages, would never
 talk to some developer, neither would the CTO. If you want a
 change to JDK8 within 2020 you have to explain to the architect
 what a closure is and why it is beneficial. I think it will be
 very hard ... The problem is in general that company internal
 development is not on a good technical level. You have to work
 for some startup or a good technical company such as Google,
 Facebook, Apple, Yahoo, etc. Those guys are out of the league of
 most "ordinary" developers. So it will be Java and something 
 else
 in your spare time. Not wanting to be fatalistic, but this is 
 how
 I see the situation.

 -- Bienlein



Yeah, I am pretty old at this game. I already lost count how many 
technologies I have used since 1986. :)
Nov 06 2013
parent reply Russel Winder <russel winder.org.uk> writes:
On Wed, 2013-11-06 at 15:59 +0100, Paulo Pinto wrote:
[…]

 Yeah, I am pretty old at this game. I already lost count how many 
 technologies I have used since 1986. :)


1986. You are a youngster then. ;-)

-- 
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
Nov 06 2013
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 06.11.2013 16:10, schrieb Russel Winder:

 On Wed, 2013-11-06 at 15:59 +0100, Paulo Pinto wrote:
 […]

 Yeah, I am pretty old at this game. I already lost count how many
 technologies I have used since 1986. :)


 1986. You are a youngster then. ;-)


Started using computers at the age of 10, so 1986 - 10 ...
Nov 06 2013
parent reply "Bienlein" <jeti789 web.de> writes:
On Wednesday, 6 November 2013 at 16:24:12 UTC, Paulo Pinto wrote:

 Am 06.11.2013 16:10, schrieb Russel Winder:

 On Wed, 2013-11-06 at 15:59 +0100, Paulo Pinto wrote:
 […]

 Yeah, I am pretty old at this game. I already lost count how 
 many
 technologies I have used since 1986. :)


 1986. You are a youngster then. ;-)


 Started using computers at the age of 10, so 1986 - 10 ...


1976? Man, you are a teenager then ;-)
Nov 06 2013
parent reply Russel Winder <russel winder.org.uk> writes:
On Wed, 2013-11-06 at 17:39 +0100, Bienlein wrote:
[…]

 1976? Man, you are a teenager then ;-)


The year I went apesh!t when I found that the elliptic integral solver
routines in the NAG library were broken. I idled away the time by
creating idioms for writing abstract data type code in FORTRAN 66.
Bizarrely, analogous tricks appear to be essential in JavaScript.

It was also the third year of listening to Dark Side of the Moon and the
first year of Wish You Were Here which is much better.

But you didn't want to know this.

-- 
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
Nov 06 2013
parent "Mike James" <foo bar.com> writes:
Mmmm - that reminds me...

http://www.youtube.com/watch?v=VKHFZBUTA4k

-=mike=-


"Russel Winder" <russel winder.org.uk> wrote in message 
news:mailman.230.1383757333.9546.digitalmars-d puremagic.com...

 On Wed, 2013-11-06 at 17:39 +0100, Bienlein wrote:
 […]

 1976? Man, you are a teenager then ;-)


 The year I went apesh!t when I found that the elliptic integral solver
 routines in the NAG library were broken. I idled away the time by
 creating idioms for writing abstract data type code in FORTRAN 66.
 Bizarrely, analogous tricks appear to be essential in JavaScript.

 It was also the third year of listening to Dark Side of the Moon and the
 first year of Wish You Were Here which is much better.

 But you didn't want to know this.

 -- 
 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
Nov 07 2013
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/6/2013 6:05 AM, Russel Winder wrote:

 Or are willing to be trained in. The problem is not the status quo in
 the organization, the problem is the intransigent inability to learn
 that far too many programmers seem to display. People should be wanting
 to use new technologies if available and appropriate. Of course the
 current language is a candidate and may be the right choice, it just
 shouldn't be assumed it is the only choice.


While your comment seems to be a commonsense truism, there are so many new 
things constantly coming out that one cannot possibly learn them all and pick 
the best, and even then there's another one that just appeared. It is not an 
unreasonable strategy to wait a bit and see which ones have staying power. Most 
don't, and in hindsight would have been a waste of time to learn.
Nov 06 2013
prev sibling parent Russel Winder <russel winder.org.uk> writes:
On Wed, 2013-11-06 at 08:33 +0100, deadalnix wrote:
[…]

 
 You may want to look at scala then.


Or possibly Ceylon or Kotlin.

Or Groovy.

At least on the JVM

-- 
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
Nov 06 2013
prev sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Wed, 2013-11-06 at 08:26 +0100, Paulo Pinto wrote:
[…]

 I rather use D than Go, but it has more to do with Go's community 
 with their religion decisions about generics, dynamic loading, 
 exceptions, enumerations, package management than anything else.


I find the Go community excellent. The mailing list is only a small part
of the community. Try coming to one of the monthly Go user group
meetings in London.

All communities are "religious". This D community takes religious
decisions just as much as the Go, Scala, C++, etc. ones. The position on
generics is not strange if you understand the Go language, it's
computational model and philosophy. Go is taking a non-standard
position, but it is not wrong, it just means that approaches to
algorithms you would take in Ada, C++, D, Rust, Java, Scala, etc. do not
apply directly to Go. It is a shift of mindset and view. If this doesn't
work for you, fine.


 The language follows the Pascal tradition of type declarations 
 and safety before performance dirty tricks. I find quite 
 appealing its Oberon and Alef/Lingo influences.
 
 It is good enough for many cases where people, wrongly, still use 
 C. For example, the complete UNIX user space.
 
 Now for those of us that have become used to the niceties the 
 mainstream languages have adopted from academia in the last 30 
 years, Go feels a bit too light.


But for those people seeking a native code language coming from Python,
Go is a breath of fresh air where D, C++, etc. are claustrophobic
language stuck in the attitudes of the 1970s.


 Anyway on my day job, we will not be moving away from JVM/.NET 
 world any time soon.


You and most of the rest of the world. This is why Java 8, Ceylon,


C, C++, D, Go, Rust.

-- 
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
Nov 06 2013
next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Wednesday, 6 November 2013 at 13:39:51 UTC, Russel Winder 
wrote:

 On Wed, 2013-11-06 at 08:26 +0100, Paulo Pinto wrote:
 […]

 I rather use D than Go, but it has more to do with Go's 
 community with their religion decisions about generics, 
 dynamic loading, exceptions, enumerations, package management 
 than anything else.


 I find the Go community excellent. The mailing list is only a 
 small part
 of the community. Try coming to one of the monthly Go user group
 meetings in London.


A bit far away from Düsseldorf. :)


 All communities are "religious". This D community takes 
 religious
 decisions just as much as the Go, Scala, C++, etc. ones. The 
 position on
 generics is not strange if you understand the Go language, it's
 computational model and philosophy. Go is taking a non-standard
 position, but it is not wrong, it just means that approaches to
 algorithms you would take in Ada, C++, D, Rust, Java, Scala, 
 etc. do not
 apply directly to Go. It is a shift of mindset and view. If 
 this doesn't
 work for you, fine.


 The language follows the Pascal tradition of type declarations 
 and safety before performance dirty tricks. I find quite 
 appealing its Oberon and Alef/Lingo influences.
 
 It is good enough for many cases where people, wrongly, still 
 use C. For example, the complete UNIX user space.
 
 Now for those of us that have become used to the niceties the 
 mainstream languages have adopted from academia in the last 30 
 years, Go feels a bit too light.


 But for those people seeking a native code language coming from 
 Python,
 Go is a breath of fresh air where D, C++, etc. are 
 claustrophobic
 language stuck in the attitudes of the 1970s.



I think the main issue is that many of those developers never 
learned the toolchains of Pascal family of languages and have so 
far mixed the C/C++ toolchains with native development.


 Anyway on my day job, we will not be moving away from JVM/.NET 
 world any time soon.


 You and most of the rest of the world. This is why Java 8, 
 Ceylon,
 Kotlin, and Groovy (not to mention Clojure) on the one hand and 


 programmers than
 C, C++, D, Go, Rust.


Yep, on my area of work I can only use those languages on hobby 
projects.

My last C++ work project was in 2006 and we routinely replace 
C/C++ systems by JVM/.NET based ones, with C/C++ leftovers for 
the few cases where no other solution is possible.

Even for gaming hobby stuff I am using Unity/LibGDX which are 
good enough for my humble graphic skills.

--
Paulo
Nov 06 2013
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/6/13 5:38 AM, Russel Winder wrote:

 On Wed, 2013-11-06 at 08:26 +0100, Paulo Pinto wrote:
 […]

 I rather use D than Go, but it has more to do with Go's community
 with their religion decisions about generics, dynamic loading,
 exceptions, enumerations, package management than anything else.


 I find the Go community excellent. The mailing list is only a small part
 of the community. Try coming to one of the monthly Go user group
 meetings in London.


Online fora are the universal place where the community meets.


 All communities are "religious". This D community takes religious
 decisions just as much as the Go, Scala, C++, etc. ones.


I disagree with this relativism that makes all language communities 
somehow idempotent. Programming languages' communities are very strongly 
influenced by their leaders. I'm friends with Walter so I can't be 
objective on that one, but let me just say his core values are well 
propagated within the community. I'll abstain to comment much about the 
Go community beyond this: it doesn't seem my cup of tea (even leaving 
aside technical issues).


 The position on
 generics is not strange if you understand the Go language, it's
 computational model and philosophy. Go is taking a non-standard
 position, but it is not wrong, it just means that approaches to
 algorithms you would take in Ada, C++, D, Rust, Java, Scala, etc. do not
 apply directly to Go. It is a shift of mindset and view. If this doesn't
 work for you, fine.


I also disagree with this "agree to disagree" that leaves everybody 
vacuously lukewarm. I think there are things that are just right and 
things that are just wrong. Go's team was unable to add generics to the 
language. That locks Go out of a variety of tools and techniques, which 
does not make it only "different", it effectively pauperizes the 
language leaving it the sole advantage that it's smaller. One 
non-technical current that I find quite difficult to like is that the Go 
proponents have not only shun generics, but effectively made it a 
politically incorrect topic in their community. All discussion on 
generics on the go forums are quickly shushed away.


 Now for those of us that have become used to the niceties the
 mainstream languages have adopted from academia in the last 30
 years, Go feels a bit too light.


 But for those people seeking a native code language coming from Python,
 Go is a breath of fresh air where D, C++, etc. are claustrophobic
 language stuck in the attitudes of the 1970s.


Interesting. Why would be D in the same category with C++ 
1970s-attidude-wise, and how is Go a breath of fresh air? If anything, 
the latter seems to me it kinda implements ideas that seemed cool in the 
1970s, but nothing since.


Andrei
Nov 06 2013
parent reply "Max Samukha" <maxsamukha gmail.com> writes:
On Wednesday, 6 November 2013 at 19:42:21 UTC, Andrei 
Alexandrescu wrote:


 Go's team was unable to add generics to the language.


Not adding generics was Go's deliberate decision. For that 
matter, D got its type system all wrong compared to Haskell. So 
why won't we all move there?
Nov 22 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/22/13 1:49 PM, Max Samukha wrote:

 On Wednesday, 6 November 2013 at 19:42:21 UTC, Andrei Alexandrescu wrote:


 Go's team was unable to add generics to the language.


 Not adding generics was Go's deliberate decision.


http://golang.org/doc/faq#generics

"We haven't yet found a design that gives value proportionate to the 
complexity, although we continue to think about it."


 For that matter, D got
 its type system all wrong compared to Haskell. So why won't we all move
 there?


Move where?


Andrei
Nov 22 2013
parent reply "Max Samukha" <maxsamukha gmail.com> writes:
On Friday, 22 November 2013 at 23:08:38 UTC, Andrei Alexandrescu 
wrote:

 On 11/22/13 1:49 PM, Max Samukha wrote:

 On Wednesday, 6 November 2013 at 19:42:21 UTC, Andrei 
 Alexandrescu wrote:


 Go's team was unable to add generics to the language.


 Not adding generics was Go's deliberate decision.


 http://golang.org/doc/faq#generics

 "We haven't yet found a design that gives value proportionate 
 to the complexity, although we continue to think about it."


Ok, I stand corrected.


 For that matter, D got
 its type system all wrong compared to Haskell. So why won't we 
 all move
 there?


 Move where?


Tried to implement a GADT in D?


 Andrei
Nov 30 2013
parent "Max Samukha" <maxsamukha gmail.com> writes:
On Saturday, 30 November 2013 at 21:14:53 UTC, Max Samukha wrote:

 On Friday, 22 November 2013 at 23:08:38 UTC, Andrei 
 Alexandrescu wrote:

 On 11/22/13 1:49 PM, Max Samukha wrote:

 On Wednesday, 6 November 2013 at 19:42:21 UTC, Andrei 
 Alexandrescu wrote:


 Go's team was unable to add generics to the language.


 Not adding generics was Go's deliberate decision.


 http://golang.org/doc/faq#generics

 "We haven't yet found a design that gives value proportionate 
 to the complexity, although we continue to think about it."


 Ok, I stand corrected.


 For that matter, D got
 its type system all wrong compared to Haskell. So why won't 
 we all move
 there?


 Move where?


 Tried to implement a GADT in D?


To clarify:

"Go's built-in maps and slices, plus the ability to use the empty 
interface to construct containers (with explicit unboxing) mean 
in many cases it is possible to write code that does what 
generics would enable, if less smoothly."

Can you implement a GADT in D as "smoothly" as in Haskell?
Nov 30 2013
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/6/2013 5:38 AM, Russel Winder wrote:

 But for those people seeking a native code language coming from Python,
 Go is a breath of fresh air where D, C++, etc. are claustrophobic
 language stuck in the attitudes of the 1970s.


I know that D carries forward some attitudes from the 1980's, particularly in 
its orientation towards supporting the separate compilation model, its 
dependency on object file formats and standard linkers, etc.

But other than that I do not know what you mean about D.
Nov 06 2013
prev sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Tue, 2013-11-05 at 21:38 -0800, Jonathan M Davis wrote:
[…]

 Go is on the list of languages that I'd like to spend more time becoming 
 familiar with, because I think that it's good to know lots of programming 
 languages, but the more I learn about it, the less I like it. Its design 
 philosophies are just too different from my preferences.


I would suggest that this is the core of the point: programming language
is about personal preference as much as it is about language features.
There are many dimensions to the scale including language complexity,
ability to easily express algorithms, ease of handling errors and
exceptions, context of use, problems being addressed, composition of
team programming, individual preference, etc., etc.

Go is a very small language, with great data communication mechanisms, a
simple build and deploy strategy, a view that DVCS (Git, Mercurial and
Bazaar) is all the version management you need, all pivoting around
static compilation of executables. I really like it, except for the
obsession with error codes and no exceptions (except one which is the
"terminate now" exception.

Go is being pushed by Google and now Canonical, so its market
penetration and traction in the programming community is assured.

Rust is an interesting language, not least because it is taking many,
many lessons from the functional programming community and transporting
them into the imperative native code world. cf. the influence of ML and
especially OCaml. Like C++ and D, Rust is actually a big language and
aimed at the same sort of context and problem. And, of course, Rust has
Mozilla pushing it.

Go and Rust are, of course, new languages, C++ and D are old language.
For D this is a bad thing. D is always playing "catch up" and has no big
influential organization saying "this is the language we use for our
developments (in such and such an area)".

Given the current situation, I would advocate creating a new language,
call it Brite say, which is an evolution of D2 (where the difference is
in reality zero), and push the LDC2 realization of it as the primary
implementation, with the GCC version a proud second. This way you get
"new", "llvm", and a high quality statically typed native code language
out there for people to go "wow" to. 





-- 
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
Nov 06 2013
parent reply "Bienlein" <jeti789 web.de> writes:
And, of course, Rust has
Mozilla pushing it.


Well, I don't know what muscle Mozilla has. I don't really
understand where they get their money from (in part from
Google?). Mozilla backing Rust is on a smaller scale than M$



Go is being pushed by Google and now Canonical, so its market
penetration and traction in the programming community is assured.


The Go user forum is the most active one I have seen besides the
one from Python. But it doesn't look like Go is a success inside
Google itself so far.

For both, Go and Rust, wait and see might be a good strategy.
Nov 07 2013
next sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Thu, 2013-11-07 at 13:04 +0100, Bienlein wrote:
[…]

 The Go user forum is the most active one I have seen besides the
 one from Python. But it doesn't look like Go is a success inside
 Google itself so far.
 
 For both, Go and Rust, wait and see might be a good strategy.


I guess the question is whether Canonical and Google end up rewriting
the systems currently using Go in something else sometime down the line.

There are a lot of SMEs in London using Go as their core language. Their
enthusiasm stems, I think, from otherwise having to use C. None of them
have used or even heard of D (until I mention it to them in
conversation).
 
-- 
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
Nov 07 2013
parent reply "Bienlein" <jeti789 web.de> writes:
 There are a lot of SMEs in London using Go as their core 
 language. Their
 enthusiasm stems, I think, from otherwise having to use C.


Well, I think that says it all. Go is made by C programmers for C
programmers. I would say that this is even objectively correct.

What puzzles me is the enormous activity in the Go forum. Only
the Python forum has that much traffic. It seems to me that
people are all that happy if they have a language with which they
can just start hacking around on something.

That is because Go doesn't force anyone to think about design.
The only design-level construct it has is the class an that's it.
Embedding is truly only to save coding effort not having to type
in dereferenciation chains as in C. There is nothing except
classes, but no inheritance, traits, mixins, overriding, etc. So
there is nothing that forces you to think about your design in
Go. And you don't have to know about manual memory management as
in Rust.

-- Bienlein
Nov 21 2013
next sibling parent reply "Bienlein" <jeti789 web.de> writes:
On Thursday, 21 November 2013 at 09:33:04 UTC, Bienlein wrote:

 What puzzles me is the enormous activity in the Go forum. Only
 the Python forum has that much traffic. It seems to me that
 people are all that happy if they have a language with which 
 they
 can just start hacking around on something.

 That is because Go doesn't force anyone to think about design.
 The only design-level construct it has is the class an that's 
 it.
 Embedding is truly only to save coding effort not having to type
 in dereferenciation chains as in C. There is nothing except
 classes, but no inheritance, traits, mixins, overriding, etc. So
 there is nothing that forces you to think about your design in
 Go. And you don't have to know about manual memory management as
 in Rust.

 -- Bienlein


I forgot to say that I really don't know what this will end up in
...
Nov 21 2013
parent reply "Chris" <wendlec tcd.ie> writes:
On Thursday, 21 November 2013 at 09:57:35 UTC, Bienlein wrote:

 On Thursday, 21 November 2013 at 09:33:04 UTC, Bienlein wrote:

 What puzzles me is the enormous activity in the Go forum. Only
 the Python forum has that much traffic. It seems to me that
 people are all that happy if they have a language with which 
 they
 can just start hacking around on something.

 That is because Go doesn't force anyone to think about design.
 The only design-level construct it has is the class an that's 
 it.
 Embedding is truly only to save coding effort not having to 
 type
 in dereferenciation chains as in C. There is nothing except
 classes, but no inheritance, traits, mixins, overriding, etc. 
 So
 there is nothing that forces you to think about your design in
 Go. And you don't have to know about manual memory management 
 as
 in Rust.

 -- Bienlein


 I forgot to say that I really don't know what this will end up 
 in
 ...


I'm wary of languages that are hyped by big companies or the web 
programming community. First there was Java which is still 
getting face lifts and plastic surgery. Then there was Ruby, "the 
way to go", but it hasn't convinced me yet. If all these 
languages are "soooo good", why do people still feel the need to 
come up with new solutions (cf. all the new languages for the 
JVM)? The answer is probably "tunnel vision" design and 
development. The language designers offer one ideology and users 
don't have to think when designing their programs. Simple as 
that. If you have a big company to back this up, people will 
think "it's THE ultimate best ever" language. Personally, I enjoy 
the freedom of D programming, even though with this freedom come 
tough questions as to the design of the program.
Nov 21 2013
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Thursday, 21 November 2013 at 11:07:15 UTC, Chris wrote:

 On Thursday, 21 November 2013 at 09:57:35 UTC, Bienlein wrote:

 On Thursday, 21 November 2013 at 09:33:04 UTC, Bienlein wrote:

 What puzzles me is the enormous activity in the Go forum. Only
 the Python forum has that much traffic. It seems to me that
 people are all that happy if they have a language with which 
 they
 can just start hacking around on something.

 That is because Go doesn't force anyone to think about design.
 The only design-level construct it has is the class an that's 
 it.
 Embedding is truly only to save coding effort not having to 
 type
 in dereferenciation chains as in C. There is nothing except
 classes, but no inheritance, traits, mixins, overriding, etc. 
 So
 there is nothing that forces you to think about your design in
 Go. And you don't have to know about manual memory management 
 as
 in Rust.

 -- Bienlein


 I forgot to say that I really don't know what this will end up 
 in
 ...


 I'm wary of languages that are hyped by big companies or the 
 web programming community. First there was Java which is still 
 getting face lifts and plastic surgery. Then there was Ruby, 
 "the way to go", but it hasn't convinced me yet. If all these 
 languages are "soooo good", why do people still feel the need 
 to come up with new solutions (cf. all the new languages for 
 the JVM)? The answer is probably "tunnel vision" design and 
 development. The language designers offer one ideology and 
 users don't have to think when designing their programs. Simple 
 as that. If you have a big company to back this up, people will 
 think "it's THE ultimate best ever" language. Personally, I 
 enjoy the freedom of D programming, even though with this 
 freedom come tough questions as to the design of the program.



You mean like C and C++ were by AT&T? Or FORTRAN and PL/I/M by 
IBM?

Java was not the first one.

Languages need a corporate sponsor or a killer framework to gain 
market share.

Luckily we can now point to Facebook as possible corporate 
sponsor.

--
Paulo
Nov 21 2013
parent reply "Chris" <wendlec tcd.ie> writes:
On Thursday, 21 November 2013 at 12:14:09 UTC, Paulo Pinto wrote:

 On Thursday, 21 November 2013 at 11:07:15 UTC, Chris wrote:

 On Thursday, 21 November 2013 at 09:57:35 UTC, Bienlein wrote:

 On Thursday, 21 November 2013 at 09:33:04 UTC, Bienlein wrote:

 What puzzles me is the enormous activity in the Go forum. 
 Only
 the Python forum has that much traffic. It seems to me that
 people are all that happy if they have a language with which 
 they
 can just start hacking around on something.

 That is because Go doesn't force anyone to think about 
 design.
 The only design-level construct it has is the class an 
 that's it.
 Embedding is truly only to save coding effort not having to 
 type
 in dereferenciation chains as in C. There is nothing except
 classes, but no inheritance, traits, mixins, overriding, 
 etc. So
 there is nothing that forces you to think about your design 
 in
 Go. And you don't have to know about manual memory 
 management as
 in Rust.

 -- Bienlein


 I forgot to say that I really don't know what this will end 
 up in
 ...


 I'm wary of languages that are hyped by big companies or the 
 web programming community. First there was Java which is still 
 getting face lifts and plastic surgery. Then there was Ruby, 
 "the way to go", but it hasn't convinced me yet. If all these 
 languages are "soooo good", why do people still feel the need 
 to come up with new solutions (cf. all the new languages for 
 the JVM)? The answer is probably "tunnel vision" design and 
 development. The language designers offer one ideology and 
 users don't have to think when designing their programs. 
 Simple as that. If you have a big company to back this up, 
 people will think "it's THE ultimate best ever" language. 
 Personally, I enjoy the freedom of D programming, even though 
 with this freedom come tough questions as to the design of the 
 program.



 You mean like C and C++ were by AT&T? Or FORTRAN and PL/I/M by 
 IBM?

 Java was not the first one.

 Languages need a corporate sponsor or a killer framework to 
 gain market share.


D's advantage is that there is no committee, laboratory or 
marketing department that decides which features to implement. 
It's as close to a grassroots thing as you can get, I think.


 Luckily we can now point to Facebook as possible corporate 
 sponsor.


But that's post-factum. The language already happily exists 
outside the corporate sphere, unlike Java that was a product from 
the very beginning.


 --
 Paulo
Nov 21 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/21/13 7:31 AM, Chris wrote:

 Luckily we can now point to Facebook as possible corporate sponsor.


 But that's post-factum. The language already happily exists outside the
 corporate sphere, unlike Java that was a product from the very beginning.


Each language has its story, but it's undeniable that corporate 
sponsorship offers a lot of liftoff. Back in 2010 (I think) a highly 
influential manager at Facebook said "I'd much more support use of Go 
than D at Facebook because Go has Google behind it." That was an 
assessment based exclusively on social proof, before (and instead of) 
any technical argument. Fortunately a lot has changed since :o).


Andrei
Nov 21 2013
next sibling parent reply "Gary Willoughby" <dev nomad.so> writes:
On Thursday, 21 November 2013 at 16:23:07 UTC, Andrei 
Alexandrescu wrote:

 Fortunately a lot has changed since :o).


Please, do tell. ;)
Nov 21 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/21/13 1:16 PM, Gary Willoughby wrote:

 On Thursday, 21 November 2013 at 16:23:07 UTC, Andrei Alexandrescu wrote:

 Fortunately a lot has changed since :o).


 Please, do tell. ;)


Not much that people don't know already. We have one solid D project 
installed and a couple of heavy-hitting engineers have started using D 
for scripts and tools (e.g. replacing Python for a 2x speedup for the 
same source code size/complexity). Walter and I are working on a second 
large project, which is quite likely to be a hit. The bug bounty is an 
obvious nod of interest. Things are happening. At this point focusing on 
making D solid and reliable is the best thing to do.

Andrei
Nov 21 2013
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:


 At this point focusing on making D solid and reliable is the 
 best thing to do.


At this point what's important is to perform the small breaking 
changes that are left to do (and deprecate what needs to be 
deprecated), because doing that even later will be a problem.

Bye,
bearophile
Nov 21 2013
next sibling parent Shammah Chancellor <anonymous coward.com> writes:
On 2013-11-21 22:17:05 +0000, bearophile said:


 Andrei Alexandrescu:
 

 At this point focusing on making D solid and reliable is the best thing to do.


 
 At this point what's important is to perform the small breaking changes 
 that are left to do (and deprecate what needs to be deprecated), 
 because doing that even later will be a problem.
 
 Bye,
 bearophile


+1
Nov 21 2013
prev sibling next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
22-Nov-2013 02:17, bearophile пишет:

 Andrei Alexandrescu:


 At this point focusing on making D solid and reliable is the best
 thing to do.


 At this point what's important is to perform the small breaking changes
 that are left to do (and deprecate what needs to be deprecated), because
 doing that even later will be a problem.


Spot on, +1  from me.


 Bye,
 bearophile



-- 
Dmitry Olshansky
Nov 22 2013
prev sibling parent reply "eles" <eles eles.com> writes:
On Thursday, 21 November 2013 at 22:17:07 UTC, bearophile wrote:

 Andrei Alexandrescu:


 At this point focusing on making D solid and reliable is the 
 best thing to do.





 changes that are left to do


 property

int[$] x=[1,2,3];
Nov 22 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-11-22 09:56, eles wrote:


 int[$] x=[1,2,3];


This would hopefully not be a braking change. The dollar sign can't be 
used like that currently?

-- 
/Jacob Carlborg
Nov 22 2013
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, November 22, 2013 11:20:41 Jacob Carlborg wrote:

 On 2013-11-22 09:56, eles wrote:

 int[$] x=[1,2,3];


 
 This would hopefully not be a braking change. The dollar sign can't be
 used like that currently?


What would that even mean? The only thing that $ is used for is for 
representing the length of the array in an indexing or slicing operation. That 
statement is trying to use it in a declaration, which is nonsensical.

- Jonathan M Davis
Nov 22 2013
parent "bearophile" <bearophileHUGS lycos.com> writes:
Jonathan M Davis:


 What would that even mean? The only thing that $ is used for is 
 for
 representing the length of the array in an indexing or slicing 
 operation. That
 statement is trying to use it in a declaration, which is 
 nonsensical.


It's not nonsensical, it's a new tiny feature. It means the 
lenght of x is statically determined by the literal. So this:

int[$] x=[1,2,3];

means:

int[3] x=[1,2,3];

But this is not a breaking change, it's just an additive change, 
so it's not urgent.

Bye,
bearophile
Nov 22 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
On Thursday, 21 November 2013 at 21:36:28 UTC, Andrei 
Alexandrescu wrote:

 On 11/21/13 1:16 PM, Gary Willoughby wrote:

 On Thursday, 21 November 2013 at 16:23:07 UTC, Andrei 
 Alexandrescu wrote:

 Fortunately a lot has changed since :o).


 Please, do tell. ;)


 Not much that people don't know already. We have one solid D 
 project installed and a couple of heavy-hitting engineers have 
 started using D for scripts and tools (e.g. replacing Python 
 for a 2x speedup for the same source code size/complexity). 
 Walter and I are working on a second large project, which is 
 quite likely to be a hit. The bug bounty is an obvious nod of 
 interest. Things are happening. At this point focusing on 
 making D solid and reliable is the best thing to do.

 Andrei


Any plans for rvalue references before D gets stable?
Nov 21 2013
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 21 November 2013 at 21:36:28 UTC, Andrei 
Alexandrescu wrote:

 On 11/21/13 1:16 PM, Gary Willoughby wrote:

 On Thursday, 21 November 2013 at 16:23:07 UTC, Andrei 
 Alexandrescu wrote:

 Fortunately a lot has changed since :o).


 Please, do tell. ;)


 Not much that people don't know already. We have one solid D 
 project installed and a couple of heavy-hitting engineers have 
 started using D for scripts and tools (e.g. replacing Python 
 for a 2x speedup for the same source code size/complexity). 
 Walter and I are working on a second large project, which is 
 quite likely to be a hit. The bug bounty is an obvious nod of 
 interest. Things are happening. At this point focusing on 
 making D solid and reliable is the best thing to do.

 Andrei


Just reiterating a common point:

We have a smattering of things that need fixing that involve 
breakage. Surely we should make said changes now, not later?
Or is it implicit in what you're saying that things like rvalue 
ref, property etc. are now won't-fix until D3 or whatever comes 
next?
Nov 21 2013
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 11/21/13 6:36 PM, Andrei Alexandrescu wrote:

 On 11/21/13 1:16 PM, Gary Willoughby wrote:

 On Thursday, 21 November 2013 at 16:23:07 UTC, Andrei Alexandrescu wrote:

 Fortunately a lot has changed since :o).


 Please, do tell. ;)


 Not much that people don't know already. We have one solid D project
 installed and a couple of heavy-hitting engineers have started using D
 for scripts and tools (e.g. replacing Python for a 2x speedup for the
 same source code size/complexity).


I would have expected a lot more speedup than just 2x, D being a 
compiled language.
Nov 22 2013
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Ary Borenszweig:


 I would have expected a lot more speedup than just 2x, D being 
 a compiled language.


I have seen many cases where Python is faster than D: reading 
files by line, some cases of associative array creation, and 
more. Python contains many very efficient routines written in C.

Bye,
bearophile
Nov 22 2013
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdan.org> writes:
Ary Borenszweig <ary esperanto.org.ar> wrote:

 On 11/21/13 6:36 PM, Andrei Alexandrescu wrote:

 On 11/21/13 1:16 PM, Gary Willoughby wrote:

 On Thursday, 21 November 2013 at 16:23:07 UTC, Andrei Alexandrescu wrote:

 Fortunately a lot has changed since :o).


 
 Please, do tell. ;)


 
 Not much that people don't know already. We have one solid D project
 installed and a couple of heavy-hitting engineers have started using D
 for scripts and tools (e.g. replacing Python for a 2x speedup for the
 same source code size/complexity).


 
 I would have expected a lot more speedup than just 2x, D being a compiled
language.


Amdahl's law.

Andrei
Nov 22 2013
parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Friday, 22 November 2013 at 15:52:31 UTC, Andrei Alexandrescu
wrote:

 Ary Borenszweig <ary esperanto.org.ar> wrote:

 On 11/21/13 6:36 PM, Andrei Alexandrescu wrote:

 On 11/21/13 1:16 PM, Gary Willoughby wrote:

 On Thursday, 21 November 2013 at 16:23:07 UTC, Andrei 
 Alexandrescu wrote:

 Fortunately a lot has changed since :o).


 
 Please, do tell. ;)


 
 Not much that people don't know already. We have one solid D 
 project
 installed and a couple of heavy-hitting engineers have 
 started using D
 for scripts and tools (e.g. replacing Python for a 2x speedup 
 for the
 same source code size/complexity).


 
 I would have expected a lot more speedup than just 2x, D being 
 a compiled language.


 Amdahl's law.

 Andrei


BTW, D needs a multithreading example here:
http://saml.rilspace.org/moar-languagez-gc-content-in-python-d-fpc-c-and-c
Nov 24 2013
prev sibling next sibling parent "Bienlein" <jeti789 web.de> writes:
On Thursday, 21 November 2013 at 16:23:07 UTC, Andrei
Alexandrescu wrote:

 Each language has its story, but it's undeniable that corporate 
 sponsorship offers a lot of liftoff.


I think books for some new language being available is also an
important factor. It tells people that some language has already
received some attention and an investment in that new language is
less likely to be in vain.

I remember that Scala received a lot of attention in my Java
community when the Scala book by Martin Odersky was published.
Last week Dart went 1.0. You can already now buy 4 books about
it, one from a renowned author such as Gilad Braha.

I think the book about D by Andrei was very important and it
would be a good thing if during the years more books about D
would follow.

-- Bienlein
Nov 22 2013
prev sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Thursday, 21 November 2013 at 16:23:07 UTC, Andrei 
Alexandrescu wrote:

 On 11/21/13 7:31 AM, Chris wrote:

 Luckily we can now point to Facebook as possible corporate 
 sponsor.


 But that's post-factum. The language already happily exists 
 outside the
 corporate sphere, unlike Java that was a product from the very 
 beginning.


 Each language has its story, but it's undeniable that corporate 
 sponsorship offers a lot of liftoff. Back in 2010 (I think) a 
 highly influential manager at Facebook said "I'd much more 
 support use of Go than D at Facebook because Go has Google 
 behind it." That was an assessment based exclusively on social 
 proof, before (and instead of) any technical argument. 
 Fortunately a lot has changed since :o).


 Andrei


Yes, yes, yes. You are of course right that corporate backing 
gives a language a boost, even if it's a mediocre language. But 
as soon as corporate thinking comes into a language (profit, 
ideology, branding, hype and whatnot), it's doomed. D has to 
breathe, and I admire all the people who have made D happen, and 
who are making it happen. I've learned a lot just by listening 
(well, reading).
Nov 22 2013
parent reply "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
On Friday, 22 November 2013 at 10:29:35 UTC, Chris wrote:

 Yes, yes, yes. You are of course right that corporate backing 
 gives a language a boost, even if it's a mediocre language. But 
 as soon as corporate thinking comes into a language (profit, 
 ideology, branding, hype and whatnot), it's doomed. D has to 
 breathe, and I admire all the people who have made D happen, 
 and who are making it happen. I've learned a lot just by 
 listening (well, reading).


You're talking about corporate _management_ rather than corporate 
backing.  The former can obviously lead to problems (though it 
doesn't have to) -- the latter is almost invariably good, as it 
means there's someone who can serve as guarantor that any 
necessary work will get done.
Nov 22 2013
parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 22 November 2013 at 12:34:23 UTC, Joseph Rushton 
Wakeling wrote:

 On Friday, 22 November 2013 at 10:29:35 UTC, Chris wrote:

 Yes, yes, yes. You are of course right that corporate backing 
 gives a language a boost, even if it's a mediocre language. 
 But as soon as corporate thinking comes into a language 
 (profit, ideology, branding, hype and whatnot), it's doomed. D 
 has to breathe, and I admire all the people who have made D 
 happen, and who are making it happen. I've learned a lot just 
 by listening (well, reading).


 You're talking about corporate _management_ rather than 
 corporate backing.  The former can obviously lead to problems 
 (though it doesn't have to) -- the latter is almost invariably 
 good, as it means there's someone who can serve as guarantor 
 that any necessary work will get done.


You cannot separate the two. Management will creep into 
development sooner or later. E.g. one day D might implement 
features that have to do with what Facebook needs more than 
features that programmers need in general. So a module 
std.webshite.upload.latest.picture gets all the attention while 
std.reallyhandy is being neglected.
Nov 22 2013
next sibling parent "Tobias Pankrath" <tobias pankrath.net> writes:
On Friday, 22 November 2013 at 13:22:10 UTC, Chris wrote:

 You cannot separate the two. Management will creep into 
 development sooner or later. E.g. one day D might implement 
 features that have to do with what Facebook needs more than 
 features that programmers need in general. So a module 
 std.webshite.upload.latest.picture gets all the attention while 
 std.reallyhandy is being neglected.


Attention of and negclection from the people payed by facebook.
Nov 22 2013
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Chris wrote:


 E.g. one day D might implement features that have to do with 
 what Facebook needs more than features that programmers need in 
 general. So a module std.webshite.upload.latest.picture gets 
 all the attention while std.reallyhandy is being neglected.


Do you know one or two cases where this phenomenon has happened 
to a language?

Bye,
bearophile
Nov 22 2013
parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 22 November 2013 at 14:11:50 UTC, bearophile wrote:

 Chris wrote:


 E.g. one day D might implement features that have to do with 
 what Facebook needs more than features that programmers need 
 in general. So a module std.webshite.upload.latest.picture 
 gets all the attention while std.reallyhandy is being 
 neglected.


 Do you know one or two cases where this phenomenon has happened 
 to a language?

 Bye,
 bearophile


Good question! To be honest I cannot put my finger on any module 
of any language in particular. Maybe Objective-C would be an 
example where sometimes things would advance at breakneck pace in 
Cocoa, while some handy features in the standard Objective-C 
library (e.g. in NSString) would still be missing (but that's 
years ago now, I haven't used it for a while, so I dunno how it 
has developed).

Java is a good example of how (corporate) ideology (and 
management) ruins things. Everything is a class, if you don't 
want this, you create a class and declare static functions to 
turn off OOP. Well, ... You can see that people are trying to 
redefine Java, to come up with a better Java. Why is that? 
Because there is a committee that decides and won't have any 
criticism. So people say "Hold on, this is not really 
practicable, let's try something else!", and D already is the 
something else. What attracts me to D (among other things) is its 
practical approach.

Go is web-oriented, so it seems, and I'm sure it will be marketed 
as the "one size fits all" solution for web development, 
multi-core and whatnot. But D goes deeper. D raises fundamental 
questions about how a good program should look like, what is good 
/ practicable. I know that this approach doesn't sell, but it's 
the best I've ever come across. D makes you think and re-assess 
your own code time and again.
Nov 22 2013
next sibling parent "Chris" <wendlec tcd.ie> writes:
On Friday, 22 November 2013 at 14:43:11 UTC, Chris wrote:

 On Friday, 22 November 2013 at 14:11:50 UTC, bearophile wrote:

 Chris wrote:


 E.g. one day D might implement features that have to do with 
 what Facebook needs more than features that programmers need 
 in general. So a module std.webshite.upload.latest.picture 
 gets all the attention while std.reallyhandy is being 
 neglected.


 Do you know one or two cases where this phenomenon has 
 happened to a language?

 Bye,
 bearophile


 Good question! To be honest I cannot put my finger on any 
 module of any language in particular. Maybe Objective-C would 
 be an example where sometimes things would advance at breakneck 
 pace in Cocoa, while some handy features in the standard 
 Objective-C library (e.g. in NSString) would still be missing 
 (but that's years ago now, I haven't used it for a while, so I 
 dunno how it has developed).

 Java is a good example of how (corporate) ideology (and 
 management) ruins things. Everything is a class, if you don't 
 want this, you create a class and declare static functions to 
 turn off OOP. Well, ... You can see that people are trying to 
 redefine Java, to come up with a better Java. Why is that? 
 Because there is a committee that decides and won't have any 
 criticism. So people say "Hold on, this is not really 
 practicable, let's try something else!", and D already is the 
 something else. What attracts me to D (among other things) is 
 its practical approach.

 Go is web-oriented, so it seems, and I'm sure it will be 
 marketed as the "one size fits all" solution for web 
 development, multi-core and whatnot. But D goes deeper. D 
 raises fundamental questions about how a good program should 
 look like, what is good / practicable. I know that this 
 approach doesn't sell, but it's the best I've ever come across. 
 D makes you think and re-assess your own code time and again.


What I'm saying is basically:

"D is what happens when you take language design away from the 
realms of the committee."
(http://www.gamedev.net/page/resources/_/technical/general-programming/what-language-do-i-use-r3318)

Later it says:

"That is to say that D would be the best of all worlds if it 
gained more support. It simply doesn't yet have the huge 
libraries of code, wealth of tools, and base of user support of 
the other languages. Hopefully its support will grow and it will 
receive the attention it deserves, but that will take some time."

The problem is that people flock to languages like Python and 
Java etc. because of all the tools and libraries. You can easily 
send an email in Python, download extensions blah blah. But 
people often confuse "usability" as in libraries & tools with 
"usability" as in program design (options), robustness and 
performance.
Nov 22 2013
prev sibling next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Friday, 22 November 2013 at 14:43:11 UTC, Chris wrote:

 On Friday, 22 November 2013 at 14:11:50 UTC, bearophile wrote:

 Chris wrote:


 E.g. one day D might implement features that have to do with 
 what Facebook needs more than features that programmers need 
 in general. So a module std.webshite.upload.latest.picture 
 gets all the attention while std.reallyhandy is being 
 neglected.


 Do you know one or two cases where this phenomenon has 
 happened to a language?

 Bye,
 bearophile


 Good question! To be honest I cannot put my finger on any 
 module of any language in particular. Maybe Objective-C would 
 be an example where sometimes things would advance at breakneck 
 pace in Cocoa, while some handy features in the standard 
 Objective-C library (e.g. in NSString) would still be missing 
 (but that's years ago now, I haven't used it for a while, so I 
 dunno how it has developed).

 Java is a good example of how (corporate) ideology (and 
 management) ruins things. Everything is a class, if you don't 
 want this, you create a class and declare static functions to 
 turn off OOP.


You know that this comes from the original concept of what OOP is 
all about and Smalltalk, right?

There are no free functions in pure OO languages, like there are 
no objects in pure FP languages.

Of course, meanwhile we have learned there are other ways to do 
OO, but don't blame Java for Smalltalk concepts.

--
Paulo
Nov 22 2013
parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 22 November 2013 at 15:31:18 UTC, Paulo Pinto wrote:

 On Friday, 22 November 2013 at 14:43:11 UTC, Chris wrote:

 On Friday, 22 November 2013 at 14:11:50 UTC, bearophile wrote:

 Chris wrote:


 E.g. one day D might implement features that have to do with 
 what Facebook needs more than features that programmers need 
 in general. So a module std.webshite.upload.latest.picture 
 gets all the attention while std.reallyhandy is being 
 neglected.


 Do you know one or two cases where this phenomenon has 
 happened to a language?

 Bye,
 bearophile


 Good question! To be honest I cannot put my finger on any 
 module of any language in particular. Maybe Objective-C would 
 be an example where sometimes things would advance at 
 breakneck pace in Cocoa, while some handy features in the 
 standard Objective-C library (e.g. in NSString) would still be 
 missing (but that's years ago now, I haven't used it for a 
 while, so I dunno how it has developed).

 Java is a good example of how (corporate) ideology (and 
 management) ruins things. Everything is a class, if you don't 
 want this, you create a class and declare static functions to 
 turn off OOP.


 You know that this comes from the original concept of what OOP 
 is all about and Smalltalk, right?

 There are no free functions in pure OO languages, like there 
 are no objects in pure FP languages.

 Of course, meanwhile we have learned there are other ways to do 
 OO, but don't blame Java for Smalltalk concepts.

 --
 Paulo


I don't blame Java for Smalltalk. I just don't like ideological 
constraints. As you said, we've learned that there are other ways 
of doing OO, but how can people cling to things when they know 
they are not good. I can't get my head around it. Same goes for 
JVM. If you have JIT, why not go all the way and have the 
_option_ to compile it to machine code?
Nov 22 2013
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Friday, 22 November 2013 at 15:36:43 UTC, Chris wrote:

 On Friday, 22 November 2013 at 15:31:18 UTC, Paulo Pinto wrote:

 On Friday, 22 November 2013 at 14:43:11 UTC, Chris wrote:

 On Friday, 22 November 2013 at 14:11:50 UTC, bearophile wrote:

 Chris wrote:


 E.g. one day D might implement features that have to do 
 with what Facebook needs more than features that 
 programmers need in general. So a module 
 std.webshite.upload.latest.picture gets all the attention 
 while std.reallyhandy is being neglected.


 Do you know one or two cases where this phenomenon has 
 happened to a language?

 Bye,
 bearophile


 Good question! To be honest I cannot put my finger on any 
 module of any language in particular. Maybe Objective-C would 
 be an example where sometimes things would advance at 
 breakneck pace in Cocoa, while some handy features in the 
 standard Objective-C library (e.g. in NSString) would still 
 be missing (but that's years ago now, I haven't used it for a 
 while, so I dunno how it has developed).

 Java is a good example of how (corporate) ideology (and 
 management) ruins things. Everything is a class, if you don't 
 want this, you create a class and declare static functions to 
 turn off OOP.


 You know that this comes from the original concept of what OOP 
 is all about and Smalltalk, right?

 There are no free functions in pure OO languages, like there 
 are no objects in pure FP languages.

 Of course, meanwhile we have learned there are other ways to 
 do OO, but don't blame Java for Smalltalk concepts.

 --
 Paulo


 I don't blame Java for Smalltalk. I just don't like ideological 
 constraints. As you said, we've learned that there are other 
 ways of doing OO, but how can people cling to things when they 
 know they are not good. I can't get my head around it. Same 
 goes for JVM. If you have JIT, why not go all the way and have 
 the _option_ to compile it to machine code?


Just get Aonix, J9, RoboVM, JET, Jasmine, JikesRVM, just to cite 
a few examples.

There are plenty AOT compilers to chose from for Java.

Oracle JVM is not the only JDK around, although people tend to 
think so.

--
Paulo
Nov 22 2013
parent "Chris" <wendlec tcd.ie> writes:
On Friday, 22 November 2013 at 15:40:07 UTC, Paulo Pinto wrote:

 On Friday, 22 November 2013 at 15:36:43 UTC, Chris wrote:

 On Friday, 22 November 2013 at 15:31:18 UTC, Paulo Pinto wrote:

 On Friday, 22 November 2013 at 14:43:11 UTC, Chris wrote:

 On Friday, 22 November 2013 at 14:11:50 UTC, bearophile 
 wrote:

 Chris wrote:


 E.g. one day D might implement features that have to do 
 with what Facebook needs more than features that 
 programmers need in general. So a module 
 std.webshite.upload.latest.picture gets all the attention 
 while std.reallyhandy is being neglected.


 Do you know one or two cases where this phenomenon has 
 happened to a language?

 Bye,
 bearophile


 Good question! To be honest I cannot put my finger on any 
 module of any language in particular. Maybe Objective-C 
 would be an example where sometimes things would advance at 
 breakneck pace in Cocoa, while some handy features in the 
 standard Objective-C library (e.g. in NSString) would still 
 be missing (but that's years ago now, I haven't used it for 
 a while, so I dunno how it has developed).

 Java is a good example of how (corporate) ideology (and 
 management) ruins things. Everything is a class, if you 
 don't want this, you create a class and declare static 
 functions to turn off OOP.


 You know that this comes from the original concept of what 
 OOP is all about and Smalltalk, right?

 There are no free functions in pure OO languages, like there 
 are no objects in pure FP languages.

 Of course, meanwhile we have learned there are other ways to 
 do OO, but don't blame Java for Smalltalk concepts.

 --
 Paulo


 I don't blame Java for Smalltalk. I just don't like 
 ideological constraints. As you said, we've learned that there 
 are other ways of doing OO, but how can people cling to things 
 when they know they are not good. I can't get my head around 
 it. Same goes for JVM. If you have JIT, why not go all the way 
 and have the _option_ to compile it to machine code?


 Just get Aonix, J9, RoboVM, JET, Jasmine, JikesRVM, just to 
 cite a few examples.

 There are plenty AOT compilers to chose from for Java.

 Oracle JVM is not the only JDK around, although people tend to 
 think so.

 --
 Paulo


Which kind of proves my point. There is demand for it. Why not 
ship Java with a machine code compiler? javac -native MyClass.java
Nov 22 2013
prev sibling next sibling parent reply "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Friday, 22 November 2013 at 14:43:11 UTC, Chris wrote:

 Java is a good example of how (corporate) ideology (and 
 management) ruins things.


I think you are attributing results to the wrong thing. Go isn't 
simplistic because of Google corporate management, it is because 
the creators decided that was what it would be. Java isn't ruined 
because of the corporation behind it is because of the vision and 
goals of its creator, which happens to be a corporation. D hasn't 
become what it is because of a lack of corporate backing, but 
because its creator decided being influenced by the community 
would be beneficial.
Nov 22 2013
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Friday, 22 November 2013 at 15:36:08 UTC, Jesse Phillips wrote:

 On Friday, 22 November 2013 at 14:43:11 UTC, Chris wrote:

 Java is a good example of how (corporate) ideology (and 
 management) ruins things.


 I think you are attributing results to the wrong thing. Go 
 isn't simplistic because of Google corporate management, it is 
 because the creators decided that was what it would be. Java 
 isn't ruined because of the corporation behind it is because of 
 the vision and goals of its creator, which happens to be a 
 corporation. D hasn't become what it is because of a lack of 
 corporate backing, but because its creator decided being 
 influenced by the community would be beneficial.


Go simplicity is easy to understand once you know the background 
of language designers.

It has Oberon-2 method syntax and the simplicity design advocated 
by Niklaus Wirth, starting with the Oberon project. Robert 
Griesemer did part of his studies at ETHZ.

Go also has many similarities to Alef (Plan9) and Limbo(Inferno). 
Projects where Rob Pike and Ken Thompson were part of.

--
Paulo
Nov 22 2013
parent reply "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Friday, 22 November 2013 at 15:56:14 UTC, Paulo Pinto wrote:

 background of language designers.


Which just reinforces my point. It is the language designer 
(creator) which dictates the result of the language. Being a 
corporation isn't what is going to drive it (much).
Nov 22 2013
parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 22 November 2013 at 16:24:25 UTC, Jesse Phillips wrote:

 On Friday, 22 November 2013 at 15:56:14 UTC, Paulo Pinto wrote:

 background of language designers.


 Which just reinforces my point. It is the language designer 
 (creator) which dictates the result of the language. Being a 
 corporation isn't what is going to drive it (much).


But being a corporation bars the community from influencing the 
language design. It reinforces self-righteousness and tunnel 
vision, committee thinking. And of course the language will go in 
a direction that suits its application within the corporation 
(web, gaming and the like). There are just too many things 
attached to a language developed by a corporation, things that 
have nothing to do with the language as such. (And don't forget 
BIG EGOS, we tend to forget that language designers are human 
beings with all their flaws and shortcomings).
Nov 22 2013
parent reply "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Friday, 22 November 2013 at 16:34:06 UTC, Chris wrote:

 On Friday, 22 November 2013 at 16:24:25 UTC, Jesse Phillips 
 wrote:

 On Friday, 22 November 2013 at 15:56:14 UTC, Paulo Pinto wrote:

 background of language designers.


 Which just reinforces my point. It is the language designer 
 (creator) which dictates the result of the language. Being a 
 corporation isn't what is going to drive it (much).


 But being a corporation bars the community from influencing the 
 language design.



both prove that. Go has corporate backing, but it would be silly 
to say the design is coming from Google and not the creators 
(though they claim the community has influence in its direction). 

anything but corporate interest driving it.
Nov 22 2013
parent "Chris" <wendlec tcd.ie> writes:
On Friday, 22 November 2013 at 18:11:34 UTC, Jesse Phillips wrote:

 On Friday, 22 November 2013 at 16:34:06 UTC, Chris wrote:

 On Friday, 22 November 2013 at 16:24:25 UTC, Jesse Phillips 
 wrote:

 On Friday, 22 November 2013 at 15:56:14 UTC, Paulo Pinto 
 wrote:

 background of language designers.


 Which just reinforces my point. It is the language designer 
 (creator) which dictates the result of the language. Being a 
 corporation isn't what is going to drive it (much).


 But being a corporation bars the community from influencing 
 the language design.


 It doesn't, it is the creator which causes it. I think Go and 

 silly to say the design is coming from Google and not the 
 creators (though they claim the community has influence in its 

 to claim had anything but corporate interest driving it.



better than Java, then D. True or not, I don't like that kind of 
propaganda. I think it's better if a company uses a language, but 
the design is done somewhere else.
Nov 22 2013
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Chris:


 But D goes deeper. D raises fundamental questions about how
 a good program should look like, what is good / practicable.


You could write a blog post/article to explain why you think 
this, with some examples.

Bye,
bearophile
Nov 22 2013
parent reply "Chris" <wendlec tcd.ie> writes:
On Saturday, 23 November 2013 at 00:13:03 UTC, bearophile wrote:

 Chris:


 But D goes deeper. D raises fundamental questions about how
 a good program should look like, what is good / practicable.


 You could write a blog post/article to explain why you think 
 this, with some examples.

 Bye,
 bearophile


Sure. One of the reasons is that you have the choice. OO, 
structs, ranges, functional. This makes me think about how to 
solve which problem. In Java you get one concept, OO, and that's 
it. What do you do? Write a class, what ever the task at hand may 
be.
Nov 23 2013
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 23.11.2013 15:16, schrieb Chris:

 On Saturday, 23 November 2013 at 00:13:03 UTC, bearophile wrote:

 Chris:


 But D goes deeper. D raises fundamental questions about how
 a good program should look like, what is good / practicable.


 You could write a blog post/article to explain why you think this,
 with some examples.

 Bye,
 bearophile


 Sure. One of the reasons is that you have the choice. OO, structs,
 ranges, functional. This makes me think about how to solve which
 problem. In Java you get one concept, OO, and that's it. What do you do?
 Write a class, what ever the task at hand may be.


Well,

structs => Packed Objects (IBM J9, being discussed for Java 9)

ranges => Iterator/Iterable/Streams (Java 8)

functional => Method handles/Lambda (Java 8)

--
Paulo
Nov 23 2013
parent reply "Chris" <wendlec tcd.ie> writes:
On Sunday, 24 November 2013 at 05:45:05 UTC, Paulo Pinto wrote:

 Am 23.11.2013 15:16, schrieb Chris:

 On Saturday, 23 November 2013 at 00:13:03 UTC, bearophile 
 wrote:

 Chris:


 But D goes deeper. D raises fundamental questions about how
 a good program should look like, what is good / practicable.


 You could write a blog post/article to explain why you think 
 this,
 with some examples.

 Bye,
 bearophile


 Sure. One of the reasons is that you have the choice. OO, 
 structs,
 ranges, functional. This makes me think about how to solve 
 which
 problem. In Java you get one concept, OO, and that's it. What 
 do you do?
 Write a class, what ever the task at hand may be.


 Well,

 structs => Packed Objects (IBM J9, being discussed for Java 9)

 ranges => Iterator/Iterable/Streams (Java 8)

 functional => Method handles/Lambda (Java 8)

 --
 Paulo


That's my point. D had / has it all, while Java is bringing it in 
bit by bit after years, and people have to re-learn Java with 
every new update. But maybe that's by design, because there's a 
huge Java-certificate industry out there.
Nov 25 2013
next sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 25/11/13 11:10, Chris wrote:

 That's my point. D had / has it all, while Java is bringing it in bit by bit
 after years, and people have to re-learn Java with every new update. But maybe
 that's by design, because there's a huge Java-certificate industry out there.


D obtained it over years, too, and has been much less constrained by the need
to 
support a huge existing user-base ...  I think you are once again letting your 
distaste for corporate management get the better of you ;-)
Nov 25 2013
parent "Chris" <wendlec tcd.ie> writes:
On Monday, 25 November 2013 at 10:28:12 UTC, Joseph Rushton 
Wakeling wrote:

 On 25/11/13 11:10, Chris wrote:

 That's my point. D had / has it all, while Java is bringing it 
 in bit by bit
 after years, and people have to re-learn Java with every new 
 update. But maybe
 that's by design, because there's a huge Java-certificate 
 industry out there.


 D obtained it over years, too, and has been much less 
 constrained by the need to support a huge existing user-base


Yes, D could breathe, which only goes to show that 
commercialization can seriously slow down the introduction of 
useful features.


 ...  I think you are once again letting your distaste for 
 corporate management get the better of you ;-)


I agree, I wasn't clear about it. Corporate management does not 
mean that the product is bad. But it means that a bad product 
gets more attention, hype and finally users than a good product 
that is not developed within a big corporation. I think it is 
only logical that as soon as a language becomes a product 
designed within a corporation, the language's design may suffer 
from external factors that have nothing to do with language 
design itself. As you said, you have to support an existing 
user-base. There are marketing issues, the company offers courses 
(these have to be re-designed, if the language is being 
re-designed). There is a whole array of external factors that 
hamper the development of the language. It has nothing to do with 
my liking or disliking corporate thinking. It's just a logical 
consequence.


some market shares, and of course in order to do so, they had to 
make it (at least a bit) better. But strategic thinking and 
marketing played a big role, thus the language is naturally 
affected by it.


corporate thinking influences and impedes language design. I'm 
almost sure that there is some kind of "corporate ideology". I'm 
saying this as someone who actually liked Java and did a lot of 
Java programming.
Nov 25 2013
prev sibling parent "Bienlein" <jeti789 web.de> writes:
 That's my point. D had / has it all, while Java is bringing it 
 in bit by bit after years, and people have to re-learn Java 
 with every new update. But maybe that's by design, because 
 there's a huge Java-certificate industry out there.


Well, I think the guys at Sun back then thought anonymous inner
class would get them around having to add closures to the
language. Maybe they thought they would get away with that quick
hack and later found out it only results in a lot of boilerplate
code. Then it turned out they have to put them in as every other
JVM language has closures baked in from the beginning...
Nov 25 2013
prev sibling parent reply "Bienlein" <jeti789 web.de> writes:
On Friday, 22 November 2013 at 14:43:11 UTC, Chris wrote:


 Go is web-oriented, so it seems, and I'm sure it will be 
 marketed as the "one size fits all" solution for web 
 development, multi-core and whatnot. But D goes deeper. D 
 raises fundamental questions about how a good program should 
 look like, what is good / practicable. I know that this 
 approach doesn't sell, but it's the best I've ever come across. 
 D makes you think and re-assess your own code time and again.


I basically I agree with this. But lately, I was asking myself, 
though, whether me classifying Go as simplistic was wrong. I 
programmed the canonical Scala trait sample in Go. In that sample 
from the Scala book there is a trait Rectangular with a upperLeft 
and bottomRight point. Some class Rectangle extends trait 
Rectangular. I could get the same accomplished using delegation 
in Go. The solution in Go is much much simpler and from what I 
can tell the power is the same. So this made me think.

I guess the solution in Scala is easier to recognize for the 
reader as the code is more structured using specific language 
constructs. Therefore someone reading the code would easier see 
the structure in the code and understand the solution. 
Nevertheless, with a simple construct like delegation with some 
compromises in visibility you get almost the same power as with 
inheritance, traits/mixins, etc. This is still amazing to me.

-- Bienlein
Nov 28 2013
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/28/13 8:07 AM, Bienlein wrote:

 On Friday, 22 November 2013 at 14:43:11 UTC, Chris wrote:


 Go is web-oriented, so it seems, and I'm sure it will be marketed as
 the "one size fits all" solution for web development, multi-core and
 whatnot. But D goes deeper. D raises fundamental questions about how a
 good program should look like, what is good / practicable. I know that
 this approach doesn't sell, but it's the best I've ever come across. D
 makes you think and re-assess your own code time and again.


 I basically I agree with this. But lately, I was asking myself, though,
 whether me classifying Go as simplistic was wrong. I programmed the
 canonical Scala trait sample in Go. In that sample from the Scala book
 there is a trait Rectangular with a upperLeft and bottomRight point.
 Some class Rectangle extends trait Rectangular. I could get the same
 accomplished using delegation in Go. The solution in Go is much much
 simpler and from what I can tell the power is the same. So this made me
 think.


Interesting. Could you please create a paste with the two code samples?

Thanks,

Andrei
Nov 28 2013
parent reply "Bienlein" <jeti789 web.de> writes:
On Thursday, 28 November 2013 at 19:22:06 UTC, Andrei 
Alexandrescu wrote:


 Interesting. Could you please create a paste with the two code 
 samples?

 Thanks,

 Andrei


Hello,

here is the Go code:

package main

import (
	"fmt"
)

type Point struct {
	x, y int
}

type Rectangular struct {
	topLeft, bottomRight Point
}

func (self Rectangular) Left() int {
	return self.topLeft.x
}

func (self Rectangular) Right() int {
	return self.bottomRight.x
}

func (self Rectangular) Width() int {
	return self.Right() - self.Left()
}

type Rectangle struct {
	Rectangular
}

func NewRectangle(topLeft, bottomRight Point) *Rectangle {
	rectangle := new(Rectangle)
	rectangle.Rectangular.topLeft = topLeft
	rectangle.Rectangular.bottomRight = bottomRight
	return rectangle
}

func main() {
	rectangle := NewRectangle(Point{1, 2}, Point{12, 2})
	fmt.Println(rectangle.Width())
}

And this is the Scala code:

import java.awt.Point

trait Rectangular {

   protected val topLeft: Point
   protected val bottomRight: Point

   def width : Int = bottomRight.x - topLeft.x
}

class Rectangle(val topLeft: Point, val bottomRight: Point) 
extends Rectangular

object RunIt extends Application {

   val rectangle = new Rectangle(new Point(1, 2), new Point(12, 2))
   println(rectangle.width)

}

I guess in D you would do something like this:

mixin template Rectangular() {
   Point x, y;
}

mixin Rectangular;

struct Rectangle {
   mixin Rectangular;
}


Note that in the Scala code Rectangular.topLeft and 
Rectangular.bottomRight are protected. Since the solution in Go 
makes use of delegation this can only be accomplished in Go 
through making getters public or defining Rectangle in the same 
package as Rectangular. Since Go does not have constructors the 
way to initialize a Rectangle in Go looks more clumsy.

An interesting point to me is that Rectangular in Go is just an 
ordinary struct whereas Rectangular is a special construct in 
Scala (being a trait) and in D (being a mixin). So Scala and D 
force you to design ahead, e.g. you have to decide in advance 
whether to make Rectangular a trait or mixin. Thereafter, 
Rectangular is not of use on its own, only when used as a trait 
or mixin.

What makes me think is whether delegation as a language construct 
has been underrated and whether Go now makes this obvious.

-- Bienlein
Nov 29 2013
next sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 29 November 2013 at 08:29:04 UTC, Bienlein wrote:

 On Thursday, 28 November 2013 at 19:22:06 UTC, Andrei 
 Alexandrescu wrote:


 Interesting. Could you please create a paste with the two code 
 samples?

 Thanks,

 Andrei


 Hello,

 here is the Go code:

 package main

 import (
 	"fmt"
 )

 type Point struct {
 	x, y int
 }

 type Rectangular struct {
 	topLeft, bottomRight Point
 }

 func (self Rectangular) Left() int {
 	return self.topLeft.x
 }

 func (self Rectangular) Right() int {
 	return self.bottomRight.x
 }

 func (self Rectangular) Width() int {
 	return self.Right() - self.Left()
 }

 type Rectangle struct {
 	Rectangular
 }

 func NewRectangle(topLeft, bottomRight Point) *Rectangle {
 	rectangle := new(Rectangle)
 	rectangle.Rectangular.topLeft = topLeft
 	rectangle.Rectangular.bottomRight = bottomRight
 	return rectangle
 }

 func main() {
 	rectangle := NewRectangle(Point{1, 2}, Point{12, 2})
 	fmt.Println(rectangle.Width())
 }

 And this is the Scala code:

 import java.awt.Point

 trait Rectangular {

   protected val topLeft: Point
   protected val bottomRight: Point

   def width : Int = bottomRight.x - topLeft.x
 }

 class Rectangle(val topLeft: Point, val bottomRight: Point) 
 extends Rectangular

 object RunIt extends Application {

   val rectangle = new Rectangle(new Point(1, 2), new Point(12, 
 2))
   println(rectangle.width)

 }

 I guess in D you would do something like this:

 mixin template Rectangular() {
   Point x, y;
 }

 mixin Rectangular;

 struct Rectangle {
   mixin Rectangular;
 }


 Note that in the Scala code Rectangular.topLeft and 
 Rectangular.bottomRight are protected. Since the solution in Go 
 makes use of delegation this can only be accomplished in Go 
 through making getters public or defining Rectangle in the same 
 package as Rectangular. Since Go does not have constructors the 
 way to initialize a Rectangle in Go looks more clumsy.

 An interesting point to me is that Rectangular in Go is just an 
 ordinary struct whereas Rectangular is a special construct in 
 Scala (being a trait) and in D (being a mixin). So Scala and D 
 force you to design ahead, e.g. you have to decide in advance 
 whether to make Rectangular a trait or mixin. Thereafter, 
 Rectangular is not of use on its own, only when used as a trait 
 or mixin.

 What makes me think is whether delegation as a language 
 construct has been underrated and whether Go now makes this 
 obvious.

 -- Bienlein


Thanks for the example. To be honest the Go code looks like a 
glorified version of JavaScript to me. I think it is way too 
"obfuscated", and Go syntax seems a bit like someone _always_ 
wanted to do it differently, just a personal preference, no 
matter what people intuitively expect.[1]

x, y int

I prefer left-to-right:

"type integer named x (or whatever)", i.e. int x;

But why on earth (a []byte)? The type is important, not the name. 
I can give it any name. a, inComing, inBytes, response, 
draculaBytes ...

[1] Raises the question whether we've been conditioned by C or 
whether C was intuitive.
Nov 29 2013
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Chris:


 But why on earth (a []byte)? The type is important, not the 
 name. I can give it any name. a, inComing, inBytes, response, 
 draculaBytes ...


I read that type "array of byte(s)", I find it a bit better than 
D syntax, especially when types become a little more complex.

Bye,
bearophile
Nov 29 2013
next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Friday, 29 November 2013 at 12:11:26 UTC, bearophile wrote:

 Chris:


 But why on earth (a []byte)? The type is important, not the 
 name. I can give it any name. a, inComing, inBytes, response, 
 draculaBytes ...


 I read that type "array of byte(s)", I find it a bit better 
 than D syntax, especially when types become a little more 
 complex.

 Bye,
 bearophile


"byte array named a" vs "a is an array of bytes". Either is fine.

I agree that sometimes the latter is better for complex types.
Nov 29 2013
prev sibling parent Russel Winder <russel winder.org.uk> writes:
On Fri, 2013-11-29 at 13:11 +0100, bearophile wrote:

 Chris:
 

 But why on earth (a []byte)? The type is important, not the 
 name. I can give it any name. a, inComing, inBytes, response, 
 draculaBytes ...


 
 I read that type "array of byte(s)", I find it a bit better than 
 D syntax, especially when types become a little more complex.


I believe it should be read as "slice of bytes" not "array of bytes".

-- 
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
Nov 29 2013
prev sibling next sibling parent reply "Bienlein" <jeti789 web.de> writes:
On Friday, 29 November 2013 at 12:06:17 UTC, Chris wrote:

 [1] Raises the question whether we've been conditioned by C or 
 whether C was intuitive.


My theory is that Go is from the beginning intended to be a 
modernized C. If I look at C from that perspective I can always 
explain why things in Go are the way they are. The syntax is only 
in part awkward as Go is in some ways inspired by Oberon.

But what suprises me is that with a language feature as simple as 
delegates you can solve so many design problems that well. I 
wonder whether this is a result of a lot of thought or only a 
result of adding some language feature that frees you from having 
to write myStruct1->field1->myStruct2->field2-> ...
Nov 29 2013
parent reply "Chris" <wendlec tcd.ie> writes:
bearophile

I wonder, if it's just the way I've learned how to program that I 
prefer

byte[] buf;

to

buf []byte; // Which seems a bit awkward to me. "it's called 
'buf' and it is an array of ... of what???? Drum roll r-r-r-r-r 
... Of bytes! Yeah!!!

Maybe it's because in my culture we read (and think?) from left 
to right. Mind you, the apple symbol on the Mac is in the upper 
left corner. The "Launcher" in Ubuntu is on the left hand side by 
default. The folders and contacts in Gmail are on the left hand 
side. Your mouse cursor is in the left half of the screen most of 
the time.

On Friday, 29 November 2013 at 12:16:07 UTC, Bienlein wrote:

 On Friday, 29 November 2013 at 12:06:17 UTC, Chris wrote:

 [1] Raises the question whether we've been conditioned by C or 
 whether C was intuitive.


 My theory is that Go is from the beginning intended to be a 
 modernized C. If I look at C from that perspective I can always 
 explain why things in Go are the way they are. The syntax is 
 only in part awkward as Go is in some ways inspired by Oberon.


Very good point. But do we need to modernize C? C is only one 
step away form assembly. So if you modernize this, your still on 
the same level.


 But what suprises me is that with a language feature as simple 
 as delegates you can solve so many design problems that well. I 
 wonder whether this is a result of a lot of thought or only a 
 result of adding some language feature that frees you from 
 having to write myStruct1->field1->myStruct2->field2-> ...


I like structs and classes for the fact that they can handle 
stuff on their own. But we do have delegation in D and it is a 
useful feature in Objective-C too. structs/classes and delegation 
are not mutually exclusive. And your question is very good. Is 
delegation in Go a "work around" within a limited language or is 
it a design feature?

If Go is modernized C, will it end up like C++?
Nov 29 2013
parent "Bienlein" <jeti789 web.de> writes:
On Friday, 29 November 2013 at 12:53:02 UTC, Chris wrote:


 Very good point. But do we need to modernize C? C is only one 
 step away form assembly. So if you modernize this, your still 
 on the same level.


Agree. If I accept a language that simple then it needs to 
deliver execution speed. And Go fails in that domain.


 delegation are not mutually exclusive. And your question is 
 very good. Is delegation in Go a "work around" within a limited 
 language or is it a design feature?


The question I ask myself whether delegation is a nglected gross 
concept. I don't mean 1:1 associations as such, of course, but I 
mean that you can simply say myStruct1-fieldN instead of 
myStruct1->field1-> ... myStructN->fieldN.


But we do have delegation in D and it is a useful feature in 
Objective-C too.


Concerning D you mean mixins? Yeah, I wonder why no JVM language 
has them. On the JVM all languages on a higher level than Java 
have chosen to go with traits only (Scala, Kotlin). Groovy has 
the  Delegate annotation, but the Groovy compiler doesn't 
complain in case some diamond problem pops up in your code. So 
it's not truly for real.

With regard to Objective-C you mean the 
instancesRespondToSelector: thing? But this is some kind of hack. 
In Go the compiler checks for correctness.


 If Go is modernized C, will it end up like C++?


Well, at least Go is very consistent. No tons of complicated 
special cases you need to know about. Rust did things very well 
here. It is made for speed and low memory consumption. The way it 
adds OO elements to the language is not that minimalistic.

I don't see how Go can compete with Java when a company is 
already using Java as Go runs at about the same speed. They have 
done concurrency very well with goroutines and channels. Some of 
the excitement about Go clearly comes from concurrency being well 
done. They have a tool that can analyse the channels in some Go 
code and tell you whether a deadlock is inevitably bound to 
happen. That's not bad. I think Go is more for C or Python people 
and for Java/.NET people that want to do a little bit of system 
programming in their spare time.

-- Bienlein
Nov 29 2013
prev sibling parent reply "Chris Cain" <clcain uncg.edu> writes:
On Friday, 29 November 2013 at 12:06:17 UTC, Chris wrote:

 [1] Raises the question whether we've been conditioned by C or 
 whether C was intuitive.


I'll answer for you: C was very counter intuitive which is why no 
one has done exactly what it did since. Look up the spiral rule 
for reading types in C. Most often it can be thought of being 
read from right to left, but that's not the actual reading.

http://c-faq.com/decl/spiral.anderson.html

D fixes this massive issue to a certain degree, but it still 
feels backwards to me, despite me having been raised with "types 
on the left of the name". After using a language doing it "the 
right way" for awhile, you quickly adapt and realize it makes the 
most sense.

At least, that's the way that I feel.
Nov 29 2013
parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 29 November 2013 at 15:21:26 UTC, Chris Cain wrote:

 On Friday, 29 November 2013 at 12:06:17 UTC, Chris wrote:

 [1] Raises the question whether we've been conditioned by C or 
 whether C was intuitive.


 I'll answer for you: C was very counter intuitive which is why 
 no one has done exactly what it did since. Look up the spiral 
 rule for reading types in C. Most often it can be thought of 
 being read from right to left, but that's not the actual 
 reading.

 http://c-faq.com/decl/spiral.anderson.html

 D fixes this massive issue to a certain degree, but it still 
 feels backwards to me, despite me having been raised with 
 "types on the left of the name". After using a language doing 
 it "the right way" for awhile, you quickly adapt and realize it 
 makes the most sense.

 At least, that's the way that I feel.


I agree that D, too, can be a bit confusing. I sometimes have 
problems with AA declarations.

Example:

string[string][string] hm; // What am I?

But I don't think it's the reading direction. I wonder why you 
would want the variable name first.

var omitNewline bool

or

func (r RepeatByte) Read(p []byte) (n int, err error)

or ":="

or "var". _Of course_ it's a variable:

bool yes;
string answer;

For my liking Go code looks too cluttered (pointing out the 
obvious). But I guess it's just the way you're "brought up" with 
a language. Maybe I'm a dinosaur.
Nov 29 2013
parent reply "Chris Cain" <clcain uncg.edu> writes:
On Friday, 29 November 2013 at 16:15:10 UTC, Chris wrote:

 I agree that D, too, can be a bit confusing. I sometimes have 
 problems with AA declarations.

 Example:

 string[string][string] hm; // What am I?

 But I don't think it's the reading direction.


Actually it is. D is pretty good about being consistently read 
backwards (which, as you can tell, is a tiny bit awkward, hence 
why I think "the other way" is better).

hm is an associative array mapping string to another associative 
array mapping string to string.

Pseudocode:
hm [string][string]string;


How about something *ridiculous* in right-to-left reading:

rofl *[string][]*bool;

Try to read that before seeing what's below:

-----

rofl is a pointer to an associative array mapping strings to 
arrays of pointers to bools. Very simple and very intuitive. 
After reading a few things like that you become very comfortable 
with it.


 I wonder why you would want the variable name first.


It's really irrelevant either way, but it "reads out loud" much 
better in my experience


 For my liking Go code looks too cluttered (pointing out the 
 obvious). But I guess it's just the way you're "brought up" 
 with a language. Maybe I'm a dinosaur.


I'm not suggesting Go got it perfectly. I've seen a lot of 
languages that have cleaner declarations, IMO. To be honest, Go 
looks kind of cluttered in my eyes too. But the right-to-left 
reading order is something I'm a very strong proponent of. I'm 
fine with D, however, since you can usually reliably read it 
backwards. C, however, is a horrific mess.
Nov 30 2013
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/30/2013 1:19 PM, Chris Cain wrote:

 C, however, is a horrific mess.


The trick to reading C declarations is the form matches exactly how it is used 
in an expression. For example, a function pointer fp:

     int (*fp)(int);   // declare

     (*fp)(3);         // use
Nov 30 2013
parent reply "eles" <eles eles.com> writes:
On Sunday, 1 December 2013 at 06:43:13 UTC, Walter Bright wrote:

 On 11/30/2013 1:19 PM, Chris Cain wrote:

 C, however, is a horrific mess.


 The trick to reading C declarations is the form matches exactly 
 how it is used in an expression. For example, a function


They acknowledge that here:

http://blog.golang.org/gos-declaration-syntax

but they give a nice convoluted counter-example; read this:

int (*(*fp)(int (*)(int, int), int))(int, int)
Dec 04 2013
next sibling parent reply "Chris Cain" <clcain uncg.edu> writes:
On Wednesday, 4 December 2013 at 10:33:02 UTC, eles wrote:

 http://blog.golang.org/gos-declaration-syntax

 but they give a nice convoluted counter-example; read this:

 int (*(*fp)(int (*)(int, int), int))(int, int)


Yep. Spiral reading on this:

fp is a pointer to a function taking in ( a pointer to a function 
taking in an int and another int returning an int ) and an int 
returning a pointer to a function taking in an int and an int 
returning an int.

Although it's an artificially really complex example, it's 
ridiculous you have to read it in a spiral to understand it.
Dec 04 2013
parent reply "Chris" <wendlec tcd.ie> writes:
On Wednesday, 4 December 2013 at 11:12:00 UTC, Chris Cain wrote:

 On Wednesday, 4 December 2013 at 10:33:02 UTC, eles wrote:

 http://blog.golang.org/gos-declaration-syntax

 but they give a nice convoluted counter-example; read this:

 int (*(*fp)(int (*)(int, int), int))(int, int)


 Yep. Spiral reading on this:

 fp is a pointer to a function taking in ( a pointer to a 
 function taking in an int and another int returning an int ) 
 and an int returning a pointer to a function taking in an int 
 and an int returning an int.

 Although it's an artificially really complex example, it's 
 ridiculous you have to read it in a spiral to understand it.


C's

int numbers[];

is really awkward. But I think that D's

int[] numbers;

is just as clear as Go's right-to-left declaration. I think the 
problem is not really the reading _direction_ but the reading 
_logic_ that makes clear what belongs to what. int[] is an array 
of integers, just as []int is an array of integers. It's clear 
because it's glued to the type and not to the variable name.
Dec 04 2013
parent "Chris Cain" <clcain uncg.edu> writes:
On Wednesday, 4 December 2013 at 11:23:35 UTC, Chris wrote:

 C's

 int numbers[];

 is really awkward. But I think that D's

 int[] numbers;

 is just as clear as Go's right-to-left declaration. I think the 
 problem is not really the reading _direction_ but the reading 
 _logic_ that makes clear what belongs to what. int[] is an 
 array of integers, just as []int is an array of integers. It's 
 clear because it's glued to the type and not to the variable 
 name.


Yeah. D's is mostly fine on this. I wouldn't at all recommend a 
change on this (even for D3). I'm just bringing up the point that 
it's more natural to read "the other way around". And that C's 
reading is terrible in this regard. I've never had an issue with 
understanding D's reading (but, that said, C's reading hasn't 
confused me after I learned the spiral rule, it's just annoyed 
me).
Dec 04 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/4/2013 2:33 AM, eles wrote:

 On Sunday, 1 December 2013 at 06:43:13 UTC, Walter Bright wrote:

 On 11/30/2013 1:19 PM, Chris Cain wrote:

 C, however, is a horrific mess.


 The trick to reading C declarations is the form matches exactly how it is used
 in an expression. For example, a function


 They acknowledge that here:

 http://blog.golang.org/gos-declaration-syntax

 but they give a nice convoluted counter-example; read this:

 int (*(*fp)(int (*)(int, int), int))(int, int)


It's not a counterexample. It's still the same as how you'd use it in an
expression.
Dec 04 2013
parent "eles" <eles eles.com> writes:
On Wednesday, 4 December 2013 at 22:11:46 UTC, Walter Bright 
wrote:

 On 12/4/2013 2:33 AM, eles wrote:

 On Sunday, 1 December 2013 at 06:43:13 UTC, Walter Bright 
 wrote:

 On 11/30/2013 1:19 PM, Chris Cain wrote:







 but they give a nice convoluted counter-example; read this:

 int (*(*fp)(int (*)(int, int), int))(int, int)


 It's not a counterexample. It's still the same as how you'd use 
 it in an expression.


yes, it is not a counter-example to the C's choice, only to the 
human capacity to read declarations.
Dec 04 2013
prev sibling parent reply "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Saturday, 30 November 2013 at 21:19:15 UTC, Chris Cain wrote:

 On Friday, 29 November 2013 at 16:15:10 UTC, Chris wrote:

 I agree that D, too, can be a bit confusing. I sometimes have 
 problems with AA declarations.

 Example:

 string[string][string] hm; // What am I?




     string[string][string] hm;

The result is a string, obtained through associative array with 
key string, obtained through associative array with key string 
which is located at hm.


 How about something *ridiculous* in right-to-left reading:

 rofl *[string][]*bool;


     bool*[][string]* rofl;

The result is bool, through a pointer, stored in an array, 
obtained through associative array with key of string, stored in 
array, and all pointeded to from a location rofl.

It really doesn't matter to me, but I'm not use to Go's backward 
style so I prefer D's choice.
Dec 02 2013
next sibling parent reply "Chris Cain" <clcain uncg.edu> writes:
On Monday, 2 December 2013 at 21:33:19 UTC, Jesse Phillips wrote:

 The result is a string, obtained through associative array with 
 key string, obtained through associative array with key string 
 which is located at hm.
...
 The result is bool, through a pointer, stored in an array, 
 obtained through associative array with key of string, stored 
 in array, and all pointeded to from a location rofl.


Maybe it's just me, but if you said that (or wrote that) without 
the code I wouldn't have the beginnings of understanding what you 
were talking about.
Dec 02 2013
parent "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Tuesday, 3 December 2013 at 00:24:08 UTC, Chris Cain wrote:

 On Monday, 2 December 2013 at 21:33:19 UTC, Jesse Phillips 
 wrote:

 The result is a string, obtained through associative array 
 with key string, obtained through associative array with key 
 string which is located at hm.
...
 The result is bool, through a pointer, stored in an array, 
 obtained through associative array with key of string, stored 
 in array, and all pointeded to from a location rofl.


 Maybe it's just me, but if you said that (or wrote that) 
 without the code I wouldn't have the beginnings of 
 understanding what you were talking about.


Thats ok, I can say the same thing about what you wrote. There 
are just too many details to keep in my head, so a nice succinct 
syntax is greatly appreciated. IMO English isn't the language to 
use for these complex descriptions e.g.[1].

1.
Dec 02 2013
prev sibling parent "eles" <eles eles.com> writes:
On Monday, 2 December 2013 at 21:33:19 UTC, Jesse Phillips wrote:

 On Saturday, 30 November 2013 at 21:19:15 UTC, Chris Cain wrote:

 On Friday, 29 November 2013 at 16:15:10 UTC, Chris wrote:

 I agree that D, too, can be a bit confusing. I sometimes have 
 problems with AA declarations.

 Example:

 string[string][string] hm; // What am I?




     string[string][string] hm;

 The result is a string, obtained through associative array with 
 key string, obtained through associative array with key string 
 which is located at hm.


 How about something *ridiculous* in right-to-left reading:

 rofl *[string][]*bool;


     bool*[][string]* rofl;

 The result is bool, through a pointer, stored in an array, 
 obtained through associative array with key of string, stored 
 in array, and all pointeded to from a location rofl.


For the record, this is the idea behind the Go's declaration 
syntax:

http://blog.golang.org/gos-declaration-syntax

I liked their idea about declaring left-to-right, but using 
right-to-left (that is the distinction between type syntax and 
expression syntax). Shame that they didn't make the right choice 
for the pointer syntax.
Dec 04 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-11-29 09:29, Bienlein wrote:

 On Thursday, 28 November 2013 at 19:22:06 UTC, Andrei Alexandrescu wrote:


 Interesting. Could you please create a paste with the two code samples?

 Thanks,

 Andrei


 Hello,

 here is the Go code:

 package main

 import (
      "fmt"
 )

 type Point struct {
      x, y int
 }

 type Rectangular struct {
      topLeft, bottomRight Point
 }

 func (self Rectangular) Left() int {
      return self.topLeft.x
 }

 func (self Rectangular) Right() int {
      return self.bottomRight.x
 }

 func (self Rectangular) Width() int {
      return self.Right() - self.Left()
 }

 type Rectangle struct {
      Rectangular
 }

 func NewRectangle(topLeft, bottomRight Point) *Rectangle {
      rectangle := new(Rectangle)
      rectangle.Rectangular.topLeft = topLeft
      rectangle.Rectangular.bottomRight = bottomRight
      return rectangle
 }

 func main() {
      rectangle := NewRectangle(Point{1, 2}, Point{12, 2})
      fmt.Println(rectangle.Width())
 }

 And this is the Scala code:

 import java.awt.Point

 trait Rectangular {

    protected val topLeft: Point
    protected val bottomRight: Point

    def width : Int = bottomRight.x - topLeft.x
 }

 class Rectangle(val topLeft: Point, val bottomRight: Point) extends
 Rectangular

 object RunIt extends Application {

    val rectangle = new Rectangle(new Point(1, 2), new Point(12, 2))
    println(rectangle.width)

 }

 I guess in D you would do something like this:

 mixin template Rectangular() {
    Point x, y;
 }

 mixin Rectangular;

 struct Rectangle {
    mixin Rectangular;
 }


 Note that in the Scala code Rectangular.topLeft and
 Rectangular.bottomRight are protected. Since the solution in Go makes
 use of delegation this can only be accomplished in Go through making
 getters public or defining Rectangle in the same package as Rectangular.
 Since Go does not have constructors the way to initialize a Rectangle in
 Go looks more clumsy.

 An interesting point to me is that Rectangular in Go is just an ordinary
 struct whereas Rectangular is a special construct in Scala (being a
 trait) and in D (being a mixin). So Scala and D force you to design
 ahead, e.g. you have to decide in advance whether to make Rectangular a
 trait or mixin. Thereafter, Rectangular is not of use on its own, only
 when used as a trait or mixin.

 What makes me think is whether delegation as a language construct has
 been underrated and whether Go now makes this obvious.


You can do the exact thing in D with the help of UFCS. BTW, you need to 
decide in advance if you should use a class or a struct in D. That's 
basically the same thing as choosing if you need a template.

-- 
/Jacob Carlborg
Nov 29 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/29/2013 12:29 AM, Bienlein wrote:

 I guess in D you would do something like this:

 mixin template Rectangular() {
    Point x, y;
 }

 mixin Rectangular;

 struct Rectangle {
    mixin Rectangular;
 }


It's easier than that:

struct Rectangular {
     Point x,y;
}

struct Rectangular {
     Rectangle rectangle;
     alias this rectangle;
}
Nov 30 2013
next sibling parent reply "Bienlein" <jeti789 web.de> writes:
On Saturday, 30 November 2013 at 18:16:23 UTC, Walter Bright 
wrote:

 On 11/29/2013 12:29 AM, Bienlein wrote:

 I guess in D you would do something like this:

 mixin template Rectangular() {
   Point x, y;
 }

 mixin Rectangular;

 struct Rectangle {
   mixin Rectangular;
 }


 It's easier than that:

 struct Rectangular {
     Point x,y;
 }

 struct Rectangular {
     Rectangle rectangle;
     alias this rectangle;
 }


D is always full of surprises ;-). Now the only feature in Go 
that sets it apart from other languages is CSP.

I got this to work with help from the book by Ali Çehreli:

struct Point {
     int x,y;
}

struct Rectangular {
     Point x,y;
}

struct Rectangle  {
     Rectangular rectangular;
	
     Rectangular rect() const {
	return rectangular;
     }
	
     alias rect this;
}

void main(string[] args)
{
	Rectangle rectangle = Rectangle();
	rectangle.x = Point();
}
Nov 30 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/30/2013 12:36 PM, Bienlein wrote:

 D is always full of surprises ;-).


The syntax for alias this is a bit off-putting to me, but it works great.
Nov 30 2013
prev sibling next sibling parent reply "Bienlein" <jeti789 web.de> writes:
On Saturday, 30 November 2013 at 18:16:23 UTC, Walter Bright
wrote:


 It's easier than that:

 struct Rectangular {
     Point x,y;
 }

 struct Rectangular {
     Rectangle rectangle;
     alias this rectangle;
 }


Are there any plans so that you can have multiple aliases per
struct/class? That would be really awesome :-).
Dec 02 2013
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Dec 02, 2013 at 05:12:47PM +0100, Bienlein wrote:

 On Saturday, 30 November 2013 at 18:16:23 UTC, Walter Bright
 wrote:
 

It's easier than that:

struct Rectangular {
    Point x,y;
}

struct Rectangular {
    Rectangle rectangle;
    alias this rectangle;
}


 
 Are there any plans so that you can have multiple aliases per
 struct/class? That would be really awesome :-).


+1. Can we have multiple alias this? Pretty please? :)


T

-- 
A mathematician is a device for turning coffee into theorems. -- P. Erdos
Dec 02 2013
parent reply "Dicebot" <public dicebot.lv> writes:
On Monday, 2 December 2013 at 16:19:11 UTC, H. S. Teoh wrote:

 +1. Can we have multiple alias this? Pretty please? :)


It think it is all about "pretty pulls please" ;)
Dec 02 2013
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Dec 02, 2013 at 05:34:12PM +0100, Dicebot wrote:

 On Monday, 2 December 2013 at 16:19:11 UTC, H. S. Teoh wrote:

+1. Can we have multiple alias this? Pretty please? :)


 
 It think it is all about "pretty pulls please" ;)


I know, I know... I just need to find the time to sit down and dig into
the dmd code. Unfortunately, unlike Phobos where the code is easy to
understand (thanks to being written in D), the dmd code is harder. Well,
that, and I just haven't had the time to look over it more carefully.

OTOH, there's also the temptation to wait until we've bootstrapped dmd
into D, so that I can work with D source code instead of C++. :)


T

-- 
Guns don't kill people. Bullets do.
Dec 02 2013
parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.208.1386005781.3242.digitalmars-d puremagic.com...

 On Mon, Dec 02, 2013 at 05:34:12PM +0100, Dicebot wrote:

 On Monday, 2 December 2013 at 16:19:11 UTC, H. S. Teoh wrote:

+1. Can we have multiple alias this? Pretty please? :)


 It think it is all about "pretty pulls please" ;)


 I know, I know... I just need to find the time to sit down and dig into
 the dmd code. Unfortunately, unlike Phobos where the code is easy to
 understand (thanks to being written in D), the dmd code is harder. Well,
 that, and I just haven't had the time to look over it more carefully.

 OTOH, there's also the temptation to wait until we've bootstrapped dmd
 into D, so that I can work with D source code instead of C++. :)


The D version is automatically generated from the C++ version, so time spent 
learning the C++ code would not be wasted.
Dec 02 2013
parent reply Shammah Chancellor <anonymous coward.com> writes:
On 2013-12-03 03:33:32 +0000, Daniel Murphy said:


 "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
 news:mailman.208.1386005781.3242.digitalmars-d puremagic.com...

 On Mon, Dec 02, 2013 at 05:34:12PM +0100, Dicebot wrote:

 On Monday, 2 December 2013 at 16:19:11 UTC, H. S. Teoh wrote:

 +1. Can we have multiple alias this? Pretty please? :)


 
 It think it is all about "pretty pulls please" ;)


 
 I know, I know... I just need to find the time to sit down and dig into
 the dmd code. Unfortunately, unlike Phobos where the code is easy to
 understand (thanks to being written in D), the dmd code is harder. Well,
 that, and I just haven't had the time to look over it more carefully.
 
 OTOH, there's also the temptation to wait until we've bootstrapped dmd
 into D, so that I can work with D source code instead of C++. :)
 


 
 The D version is automatically generated from the C++ version, so time 
 spent learning the C++ code would not be wasted.


Please tell me more.   Is this actually happening?  Where's it at?
Dec 03 2013
parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Shammah Chancellor" <anonymous coward.com> wrote in message 
news:l7lrsm$2s0c$1 digitalmars.com...

 On 2013-12-03 03:33:32 +0000, Daniel Murphy said:


 "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
 news:mailman.208.1386005781.3242.digitalmars-d puremagic.com...

 On Mon, Dec 02, 2013 at 05:34:12PM +0100, Dicebot wrote:

 On Monday, 2 December 2013 at 16:19:11 UTC, H. S. Teoh wrote:

 +1. Can we have multiple alias this? Pretty please? :)


 It think it is all about "pretty pulls please" ;)


 I know, I know... I just need to find the time to sit down and dig into
 the dmd code. Unfortunately, unlike Phobos where the code is easy to
 understand (thanks to being written in D), the dmd code is harder. Well,
 that, and I just haven't had the time to look over it more carefully.

 OTOH, there's also the temptation to wait until we've bootstrapped dmd
 into D, so that I can work with D source code instead of C++. :)


 The D version is automatically generated from the C++ version, so time 
 spent learning the C++ code would not be wasted.


 Please tell me more.   Is this actually happening?  Where's it at?


Yeah.  See:
http://forum.dlang.org/post/khkst4$13ad$1 digitalmars.com
http://forum.dlang.org/post/jqvduhyvfufpzovpyqbj forum.dlang.org

Patches against dmd: https://github.com/D-Programming-Language/dmd/pull/1980
Converter tool: https://github.com/yebblies/magicport2
Pull requests marked DDMD: 
https://github.com/D-Programming-Language/dmd/pulls/yebblies
Dec 03 2013
parent reply Shammah Chancellor <anonymous coward.com> writes:
On 2013-12-04 03:19:45 +0000, Daniel Murphy said:


 "Shammah Chancellor" <anonymous coward.com> wrote in message 
 news:l7lrsm$2s0c$1 digitalmars.com...

 On 2013-12-03 03:33:32 +0000, Daniel Murphy said:
 

 "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
 news:mailman.208.1386005781.3242.digitalmars-d puremagic.com...

 On Mon, Dec 02, 2013 at 05:34:12PM +0100, Dicebot wrote:

 On Monday, 2 December 2013 at 16:19:11 UTC, H. S. Teoh wrote:

 +1. Can we have multiple alias this? Pretty please? :)


 
 It think it is all about "pretty pulls please" ;)


 
 I know, I know... I just need to find the time to sit down and dig into
 the dmd code. Unfortunately, unlike Phobos where the code is easy to
 understand (thanks to being written in D), the dmd code is harder. Well,
 that, and I just haven't had the time to look over it more carefully.
 
 OTOH, there's also the temptation to wait until we've bootstrapped dmd
 into D, so that I can work with D source code instead of C++. :)
 


 
 The D version is automatically generated from the C++ version, so time 
 spent learning the C++ code would not be wasted.


 
 Please tell me more.   Is this actually happening?  Where's it at?
 


 
 Yeah.  See:
 http://forum.dlang.org/post/khkst4$13ad$1 digitalmars.com
 http://forum.dlang.org/post/jqvduhyvfufpzovpyqbj forum.dlang.org
 
 Patches against dmd: https://github.com/D-Programming-Language/dmd/pull/1980
 Converter tool: https://github.com/yebblies/magicport2
 Pull requests marked DDMD: 
 https://github.com/D-Programming-Language/dmd/pulls/yebblies



This is AWESOME!!!!   Keep up the good work.  Can't wait to see how the 
DMD frontend performs in D.

With the version, is there any chance of LLVM being the default backend 
-- or is Walter opposed to that?

-Shammah
Dec 04 2013
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/4/2013 4:16 AM, Shammah Chancellor wrote:

 With the version, is there any chance of LLVM being the default backend -- or
is
 Walter opposed to that?


I'm opposed to it.

For one example, a year ago I had to make dmd work on Win64. LLVM didn't
support 
Win64. I would have been stymied.

It is very good for D to have 3 equivalent implementations - dmd, gdc, and ldc. 
Each has its strengths and weaknesses. It makes for a very strong ecosystem.
Dec 04 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-12-04 23:14, Walter Bright wrote:


 For one example, a year ago I had to make dmd work on Win64. LLVM didn't
 support Win64. I would have been stymied.


The answer to that would be: contribute that implementation to LLVM. But 
I know you're opposed to that as well.

If they don't accept the contributions, use a fork.

-- 
/Jacob Carlborg
Dec 05 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/5/2013 12:11 AM, Jacob Carlborg wrote:

 On 2013-12-04 23:14, Walter Bright wrote:


 For one example, a year ago I had to make dmd work on Win64. LLVM didn't
 support Win64. I would have been stymied.


 The answer to that would be: contribute that implementation to LLVM. But I know
 you're opposed to that as well.

 If they don't accept the contributions, use a fork.



Easy to say, but doing Win64 was a major effort:

1. bizarre function calling conventions

2. undocumented symbolic debug info format

3. new object file format

Making such changes on a backend without thoroughly understanding how the 
backend works would be quite a challenge. I seriously doubt anyone could have 
done that on the tight schedule I was under.

Besides, forking LLVM subverts most of the advantages of using it.
Dec 05 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-12-06 03:02, Walter Bright wrote:


 Easy to say, but doing Win64 was a major effort:

 1. bizarre function calling conventions

 2. undocumented symbolic debug info format

 3. new object file format

 Making such changes on a backend without thoroughly understanding how
 the backend works would be quite a challenge. I seriously doubt anyone
 could have done that on the tight schedule I was under.


Yes, I understand that. Hopefully you wouldn't have moved to LLVM and at 
the same time implement Win64. Meaning that hopefully you would have had 
better knowledge about the LLVM source code when starting with Win64.


 Besides, forking LLVM subverts most of the advantages of using it.


Just fold in the changes from upstream. Yes, I know that won't be as 
easy as having the code merged with upstream.

-- 
/Jacob Carlborg
Dec 05 2013
prev sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 04/12/13 23:14, Walter Bright wrote:

 I'm opposed to it.

 For one example, a year ago I had to make dmd work on Win64. LLVM didn't
support
 Win64. I would have been stymied.

 It is very good for D to have 3 equivalent implementations - dmd, gdc, and ldc.
 Each has its strengths and weaknesses. It makes for a very strong ecosystem.


The problem we have is that while all 3 implementations are equivalent, some 
implementations are more equivalent than others ... :-)

Sometimes this can be a downstream problem -- people testing code with DMD but 
not LDC or GDC, so bugs or issues don't get recognized (or they do, but the
bugs 
don't get reported to the compiler teams).  But more fundamentally, it's that
if 
you're running git-HEAD DMD, you're running the very latest code, whereas if 
you're running git-HEAD LDC or GDC, you're still running only the latest stable 
frontend/runtime/standard library releases.

So, that means that if you need the ability to get fast turnaround on bugfixes 
or new features, you HAVE to run DMD.

That really seems a constraint that we ought to be free of.
Dec 06 2013
next sibling parent reply "Craig Dillabaugh" <craig.dillabaugh gmail.com> writes:
On Friday, 6 December 2013 at 12:13:28 UTC, Joseph Rushton 
Wakeling wrote:

 On 04/12/13 23:14, Walter Bright wrote:

 I'm opposed to it.

 For one example, a year ago I had to make dmd work on Win64. 
 LLVM didn't support
 Win64. I would have been stymied.

 It is very good for D to have 3 equivalent implementations - 
 dmd, gdc, and ldc.
 Each has its strengths and weaknesses. It makes for a very 
 strong ecosystem.


 The problem we have is that while all 3 implementations are 
 equivalent, some implementations are more equivalent than 
 others ... :-)

 Sometimes this can be a downstream problem -- people testing 
 code with DMD but not LDC or GDC, so bugs or issues don't get 
 recognized (or they do, but the bugs don't get reported to the 
 compiler teams).  But more fundamentally, it's that if you're 
 running git-HEAD DMD, you're running the very latest code, 
 whereas if you're running git-HEAD LDC or GDC, you're still 
 running only the latest stable frontend/runtime/standard 
 library releases.

 So, that means that if you need the ability to get fast 
 turnaround on bugfixes or new features, you HAVE to run DMD.

 That really seems a constraint that we ought to be free of.


But is D not still doing a better job than Microsoft is of 
keeping their C++ compiler up to the latest C++ standard?

In fact in the C++ world all the compilers lag the standard to 
some extent. Its hard to expect that D would have all the 
compilers exactly in sync, though with the common front-end it 
should help.
Dec 06 2013
parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 06/12/13 13:38, Craig Dillabaugh wrote:

 But is D not still doing a better job than Microsoft is of keeping their C++
 compiler up to the latest C++ standard?


I'm not making any comparisons here, I'm simply saying that this is something
it 
could be helpful to address, for D's own sake.

Comparisons to Microsoft are not very helpful anyway, because Microsoft is to a 
great extent in the position of being able to effectively dictate solutions, 
even where they clash with or fail to live up to standards.  That's both their 
advantage and their weakness.


 In fact in the C++ world all the compilers lag the standard to some extent. Its
 hard to expect that D would have all the compilers exactly in sync, though with
 the common front-end it should help.


That's the point -- with D we are in the lucky situation that not only do all 
our compilers share common frontends, runtimes and standard libraries, but all 
the developers are friends working together in a cooperative community.  We
have 
all the resources in place to ensure that the 3 compilers are truly equal 
players.  All it will take is time and effort and a focus on making it happen.

I should add that (since bounties have been mentioned) this is another thing
I'd 
happily put money towards, if it would help.
Dec 06 2013
parent "Chris" <wendlec tcd.ie> writes:
On Friday, 6 December 2013 at 14:33:59 UTC, Joseph Rushton 
Wakeling wrote:

 On 06/12/13 13:38, Craig Dillabaugh wrote:

 But is D not still doing a better job than Microsoft is of 
 keeping their C++
 compiler up to the latest C++ standard?


 I'm not making any comparisons here, I'm simply saying that 
 this is something it could be helpful to address, for D's own 
 sake.

 Comparisons to Microsoft are not very helpful anyway, because 
 Microsoft is to a great extent in the position of being able to 
 effectively dictate solutions, even where they clash with or 
 fail to live up to standards.  That's both their advantage and 
 their weakness.


 In fact in the C++ world all the compilers lag the standard to 
 some extent. Its
 hard to expect that D would have all the compilers exactly in 
 sync, though with
 the common front-end it should help.


 That's the point -- with D we are in the lucky situation that 
 not only do all our compilers share common frontends, runtimes 
 and standard libraries,



 but all the developers are friends working together in a 
 cooperative community.


Shhhhhhhhhhhhhhhhhhhhhh! Don't tell anyone!


 We have all the resources in place to ensure that the 3 
 compilers are truly equal players.  All it will take is time 
 and effort and a focus on making it happen.

 I should add that (since bounties have been mentioned) this is 
 another thing I'd happily put money towards, if it would help.
Dec 06 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/6/2013 4:13 AM, Joseph Rushton Wakeling wrote:

 So, that means that if you need the ability to get fast turnaround on bugfixes
 or new features, you HAVE to run DMD.


Or, you could contribute to the gdc and ldc projects!
Dec 12 2013
parent reply "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
On Thursday, 12 December 2013 at 22:46:26 UTC, Walter Bright 
wrote:

 On 12/6/2013 4:13 AM, Joseph Rushton Wakeling wrote:

 So, that means that if you need the ability to get fast 
 turnaround on bugfixes
 or new features, you HAVE to run DMD.


 Or, you could contribute to the gdc and ldc projects!


Well, when I first contributed to Phobos I looked into getting 
the same patches accepted into GDC, not least because I wanted 
the functionality for my own work. It wasn't really a workable 
thing to do, both because of the lack of common git history and 
because GDC (as LDC) works by matching the features of the 
current stable release -- so adding stuff only available via 
git-HEAD Phobos wasn't really an option.

That situation would be much different if the frontend were truly 
common across all backends.
Dec 12 2013
parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On 12 December 2013 23:01, Joseph Rushton Wakeling
<joseph.wakeling webdrake.net> wrote:

 On Thursday, 12 December 2013 at 22:46:26 UTC, Walter Bright wrote:

 On 12/6/2013 4:13 AM, Joseph Rushton Wakeling wrote:

 So, that means that if you need the ability to get fast turnaround on
 bugfixes
 or new features, you HAVE to run DMD.



 Or, you could contribute to the gdc and ldc projects!



 Well, when I first contributed to Phobos I looked into getting the same
 patches accepted into GDC, not least because I wanted the functionality for
 my own work. It wasn't really a workable thing to do, both because of the
 lack of common git history and because GDC (as LDC) works by matching the
 features of the current stable release -- so adding stuff only available via
 git-HEAD Phobos wasn't really an option.


Well patches that go into phobos will soon hit gdc (eventually) - and
there's nothing wrong with cherry picking much needed patches prior to
release, if you can't wait 6 months for the next release and your bug
to be fixed.

Of course, what you can't guarantee is if fixing a bug in phobos has
some dependency on semantic changes/but fixed in the frontend.


 That situation would be much different if the frontend were truly common
 across all backends.


It's not too bad nowadays, I'll update the differences list sometime
today, but the only notable differences now between the two are:

https://github.com/D-Programming-Language/dmd/pull/2694
https://github.com/D-Programming-Language/dmd/pull/2200
https://github.com/D-Programming-Language/dmd/pull/2176




Regards
Iain.
Dec 13 2013
parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Iain Buclaw" <ibuclaw gdcproject.org> wrote in message 
news:mailman.525.1386923049.3242.digitalmars-d puremagic.com...

 On 12 December 2013 23:01, Joseph Rushton Wakeling
 <joseph.wakeling webdrake.net> wrote:

 On Thursday, 12 December 2013 at 22:46:26 UTC, Walter Bright wrote:

 On 12/6/2013 4:13 AM, Joseph Rushton Wakeling wrote:

 So, that means that if you need the ability to get fast turnaround on
 bugfixes
 or new features, you HAVE to run DMD.



 Or, you could contribute to the gdc and ldc projects!



 Well, when I first contributed to Phobos I looked into getting the same
 patches accepted into GDC, not least because I wanted the functionality 
 for
 my own work. It wasn't really a workable thing to do, both because of the
 lack of common git history and because GDC (as LDC) works by matching the
 features of the current stable release -- so adding stuff only available 
 via
 git-HEAD Phobos wasn't really an option.


 Well patches that go into phobos will soon hit gdc (eventually) - and
 there's nothing wrong with cherry picking much needed patches prior to
 release, if you can't wait 6 months for the next release and your bug
 to be fixed.

 Of course, what you can't guarantee is if fixing a bug in phobos has
 some dependency on semantic changes/but fixed in the frontend.


 That situation would be much different if the frontend were truly common
 across all backends.


 It's not too bad nowadays, I'll update the differences list sometime
 today, but the only notable differences now between the two are:

 https://github.com/D-Programming-Language/dmd/pull/2694
 https://github.com/D-Programming-Language/dmd/pull/2200
 https://github.com/D-Programming-Language/dmd/pull/2176




 Regards
 Iain.


Well, you know how I feel about 2594.  If you merge that ddmd will FTBFS.
Dec 13 2013
parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On 13 December 2013 11:11, Daniel Murphy <yebblies nospamgmail.com> wrote:

 "Iain Buclaw" <ibuclaw gdcproject.org> wrote in message
 news:mailman.525.1386923049.3242.digitalmars-d puremagic.com...

 On 12 December 2013 23:01, Joseph Rushton Wakeling
 <joseph.wakeling webdrake.net> wrote:

 On Thursday, 12 December 2013 at 22:46:26 UTC, Walter Bright wrote:

 On 12/6/2013 4:13 AM, Joseph Rushton Wakeling wrote:

 So, that means that if you need the ability to get fast turnaround on
 bugfixes
 or new features, you HAVE to run DMD.



 Or, you could contribute to the gdc and ldc projects!



 Well, when I first contributed to Phobos I looked into getting the same
 patches accepted into GDC, not least because I wanted the functionality
 for
 my own work. It wasn't really a workable thing to do, both because of the
 lack of common git history and because GDC (as LDC) works by matching the
 features of the current stable release -- so adding stuff only available
 via
 git-HEAD Phobos wasn't really an option.


 Well patches that go into phobos will soon hit gdc (eventually) - and
 there's nothing wrong with cherry picking much needed patches prior to
 release, if you can't wait 6 months for the next release and your bug
 to be fixed.

 Of course, what you can't guarantee is if fixing a bug in phobos has
 some dependency on semantic changes/but fixed in the frontend.


 That situation would be much different if the frontend were truly common
 across all backends.


 It's not too bad nowadays, I'll update the differences list sometime
 today, but the only notable differences now between the two are:

 https://github.com/D-Programming-Language/dmd/pull/2694
 https://github.com/D-Programming-Language/dmd/pull/2200
 https://github.com/D-Programming-Language/dmd/pull/2176




 Regards
 Iain.


 Well, you know how I feel about 2594.  If you merge that ddmd will FTBFS.


Yeah, it's my fault really. I should have foresaw how the change would
have affected me *before* I hit merge.  Curse you hindsight! :o)
Dec 13 2013
prev sibling parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Shammah Chancellor" <anonymous coward.com> wrote in message 
news:l7n6fh$16s0$1 digitalmars.com...

 Yeah.  See:
 http://forum.dlang.org/post/khkst4$13ad$1 digitalmars.com
 http://forum.dlang.org/post/jqvduhyvfufpzovpyqbj forum.dlang.org

 Patches against dmd: 
 https://github.com/D-Programming-Language/dmd/pull/1980
 Converter tool: https://github.com/yebblies/magicport2
 Pull requests marked DDMD: 
 https://github.com/D-Programming-Language/dmd/pulls/yebblies



 This is AWESOME!!!!   Keep up the good work.  Can't wait to see how the 
 DMD frontend performs in D.


From a quick test, compiling ddmd with ddmd takes about 80% longer than 
compiling ddmd with c++dmd.  I suspect a lot of this is from not using the 
tuned allocator from the C++ version.


 With the version, is there any chance of LLVM being the default backend --  
 or is Walter opposed to that?


As Walter said, there is no chance of that happening.  However, we are 
slowly working to integrate or refactor away all gdc/ldc patches against the 
frontend.  This should greatly reduce the effort to merge patches, hopefully 
resulting in all three compilers permanently being in sync.
Dec 04 2013
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Dec 05, 2013 at 02:08:34PM +1100, Daniel Murphy wrote:

 "Shammah Chancellor" <anonymous coward.com> wrote in message 
 news:l7n6fh$16s0$1 digitalmars.com...


[...]

 With the version, is there any chance of LLVM being the default
 backend --  or is Walter opposed to that?


 
 As Walter said, there is no chance of that happening.  However, we are
 slowly working to integrate or refactor away all gdc/ldc patches
 against the frontend.  This should greatly reduce the effort to merge
 patches, hopefully resulting in all three compilers permanently being
 in sync. 


I'm looking forward to that. Recently I've been working on a
compute-intensive program, and I've been hoping to test it with gdc to
get maximal performance, but since I developed the code mainly with dmd
git HEAD, it doesn't compile with gdc, which is rather frustrating. It
would be great if the three compilers are always in sync -- if gdc
could, for example, just pull straight from DFE git HEAD and Just
Work(tm).


T

-- 
"The number you have dialed is imaginary. Please rotate your phone 90
degrees and try again."
Dec 04 2013
prev sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 05/12/13 04:08, Daniel Murphy wrote:

 As Walter said, there is no chance of that happening.  However, we are
 slowly working to integrate or refactor away all gdc/ldc patches against the
 frontend.  This should greatly reduce the effort to merge patches, hopefully
 resulting in all three compilers permanently being in sync.


.... just as I brought the topic up in another branch of this thread [*] ... :-)

How are things going with that, what's the current status in terms of GDC/LDC 
patches being eliminated?  Do you have any idea of the timeframe within which 
it'll be complete, and does it rely at all on the C++ --> D transition?




[* I'm not sure this mix of metaphors really works.]
Dec 06 2013
parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> wrote in message 
news:mailman.304.1386341329.3242.digitalmars-d puremagic.com...

 On 05/12/13 04:08, Daniel Murphy wrote:

 As Walter said, there is no chance of that happening.  However, we are
 slowly working to integrate or refactor away all gdc/ldc patches against 
 the
 frontend.  This should greatly reduce the effort to merge patches, 
 hopefully
 resulting in all three compilers permanently being in sync.


 .... just as I brought the topic up in another branch of this thread [*] 
 ... :-)

 How are things going with that, what's the current status in terms of 
 GDC/LDC patches being eliminated?  Do you have any idea of the timeframe 
 within which it'll be complete, and does it rely at all on the C++ --> D 
 transition?


It's going very slowly.  There have been a few pulls working on some areas, 
but most of my effort has been on the d port.  The frontend unification does 
not depend on the D port, and the D port is not technically blocked by it, 
but we will need to finish it before abandoning the C++ version of the 
frontend.

I'd love to give a timeframe, but I don't have that much control over it.  A 
fairly important step is currently blocked because Walter is sitting on a 
pull request. (https://github.com/D-Programming-Language/dmd/pull/2754)
Dec 06 2013
parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 06/12/13 16:37, Daniel Murphy wrote:

 It's going very slowly.  There have been a few pulls working on some areas,
 but most of my effort has been on the d port.  The frontend unification does
 not depend on the D port, and the D port is not technically blocked by it,
 but we will need to finish it before abandoning the C++ version of the
 frontend.


OK, clear.  It's kind of what I'd expected; I'm glad to see that it's planned
as 
a precursor to the D transition rather than something to take place as part of
it.


 I'd love to give a timeframe, but I don't have that much control over it.  A
 fairly important step is currently blocked because Walter is sitting on a
 pull request. (https://github.com/D-Programming-Language/dmd/pull/2754)


That's a shame though I guess somewhat inevitable given that we're talking
about 
quite significant changes.

Is there a documented TODO list anywhere?  And is there anything that those of 
us not contributing frontend code can do to help?  (No, not spamming Walter
with 
"Please look at Pull Request 2754!" messages:-)
Dec 06 2013
parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> wrote in message 
news:mailman.307.1386345047.3242.digitalmars-d puremagic.com...

 On 06/12/13 16:37, Daniel Murphy wrote:

 Is there a documented TODO list anywhere?  And is there anything that 
 those of us not contributing frontend code can do to help?  (No, not 
 spamming Walter with "Please look at Pull Request 2754!" messages:-)


The TODO list is basically the diff between dmd's and ldc/gdc's frontends. 
I don't know of anything to do outside of the code, this is pretty much an 
internal refactoring and shouldn't have any visible effects on anything 
else.
Dec 10 2013
prev sibling parent =?UTF-8?B?Ikx1w61z?= Marques" <luis luismarques.eu> writes:
On Saturday, 30 November 2013 at 18:16:23 UTC, Walter Bright 
wrote:

 It's easier than that:

 struct Rectangular {
     Point x,y;
 }

 struct Rectangular {
     Rectangle rectangle;
     alias this rectangle;
 }


The other day in IRC I asked about the transition to the newer 
alias X = Type syntax (I would love to see it everywhere!), and 
someone was saying that the "alias this" syntax always tripped 
him, because the name misleadingly suggests that the 'this' comes 
after the 'alias'. I guess it trips everybody :-)
Dec 05 2013
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Thursday, 28 November 2013 at 16:07:47 UTC, Bienlein wrote:

 ...
 -- Bienlein


IMHO, problem with go simplicity is not as much as being not 
expressive enough to do something as with being forced to move 
lot of things to run-time. Which is not actually a problem for 
many applications but very discouraging for certain type of 
programmers.
Nov 28 2013
parent reply "Bienlein" <jeti789 web.de> writes:
On Thursday, 28 November 2013 at 19:25:56 UTC, Dicebot wrote:

 On Thursday, 28 November 2013 at 16:07:47 UTC, Bienlein wrote:

 ...
 -- Bienlein


 IMHO, problem with go simplicity is not as much as being not 
 expressive enough to do something as with being forced to move 
 lot of things to run-time.


Could you just quickly describe what you mean by "being forced to 
move
lot of things to run-time"? I simply don't see what you are 
refering to.

Thanks.
Nov 29 2013
parent "Dicebot" <public dicebot.lv> writes:
On Friday, 29 November 2013 at 08:35:58 UTC, Bienlein wrote:

 Could you just quickly describe what you mean by "being forced 
 to move
 lot of things to run-time"? I simply don't see what you are 
 refering to.


For example the dreaded generics issue. You can workaround it in 
many cases by using common polymorphic storage types but it 
costs. Or some applications of declarative programming in D - one 
can avoid using reflection and just move base data to runtime 
values but that requires to do processing during runtime.

In your Rectangular example the difference will start to appear 
when one wants to express a function that accepts any Rectangular 
type. As far as I know, in Go only option uses fat pointer. In D 
you can also express it as template constrain and thus can make 
more finely tuned design decision.
Nov 29 2013
prev sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 22 November 2013 at 13:22:10 UTC, Chris wrote:

 On Friday, 22 November 2013 at 12:34:23 UTC, Joseph Rushton 
 Wakeling wrote:

 On Friday, 22 November 2013 at 10:29:35 UTC, Chris wrote:

 Yes, yes, yes. You are of course right that corporate backing 
 gives a language a boost, even if it's a mediocre language. 
 But as soon as corporate thinking comes into a language 
 (profit, ideology, branding, hype and whatnot), it's doomed. 
 D has to breathe, and I admire all the people who have made D 
 happen, and who are making it happen. I've learned a lot just 
 by listening (well, reading).


 You're talking about corporate _management_ rather than 
 corporate backing.  The former can obviously lead to problems 
 (though it doesn't have to) -- the latter is almost invariably 
 good, as it means there's someone who can serve as guarantor 
 that any necessary work will get done.


 You cannot separate the two. Management will creep into 
 development sooner or later. E.g. one day D might implement 
 features that have to do with what Facebook needs more than 
 features that programmers need in general. So a module 
 std.webshite.upload.latest.picture gets all the attention while 
 std.reallyhandy is being neglected.


To be clear, this doesn't mean that this is happening, it's not, 
and it is good that Facebook now uses D. But the two should be 
separate. What D does should not be influenced by any company.
Nov 22 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/22/13 9:38 AM, Chris wrote:

 On Friday, 22 November 2013 at 13:22:10 UTC, Chris wrote:

 On Friday, 22 November 2013 at 12:34:23 UTC, Joseph Rushton Wakeling
 wrote:

 On Friday, 22 November 2013 at 10:29:35 UTC, Chris wrote:

 Yes, yes, yes. You are of course right that corporate backing gives
 a language a boost, even if it's a mediocre language. But as soon as
 corporate thinking comes into a language (profit, ideology,
 branding, hype and whatnot), it's doomed. D has to breathe, and I
 admire all the people who have made D happen, and who are making it
 happen. I've learned a lot just by listening (well, reading).


 You're talking about corporate _management_ rather than corporate
 backing.  The former can obviously lead to problems (though it
 doesn't have to) -- the latter is almost invariably good, as it means
 there's someone who can serve as guarantor that any necessary work
 will get done.


 You cannot separate the two. Management will creep into development
 sooner or later. E.g. one day D might implement features that have to
 do with what Facebook needs more than features that programmers need
 in general. So a module std.webshite.upload.latest.picture gets all
 the attention while std.reallyhandy is being neglected.


 To be clear, this doesn't mean that this is happening, it's not, and it
 is good that Facebook now uses D. But the two should be separate. What D
 does should not be influenced by any company.


Oh please.

Andrei
Nov 22 2013
parent "Chris" <wendlec tcd.ie> writes:
On Friday, 22 November 2013 at 17:43:06 UTC, Andrei Alexandrescu 
wrote:

 On 11/22/13 9:38 AM, Chris wrote:

 On Friday, 22 November 2013 at 13:22:10 UTC, Chris wrote:

 On Friday, 22 November 2013 at 12:34:23 UTC, Joseph Rushton 
 Wakeling
 wrote:

 On Friday, 22 November 2013 at 10:29:35 UTC, Chris wrote:

 Yes, yes, yes. You are of course right that corporate 
 backing gives
 a language a boost, even if it's a mediocre language. But 
 as soon as
 corporate thinking comes into a language (profit, ideology,
 branding, hype and whatnot), it's doomed. D has to breathe, 
 and I
 admire all the people who have made D happen, and who are 
 making it
 happen. I've learned a lot just by listening (well, 
 reading).


 You're talking about corporate _management_ rather than 
 corporate
 backing.  The former can obviously lead to problems (though 
 it
 doesn't have to) -- the latter is almost invariably good, as 
 it means
 there's someone who can serve as guarantor that any 
 necessary work
 will get done.


 You cannot separate the two. Management will creep into 
 development
 sooner or later. E.g. one day D might implement features that 
 have to
 do with what Facebook needs more than features that 
 programmers need
 in general. So a module std.webshite.upload.latest.picture 
 gets all
 the attention while std.reallyhandy is being neglected.


 To be clear, this doesn't mean that this is happening, it's 
 not, and it
 is good that Facebook now uses D. But the two should be 
 separate. What D
 does should not be influenced by any company.


 Oh please.

 Andrei


Yeah, you're right.  Sometimes I get carried away and dramatize 
things.
Nov 22 2013
prev sibling parent reply "SomeDude" <lovelydear mailmetrash.com> writes:
On Thursday, 21 November 2013 at 09:33:04 UTC, Bienlein wrote:

 What puzzles me is the enormous activity in the Go forum. Only
 the Python forum has that much traffic. It seems to me that
 people are all that happy if they have a language with which 
 they
 can just start hacking around on something.

 That is because Go doesn't force anyone to think about design.
 The only design-level construct it has is the class an that's 
 it.
 Embedding is truly only to save coding effort not having to type
 in dereferenciation chains as in C. There is nothing except
 classes, but no inheritance, traits, mixins, overriding, etc. So
 there is nothing that forces you to think about your design in
 Go. And you don't have to know about manual memory management as
 in Rust.

 -- Bienlein


That actually makes it a good first language to learn programming 
(and also bad programming). Simplicity is appealing. A language 
that can be learnt in a couple of afternoons is always pleasant 
and will draw masses. OTOH, if it doesn't force you to think 
about design, I guess the absence of design bites you in the long 
term. Then, the simplicity of the language added to the fact that 
it's statically typed might allow for fairly sophisticated 
refactoring using tooling.
These are just suppositions, I don't have any experience with Go.
Nov 21 2013
parent "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Friday, 22 November 2013 at 02:25:22 UTC, SomeDude wrote:

 That is because Go doesn't force anyone to think about design.
 The only design-level construct it has is the class an that's 
 it.


 That actually makes it a good first language to learn 
 programming (and also bad programming). Simplicity is appealing.


Or a second language. Simple to learn makes it easy for one of 
any skill to pick it up.

I don't think any language forces one to think about design. Go 
just removes design options. D allows for the same quick fix, but 
it makes it 100x easier to work that quick fix into a design.

I'm not a fan of object oriented programming. Its strength is its 
weakness. It provides structure, structure is resistant to 
change. Change is what we do, problems come from change.
Nov 21 2013
prev sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 11/7/2013 7:04 AM, Bienlein wrote:

 And, of course, Rust has
 Mozilla pushing it.


 Well, I don't know what muscle Mozilla has. I don't really
 understand where they get their money from (in part from
 Google?).


Primarily from Google, AIUI. From what I've read on Wikipedia, the vast 
majority of Mozilla's income is apparently from Google paying them to be 
Firefox's default search engine.
Nov 07 2013
prev sibling next sibling parent "Gary Willoughby" <dev nomad.so> writes:
On Tuesday, 5 November 2013 at 13:05:21 UTC, Atila Neves wrote:

 - Trying to use dub to compile the project in release or 
 profile mode flat out didn't work. I had to take the verbose 
 output of dub, use it to compile vibe.d in debug mode into an 
 object file and compile my own code separately and link it in. 
 I believe this was a dmd regression. Speaking of which, why 
 does dub recompile the world instead of tracking dependencies 
 (I tried the rdmd option once but that didn't work, I can't 
 remember why)?

 - I ran into a dmd bug when I tried to use TaskPool.map with a 
 delegate so I had to give up trying that possible optimisation.

 - I ran into another dmd bug (it crashed) at one point if 
 -inline was used.

 - dub build with LDC and GDC failed miserably. I think it was 
 because of vibe.d.


Are all of these issues noted on bugzilla? If not are you able to 
add them please? They sound serious and don't want to be 
forgotten about.
Nov 05 2013
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/5/2013 5:05 AM, Atila Neves wrote:

 - I ran into a dmd bug when I tried to use TaskPool.map with a delegate so I
had
 to give up trying that possible optimisation.

 - I ran into another dmd bug (it crashed) at one point if -inline was used.


It's very important to file these issues in bugzilla.



 - dub build with LDC and GDC failed miserably. I think it was because of
vibe.d.


These too in the dub system.
Nov 05 2013
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Tuesday, 5 November 2013 at 19:57:07 UTC, Walter Bright wrote:

 - I ran into another dmd bug (it crashed) at one point if 
 -inline was used.




At least this one will be fixed in 2.064
Nov 05 2013
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 05.11.2013 21:33, schrieb Dicebot:

 On Tuesday, 5 November 2013 at 19:57:07 UTC, Walter Bright wrote:

 - I ran into another dmd bug (it crashed) at one point if -inline was
 used.




 At least this one will be fixed in 2.064


Are you sure? There are still 5 open ICE-bugs with -inline

https://d.puremagic.com/issues/buglist.cgi?query_format=advanced&short_desc=-inline%20ICE&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&short_desc_type=allwordssubstr&component=DMD&product=D

-- 
Kind Regards
Benjamin Thaut
Nov 06 2013
parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 6 November 2013 at 11:27:04 UTC, Benjamin Thaut 
wrote:

 Are you sure? There are still 5 open ICE-bugs with -inline

 https://d.puremagic.com/issues/buglist.cgi?query_format=advanced&short_desc=-inline%20ICE&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&short_desc_type=allwordssubstr&component=DMD&product=D


Probably not all of them but at least on of "-inline" ICE's I got 
running vibe.d unittests on 2.063.2 faded away after switching to 
2.064 branch
Nov 06 2013
prev sibling parent "Atila Neves" <atila.neves gmail.com> writes:
I submitted the -inline bug. The other one with TaskPool.map was 
a known one, as was one with dub and dmd. I'll look at dub with 
ldc/gdc and at their bug tracking.


On Tuesday, 5 November 2013 at 19:57:07 UTC, Walter Bright wrote:

 On 11/5/2013 5:05 AM, Atila Neves wrote:

 - I ran into a dmd bug when I tried to use TaskPool.map with a 
 delegate so I had
 to give up trying that possible optimisation.

 - I ran into another dmd bug (it crashed) at one point if 
 -inline was used.


 It's very important to file these issues in bugzilla.



 - dub build with LDC and GDC failed miserably. I think it was 
 because of vibe.d.


 These too in the dub system.
Nov 06 2013
prev sibling parent reply "brad clawsie" <brad b7j0c.org> writes:
this has been a great thread and I've found a lot of the replies  
very insightful. I've been programming in Go at work for about a 
year or so now, so I have some opinions on Go that I believe are 
reasonably informed, while I am still a D novice but hope to 
continue learning.

First, let me say that it is obvious that, by design, D is a more 
powerful language than Go. Go's simplicity will either be an 
advantage or a deal-breaker based on who you ask.

On my vps instance last night I tried to create an initial D 
programming environment, with the following tools:

- dmd
- dub
- vibe.d
- ldc (not strictly necessary but I've heard so many good things 
about it)

First I tried installing dmd from source, which was fine but then 
I would get strange errors about referring to a file "object.d" 
when trying to build dub. Some poking around on the web resulted 
in the advice of installing the pre-built dmd binary that is in 
the release distribution. Now I was able to build dub, although 
it was strange to see two completely different build mechanisms 
for dmd and dub - dmd using a makefile and dub using a sh script 
wrapper. vibe.d was easier to install once dub worked. Over an 
hour just to get basic tools installed, although I feel HTTP 
serving is so common that it should be one of the accepted 
"batteries included" by default.

If this were Go, I would have installed the default build for my 
platform and had an http server in my standard sdk and everything 
else available by "go get", which has never failed to work 
flawlessly for me in a year of dealing with code from the web. 
This is one reason why there are already so many libraries for Go 
- it is trivial to expose your code to other developers via the 
supported toolchain.

This might not be a fair assessment given my shallow experience 
with D, but it seems much less polished relative to Go for 
setting up a development environment and working with code from 
the web.

Go's tools can be criticized as precluding operating system 
package managers, if people feel that criticism is valid, maybe a 
solution is something like the Haskell Platform, which was a 
reasonable response to the same criticism with haskell in years 
back - that setting up a development environment with basic 
consistent libraries was very painful. Haskell Platform does not 
seek to preclude operating system package managers.

Anyway, I hope this didn't seem too harsh. I still am playing 
with D and hopefully at some point in the future, package 
managers will address some of these needs.

brad
Nov 28 2013
next sibling parent reply "Craig Dillabaugh" <craig.dillabaugh gmail.com> writes:
On Friday, 29 November 2013 at 05:14:14 UTC, brad clawsie wrote:

 this has been a great thread and I've found a lot of the 
 replies  very insightful. I've been programming in Go at work 
 for about a year or so now, so I have some opinions on Go that 
 I believe are reasonably informed, while I am still a D novice 
 but hope to continue learning.

 First, let me say that it is obvious that, by design, D is a 
 more powerful language than Go. Go's simplicity will either be 
 an advantage or a deal-breaker based on who you ask.

 On my vps instance last night I tried to create an initial D 
 programming environment, with the following tools:

 - dmd
 - dub
 - vibe.d
 - ldc (not strictly necessary but I've heard so many good 
 things about it)

 First I tried installing dmd from source, which was fine but 
 then I would get strange errors about referring to a file 
 "object.d" when trying to build dub. Some poking around on the 
 web resulted in the advice of installing the pre-built dmd 
 binary that is in the release distribution. Now I was able to 
 build dub, although it was strange to see two completely 
 different build mechanisms for dmd and dub - dmd using a 
 makefile and dub using a sh script wrapper. vibe.d was easier 
 to install once dub worked. Over an hour just to get basic 
 tools installed, although I feel HTTP serving is so common that 
 it should be one of the accepted "batteries included" by 
 default.


So when you say you would install Go using the default build,
did you mean as a binary, or do you mean some sort of default
build configuration (from source) for your platform?
If as binary then this comparison is a bit unfair here.

For me (OpenSuse) all I need to do is:
sudo zypper in dmd

I've used the pre-built binaries on various Windows & Linux
OSs with no troubles.

If you want to build from source you might want to have a look at 
DVM:

https://bitbucket.org/doob/dvm/wiki/Home

(I don't have any experience with it personally, so I can't say 
how trouble free your experience would be).


 If this were Go, I would have installed the default build for 
 my platform and had an http server in my standard sdk and 
 everything else available by "go get", which has never failed 
 to work flawlessly for me in a year of dealing with code from 
 the web. This is one reason why there are already so many 
 libraries for Go - it is trivial to expose your code to other 
 developers via the supported toolchain.

 This might not be a fair assessment given my shallow experience 
 with D, but it seems much less polished relative to Go for 
 setting up a development environment and working with code from 
 the web.


Well D is a volunteer effort while Go is being backed by the 
worlds biggest web company!  That sort of accounts for that I 
suppose. There has been recognition in the community that this 
needs to improve, but progress is only so fast with the limited 
resources.


 Go's tools can be criticized as precluding operating system 
 package managers, if people feel that criticism is valid, maybe 
 a solution is something like the Haskell Platform, which was a 
 reasonable response to the same criticism with haskell in years 
 back - that setting up a development environment with basic 
 consistent libraries was very painful. Haskell Platform does 
 not seek to preclude operating system package managers.

 Anyway, I hope this didn't seem too harsh. I still am playing 
 with D and hopefully at some point in the future, package 
 managers will address some of these needs.

 brad


Hope you enjoy your experience with D.
Nov 28 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/28/13 9:49 PM, Craig Dillabaugh wrote:

 On Friday, 29 November 2013 at 05:14:14 UTC, brad clawsie wrote:

 This might not be a fair assessment given my shallow experience with
 D, but it seems much less polished relative to Go for setting up a
 development environment and working with code from the web.


 Well D is a volunteer effort while Go is being backed by the worlds
 biggest web company!  That sort of accounts for that I suppose. There
 has been recognition in the community that this needs to improve, but
 progress is only so fast with the limited resources.


Thanks Brad for the compare & contrast. Craig, I think funding is part 
of the story but not all - our community could get better at being 
perfectionist about the out-of-the box experience.

Go is underpowered but its good execution is undeniably attractive: the 
first experience, the implementation works as advertised, and the 
networking libraries show their authors' expertise. We stand to learn 
from that.


Andrei
Nov 29 2013
prev sibling next sibling parent reply "Chris Cain" <clcain uncg.edu> writes:
On Friday, 29 November 2013 at 05:14:14 UTC, brad clawsie wrote:

 First I tried installing dmd from source, which was fine but 
 then I would get strange errors about referring to a file 
 "object.d" when trying to build dub. Some poking around on the 
 web resulted in the advice of installing the pre-built dmd 
 binary that is in the release distribution.


I really have to agree. I recently had to set up an environment 
for contributing to phobos but the whole experience was a bit ... 
tedious. I ended up just using dmd.2.064.2.zip and putting the 
git repos in the src folder and making a bunch of scripts to move 
the built binaries into their correct positions. Being in the 
unique position of programming on Windows, Mac, and Linux, I've 
had to rewrite the coping script differently for each one. 
Windows is the worst for that sort of thing, but that's to be 
expected.

The whole build process is a lot more involved than it really 
should be. Ideally you should be able to clone dmd, phobos, and 
druntime and just have everything compile and be put into a 
relative path together and just "work". Maybe alert you if you 
don't have phobos and druntime to build. Ultimately, you really 
"have to" download the binary version if you want it to work 
transparently, but it would be nice if it were easy enough to 
build from source that a printed 1 page guide would get you 100% 
running.


 I feel HTTP serving is so common that it should be one of the 
 accepted "batteries included" by default.


That I'm not sure I'd agree with. Maybe getting stuff via HTTP 
(we have curl at a.t.m.) but serving HTTP files really needs 
something more substantial than I'd feel comfortable being in the 
standard library. Something too simple would likely not be used 
in favor of something like vibe.d while something the size of 
vibe.d probably is a bit too expansive to really be considered 
for part in the standard library. Not to mention the fact that 
vibe.d is in reasonably rapid development. The speed of vibe.d 
releases outpaces DMD releases and I think that's a positive 
thing overall.

Plus I feel like such an approach might make "simpler" things 
suffer (or, at least, make them feel like they suffer). Every 
time I use python I think "it's so nice that I can write an 
advanced http server with ssl encryption serving up a calculated 
meaning of life and the last digit of pi in one line, but I have 
to write an iterator to iterate over elements pairwise, which I'd 
really think should be in the standard library somewhere." (A 
"recipe" for it is in itertools which, strangely, suggests that 
they know how often it might be needed but failed to add it as an 
actual part of the standard library, but I digress...)
Nov 28 2013
parent reply "Dicebot" <public dicebot.lv> writes:
On Friday, 29 November 2013 at 05:51:48 UTC, Chris Cain wrote:

 The whole build process is a lot more involved than it really 
 should be. Ideally you should be able to clone dmd, phobos, and 
 druntime and just have everything compile and be put into a 
 relative path together and just "work". Maybe alert you if you 
 don't have phobos and druntime to build. Ultimately, you really 
 "have to" download the binary version if you want it to work 
 transparently, but it would be nice if it were easy enough to 
 build from source that a printed 1 page guide would get you 
 100% running.


Huh?

git clone https://github.com/D-Programming-Language/dmd.git
git clone https://github.com/D-Programming-Language/druntime.git
git clone https://github.com/D-Programming-Language/phobos.git

cd ./dmd/src
make -f posix.mak MODEL=64 RELEASE=1

cd ../../druntime
make -f posix.mak MODEL=64 DMD=../dmd/src/dmd RELEASE=1

cd ../phobos
make -f posix.mak MODEL=64 DMD=../dmd/src/dmd RELEASE=1

After that just make symlink to dmd binary and add 
Phobos/druntime paths to dmd.conf and you are ready to go.
Nov 29 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-11-29 16:15, Dicebot wrote:


 After that just make symlink to dmd binary and add Phobos/druntime paths
 to dmd.conf and you are ready to go.


dmd.conf.default is only for Linux. There's also no sc.ini for Windows.

-- 
/Jacob Carlborg
Nov 29 2013
parent "Dicebot" <public dicebot.lv> writes:
On Friday, 29 November 2013 at 15:34:21 UTC, Jacob Carlborg wrote:

 On 2013-11-29 16:15, Dicebot wrote:


 After that just make symlink to dmd binary and add 
 Phobos/druntime paths
 to dmd.conf and you are ready to go.


 dmd.conf.default is only for Linux. There's also no sc.ini for 
 Windows.


Pardon my ignorance, I have never used D on Windows. Well, I 
guess at least building part should be pretty much the same 
(afair make binary for Windows is in distribution)
Nov 29 2013
prev sibling next sibling parent "Paolo Invernizzi" <paolo.invernizzi gmail.com> writes:
This reply is not intended as a specific reply to Brad, so no pun 
inside, really, but...

I always wonder for how much attention there's out there 
regarding the setting up of the development environment: from my 
experience, I very very like the D simplicity, just grab a zip, 
and inside you have all the basic for every supported os. The 
_only_ missing thing in the zip is dub (guys, that MUST be in the 
official distribution).

It's so easy that when I hear about installer, packager, etc, etc 
I scratch my head... O_o

/Paolo

On Friday, 29 November 2013 at 05:14:14 UTC, brad clawsie wrote:

<snip>

 This might not be a fair assessment given my shallow experience 
 with D, but it seems much less polished relative to Go for 
 setting up a development environment and working with code from 
 the web.


<snip>

 brad
Nov 28 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-11-29 06:14, brad clawsie wrote:

 this has been a great thread and I've found a lot of the replies very
 insightful. I've been programming in Go at work for about a year or so
 now, so I have some opinions on Go that I believe are reasonably
 informed, while I am still a D novice but hope to continue learning.

 First, let me say that it is obvious that, by design, D is a more
 powerful language than Go. Go's simplicity will either be an advantage
 or a deal-breaker based on who you ask.

 On my vps instance last night I tried to create an initial D programming
 environment, with the following tools:

 - dmd
 - dub
 - vibe.d
 - ldc (not strictly necessary but I've heard so many good things about it)

 First I tried installing dmd from source, which was fine but then I
 would get strange errors about referring to a file "object.d" when
 trying to build dub. Some poking around on the web resulted in the
 advice of installing the pre-built dmd binary that is in the release
 distribution. Now I was able to build dub, although it was strange to
 see two completely different build mechanisms for dmd and dub - dmd
 using a makefile and dub using a sh script wrapper. vibe.d was easier to
 install once dub worked. Over an hour just to get basic tools installed,
 although I feel HTTP serving is so common that it should be one of the
 accepted "batteries included" by default.

 If this were Go, I would have installed the default build for my
 platform and had an http server in my standard sdk and everything else
 available by "go get", which has never failed to work flawlessly for me
 in a year of dealing with code from the web. This is one reason why
 there are already so many libraries for Go - it is trivial to expose
 your code to other developers via the supported toolchain.


Why did you install dmd from source and not the same way as Go? It's a 
bit unfair comparison. Dub is a package manager for D, with many 
libraries available.

-- 
/Jacob Carlborg
Nov 29 2013
parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 29/11/13 14:53, Jacob Carlborg wrote:

 Why did you install dmd from source and not the same way as Go? It's a bit
 unfair comparison. Dub is a package manager for D, with many libraries
available.


There is absolutely no point trying to complain about "unfair comparison" here. 
  The real question you have to ask is why there wasn't an obvious equivalent
to 
Go's "install the default build for my platform".

You can say, "Hey, D does have that equivalent, the .zip installer, or the .deb 
or .rpm files ...!" but that's not the point.  The point is why OP considered 
that the natural way to do things was to install from source.

The obvious solution to this is that the homepage should have a Big Friendly 
Button shouting "Get started with D!" that should take you to a page which 
auto-detects your system and makes available an appropriate installer.
Dec 03 2013
next sibling parent reply "eles" <eles eles.com> writes:
On Tuesday, 3 December 2013 at 15:07:36 UTC, Joseph Rushton 
Wakeling wrote:

 On 29/11/13 14:53, Jacob Carlborg wrote:



 The obvious solution to this is that the homepage should have a 
 Big Friendly Button shouting "Get started with D!" that should 
 take you to a page which auto-detects your system and makes 
 available an appropriate installer.


At least let it be a *proeminent* link towards the "Downloads & 
Tools" page, which is so quietly hidden in the left menu.
Dec 03 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/3/13 7:56 AM, eles wrote:

 On Tuesday, 3 December 2013 at 15:07:36 UTC, Joseph Rushton Wakeling wrote:

 On 29/11/13 14:53, Jacob Carlborg wrote:



 The obvious solution to this is that the homepage should have a Big
 Friendly Button shouting "Get started with D!" that should take you to
 a page which auto-detects your system and makes available an
 appropriate installer.


 At least let it be a *proeminent* link towards the "Downloads & Tools"
 page, which is so quietly hidden in the left menu.


Pull request please. Also does everybody like the graphics at the top of 
http://dconf.org/2014/index.html?

Andrei
Dec 03 2013
next sibling parent reply "Craig Dillabaugh" <craig.dillabaugh gmail.com> writes:
On Tuesday, 3 December 2013 at 20:53:28 UTC, Andrei Alexandrescu 
wrote:

 On 12/3/13 7:56 AM, eles wrote:

 On Tuesday, 3 December 2013 at 15:07:36 UTC, Joseph Rushton 
 Wakeling wrote:

 On 29/11/13 14:53, Jacob Carlborg wrote:



 The obvious solution to this is that the homepage should have 
 a Big
 Friendly Button shouting "Get started with D!" that should 
 take you to
 a page which auto-detects your system and makes available an
 appropriate installer.


 At least let it be a *proeminent* link towards the "Downloads 
 & Tools"
 page, which is so quietly hidden in the left menu.


 Pull request please. Also does everybody like the graphics at 
 the top of http://dconf.org/2014/index.html?

 Andrei


I do, nice and clean.

If I had any criticism it would be that the lettering on "Menlo 
Park" etc. is just a tiny bit too heavy.  If the letters could be 
made  more distinct, that would be nice.  However, I don't think 
it is a show-stopper.

Of course, now the next person to respond is going to say how 
much they like that lettering.

Craig
Dec 03 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/3/13 4:57 PM, Craig Dillabaugh wrote:

 On Tuesday, 3 December 2013 at 20:53:28 UTC, Andrei Alexandrescu wrote:

 On 12/3/13 7:56 AM, eles wrote:

 On Tuesday, 3 December 2013 at 15:07:36 UTC, Joseph Rushton Wakeling
 wrote:

 On 29/11/13 14:53, Jacob Carlborg wrote:



 The obvious solution to this is that the homepage should have a Big
 Friendly Button shouting "Get started with D!" that should take you to
 a page which auto-detects your system and makes available an
 appropriate installer.


 At least let it be a *proeminent* link towards the "Downloads & Tools"
 page, which is so quietly hidden in the left menu.


 Pull request please. Also does everybody like the graphics at the top
 of http://dconf.org/2014/index.html?

 Andrei


 I do, nice and clean.

 If I had any criticism it would be that the lettering on "Menlo Park"
 etc. is just a tiny bit too heavy.  If the letters could be made  more
 distinct, that would be nice.  However, I don't think it is a show-stopper.

 Of course, now the next person to respond is going to say how much they
 like that lettering.

 Craig


Thanks. I was asking mainly hoping that someone would say it's horrible 
and submit a fix :o). I adapted that from last year's logo with a free 
online image editor over my phone's 4G connection on a bus. True story.

Andrei
Dec 03 2013
prev sibling next sibling parent reply "Meta" <jared771 gmail.com> writes:
On Tuesday, 3 December 2013 at 20:53:28 UTC, Andrei Alexandrescu 
wrote:

 Pull request please. Also does everybody like the graphics at 
 the top of http://dconf.org/2014/index.html?

 Andrei


The space between the 0, 1 and 4 in 2014 is making me cringe.
Dec 03 2013
parent Philippe Sigaud <philippe.sigaud gmail.com> writes:
On Wed, Dec 4, 2013 at 6:13 AM, Meta <jared771 gmail.com> wrote:

 On Tuesday, 3 December 2013 at 20:53:28 UTC, Andrei Alexandrescu wrote:

 Pull request please. Also does everybody like the graphics at the top of
 http://dconf.org/2014/index.html?

 Andrei



 The space between the 0, 1 and 4 in 2014 is making me cringe.


Compulsory XKCD link:

http://xkcd.com/1015/
Dec 03 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-12-03 21:53, Andrei Alexandrescu wrote:


 Pull request please. Also does everybody like the graphics at the top of
 http://dconf.org/2014/index.html?


Honestly, no. It's very, yellow. Although I'm no designer so I won't try 
to create an alternative.

-- 
/Jacob Carlborg
Dec 03 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 03/12/13 21:53, Andrei Alexandrescu wrote:

 Pull request please.


I've no objection to that, but in this case I think I'd rather donate towards 
hiring a really good designer to modernize the website UI [*].  If we're not 
kickstarting the conference this year, how about a donation drive for the 
website + forums?

[* Secondary worry: if we're going to have a big "Get Started With D!" notice
on 
the front page, all those installers had better be well tested and guaranteed
to 
Just Work.]

[* Tertiary worry: I'm not convinced the website will benefit from one or two
of 
us contributing what we think is a clearer "get started" message.  User testing 
is really the only way to ensure that people get from the website what we want 
them to get.]
Dec 04 2013
prev sibling next sibling parent "Chris" <wendlec tcd.ie> writes:
On Tuesday, 3 December 2013 at 20:53:28 UTC, Andrei Alexandrescu 
wrote:

 On 12/3/13 7:56 AM, eles wrote:

 On Tuesday, 3 December 2013 at 15:07:36 UTC, Joseph Rushton 
 Wakeling wrote:

 On 29/11/13 14:53, Jacob Carlborg wrote:



 The obvious solution to this is that the homepage should have 
 a Big
 Friendly Button shouting "Get started with D!" that should 
 take you to
 a page which auto-detects your system and makes available an
 appropriate installer.


 At least let it be a *proeminent* link towards the "Downloads 
 & Tools"
 page, which is so quietly hidden in the left menu.


 Pull request please. Also does everybody like the graphics at 
 the top of http://dconf.org/2014/index.html?

 Andrei


The yellow doesn't "stand" well on the dark gray background. It 
causes the eyes to focus and defocus. Plain white or a very light 
yellow would be better.

Good idea to have a curvy font based on the letter "D". Only the 
"4" in 2014 seems to be a bit of an outlier, maybe it would help 
to give it some curves at the top (and on the left). It kind of 
breaks the overall curvy feeling.

Maybe move the logo+text a bit more to the right and give the 
text a bit more padding-left to give it more room to "breathe". 
The content could do with a bit more line spacing in the 
bullet-point section.

If I have time and there is demand I could attempt a design 
template for 2015. At the moment I'm too busy to come up with 
anything for 2014.
Dec 04 2013
prev sibling parent reply "Martin Nowak" <code dawg.eu> writes:
On Tuesday, 3 December 2013 at 20:53:28 UTC, Andrei Alexandrescu 
wrote:

 Also does everybody like the graphics at the top of 
 http://dconf.org/2014/index.html?


Frankly, it's awful.
Dec 04 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/4/13 10:57 PM, Martin Nowak wrote:

 On Tuesday, 3 December 2013 at 20:53:28 UTC, Andrei Alexandrescu wrote:

 Also does everybody like the graphics at the top of
 http://dconf.org/2014/index.html?


 Frankly, it's awful.


I agree!!

Andrei
Dec 05 2013
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, December 05, 2013 06:44:41 Andrei Alexandrescu wrote:

 On 12/4/13 10:57 PM, Martin Nowak wrote:

 On Tuesday, 3 December 2013 at 20:53:28 UTC, Andrei Alexandrescu wrote:

 Also does everybody like the graphics at the top of
 http://dconf.org/2014/index.html?


 
 Frankly, it's awful.


 
 I agree!!


As do I. The font is not particularly pretty, and the yellow is way to harsh. 
But unfortunately, I doubt that I could do much better. And it's pretty 
amazing that you managed to do that on your phone. Imagine how someone would 
have looked at you had you told them ten years ago that in the future, you'd 
be doing something like that on your phone... :)

- Jonathan M Davis
Dec 06 2013
prev sibling parent reply "Tourist" <gravatar gravatar.com> writes:
On Thursday, 5 December 2013 at 14:44:41 UTC, Andrei Alexandrescu 
wrote:

 On 12/4/13 10:57 PM, Martin Nowak wrote:

 On Tuesday, 3 December 2013 at 20:53:28 UTC, Andrei 
 Alexandrescu wrote:

 Also does everybody like the graphics at the top of
 http://dconf.org/2014/index.html?


 Frankly, it's awful.


 I agree!!

 Andrei


I'm not a designer, but I think whatever alternative is better.

My try:
http://imgur.com/a/hCIPm

Font: Sansus Webissimo
Dec 06 2013
next sibling parent reply "Tourist" <gravatar gravatar.com> writes:
On Friday, 6 December 2013 at 11:45:36 UTC, Tourist wrote:

 On Thursday, 5 December 2013 at 14:44:41 UTC, Andrei 
 Alexandrescu wrote:

 On 12/4/13 10:57 PM, Martin Nowak wrote:

 On Tuesday, 3 December 2013 at 20:53:28 UTC, Andrei 
 Alexandrescu wrote:

 Also does everybody like the graphics at the top of
 http://dconf.org/2014/index.html?


 Frankly, it's awful.


 I agree!!

 Andrei


 I'm not a designer, but I think whatever alternative is better.

 My try:
 http://imgur.com/a/hCIPm

 Font: Sansus Webissimo


Oops, 2014 of course :)
http://imgur.com/a/EkIPw
Dec 06 2013
parent "eles" <eles eles.com> writes:
On Friday, 6 December 2013 at 12:21:12 UTC, Tourist wrote:

 On Friday, 6 December 2013 at 11:45:36 UTC, Tourist wrote:

 On Thursday, 5 December 2013 at 14:44:41 UTC, Andrei 
 Alexandrescu wrote:

 On 12/4/13 10:57 PM, Martin Nowak wrote:

 On Tuesday, 3 December 2013 at 20:53:28 UTC, Andrei 
 Alexandrescu wrote:









 My try:
 http://imgur.com/a/hCIPm

 Font: Sansus Webissimo


 Oops, 2014 of course :)


Too bad. I really loved the way that you rounded the 4 until it 
became a 3. People find 4 to be not as smooth as the D belly, so 
maybe they will take a 3 instead :)
Dec 06 2013
prev sibling next sibling parent "Chris" <wendlec tcd.ie> writes:
On Friday, 6 December 2013 at 11:45:36 UTC, Tourist wrote:

 On Thursday, 5 December 2013 at 14:44:41 UTC, Andrei 
 Alexandrescu wrote:

 On 12/4/13 10:57 PM, Martin Nowak wrote:

 On Tuesday, 3 December 2013 at 20:53:28 UTC, Andrei 
 Alexandrescu wrote:

 Also does everybody like the graphics at the top of
 http://dconf.org/2014/index.html?


 Frankly, it's awful.


 I agree!!

 Andrei


 I'm not a designer, but I think whatever alternative is better.

 My try:
 http://imgur.com/a/hCIPm

 Font: Sansus Webissimo


Just add some letter spacing and bin that effin yellow. It will 
work wonders. The font is not really the problem, cos it makes 
sense to base it on the belly of "D". But add letter-spacing and 
make the font slimmer.

[ other suggestion] No drop shadows, please. In this context it 
don't make no sense to have drop shadows. Unless it's on a white 
or not grayish background.
Dec 06 2013
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/6/13 3:45 AM, Tourist wrote:

 On Thursday, 5 December 2013 at 14:44:41 UTC, Andrei Alexandrescu wrote:

 On 12/4/13 10:57 PM, Martin Nowak wrote:

 On Tuesday, 3 December 2013 at 20:53:28 UTC, Andrei Alexandrescu wrote:

 Also does everybody like the graphics at the top of
 http://dconf.org/2014/index.html?


 Frankly, it's awful.


 I agree!!

 Andrei


 I'm not a designer, but I think whatever alternative is better.

 My try:
 http://imgur.com/a/hCIPm

 Font: Sansus Webissimo


s/2013/2014/

Andrei
Dec 06 2013
parent "Tourist" <gravatar gravatar.com> writes:
On Friday, 6 December 2013 at 20:35:10 UTC, Andrei Alexandrescu 
wrote:

 On 12/6/13 3:45 AM, Tourist wrote:

 On Thursday, 5 December 2013 at 14:44:41 UTC, Andrei 
 Alexandrescu wrote:

 On 12/4/13 10:57 PM, Martin Nowak wrote:

 On Tuesday, 3 December 2013 at 20:53:28 UTC, Andrei 
 Alexandrescu wrote:

 Also does everybody like the graphics at the top of
 http://dconf.org/2014/index.html?


 Frankly, it's awful.


 I agree!!

 Andrei


 I'm not a designer, but I think whatever alternative is better.

 My try:
 http://imgur.com/a/hCIPm

 Font: Sansus Webissimo


 s/2013/2014/

 Andrei


lol, I saw you've pulled the 2013 one.
http://forum.dlang.org/post/wtsohypsvefsabegidmy forum.dlang.org
Dec 06 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-12-03 16:07, Joseph Rushton Wakeling wrote:


 There is absolutely no point trying to complain about "unfair
 comparison" here.  The real question you have to ask is why there wasn't
 an obvious equivalent to Go's "install the default build for my platform".

 You can say, "Hey, D does have that equivalent, the .zip installer, or
 the .deb or .rpm files ...!" but that's not the point.  The point is why
 OP considered that the natural way to do things was to install from source.


I thought that was just what I asked. Sure I could have skipped the 
"unfair comparison".

-- 
/Jacob Carlborg
Dec 03 2013
prev sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 29/11/13 06:14, brad clawsie wrote:

 First I tried installing dmd from source, which was fine but then I would get
 strange errors about referring to a file "object.d" when trying to build dub.


Had you created a dmd.conf file containing the right locations for 
runtime/Phobos and placed in the same directory as the dmd binary?
Dec 03 2013