Index » General » Rust and D (page 4)

September 29, 2012
On 9/29/2012 5:05 AM, Peter Alexander wrote:
> There's two ways to interpret this sentence:
>
> 1. You claim it is okay to reject Go because it differs from other statically
> typed languages, or
> 2. You claim that all statically typed languages must have generics to be worth
> using.
>
> I hope it is not 1, and if it is 2 then again, I find this incredibly
> unimaginative.

Is it really? For example, all modern cars use fuel injection. That doesn't make carbureted cars unusable, I've driven them just fine for decades, but I sure do prefer fuel injection. Most people prefer it so much that you can buy fuel injection kits to replace the carburetors on most older cars.

I would not buy a new car with a carburetor.

Same goes for electronic ignition. Man, is that better than the old points/dwell system.
September 29, 2012
On Saturday, 29 September 2012 at 17:03:33 UTC, Peter Alexander wrote:
>  I'm sure most people here have seen similar arguments against D.

The complaint I've seen in a similar vain have been, "D is too complex" "it has everything and the kitchen sink" "if someone asks for it, it gets added"

And all but the last one is true. These are valid concerns and should not be dismissed as "people complaining to complain." Attempts to explain that to simplify the language introduces complexity to the code may fail. But the concern is not any less valid.

What is more annoying is that the level of understanding the complexity is usually attributed to that of C++. I grasp meta programming to a fairly decent degree, but I fail to read and understand that demonstrated in C++. I have very limited experience with C++ and almost no familiarity with templates (outside of the overlap with D). The syntax makes a huge difference! And with such clean syntax I guess our semantics is cleaner too.

A similar parallel I may have identified is Go return values. These are compared to those used in C. But if I picked up on this correctly, errors codes must be explicitly ignored. In which case I think of checked exceptions, except now every call is made with a try.

As you can see I am trying to apply experience I have with other languages to conform an understanding of the experience I'd get from Go. It doesn't mean it will be exactly correct, but this is how we efficiently eventuate things. If I have only ridden roller coasters that go upside-down, if asked whether I would enjoy one that doesn't go upside-down, I can apply my knowledge of the time spent not being upside down for those that do and make a best guess if I would find it fun/scary.
September 29, 2012
On Saturday, 29 September 2012 at 19:09:46 UTC, Walter Bright wrote:
> On 9/29/2012 1:08 AM, Peter Alexander wrote:
>> As you can see, no matter what you think of these features, the arguments are
>> pointless because it is very clear that you can do meaningful work without them.
>> We get by without channels, homoiconicity, and full program type inference; just
>> as the Go programmers get by without generics.
>
> I think that argument is making the claims that:
>
> 1. all features are equally valuable
>
> 2. if one can get by without a feature, then that feature is not needed
>
> Both of those are invalid.

Exactly my thoughts. Templates enable abstraction. Go channels enable ... channels. Comparing both on the same level is ridiculous. Go has a vey low level of abstraction. I feel it is even worse than C. In C, void* can be a powerful abstraction tool, but in Go pointers are almost banned and made difficult to use. Empty interfaces do not cut it because they involve boxing and unboxing and they give you nothing that void * could not give you and easier. Interfaces in general? You cannot even sensibly define interfaces with methods that have that same interfaces as their return types (just try it). I cannot see Go being used beyond utf-8 text processing (web servers and the like). Numeric calculations? Without some serious abstraction tools nobody is going to waste their time. Other uses? Wherever you go abstraction (read generics and the like) rules. Not using abstraction means usually wasting your programming effort and redoing things multiple times. When people refuse to use programming languages without abstraction mechanisms it is exactly immagination that they use.

September 29, 2012
On Saturday, 29 September 2012 at 19:09:46 UTC, Walter Bright wrote:
> On 9/29/2012 1:08 AM, Peter Alexander wrote:
>> As you can see, no matter what you think of these features, the arguments are
>> pointless because it is very clear that you can do meaningful work without them.
>> We get by without channels, homoiconicity, and full program type inference; just
>> as the Go programmers get by without generics.
>
> I think that argument is making the claims that:
>
> 1. all features are equally valuable
>
> 2. if one can get by without a feature, then that feature is not needed
>
> Both of those are invalid.

