Re: Go vs. D [was Re: Rust vs Dlang]
On Sunday, 17 March 2013 at 21:13:48 UTC, Paulo Pinto wrote: If I am not mistaken, Rust makes use of them as well. Rust doesn't anymore: https://mail.mozilla.org/pipermail/rust-dev/2013-November/006314.html The announcement also mentions performance problems related to Go segmented stacks: https://docs.google.com/document/d/1wAaf1rYoM4S4gtnPh0zOlGzWtrZFQ5suE8qr2sD8uWQ/pub
Re: Go vs. D [was Re: Rust vs Dlang]
The trick is to make something which is powerful and flexible for the experienced user and yet not too daunting for the newbie. I don't know how well we've succeeded on that front, but I'm sure that more tutorials and better documentation and whatnot would help. - Jonathan M Davis Jonathan you've answered some many of me questions and I wanted to comment on this thought. I am a very poor programmer who has only used languages as needed to get a job done and never becoming good at any of them. I picked up D to start developing some text processing tools. I started with other guys in our office building these tools in Python but then learned I could actually generate tiny .exe's and not have to have Python installed on systems that I needed my tools on. The slices and associative arrays are awesome. I've acquired the habit of using the time functions and printing out how long it takes the program to do its work. 245ms! 657ms! LOL. D rocks! It is extremely complex and 90% of it is over my head but making my own little .exe's that blast through things orders of magnitude faster than the scripting languages is fun. Keep up the good work all!
Re: Go vs. D [was Re: Rust vs Dlang]
On Monday, 18 March 2013 at 19:05:09 UTC, Walter Bright wrote: On 3/18/2013 3:25 AM, bearophile wrote: Walter Bright: That's just not an issue when you have 64 bits of address space. You can still have 4 billion stacks of 4 billion bytes each. At this point I suggest you to study exactly why Rust developers have decided to use a segmented stack. It seems to work well for them. If you know a reason, please post one. I believe the Rust developers are also targeting embedded systems that may not have 64-bit virtual address spaces. Hence the spaghetti stacks.
Re: Go vs. D [was Re: Rust vs Dlang]
On Tue, Mar 26, 2013 at 4:43 AM, Walter Bright newshou...@digitalmars.comwrote: How to do profiling with the dmd D compiler: 1. Add the -profile switch to the command line. 2. Read the report generated. To do coverage analysis: 1. Add the -cov switch to the command line. 2. Read the report generated. That's it. Hi Walter, Thanks I remember about the -profile switch but I don't see memory usage there. If you see your program using more and more memory even though it should not be how do you check where the problem is? In Go you generate a graph that shows the relationship between the various function calls their memory use and cpu time. Its not a flashy graph I think they use graphviz or something. What would I use in D to profile heap usage? Would I be able to find the problem area as quickly?
Re: Go vs. D [was Re: Rust vs Dlang]
26-Mar-2013 13:38, Rory McGuire пишет: On Tue, Mar 26, 2013 at 4:43 AM, Walter Bright newshou...@digitalmars.com mailto:newshou...@digitalmars.com wrote: How to do profiling with the dmd D compiler: 1. Add the -profile switch to the command line. 2. Read the report generated. To do coverage analysis: 1. Add the -cov switch to the command line. 2. Read the report generated. That's it. Hi Walter, Thanks I remember about the -profile switch but I don't see memory usage there. If you see your program using more and more memory even though it should not be how do you check where the problem is? In Go you generate a graph that shows the relationship between the various function calls their memory use and cpu time. Its not a flashy graph I think they use graphviz or something. What would I use in D to profile heap usage? Would I be able to find the problem area as quickly? What everybody in all other native languages use, for instance: valgrind --tool=massif, valgrind --tool=callgrind Any general purpose profiler works. I can confirm that e.g. AMD CodeAnalyst works just fine if application is compiled with symbols. Intel's Vtune also should work as well as many opensource tools. -- Dmitry Olshansky
Re: Go vs. D [was Re: Rust vs Dlang]
On 3/26/2013 2:38 AM, Rory McGuire wrote: Thanks I remember about the -profile switch but I don't see memory usage there. -profile and -cov do not track memory usage. If you see your program using more and more memory even though it should not be how do you check where the problem is? I've written memory usage profilers before, but haven't done one for D. You're the first to ask for one. What would I use in D to profile heap usage? Would I be able to find the problem area as quickly? What you can do is use -cov and see how often particular calls to new are done. This will give a pretty good clue as to where memory consumption is coming from.
Re: Go vs. D [was Re: Rust vs Dlang]
On 3/26/2013 3:04 AM, Walter Bright wrote: On 3/26/2013 2:38 AM, Rory McGuire wrote: Thanks I remember about the -profile switch but I don't see memory usage there. -profile and -cov do not track memory usage. If you see your program using more and more memory even though it should not be how do you check where the problem is? I've written memory usage profilers before, but haven't done one for D. You're the first to ask for one. Now that I think about it, it wouldn't be that hard to add memory allocated per function when using -profile. But my larger point is how simple it is to use -cov and -profile; it's hard to imagine it being any easier.
Re: Go vs. D [was Re: Rust vs Dlang]
On 2013-03-26 10:49, Dmitry Olshansky wrote: What everybody in all other native languages use, for instance: valgrind --tool=massif, valgrind --tool=callgrind Any general purpose profiler works. I can confirm that e.g. AMD CodeAnalyst works just fine if application is compiled with symbols. Intel's Vtune also should work as well as many opensource tools. On Mac OS X there's Instruments. There's also dtrace. -- /Jacob Carlborg
Re: Go vs. D [was Re: Rust vs Dlang]
On Tuesday, 26 March 2013 at 10:08:30 UTC, Walter Bright wrote: On 3/26/2013 3:04 AM, Walter Bright wrote: On 3/26/2013 2:38 AM, Rory McGuire wrote: Thanks I remember about the -profile switch but I don't see memory usage there. -profile and -cov do not track memory usage. If you see your program using more and more memory even though it should not be how do you check where the problem is? I've written memory usage profilers before, but haven't done one for D. You're the first to ask for one. Now that I think about it, it wouldn't be that hard to add memory allocated per function when using -profile. But my larger point is how simple it is to use -cov and -profile; it's hard to imagine it being any easier. Something like this? http://visualvm.java.net/features.html
Re: Go vs. D [was Re: Rust vs Dlang]
On Mon, Mar 18, 2013 at 2:21 PM, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Could you please go into details on the debugging and benchmarking tools? Thanks. Hi Andrei, Apologies for not replying sooner. Perhaps it is actually just the feel of the debugging and benchmarking, and the general completeness of the *documentation*. This set of slides: http://talks.golang.org/2012/simple.slide introduces pretty much everything you need to know about Go. Graphs that show memory allocation by which function allocated, and the time taken of each function (d has a way to get the data as Walter points out). Ah the profiling was only mentioned in that slide set. The profiling doc is here: http://blog.golang.org/2011/06/profiling-go-programs.html It is all super easy, and documented so that you can do it now. All in one place. And I think possibly the most important thing about it is that it does what it says. The standard library all works together as a whole. Another thing which is different and makes Go easier or faster to pick up is that there is often only one way to do something. D excels in allowing a multitude of ways to do things. Do you know of any all encompassing slide set of document that one can pick up the information contained in http://talks.golang.org/2012/simple.slide? Is there an equivalent to http://blog.golang.org/2011/06/profiling-go-programs.html?
Re: Go vs. D [was Re: Rust vs Dlang]
On 3/25/13 8:02 AM, Rory McGuire wrote: Perhaps it is actually just the feel of the debugging and benchmarking, and the general completeness of the *documentation*. This set of slides: http://talks.golang.org/2012/simple.slide introduces pretty much everything you need to know about Go. Graphs that show memory allocation by which function allocated, and the time taken of each function (d has a way to get the data as Walter points out). Ah the profiling was only mentioned in that slide set. The profiling doc is here: http://blog.golang.org/2011/06/profiling-go-programs.html It is all super easy, and documented so that you can do it now. All in one place. And I think possibly the most important thing about it is that it does what it says. The standard library all works together as a whole. Another thing which is different and makes Go easier or faster to pick up is that there is often only one way to do something. D excels in allowing a multitude of ways to do things. Do you know of any all encompassing slide set of document that one can pick up the information contained in http://talks.golang.org/2012/simple.slide? Is there an equivalent to http://blog.golang.org/2011/06/profiling-go-programs.html? Thanks, Rory, these are good reads. We should get some articles too, we definitely have most of the technical pieces in place! Andrei
Re: Go vs. D [was Re: Rust vs Dlang]
On 3/25/2013 5:02 AM, Rory McGuire wrote: The profiling doc is here: http://blog.golang.org/2011/06/profiling-go-programs.html It is all super easy, and documented so that you can do it now. What it says about profiling: To start tuning the Go program, we have to enable profiling. If the code used the Go testing package's benchmarking support, we could use gotest's standard -cpuprofile and -memprofile flags. In a standalone program like this one, we have to import runtime/pprof and add a few lines of code: [... bunch of code you have to copy/pasta in ...] After adding that code, we can run the program with the new -cpuprofile flag and then run gopprof to interpret the profile. How to do profiling with the dmd D compiler: 1. Add the -profile switch to the command line. 2. Read the report generated. To do coverage analysis: 1. Add the -cov switch to the command line. 2. Read the report generated. That's it.
Re: Go vs. D [was Re: Rust vs Dlang]
On 3/25/13 10:43 PM, Walter Bright wrote: On 3/25/2013 5:02 AM, Rory McGuire wrote: The profiling doc is here: http://blog.golang.org/2011/06/profiling-go-programs.html It is all super easy, and documented so that you can do it now. What it says about profiling: To start tuning the Go program, we have to enable profiling. If the code used the Go testing package's benchmarking support, we could use gotest's standard -cpuprofile and -memprofile flags. In a standalone program like this one, we have to import runtime/pprof and add a few lines of code: [... bunch of code you have to copy/pasta in ...] After adding that code, we can run the program with the new -cpuprofile flag and then run gopprof to interpret the profile. How to do profiling with the dmd D compiler: 1. Add the -profile switch to the command line. 2. Read the report generated. To do coverage analysis: 1. Add the -cov switch to the command line. 2. Read the report generated. That's it. We need an article on that. Andrei
Re: Go vs. D [was Re: Rust vs Dlang]
Whether it is Go or D, I wish one of you guys would fill the gap between the numeric work I need to do in fortran and the ui/string parsing/web work/plotting/animating I do in python. While working in two languages is realistically not a huge deal, it would be nice if there was something that bridged the gap for all of us people out there writing stuff for science so that we could just learn one and be done with it. the day a D program can begin with import SciD; import Dplot;, and progress to matrix.invert(); and surf(matrix);, I will ditch both python and Go. I am being incredibly self-serving and am half-kidding on this post since other people use D for all sorts of other things and they probably outnumber me. Still, I would love to see a compiled language implement numeric libraries that worked as fluidly as numpy and matplotlib work with python. One reason I prefer D over Go is that the D community is so incredibly nice :)
Re: Go vs. D [was Re: Rust vs Dlang]
edit: ditch both python and fortran.
Re: Go vs. D [was Re: Rust vs Dlang]
That's julia's(http://julialang.org/) goal, but of course it's not nearly polished. I'm interested in this as well, since I'm not totally comfortable about using a pirated MATLAB version and I hear that numpy can't match its performance on macro code.
Re: Go vs. D [was Re: Rust vs Dlang]
On Tuesday, 26 March 2013 at 04:11:05 UTC, Geancarlo Rocha wrote: That's julia's(http://julialang.org/) goal, but of course it's not nearly polished. I'm interested in this as well, since I'm not totally comfortable about using a pirated MATLAB version and I hear that numpy can't match its performance on macro code. I have heard of Julia and have not really messed with it yet for the reason you mentioned (it being in its early stages). I used MATLAB for a about a year before switching to numpy full time. I would totally recommend it. The performance loss (which I am not sure is actually there in all problems being solved) is really not that big of a deal unless you are doing some pretty heavy math, in which case MATLAB is slow compared to using C or fortran anyway. Another great thing is that numpy shares a lot of the same syntax as MATLAB, so the switch is fairly painless. If it were just numeric stuff, fortran would work okay (albeit it is a chore). I have a small collection of libraries I have written so I can execute MATLAB-esque commands for creating vectors and doing basic plotting. For example, this works: call linspace(0, pi, 100, x) y = sin(x) call plot2d(x,y) It's not the cleanest looking thing, but its better than doing it from scratch every time :P What if I wanted to plot a surface? Well, I need to write another fortran subroutine for that (which I have). The point is, it gets old having to write subroutines to do every little thing. Calculating an exponential integral requires me to link to the SLATEC library while MATLAB will do it with expint(x). There are so many things that are commonly used in numeric programming and not standard in fortran (or any compiled language). Is there some rule that only scripting languages are allowed to do these sorts of things easily? I would LOVE to see a compiled language that ran on par with C or fortran and had libraries that executed as cleanly as numpy and matplotlib do.
Re: Go vs. D [was Re: Rust vs Dlang]
On Sun, 2013-03-17 at 22:13 +0100, Paulo Pinto wrote: Am 17.03.2013 20:28, schrieb 1100110: […] The day I can compile pypy without needing 8Gb of memory is the day I'll consider it. Uau, that much?! I tend to use Python only for shell scripting type of tasks, so I wasn't aware that PyPy is so memory hungry. Using PyPy to execute Python scripts is not the problem, that is fast and efficient. 1100110 stated that it took 8GB to compile the PyPy system in his experience. Most people will never need to do that. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Go vs. D [was Re: Rust vs Dlang]
On Sun, 2013-03-17 at 13:56 -0700, Walter Bright wrote: On 3/17/2013 3:01 AM, Russel Winder wrote: I guess this is because of the segmented stacks architecture behind the realization of Go. Segmented stacks have a significant performance cost to them, as well as making it hard to interface to other languages. I also think that the shift to 64 bits makes them obsolete anyway. I think this is possibly not the case or Go and Rust would not have gone this route – which is the imperative native code equivalent of what the functional languages and the dynamic languages do using the heap. The problem is to not have a single stack so that it becomes easy to manage 1,000+ threads within a single process. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Go vs. D [was Re: Rust vs Dlang]
On 3/18/2013 2:22 AM, Russel Winder wrote: On Sun, 2013-03-17 at 13:56 -0700, Walter Bright wrote: On 3/17/2013 3:01 AM, Russel Winder wrote: I guess this is because of the segmented stacks architecture behind the realization of Go. Segmented stacks have a significant performance cost to them, as well as making it hard to interface to other languages. I also think that the shift to 64 bits makes them obsolete anyway. I think this is possibly not the case or Go and Rust would not have gone this route – which is the imperative native code equivalent of what the functional languages and the dynamic languages do using the heap. The problem is to not have a single stack so that it becomes easy to manage 1,000+ threads within a single process. That's just not an issue when you have 64 bits of address space. You can still have 4 billion stacks of 4 billion bytes each.
Re: Go vs. D [was Re: Rust vs Dlang]
On Monday, 18 March 2013 at 09:18:38 UTC, Russel Winder wrote: On Sun, 2013-03-17 at 22:13 +0100, Paulo Pinto wrote: Am 17.03.2013 20:28, schrieb 1100110: […] The day I can compile pypy without needing 8Gb of memory is the day I'll consider it. Uau, that much?! I tend to use Python only for shell scripting type of tasks, so I wasn't aware that PyPy is so memory hungry. Using PyPy to execute Python scripts is not the problem, that is fast and efficient. 1100110 stated that it took 8GB to compile the PyPy system in his experience. Most people will never need to do that. Yeah, you are right. Compiling Firefox will even require more than that.
Re: Go vs. D [was Re: Rust vs Dlang]
Walter Bright: That's just not an issue when you have 64 bits of address space. You can still have 4 billion stacks of 4 billion bytes each. At this point I suggest you to study exactly why Rust developers have decided to use a segmented stack. It seems to work well for them. Bye, bearophile
Re: Go vs. D [was Re: Rust vs Dlang]
On 3/18/13 1:46 AM, Rory McGuire wrote: The reason I use golang and not dlang for development at work is because debugging is straightforward no weird segfaults after you program has been running for a couple of days. Their debugging and benchmark tools are really good and the documentation is fantastic. Could you please go into details on the debugging and benchmarking tools? Thanks. I haven't used dlang for a while now so I don't know how much that sort of thing is improved. I'm guessing from the fact that more companies are starting to use it, that it becoming more stable to use. I am a HUGE fan of D and hope to use it exclusively one day, but last I checked if you have 5 days to do a project in golang is more likely to get you results. One question, is there a place where I can see who is currently involved with D and what their primary roles are? At this point roles are determined by what people work on, and how intensely. Andrei
Re: Go vs. D [was Re: Rust vs Dlang]
On 3/18/2013 3:25 AM, bearophile wrote: Walter Bright: That's just not an issue when you have 64 bits of address space. You can still have 4 billion stacks of 4 billion bytes each. At this point I suggest you to study exactly why Rust developers have decided to use a segmented stack. It seems to work well for them. If you know a reason, please post one.
Re: Go vs. D [was Re: Rust vs Dlang]
Am 18.03.2013 13:21, schrieb Andrei Alexandrescu: On 3/18/13 1:46 AM, Rory McGuire wrote: The reason I use golang and not dlang for development at work is because debugging is straightforward no weird segfaults after you program has been running for a couple of days. Their debugging and benchmark tools are really good and the documentation is fantastic. Could you please go into details on the debugging and benchmarking tools? Thanks. From the time I used Go. You can use gdb or if you prefer something like a debugger IDE, LiteIDE http://code.google.com/p/liteide/ For benchmarking there is an old blog entry about the tools. http://blog.golang.org/2011/06/profiling-go-programs.html Nothing that you cannot find in other languages, unless there is now something much better available. -- Paulo
Re: Go vs. D [was Re: Rust vs Dlang]
18-Mar-2013 14:25, bearophile пишет: Walter Bright: That's just not an issue when you have 64 bits of address space. You can still have 4 billion stacks of 4 billion bytes each. At this point I suggest you to study exactly why Rust developers have decided to use a segmented stack. It seems to work well for them. Walter's position is crystal clear. IMHO virtual memory was designed among other things to avoid piecing together segmented memory blocks by hand. Memory manager (OS) will od the whole dirty work for you and even hardware assists the process resulting in decent speed and complete transparency of operation. Why destroy this marvelous creation of hardware and OS developers? The whole segmented stack thing smells a lot like good ol' 16-bit days and is a step backwards unless you assume that: a) There is no virtual memory i.e. no MMU. Well, some MCU units are still like this but the trend goes towards having MMU even on tiny chips. b) Virtual ram / physical ram relation is close to 1 or even worse, like in 32-bit OS running on 8G desktops. As for virtual memory to be truly exploitable address space better be many times the total ram, the more the better. Both cases do not seem likely to be related to the future technology like at all. Bye, bearophile -- Dmitry Olshansky
Re: Go vs. D [was Re: Rust vs Dlang]
On Sun, 2013-03-17 at 08:59 +0100, Paulo Pinto wrote: […] However the Go guys just don't agree with the progresses made in language abstractions in the last decades, which in my view is a plus point for D and Rust, and made me stop caring about Go. […] So what are the features that Go is ignoring that D has? An article on this would be good marketing for D just now. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Go vs. D [was Re: Rust vs Dlang]
On 17.03.2013 09:05, Russel Winder wrote: On Sun, 2013-03-17 at 08:59 +0100, Paulo Pinto wrote: […] However the Go guys just don't agree with the progresses made in language abstractions in the last decades, which in my view is a plus point for D and Rust, and made me stop caring about Go. […] So what are the features that Go is ignoring that D has? An article on this would be good marketing for D just now. The first known one is that Go is the only strong typed language to eschew generics in the 21st century. For the rest, copying from my discussion on Lambda the Ultimate about C++ developers not jumping into Go (http://lambda-the-ultimate.org/node/4554#comment-71504): - exceptions; - enumerations; - generic types; - direct use of OS APIs, without the need of writing wrappers; - currently only static compilation is available; - due to static compilation only model, there are issues with 3rd party code; - no support for meta-programming; - rich set of available libraries; - the PR about go routines and channels, usually forgets to mention that similar features do exist as libraries for other languages I know you can fake enumerations with typed consts, but it is not the same thing as real enumerations. My point about direct OS APIs is that while D and Rust follow the approach used by other languages where you just declare bindings, Go forces the use of the CGO tool and a C compiler that speaks Go ABI. Their talk about fast compilation is also quite effective with young developers that did not grew up with Modula-2 and Mac/Turbo Pascal or using other compiled languages with modules, so they think Go is the first compiled language to offer that. Feel free to destroy. :) -- Paulo
Re: Go vs. D [was Re: Rust vs Dlang]
On 3/17/2013 1:17 AM, Paulo Pinto wrote: On 17.03.2013 09:05, Russel Winder wrote: So what are the features that Go is ignoring that D has? - exceptions; - enumerations; - generic types; - direct use of OS APIs, without the need of writing wrappers; - currently only static compilation is available; - due to static compilation only model, there are issues with 3rd party code; - no support for meta-programming; - rich set of available libraries; - the PR about go routines and channels, usually forgets to mention that similar features do exist as libraries for other languages I'd like to add that D has: - operator overloading - user defined attributes - dll's (coming soon) - vector operations - SIMD operations - scope guard - compile time function execution - true immutability and purity - inline assembler Their talk about fast compilation is also quite effective with young developers that did not grew up with Modula-2 and Mac/Turbo Pascal or using other compiled languages with modules, so they think Go is the first compiled language to offer that. Andrei did some tests a while back showing that D compiles considerably faster than Go. High compilation speed has been a major factor among companies who have adopted D.
Re: Go vs. D [was Re: Rust vs Dlang]
On Sun, 2013-03-17 at 09:17 +0100, Paulo Pinto wrote: […] The first known one is that Go is the only strong typed language to eschew generics in the 21st century. On the other hand, perhaps generics is not a good thing, yet has created an unchallenged mindset? NB I am tainted by C++ templates and generics on the JVM both of which really suck as far as I am concerned – C# has much less of a problem here, and Scala hacks it's way around it. Also I use Python a lot which has only one variable type, reference to object. Heterogeneity is not your enemy. I like the experiment of objects as values with methods added as needed, very Pythonic. Go even makes this static compile time type checked; though I think they miss the underlying irony of this. Far too many object oriented languages have forgotten that the computational model is one of sending messages to objects asking them to undertake a behaviour. Statically typed languages constrain objects not to be able to evolve their behaviours. For the rest, copying from my discussion on Lambda the Ultimate about C++ developers not jumping into Go (http://lambda-the-ultimate.org/node/4554#comment-71504): - exceptions; - enumerations; - generic types; - direct use of OS APIs, without the need of writing wrappers; - currently only static compilation is available; - due to static compilation only model, there are issues with 3rd party code; - no support for meta-programming; - rich set of available libraries; - the PR about go routines and channels, usually forgets to mention that similar features do exist as libraries for other languages Go is a stripped down C with stronger type checking. memory management and CSP. This actually makes it an important language in the scheme of things, even if I agree with you that in so many way it is a regression into the 1960s. The major problem for all statically compiled languages is the reliance on hardware integers. I know you can fake enumerations with typed consts, but it is not the same thing as real enumerations. On the other hand C and C++ enumerations are just syntactic sugar for the same thing so not real difference. In fact exactly the opposite, they are a delusion. Conversely Java enumerations are a bit heavyweight. My point about direct OS APIs is that while D and Rust follow the approach used by other languages where you just declare bindings, Go forces the use of the CGO tool and a C compiler that speaks Go ABI. I guess this is because of the segmented stacks architecture behind the realization of Go. Their talk about fast compilation is also quite effective with young developers that did not grew up with Modula-2 and Mac/Turbo Pascal or using other compiled languages with modules, so they think Go is the first compiled language to offer that. Feel free to destroy. :) Far from it. I think Go is a significant improvement over C, but that in 2013 applications programmers should be using something better. I continue to be surprised by Python people moving to Go. The only positive for Go is goroutines. Python's GIL's days are numbered at which point even that issue goes away. The issue is then how to make D appealing to Python programmers. People need to convince me why I should stop training people to use Python. This will be hard given that C/C++/Python is now the standard model for computational systems. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Go vs. D [was Re: Rust vs Dlang]
On Sun, 2013-03-17 at 01:57 -0700, Walter Bright wrote: […] I'd like to add that D has: - operator overloading - user defined attributes - dll's (coming soon) - vector operations - SIMD operations - scope guard - compile time function execution - true immutability and purity - inline assembler […] On the other hand creeping featurism can be a bad thing. Isn't the mantra small language, large (properly indexed) library? Immutability though I like. Single assignment rules. Inline assembler is anathema. Andrei did some tests a while back showing that D compiles considerably faster than Go. High compilation speed has been a major factor among companies who have adopted D. Excellent. Java / Scala is an interesting battle: Java is massively verbose, Scala is not; Java takes a while to compile, Scala takes eons. Hence static Groovy (as well as dynamic), and Kotlin. The jury is still out on whether Ceylon has any relevance to the universe. PS Can I have shared objects last week please ;-) -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Go vs. D [was Re: Rust vs Dlang]
17-Mar-2013 14:06, Russel Winder пишет: On Sun, 2013-03-17 at 01:57 -0700, Walter Bright wrote: […] I'd like to add that D has: - operator overloading - user defined attributes - dll's (coming soon) - vector operations - SIMD operations - scope guard - compile time function execution - true immutability and purity - inline assembler […] On the other hand creeping featurism can be a bad thing. Isn't the mantra small language, large (properly indexed) library? Built-in channels and goroutines don't count as feature creep ? ;) Immutability though I like. Single assignment rules. Inline assembler is anathema. Andrei did some tests a while back showing that D compiles considerably faster than Go. High compilation speed has been a major factor among companies who have adopted D. Excellent. Java / Scala is an interesting battle: Java is massively verbose, Scala is not; Java takes a while to compile, Scala takes eons. Hence static Groovy (as well as dynamic), and Kotlin. The jury is still out on whether Ceylon has any relevance to the universe. PS Can I have shared objects last week please ;-) -- Dmitry Olshansky
Re: Go vs. D [was Re: Rust vs Dlang]
On Sunday, 17 March 2013 at 08:57:48 UTC, Walter Bright wrote: I'd like to add that D has: - operator overloading - user defined attributes - dll's (coming soon) So it doesn't. - vector operations - SIMD operations - scope guard - compile time function execution - true immutability and purity It isn't guaranteed by the current type system. - inline assembler Their talk about fast compilation is also quite effective with young developers that did not grew up with Modula-2 and Mac/Turbo Pascal or using other compiled languages with modules, so they think Go is the first compiled language to offer that. Andrei did some tests a while back showing that D compiles considerably faster than Go. High compilation speed has been a major factor among companies who have adopted D. If you use some of the mentioned above features, resources required to compile can explode dramatically.
Re: Go vs. D [was Re: Rust vs Dlang]
On 03/17/2013 07:09 AM, Paulo Pinto wrote: On 17.03.2013 11:01, Russel Winder wrote: On Sun, 2013-03-17 at 09:17 +0100, Paulo Pinto wrote: […] The first known one is that Go is the only strong typed language to eschew generics in the 21st century. On the other hand, perhaps generics is not a good thing, yet has created an unchallenged mindset? NB I am tainted by C++ templates and generics on the JVM both of which really suck as far as I am concerned – C# has much less of a problem here, and Scala hacks it's way around it. Also I use Python a lot which has only one variable type, reference to object. Heterogeneity is not your enemy. I like the experiment of objects as values with methods added as needed, very Pythonic. Go even makes this static compile time type checked; though I think they miss the underlying irony of this. I think for static strong type languages you need some kind of genericity support like generics, parametric types or similar. There are many other ways to implement them. Eiffel, Modula-3, Ada and many other strong type languages also offer generics. Interfaces are halfway there, because if you are not allowed to use operators as functions, then there is always the need to write boilerplate code, even for basic types. Dynamic type languages don't require this of course, given the way their type systems work. Far too many object oriented languages have forgotten that the computational model is one of sending messages to objects asking them to undertake a behaviour. Statically typed languages constrain objects not to be able to evolve their behaviours. I might be brain damaged here, because I used OO in Object Pascal, C++, Smalltalk, CLOS, Prolog, Java, C#, VB, C++, ML and a few obscure languages. So I don't see the mainstream enterprise OO way of doing things as the only way of how OO is supposed to be. Sadly most developers in the enterprise world lack this kind of understanding and write the type of code that gives bad name to OO. For the rest, copying from my discussion on Lambda the Ultimate about C++ developers not jumping into Go (http://lambda-the-ultimate.org/node/4554#comment-71504): - exceptions; - enumerations; - generic types; - direct use of OS APIs, without the need of writing wrappers; - currently only static compilation is available; - due to static compilation only model, there are issues with 3rd party code; - no support for meta-programming; - rich set of available libraries; - the PR about go routines and channels, usually forgets to mention that similar features do exist as libraries for other languages Go is a stripped down C with stronger type checking. memory management and CSP. This actually makes it an important language in the scheme of things, even if I agree with you that in so many way it is a regression into the 1960s. Here they follow Niklaus Wirth, which I admire, school of though. When he went out to create Oberon, he decided to remove all language features he did not consider essential in a programming language. Actually all the successors, Oberon-2, Component Pascal and Active Oberon were created by his students or collaborators. In 2011 the last Oberon language report, Oberon-07, removes even a few more features. On his talk at HOPL-3 he recognizes that the industry did not follow his appreciation for smaller languages. http://www.inf.ethz.ch/personal/wirth/Articles/Modula-Oberon-June.pdf Go seems to be heading this way, as Rob Pike already wrote a blog entry about the same issue, where he mentions that Go only attracts Ruby and Python guys, but not the C++ one he expected to attract. Although I am a big fan of the Oberon operating systems and languages, I think we are no longer in the late 90's, and given the mainstream acceptance of many features that used to be only academic, why throw them away? Go's workarounds for lack of generics remind me of the time C++ still lacked generics and there were a few pre-processor tools to generate generic code. Borland used to ship one in their compilers. I don't miss those days. The major problem for all statically compiled languages is the reliance on hardware integers. I know you can fake enumerations with typed consts, but it is not the same thing as real enumerations. On the other hand C and C++ enumerations are just syntactic sugar for the same thing so not real difference. In fact exactly the opposite, they are a delusion. Conversely Java enumerations are a bit heavyweight. I prefer the enumerations the Pascal away, similar to what Java and .NET offer with primitives for generic manipulation of values. My point about direct OS APIs is that while D and Rust follow the approach used by other languages where you just declare bindings, Go forces the use of the CGO tool and a C compiler that speaks Go ABI. I guess this is because of the segmented stacks architecture behind the realization of Go. Their talk about fast compilation is also quite effective with
Re: Go vs. D [was Re: Rust vs Dlang]
On 3/17/2013 3:06 AM, Russel Winder wrote: On the other hand creeping featurism can be a bad thing. Isn't the mantra small language, large (properly indexed) library? It can be a bad thing, no doubt about it. On the other hand: When I was in London for the 2010 ACCU (when the volcano stranded me there), I took a chance to tour the Belfast cruiser sitting in the Thames. One interesting aspect of it was the ship's machine shop. It was full of carefully selected machine tools. It was pretty clear to me that an expert machinist could quickly and accurately make or repair about anything that broke on that ship. Sure, you can make do with fewer, more general purpose machines. But it'll take you considerably longer, and the result won't be as good. For example, I've used electric drills for years. I was never able to get it to drill a hole perfectly perpendicular. I finally got a drill press, and problem solved. Not only is it far more accurate, it's much faster when you've got a lot of holes to drill. I prefer to view D as a fully equipped machine shop with the right tools for the right job. Yes, it will take longer to master it than a simpler language. But we're professionals, we program all day. The investment of time to master it is trivial next to the career productivity improvement. And as for the library, yes that is crucial. A large part of D's feature set is there to enable more powerful libraries, such as the language support for ranges, and the language support for library-defined garbage collection.
Re: Go vs. D [was Re: Rust vs Dlang]
On 3/17/2013 3:01 AM, Russel Winder wrote: I guess this is because of the segmented stacks architecture behind the realization of Go. Segmented stacks have a significant performance cost to them, as well as making it hard to interface to other languages. I also think that the shift to 64 bits makes them obsolete anyway.
Re: Go vs. D [was Re: Rust vs Dlang]
Am 17.03.2013 21:56, schrieb Walter Bright: On 3/17/2013 3:01 AM, Russel Winder wrote: I guess this is because of the segmented stacks architecture behind the realization of Go. Segmented stacks have a significant performance cost to them, as well as making it hard to interface to other languages. I also think that the shift to 64 bits makes them obsolete anyway. If I am not mistaken, Rust makes use of them as well.
Re: Go vs. D [was Re: Rust vs Dlang]
Am 17.03.2013 20:28, schrieb 1100110: On 03/17/2013 07:09 AM, Paulo Pinto wrote: On 17.03.2013 11:01, Russel Winder wrote: On Sun, 2013-03-17 at 09:17 +0100, Paulo Pinto wrote: […] The first known one is that Go is the only strong typed language to eschew generics in the 21st century. On the other hand, perhaps generics is not a good thing, yet has created an unchallenged mindset? NB I am tainted by C++ templates and generics on the JVM both of which really suck as far as I am concerned – C# has much less of a problem here, and Scala hacks it's way around it. Also I use Python a lot which has only one variable type, reference to object. Heterogeneity is not your enemy. I like the experiment of objects as values with methods added as needed, very Pythonic. Go even makes this static compile time type checked; though I think they miss the underlying irony of this. I think for static strong type languages you need some kind of genericity support like generics, parametric types or similar. There are many other ways to implement them. Eiffel, Modula-3, Ada and many other strong type languages also offer generics. Interfaces are halfway there, because if you are not allowed to use operators as functions, then there is always the need to write boilerplate code, even for basic types. Dynamic type languages don't require this of course, given the way their type systems work. Far too many object oriented languages have forgotten that the computational model is one of sending messages to objects asking them to undertake a behaviour. Statically typed languages constrain objects not to be able to evolve their behaviours. I might be brain damaged here, because I used OO in Object Pascal, C++, Smalltalk, CLOS, Prolog, Java, C#, VB, C++, ML and a few obscure languages. So I don't see the mainstream enterprise OO way of doing things as the only way of how OO is supposed to be. Sadly most developers in the enterprise world lack this kind of understanding and write the type of code that gives bad name to OO. For the rest, copying from my discussion on Lambda the Ultimate about C++ developers not jumping into Go (http://lambda-the-ultimate.org/node/4554#comment-71504): - exceptions; - enumerations; - generic types; - direct use of OS APIs, without the need of writing wrappers; - currently only static compilation is available; - due to static compilation only model, there are issues with 3rd party code; - no support for meta-programming; - rich set of available libraries; - the PR about go routines and channels, usually forgets to mention that similar features do exist as libraries for other languages Go is a stripped down C with stronger type checking. memory management and CSP. This actually makes it an important language in the scheme of things, even if I agree with you that in so many way it is a regression into the 1960s. Here they follow Niklaus Wirth, which I admire, school of though. When he went out to create Oberon, he decided to remove all language features he did not consider essential in a programming language. Actually all the successors, Oberon-2, Component Pascal and Active Oberon were created by his students or collaborators. In 2011 the last Oberon language report, Oberon-07, removes even a few more features. On his talk at HOPL-3 he recognizes that the industry did not follow his appreciation for smaller languages. http://www.inf.ethz.ch/personal/wirth/Articles/Modula-Oberon-June.pdf Go seems to be heading this way, as Rob Pike already wrote a blog entry about the same issue, where he mentions that Go only attracts Ruby and Python guys, but not the C++ one he expected to attract. Although I am a big fan of the Oberon operating systems and languages, I think we are no longer in the late 90's, and given the mainstream acceptance of many features that used to be only academic, why throw them away? Go's workarounds for lack of generics remind me of the time C++ still lacked generics and there were a few pre-processor tools to generate generic code. Borland used to ship one in their compilers. I don't miss those days. The major problem for all statically compiled languages is the reliance on hardware integers. I know you can fake enumerations with typed consts, but it is not the same thing as real enumerations. On the other hand C and C++ enumerations are just syntactic sugar for the same thing so not real difference. In fact exactly the opposite, they are a delusion. Conversely Java enumerations are a bit heavyweight. I prefer the enumerations the Pascal away, similar to what Java and .NET offer with primitives for generic manipulation of values. My point about direct OS APIs is that while D and Rust follow the approach used by other languages where you just declare bindings, Go forces the use of the CGO tool and a C compiler that speaks Go ABI. I guess this is because of the segmented stacks architecture behind the realization of Go. Their talk about fast
Re: Go vs. D [was Re: Rust vs Dlang]
Walter Bright wrote: [snip] I prefer to view D as a fully equipped machine shop with the right tools for the right job. Yes, it will take longer to master it than a simpler language. But we're professionals, we program all day. Not everyone is. With its scripting abilities (fast compilation, a rich std lib, nice syntax) D is attractive for people which has used a scripting language + C/C++ before to get their job done and are frustrated by the limitations of such a combo. The investment of time to master it is trivial next to the career productivity improvement. IMHO the problem here is documentation and integration of the various aspects of the language. The learning curve is rather steep and takes (much) more time than is really needed. Of course, I agree with you on the bottom line to prefer a rich set of tools over overly simplification. Peter
Re: Go vs. D [was Re: Rust vs Dlang]
On 03/17/2013 03:44 PM, Walter Bright wrote: On 3/17/2013 3:06 AM, Russel Winder wrote: On the other hand creeping featurism can be a bad thing. Isn't the mantra small language, large (properly indexed) library? It can be a bad thing, no doubt about it. On the other hand: When I was in London for the 2010 ACCU (when the volcano stranded me there), I took a chance to tour the Belfast cruiser sitting in the Thames. One interesting aspect of it was the ship's machine shop. It was full of carefully selected machine tools. It was pretty clear to me that an expert machinist could quickly and accurately make or repair about anything that broke on that ship. Sure, you can make do with fewer, more general purpose machines. But it'll take you considerably longer, and the result won't be as good. For example, I've used electric drills for years. I was never able to get it to drill a hole perfectly perpendicular. I finally got a drill press, and problem solved. Not only is it far more accurate, it's much faster when you've got a lot of holes to drill. I prefer to view D as a fully equipped machine shop with the right tools for the right job. Yes, it will take longer to master it than a simpler language. But we're professionals, we program all day. The investment of time to master it is trivial next to the career productivity improvement. And as for the library, yes that is crucial. A large part of D's feature set is there to enable more powerful libraries, such as the language support for ranges, and the language support for library-defined garbage collection. Soo... You're saying D is like Vim? =P
Re: Go vs. D [was Re: Rust vs Dlang]
On Sunday, March 17, 2013 17:14:42 1100110 wrote: Soo... You're saying D is like Vim? =P LOL. D's learning curve is nowhere near as steep as that. Almost nothing has a learning curve as steep as vim... But on some level, the concept is the same. In order for something to be powerful enough to properly equip an experienced user, it usually ends up being more complicated for the newbie to learn. Making it super easy for the newbie to learn will just make it less useful for them in the long run, because the power just won't be there even when they're no longer a newbie. The trick is to make something which is powerful and flexible for the experienced user and yet not too daunting for the newbie. I don't know how well we've succeeded on that front, but I'm sure that more tutorials and better documentation and whatnot would help. - Jonathan M Davis
Re: Go vs. D [was Re: Rust vs Dlang]
The reason I use golang and not dlang for development at work is because debugging is straightforward no weird segfaults after you program has been running for a couple of days. Their debugging and benchmark tools are really good and the documentation is fantastic. I haven't used dlang for a while now so I don't know how much that sort of thing is improved. I'm guessing from the fact that more companies are starting to use it, that it becoming more stable to use. I am a HUGE fan of D and hope to use it exclusively one day, but last I checked if you have 5 days to do a project in golang is more likely to get you results. One question, is there a place where I can see who is currently involved with D and what their primary roles are? -Rory