I'm not making claim 1, and claim 2 is true by definition.

September 29, 2012
On 09/29/2012 09:12 PM, Walter Bright wrote:
> On 9/29/2012 3:54 AM, Peter Alexander wrote:
>> So, with this in mind, do you think these hypothetical people are all
>> justified?
>>
>> (a) [Go programmer]: D is rubbish because it doesn't have channels.
>> (b) [Lisp programmer]: D is rubbish because it doesn't have
>> homoiconicity.
>> (c) [Haskell programmer]: D is rubbish because it doesn't have full
>> type inference.
>>
>> All of those things are considered "a major thing" by their users, and
>> many
>> people do find them to "make a big difference."
>
> People can and do make those arguments and justifications.
>
> The question is, really, how large of a class of programming problems
> does each of those features address?
>

a) can be done in a library. (eg. in D, but not in Go) Therefore,
claiming that D does not have channels is moot anyway.
b), c) enable more powerful abstractions. They help all programs
if the programmer knows how to leverage them.
September 29, 2012
On Sun, 30 Sep 2012 00:12:33 +0200
"Peter Alexander" <peter.alexander.au@gmail.com> wrote:

> On Saturday, 29 September 2012 at 19:09:46 UTC, Walter Bright wrote:
> >
> > I think that argument is making the claims that:
> >
> > 1. all features are equally valuable
> >
> > 2. if one can get by without a feature, then that feature is not needed
> >
> > Both of those are invalid.
> 
> I'm not making claim 1, and claim 2 is true by definition.
> 

Such a feature may not be *strictly* needed to accomplish a given task within a given language. However, it may very well still be needed in order to make said language actually worth switching to.

I can get by with conditional jumps instead of if/else blocks (ex: Assembly, or old-school BASIC). And I even did for several years. But I sure as hell won't anymore if I don't have to.

I, and many other people, find metaprogramming to be similarly "One you try it, you don't want to leave it". Not only does Go not have metaprogramming, but it doesn't even have the limited form of metaprogramming, generics, that's already common in many other languages. Therefore, the onus is on Go (or any other language that lacks generics), to show that there's something about the langauge that makes that sacrifice either worthwhile or at least somehow irrelevent.

September 29, 2012
>> 1. all features are equally valuable
>>
>> 2. if one can get by without a feature, then that feature is not needed
>>
>> Both of those are invalid.
>
> I'm not making claim 1, and claim 2 is true by definition.

Brainfuck has all the needed language features by that definition.
September 30, 2012
 Go looks like a horrible combination of C and Lua, lacking the speed of C and the  power of Lua(and I'd bet LuaJIT beats Go for performance).

 Not all features are equal, for me, meta programming is such a useful thing that a language better have something damn impressive to replace it(especially a systems programming language). I scanned through the Rust docs and did not see anything that appeared capable of doing so.

September 30, 2012
Looking at Rust's concurrency model, it does have some great ideas.
I wonder what would happen if D used thread-local heaps...

As far as syntax goes, the "shared" keyword could be used to distinguish between the heap types. I'm not sure how all this would work with "new", but I'm sure someone can think of a clean syntax.

In all, it's an intriguing idea, and it could fit with D's current concurrency model extremely well. I can definitely see this breaking code, but not much more than the switch to TLS globals did. It might be something to consider eventually.
September 30, 2012
On 28-09-2012 19:42, Froglegs wrote:
>    The Rust website says this:
>
> Generic types    yes, only simple, non-turing-complete substitution
>
>    After seeing that I just assumed the language was worthless and
> ignored it..  is there something more to this?
>

Let me just clarify to everyone that Rust *does* have macros, which is certainly better than nothing at all: https://github.com/mozilla/rust/blob/master/doc/tutorial-macros.md

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org
Next ›   Last »
1 2 3 4
Top | Discussion index | About this forum | D home