Rust Programming Language Reaches 1.0 Alpha

c0d3g33k writes: Rust, a new a systems programming language with a focus on safety, performance and concurrency, has released the 1.0 alpha version of the language. This means that the language and core libraries are feature-complete for the 1.0 release. In practical terms, this means that the rate of change experienced by early adopters will slow down dramatically and major breaking changes should be very rare (during the alpha cycle some major changes may still occur if considered necessary). The language will stabilize further when the beta stage is reached (planned for six weeks from now).

Comments

Obligatory

[NeoGeo64]

I'm a bit Rusty on the subject. Pardon?

Re:Obligatory

[Anonymous Coward]

I'm a bit Rusty on the subject. Pardon?

Why is this down-modded? Funniest comment I've read in minutes.

Re:Obligatory

[Anonymous Coward]

Probably because this is a topic that deserves actual commentary and discussion and not cheap jokes.

Re:Obligatory

[Anonymous Coward]

It is a good language, and now that it is stable, worthy of some effort to get all that rust off.

Re:Obligatory

[phantomfive]

Well, here is my non-humorous commentary. (I actually don't think I have a sense of humor). According to them, the primary goal of the language is:

Rust is a modern systems programming language focusing on safety and speed. It accomplishes these goals by being memory safe without using garbage collection.

ok, sounds like a great goal. How do they do that? If you read their tutorial, you won't find out for a while, they distract you with a discussion of their build system, versioning system, and package manager (that's a warning right there: a package manager should not be integrated into the language. Also, do we really need yet another package manager? And if you're actually looking for stability, avoid a language that is so focused on versioning: it's a sign they're not going to be stable).

The way it ensures memory safety is by assigning 'ownership' of an object. If two pointers point to the same thing, only one of them is allowed to change it. This is an interesting idea, and is probably especially useful when working with threads. Memory management is mainly done with smartpointers, like C++. (I also kind of like how they separate macros from generics).

Overall to me the language looks primarily based on C++, an attempt to smooth out the rough spots of C++, with a bit of Erlang thrown in (pattern matching). You might say that 'D' language was an attempt to improve on C++98, and Rust is an attempt to improve on C++11. It's like D for the new era.

To me, it's not a clear improvement over C++. For example, here is some code to read a line from input. Each of those function calls return a different object, you can't just type io::stdin().read_line(); The constant switching between return values is a bit mind-numbing for me, not only do you have to remember what functions to call, you have to remember what they all return. Kind of painful.

let input = io::stdin().read_line().ok().expect("Failed to read line");

Re:Obligatory

[Anonymous Coward]

It'd be "just type io::stdin().read_line()" only if you don't care about error handling, and not caring about error handling is pretty much the opposite of their design goals.

Actual analog of that expression wouldn't be "io::stdin().read_line()", it'd be more like
try {
        input = io::stdin.read_line();
} catch(exception &e) {
        cerr<<"Failed to read line";
        terminate();
}

In C it would be even uglier, with manual checking of error codes and all.

Re:Obligatory

[smittyoneeach]

Oh for crying out loud in the dark: this is Slashdot, where the signal-to-noise ratio is both constant and lousy.

Re:Obligatory

[RoccamOccam]

I'm guessing (truly!) that last function call should be "except" and not "expect".

Re:Obligatory

[SkepticalEmpiricist]

> Overall to me the language looks primarily based on C++, an attempt to smooth out the rough spots of C++,

It's like C++, but where segfaults are impossible. In C++ (and C) you might try to return a pointer to a stack-allocated object:

        X * foo() {
                X x;
                return
        }

Any decent compiler will warn you that this is buggy. But that's only because it's a blatant bug. It's possible to write much more subtle bugs, which lead to the same problems, but which modern C and C++ compilers will miss. As well as accessing stack variables after their valid lifetime, you might free some heap memory twice, or not at all, and so on.

(Disclaimer: I have essentially no real experience with Rust, but have followed it's development a little.)

Rust will not allow you to compile the program until it can prove that your program is safe, that you are not abusing the lifetime of anything. This allows us to have performance and safety without compromising on either. The language also limits at most one variable at a time to have write access to a given object, this is good for concurrency also (well, even single threaded code would benefit from this). Basically, you just write C++-style code, but instead of having to convince a code review commitee of the safety of your code, you can just say "the compiler accepted it, therefore certain safety guarantees can now be assumed".

For example,

        Circle * foo() {
                Circle c1(5);
                Circle c2(10);
                return biggestCircle(&c1,&c2);
        }

We know that would be invalid, but a C++ compiler wouldn't see any problem. The Rust compiler, on the other hand, can see that the lifetime of the return object of biggestCircle can be no longer than the lifetime of either parameter.

I am gradually becoming incredibly excited about this feature. But it's going to be interesting watching the future of the language. This kind of feature isn't appreciated unless you're an experienced C++ developer. So we might find that lots of important software, from rocket ship code to web browser code, is written in Rust in future but we might find that most people don't understand why! It will be kind of like C++ for many people, they dismiss it when they are new to software, but ultimately everyone goes to C++ (or, in future, Rust) instead! :-)

[Java took a very different approach to the problem of "how to we get rid of segfaults and memory corruption". Java basically banned all interesting use of the stack, forcing everything onto the heap, and barred developers from using RAII. Nowadays, with more advanced compilers able to do advanced lifetime analysis, we can reconsider languages - such as Rust - that take a less draconian approach.]

Re:Obligatory

[phantomfive]

Java took a very different approach to the problem of "how to we get rid of segfaults and memory corruption".

Well, they didn't; NPEs are pretty common in Java. And let's not get started on memory leaks......

Re:Obligatory

[phantomfive]

No, I think it's expect, because it's repeated all over the place in this section and the next section. I have to say the deeper I look into the language, the less I like it.

I find the safety aspect very interesting, but I've been trying to think how many bugs that would catch in my own code. I think the answer is not many; the last time I accidentally wrote a dangling pointer was something like 7 years ago. I avoid them by making sure my code is understandable.

There's a similar problem with null seg-faults (which they avoid by not allowing null pointers at all). I get them, but they are an indication of a logical error in my code, and they are easy to debug because they are noticed immediately. Because the NULL is used as a flag, containing logic. If people can't use the NULL flag, they will use a separate variable to have the same meaning as NULL previously had. However in those cases, the seg-fault (or NPE) won't be around to let you know that something is wrong, the program will merely continue executing poor logic which hopefully you notice.

Re:Obligatory

[phantomfive]

Somehow my link got eaten. It actually is expect.

Re:Obligatory

[Raenex]

An NullPointerException is not a segfault or memory corruption, except in a very trivial sense you can consider it a segfault. The difference is night and day between the kind of memory corruption and wild pointers you get with C/C++.

As for memory leaks, yeah, that can still happen, but it isn't very common and they are easy to track down with VM tooling.

Now if you want to bash Java for not tackling serious issues, just look at its threading model, basically "threads and locks", and it's very easy to have threads stomping on data that it shouldn't. That's corruption.

Java also didn't do a good job for resource leaks, meaning things besides memory, like connection handles.

Re:Obligatory

[phantomfive]

An NullPointerException is not a segfault

Yes it is lol

Now if you want to bash Java

I wasn't bashing Java lol. You have some kind of weird defensiveness issues.

Java also didn't do a good job for resource leaks, meaning things besides memory

Memory leaks are surprisingly common in Java as well, because people don't think. If you put something in a list or queue, you need to have a plan for getting it out. I've spent so many hours fixing leaks from people who didn't have a plan. Javascript is even worse (especially stuff like Angular.js): people stick stuff in the DOM and just leave it there.

Re:Obligatory

[SkepticalEmpiricist]

Null Pointer Exceptions are certainly undesirable. But it is at least well defined behaviour, and you can catch the exception if you like.

In C and C++, dereferencing a null pointer is undefined. If you're lucky, you might get a segfault, but if you're unlucky it can do literally anything, including deleting all your files.

When I originally said:

> Java took a very different approach to the problem of "how to we get rid of segfaults and memory corruption".

I should have said:

> Java took a very different approach to the problem of "how to we get rid of undefined behaviour, including - but not limited too - segfaults and memory corruption".

Java did tackle this problem - it appears to have been a major principle behind it. And they did successfully do this. People might debate whether the price was worth paying, but this isn't the thread to discuss it. See to discuss Java furthur.

Our goal here isn't to discuss Java in detail, but to highlight the problem that is solved in Rust by lifetime analysis.

Re:Obligatory

[IamTheRealMike]

[Java took a very different approach to the problem of "how to we get rid of segfaults and memory corruption". Java basically banned all interesting use of the stack, forcing everything onto the heap, and barred developers from using RAII. Nowadays, with more advanced compilers able to do advanced lifetime analysis, we can reconsider languages - such as Rust - that take a less draconian approach.]

I think it's rather misleading to state that more advanced compilers have obviated the need for Java's approach.

Firstly, Rust doesn't solve automatic memory management like garbage collection does. Their solution appears to be basically smart pointers with move semantics + reference counting for the cases where data doesn't have a lifetime cleanly tied to scope. Well, great. It's back to the 1990's and COM. Reference counting notoriously cannot handle cycles, which are very common in real programs. Any tree structure where you want to be able to navigate both up and down, for example.

In addition to the difficulty of breaking reference cycles and preventing memory leaks in complex programs, refcounting also has poor performance especially if you want threads involved. Garbage collection has now been optimised (in good implementations like HotSpot) to the point where it's faster than refcounting.

If we start seeing teams of non-expert programmers writing large programs in Rust, you will see programs with memory leaks all over the place.

Additionally, you realise that Java compilers have got smarter over the years too, right? HotSpot can stack allocate objects in a bunch of different circumstances, when analysis reveals that it'd be safe.

Re:Obligatory

[Raenex]

Yes it is lol

Nice job taking what I said out of context, dickhead. You completely ignored the rest of the explanatory text.

I wasn't bashing Java lol. You have some kind of weird defensiveness issues.

Uh huh, sure you weren't.

Memory leaks are surprisingly common in Java as well, because people don't think. If you put something in a list or queue, you need to have a plan for getting it out.

If the list goes out of scope and nothing else points to the object in the list, it gets collected. Yes, you can leak memory in Java. No, it doesn't happen nearly as often as it does in a language like C or C++, and you aren't constantly spending time worrying about memory allocation issues to do trivial code. That to me is the biggest thing.

Re:Obligatory

[phantomfive]

Nice job taking what I said out of context, dickhead. You completely ignored the rest of the explanatory text.

Yes, that was me being kind, because the rest of your 'explanatory text' didn't support your main point. Sorry, NPEs are seg faults and you're wrong.

Re:Obligatory

[phantomfive]

In C and C++, dereferencing a null pointer is undefined. If you're lucky, you might get a segfault, but if you're unlucky it can do literally anything, including deleting all your files.

Come on, that's a strawman. In every modern system it throws an interrupt, which is usually not caught, and optionally dumps a core (which is useful for debugging because not only does it have a stack trace, it contains all the variables at the time of the crash), and you know it.

Our goal here isn't to discuss Java in detail, but to highlight the problem that is solved in Rust by lifetime analysis.

True point, let's focus on that.

I've been thinking about this over the night, and the problem it solves is essentially two different places modifying an object at the same time (the first example I found on their website where the program grabs a reference to the first item in a queue, then the queue modifies the item's address internally). I am always interested in new ways to verify correctness automatically, and I find this idea interesting.

However, I'm not sure it justifies a new language (or rather, I see this as an interesting experimental language). The reason is this: I've thought through all the bugs I can remember in the past several years, and tried to decide if this would have helped catch those problems. The answer I come up with is that not many bugs would have been caught by this.

To some degree it puzzles me, because these guys seem to think it's a serious enough problem to be worth creating a whole new language. And that makes me wonder how they are programming, what they are doing to get all these errors.

Re:Obligatory

[phantomfive]

Garbage collection has now been optimised (in good implementations like HotSpot) to the point where it's faster than refcounting.

I'm not convinced of that. Firstly, I've seen that once you get ~15GB of ram in your program, the garbage collect process can 10 minutes to run, once an hour. Secondly, in the gc systems I've seen, they perform fine when they have plenty of extra RAM, but when RAM gets tight, they slow down quite a bit.

Re:Obligatory

[Raenex]

It's not you being kind, it's you being a dickhead, because I explicitly acknowledged that they were segfaults "in a very trivial sense".

The point being that when a random segfault occurs in a C/C++ program, it could be anything. If you're lucky, the pointer is null. In Java this is a nuisance issue and usually trivial to track down, a typical example being you forgot to check for null when you pulled something out of a collection or similar.

Re:Obligatory

[phantomfive]

I explicitly acknowledged that they were segfaults "in a very trivial sense".

And you are wrong. It's not in a trivial sense, it's in a very real sense.

If you're lucky, the pointer is null.

No, 99.999% of the time it's null. What kind of weird programming style do you have that it's not?

In Java this is a nuisance issue and usually trivial to track down, a typical example being you forgot to check for null when you pulled something out of a collection or similar.

Yup, same with C, they're pretty trivial to track down. But hey, you started with the name calling, do you want me to call you a moron?

Re:Obligatory

[phantomfive]

It'd be "just type io::stdin().read_line()" only if you don't care about error handling

I don't think that works in the language. read_line() returns an IoResult. That's different than a String (obviously), and I don't think they can do automatic type conversion like that (although that would be cool).

Re:Obligatory

[SkepticalEmpiricist]

> Come on, that's a strawman. In every modern system it throws an interrupt, which is usually not caught, and optionally dumps a core

I gave the wrong example. Null pointers aren't half as serious as dereferencing a non-null pointer to a local variable in a function that already has returned. In C and C++ this really will do random crazy things quite often.

> However, I'm not sure it justifies a new language ...

I guess some or all of this lifetime-analysis technology could be included in a C++ compiler. But some extensions to the language are needed, for example is Rust you can annotate the function parameters with hints that help it to prove the lifetime. And I guess those kind of extensions aren't going to be officially accepted in C++ any time soon. Lifetime analysis isn't the only new thing in Rust, it's just the thing I'm most excited by currently. I really like their approach to polymorphism, it reminds me of Haskell. Adding these things to C++, without breaking C++, would lead to a syntax that isn't very concise.

In Rust, everything is const by default. I can't imagine C++ going that way soon - backwards compatibility would be a nightmare.

Ideally, Rust and C++ could inspire each other to improve. There's a lot of compatibility between them, so we could mix them.

Re:Obligatory

[phantomfive]

Null pointers aren't half as serious as dereferencing a non-null pointer to a local variable in a function that already has returned.

true, but the latter is extremely rare (at last they should be...if they are common when you write code, you need to change your programming style). Adding an auto-checker for these things is cool, but I don't see the benefit being huge, more like incremental improvements.

Which is why I compare the language to D: D was an incremental improvement on C++, and it was nicer, but not enough to really gain traction. I imagine Rust will follow a similar trajectory.

Re:Obligatory

[Anonymous Coward]

If you're lucky, the pointer is null.

No, 99.999% of the time it's null. What kind of weird programming style do you have that it's not?

Rubbish, segfaults can occur on any number of memory accesses like invalid c-style casts, references to uninitialized memory, references to freed memory, writing to read-only memory, stack overflows, etc...

Re:Obligatory

[Raenex]

I'm not the anon, but yeah, what he said. There are a myriad number of ways to screw up memory in C and C++. But if you want to look like a moron and pretend the vast majority are just null pointers, be my guest.

Re:Obligatory

[Anonymous Coward]

true, but the latter is extremely rare (at last they should be...if they are common when you write code, you need to change your programming style).

Sometimes you get to work on a decade old code base that was developed by a string of "programmers" who didn't really know what they were doing.

Re:Obligatory

[Anonymous Coward]

In Java this is a nuisance issue and usually trivial to track down, a typical example being you forgot to check for null when you pulled something out of a collection or similar.

Yup, same with C, they're pretty trivial to track down. But hey, you started with the name calling, do you want me to call you a moron?

No, quite clearly you do not have much real world programming experience. In Java it is as simple as breaking on unhandled exceptions in the debugger and it will throw a null pointer exception even on a release build, in C a seg fault does not throw an exception so how do you handle it if the memory has already been freed or it was unintialized or it was a bad cast? You see seg faults in C code are most often caused by things other than dereferencing a null pointer which makes them difficult to track down.

If you're running a release build you're pretty boned, if you run a debug build it is easier to catch some seg fault causes depending on the compiler (it may init all memory to 0 initially and freed memory to 0xfeeefeee in debug mode but you still won't just get an exception) but buffer overflows and invalid casts are still difficult to detect.

Re:Obligatory

[Forever Wondering]

For example,

        Circle * foo() {

                Circle c1(5);

                Circle c2(10);

                return biggestCircle(&c1,&c2);

        }

We know that would be invalid, but a C++ compiler wouldn't see any problem. The Rust compiler, on the other hand, can see that the lifetime of the return object of biggestCircle can be no longer than the lifetime of either parameter.

If Circle is a non-trivial struct (e.g. has 50 elements in it), passing by reference might be done for efficiency [e.g. biggestCircle args are "const Circle *"].

A compiler shouldn't make an assumption because biggestCircle might be defined in a separate .cc file and might clone/dup its return value from its arguments or a combination of arguments. The invocation might be:
    x = foo(); ...
    free(x);

Or biggestCircle might return something only obliquely related to c1/c2. biggestCircle might compare c1/c2 and get the max, but then do a search within "the global list of geometric objects" looking for a match to the max value and return the global/persistent value [which would live on beyond the outer return].

Rust would squash this even though it's perfectly valid [and desired].

Re:Obligatory

[phantomfive]

So.... what are you doing that you mess up memory so much when you program in C and C++? I'm really curious.

Re:Obligatory

[Anonymous Coward]

Did you get to the Option type in the docs? You can use it the same way you could use a nullable pointer, and you can't sidestep checking for None in that case.

Basically, instead of "x = mayfail(args); if(x == nullptr) { error("Whoops"); } else { use(x); }", you'd write something like "match mayfail(args) { None => panic!("Whoops"), Some(x) => use(x) };", except you can miss a nullptr check, but you *can't* get to use an option without matching on it first.

Or you could say "let x = mayfail(args).expect("Whoops"); use(x)" in this case.

Or "let x = mayfail(args).or_else(|| alternative_mayfail(args)).expect("No usable alternatives");"

Or "let x = mayfail(args).or_else(|| alternative_mayfail(args)).unwrap_or(some_default_value);"

You can't easily get an actual null pointer from inside the language too. You have to use raw pointers for that, which are a different type from usual Rust references and can't be dereferenced outside of "unsafe { }" block.

Re:Obligatory

[Anonymous Coward]

No, I think it's expect, because it's repeated all over the place in this section and the next section.

There is a type called Option that can be Some(x) or None, where 'x' is some value. Option has a method called 'unwrap' that returns the value inside it, or, in case of a 'None', it crashes the current thread. The 'expect' method works the same, but it will print the message you pass it before crashing, so it is easier to figure out what happened. Because all this crashing is annoying you can use match or if let to get the value out of an Option, which is really the preferred way to do it, but 'unwrap' can be convenient when you don't feel like handling errors or know for a fact that the Option will contain a value.

Because the NULL is used as a flag, containing logic. If people can't use the NULL flag, they will use a separate variable to have the same meaning as NULL previously had. However in those cases, the seg-fault (or NPE) won't be around to let you know that something is wrong, the program will merely continue executing poor logic which hopefully you notice.

If you want this functionality you use Option. It's makes your intent explicit and you *cannot* forget to check for NULL.

Re:Obligatory

[aberglas]

Yes, Java does not let you take the address of a local variable. And it is no big deal. C# does in a controlled manner for parameters only, so is safe and efficient. Both have excellent whole program JIT optimizers that will do powerful things. Just because you write

    f = new Foo()

Does not necessarily mean that anything actually gets put on the heap if Java/C# can see that it does not need to be. C# is better because it allows structs inline, but even this lack has not been an issue in Java.

It is an old result that properly written garbage collection is often faster than explicit malloc/frees. The bigger issue is that garbage collected languages tend to produce more garbage because there is no need to write code that collects it.

In a few benchmarks that I have done over the years Lisp and Java have proven to be faster than C. Usually for odd reasons like a programmer forgetting to inline a critical function. When fixed they run withing 20%.

But this is slashdot. So any programming language that does not permit
    while (*x++ !=0)
is clearly grossly inefficient. Of course it is important to be able to increment a pointer to arbitrary memory. And there will always be a null eventually...

Re:Obligatory

[Anonymous Coward]

Rust doesn't make such assumptions. References have (usually implicit) lifetime parameter attached, and when compiler can't deduce one, it asks for clarification. It's also done in the defining module, not in the calling one.

Signature "fn biggestCircle(a: &Circle, b: &Circle) -> &Circle" would give a compiler error because it wouldn't be able to guess which one of inputs define the lifetime of ouput.

Returning one of two references would have type "fn biggestCircle(a: &'life Circle, b: &'life Circle) -> &'life Circle", where 'life is arbitrary name and only shows that no mentioned references outlive others.

Returning a reference to global would be "fn biggestCircle(a: &Circle, b: &Circle) -> &'static Circle", where 'static is a special lifetime for global objects.

Returning a duplicate would be something like "fn biggestCircle(a: &Circle, b: &Circle) -> Box" or one of the other heap pointer types.

TL;DR: You can do all the same things, but you have to be more explicit if your intentions are ambiguous.

Re:Obligatory

[Anonymous Coward]

So.... what are you doing that you mess up memory so much when you program in C and C++? I'm really curious.

So much? No it occurs every so often under any of those many circumstances. I am not perfect, I make mistakes just like you do and I dont expect other code authors to be faultless and that they make no mistakes either.

But that is neither here nor there, the point is that your claim that 99.999% of seg faults are null pointer errors is false and I would be wondering how exactly it is that you can manage to avoid invalid c-style casts, references to uninitialized memory, references to freed memory, writing to read-only memory, stack overflows, etc... yet you find the issue of null pointers so difficult. Why is that? What is it about null pointers that you struggle with so much more than the other causes of seg faults?

Re:Obligatory

[phantomfive]

I don't find the issues of null pointers 'difficult,' but they happen significantly more often than the other reasons for seg faults. They aren't really a problem, just a symptom of a deeper problem, and with a core dump, the actual problem is easy to find. Similarly, stack overflows aren't a common problem either. In C if it happens it's usually because you have an infinite recursion loop. In Java, because the default stack size is so small, they happen fairly often even when the recursion is correct. So make the stack bigger, no problem.

I would be wondering how exactly it is that you can manage to avoid invalid c-style casts, references to uninitialized memory, references to freed memory, writing to read-only memory, stack overflows,

references to uninitialized memory: the compiler catches this one.
references to freed memory: This one actually is a serious problem if it happens. I set all pointers to NULL after freeing them, you can do it easily with a macro.
writing to read-only memory: This one isn't a huge problem either: if you do it crashes immediately and you fix it. But the only read-only memory I can think of in a typical C program are string constants. I don't actually remember trying to write to a string constant since my college days. I don't know, I just don't do it.
invalid c-style casts: This is another one....what kind of people are casting tree objects to stack objects? I just don't understand what these people are thinking. I've never had a problem with this, so I don't have any specific technique for avoiding it, other than generally writing clean, understandable, readable code.

Re:Obligatory

[Anonymous Coward]

I don't find the issues of null pointers 'difficult,' but they happen significantly more often than the other reasons for seg faults.

To you maybe, but perhaps that's due to lack of experience and limited exposure and/or use of other codebases. Different programmers work in different ways at different levels.

references to uninitialized memory: the compiler catches this one.

No, not always, particularly if you have something like the following very simple example:
int f(int v)
{
int x;
if( v ) x=1;
return x;
}

You will find many compilers dont catch this and those that do require additional switches to catch it and it may be a false positive.

references to freed memory: This one actually is a serious problem if it happens. I set all pointers to NULL after freeing them, you can do it easily with a macro.

Again, if you limit the scope to only code written by you, however experienced developers work with other developers and with codebases written by other developers.

writing to read-only memory: This one isn't a huge problem either: if you do it crashes immediately and you fix it.

If that crash happens every time and you get it on your developer system. This is another demonstration of lack of experience, not all bugs are deterministic and not all bugs will manifest on developer machines during development.

But the only read-only memory I can think of in a typical C program are string constants.

It doesn't take much thought to realize this can happen quite easily in any pointer arithmetic scenario.

invalid c-style casts: This is another one....what kind of people are casting tree objects to stack objects?

The sort of situation where your code doesn't have access to the derived class implementation that may be passed to it and only requires base class functionality, again very common when you are dealing with different libraries particularly when they are authored by different people.

The lack of imagination is what demonstrates your inexperience, the attitude of "I have never seen it" or "I cant think of way that would happen" are hallmarks of having not been exposed to much real code. Sure you can't think of a way that it would manifest or you havent seen it, but that doesnt mean it doesnt happen, There are lots of things that I havent seen but I wont pretend I have the experience to dismiss them as impossible or come up with some random statistic about them.

Re:Obligatory

[phantomfive]

ok, you're smarter than me, I guess.
But my code is better than yours.

Re:Obligatory

[Anonymous Coward]

ok, you're smarter than me, I guess.

I would say perhaps more experienced but then only in this area. I have very little experience in for example Java so if you were to ask me similar questions about Java-specific best practices and code quality or its garbage collection mechanisms I would probably not be able to answer them.

But my code is better than yours.

My point is more about other people's code. Your suggestions about things like NULLing references when you free the memory are fine in your code and are good practice but that doesn't stop somebody else from taking a reference to that block of memory and accessing it after you have deleted it, your reference is NULL but theirs isn't. Or flipping this example, once you start more heavily interacting with other peoples' code you'll start to realize that when you interact with something you didn't create it can indeed be deleted right out from under you and all your best practices won't help when a 3rd party library does something you didn't expect.

Re:Obligatory

[SkepticalEmpiricist]

> Rust would squash this even though it's perfectly valid [and desired].

It wouldn't. It depends on the implementation of biggestCircle. I should have expanded on this, but the simple version of biggestCircle would simply return one of its arguments, the pointer-to-Circle which has the biggest area. (I'm writing my examples in C++, I would make a mistake if I tried to write it in Rust):

        Circle * biggestCircle(Circle * p, Circle * q) {
                return (p->getArea() > q->getArea()) ? p : q;
        }

With this implementation, the lifetime or the return value is (to be conservative) the shortest lifetime of the two inputs. The implementation of foo() that I gave is therefore incorrect as its return value tries to live longer than the local variables c1 c2. The implementation of foo() is dissallowed therefore - and it would be invalid to do the following as it would attempt to free() something on the stack, totally unacceptable in any language:

        Circle* x = foo(); // x points to stack space that is no longer valid, as foo() has returned. We can't even read from this pointer
        free(x); // and this is undefined behaviour

> Or biggestCircle might return something only obliquely related to c1/c2. ...

True. You're saying that biggestCircle might be implemented differently and might return a pointer to an object with a (provably) longer lifetime. That's no problem to Rust. The compiler can see the implementation of biggestCircle and be as relaxed or as fussy as necessary, depending on the implementation of biggestCircle and also depending on how biggestCircle is called from other functions.

Re:Obligatory

[SkepticalEmpiricist]

> But this is slashdot.

Yes. I made a simple, non-offensive, true, observation about Java, and you assumed that I wanted to start a flamewar on the topic! There's is nothing more predictable on programming websites than a childish Java-vs-C++ flameware.

> Yes, Java does not let you take the address of a local variable.

You agree that I told the truth. I didn't say Java was *slow*, nor did I imply that java runtimes hadn't developed certain optimizations. We *could* have an argument about speed, but I'm confident I won't hear an argument in favour of Java that I haven't heard a thousand times already. (And you feel the same regarding arguments in favour of C++, I'm sure!)

Yes, I admit my original comment did demonstrate that I disagreed with the decisions in Java. I shouldn't have done that. But arguing about this is irrelevant for Rust. And, crucially, I didn't say that the Java design made it slower. I just said that Rust and C++ are quite similar and therefore the performance will be no worse than C++ (whenever we get really well-tuned Rust compilers).

Looking again at my original comment, this is the only time I mentioned Java:

> [Java took a very different approach to the problem of "how to we get rid of segfaults and memory corruption". Java basically banned all interesting use of the stack, forcing everything onto the heap, and barred developers from using RAII. Nowadays, with more advanced compilers able to do advanced lifetime analysis, we can reconsider languages - such as Rust - that take a less draconian approach.]

I probably shouldn't have used loaded terms such as "interesting use", "forcing" and "draconian". But basically, I was quite neutral and I said nothing about speed.
I didn't say anything about which language had taken the "correct" or "fastest" approach. I simply observed that various languages had taken different approaches. In the context of a new language called Rust (remember, we are talking about Rust in this thread) I thought it would be useful to compare the approach in Rust to the approach in two languages that are much more popular at the moment - Java and C++. I was being informative, not argumentative.

C, and "old" C++, has big problems regarding safety and the lifetime of variables. Modern C++ has greatly improved things (value semantics, move semantics, unique_ptr, shared_ptr). Java went back and took a very different approach. It defined a much smaller language. For C++ developers, the absence of destructors is probably the single most definitive aspect of Java -- for good or bad, that is what makes Java Java.

This is a discussion about Rust. My observation was simply that Rust is basically about making C++-style programming work "as-is". A C++ developer moving to Java would have to learn to program very differently, for example they would be required to manually free non-trivial resources in Java - database connections, especially data written to the connection that hasn't been flush()ed - whereas Rust allows C++ developers to keeping writing C++-style code (including relying on destructors to automatically free their resources for them) and get lots more safety for free.

Re:Obligatory

[tehcyder]

Probably because this is a topic that deserves actual commentary and discussion and not cheap jokes.

Yeah let's leave the jokes to posts about non serious topics like the Charlie Hebdo shootings.

Re:Obligatory

[Anonymous Coward]

And if you're actually looking for stability, avoid a language that is so focused on versioning: it's a sign they're not going to be stable

What a pointless generalization of a bullshit principle that you just pulled out of your ass.

I mean seriously, you actually consider this sage advice? Avoid languages that handle versioning well? Do you think versioning isn't an issue? Have you ever worked in a team of more than one? Jesus.

that's a warning right there: a package manager should not be integrated into the language

What the fuck are you talking about? A warning? Lots of languages have package systems built in. What's it a warning about? That using packages will be easy? Shit, better nuke it from orbit, it's the only way to be safe.

Re:Obligatory

[phantomfive]

My point is more about other people's code. Your suggestions about things like NULLing references when you free the memory are fine in your code and are good practice but that doesn't stop somebody else from taking a reference to that block of memory and accessing it after you have deleted it, your reference is NULL but theirs isn't

That's what code review is for. You teach the people you work with to be better programmers. If someone wants to write bad code, there are plenty of ways in every language. If you can't trust your coworkers, language choice is the least of your problems.

Re:Obligatory

[Anonymous Coward]

As I understand it, if you want a nullable pointer in Rust you just use Option.

For example:

fn main() {
        let mut x = 5is;
        {
                let y: Option = Some(&mut x);
                match y {
                        Some(p) => {*p = 7; },
                        None => { println!("null pointer!"); return }
                }
        }
        println!("x={}", x);
}

which as you might expect prints "x=7".

Re:Obligatory

[Anonymous Coward]

...which would have looked a lot better if the angle brackets hadn't all been stripped. fn main() { let mut x = 5is; { let y: Option<&mut isize> = Some(&mut x); match y { Some(p) => {*p = 7; }, None => { println!("null pointer!"); return } } } println!("x={}", x); }

Re:Obligatory

[david_thornley]

If you're using modern C++ in a halfway intelligent manner, none of this happens. Of course, some people are using it in a dumb manner.

A raw pointer does not own anything. It should never be deleted or freed or anything like that.

If memory is owned by one part of the program, it is owned by a unique_ptr. If it's a matter of shared ownership, it's owned by (possibly multiple) shared_ptr.

Follow these rules (enforce with code review) and most of your memory issues will simply go away.

Re:Obligatory

[Anonymous Coward]

That's what code review is for. You teach the people you work with to be better programmers. If someone wants to write bad code, there are plenty of ways in every language. If you can't trust your coworkers, language choice is the least of your problems.

And how exactly are you going to do that when you are working with ancient code, 3rd party code and/or binaries? You will need to find those bugs and fix them, as I said there are many ways seg faults can and do occur and when you work with other peoples' code you will learn that and encounter them. Not everything you use will be heavily documented and written with best practices safely in C++11.

Re:Obligatory

[Anonymous Coward]

You can pontificate all you like about how things should be done, that is indeed how I work and how everybody should work but until everybody does work like that the claim that 99.999% of seg faults are null pointer accesses is rubbish. And you're kidding yourself if you actually believe that all the code out there has been written with those best practices.

It may be that you misunderstood: I'm not saying it can't be done or shouldn't be done what I'm saying is that it by and large has not been done so many existing programs and libraries do indeed seg fault for reasons other that null pointer accesses.

Re:Obligatory

[phantomfive]

And how exactly are you going to do that when you are working with ancient code, 3rd party code and/or binaries?

So far I haven't had a problem with this either in ancient code, or third party code. If it's ancient enough, then it's probably been debugged. As far as third party code, if it hasn't been debugged, then that's a strong warning not to use it.

As for third party binaries.....those tend to be pain in no matter what language you use, unless they have extremely good documentation, which is rare. Even when using the Java standard libraries (which are) well documented, it's occasionally convenient to step into the source so you can figure out what is actually going on when the docs are confusing.

Re:Obligatory

[phantomfive]

btw, it's even if you aren't setting your pointers to null after freeing them, dangling pointers aren't a common problem. Someone on Slashdot once said that it's the programmatic equivalent of tripping and falling on your face. Sure, sometimes it happens, but it's rare. So it's not like you have to be a super-programmer or something, you just have to be average.

Re:Obligatory

[aberglas]

eh, don't take it so personally. This is Slash Dot.

But it is true that many of the criticisms of Java-like languages are based on old misunderstandings. (I am an old Lisp guy.)

Certainly there are idiot decisions in the design of Java specifically. Such as that strings require Two objects on the heap each. And are UTF-16. Not being able to share pure coded. And the c# structs are good. But overall there is not the performance penalty that is claimed. I have even worked on real time Lisp systems -- just made sure no garbage collection was needed during the real time part.

My guess is that about 90% of "system programming" could be made in a Java like language. The old Lisp machines had their O/S written in Lisp on hardware that had to be run efficiently.

No exceptions are a real killer for me. Yes C++ got them wrong but having a good quarter of the code testing for exceptions (probably badly) is not OK.

As to taming threading, that part of Rust could be much more interesting. But I did not understand it from the description. My personal preference is for independent processes, with only copy semantics for sharing. One of the worst things about Java is that it makes process creation expensive, and so kills this approach. But a partitioned memory space might be good.

Anthony

Re:Obligatory

[david_thornley]

The code here is written that way (we made heavy use of auto_ptr and boost::shared_ptr early on). I can't speak for all the outside code.

It is possible to run a shop with good-quality code.

Re:Obligatory

[IamTheRealMike]

GC tuning can do a lot, but yes, huge heaps where the GC cannot keep up with the rate of garbage requires a full stop the world collection. However, if your application is really keeping a 15 gigabyte working set, I suspect you'd hit problems with fragmentation and memory leaks using something like Rust long before scaling to such sizes.

Re:Obligatory

[phantomfive]

However, if your application is really keeping a 15 gigabyte working set

I've heard of this problem most often in ad servers, where everyone wants millisecond latency, so they cache as much as possible in RAM, and write the results to the database after the response has been sent.

But lets think of a typical client/server scenario. A request comes in, you start a thread (or get it from a pool), allocate a few objects, send a response, then you're done. If you're getting thousands of requests a minute, then you can have a lot of objects allocated at any given time.

How would you handle the situation in Rust? By allocating everything on the stack of each thread, instead of the heap, you don't have to worry about fragmentation at all. And in fact, I have seen large programs in C that only use on or two heap allocations in the entire program. As a side benefit, this also eliminates memory leaks.

So...

[Njorthbiatr]

I always heard that Rust was like a 3D printed gun. Nifty, if they can ever get it to work.

Re:So...

[rwa2]

Eh, I'll try it when they find a way to finally reintroduce female characters without it turning into some misogynistic sausage-fest.
~ censor.nudity false

http://www.penny-arcade.com/co...

Re:So...

[Anonymous Coward]

I don't think you understand what 'misogynistic' means. Rust is a survival game where the modern society propping up (among other things) social equality has broken down.

Quit looking for reasons to play a victim (or a knight for one).

Re:So...

[Anonymous Coward]

Eh, I'll try it when they find a way to finally reintroduce female characters without it turning into some misogynistic sausage-fest.
~ censor.nudity false

http://www.penny-arcade.com/co...

What about "Rust PROGRAMMING LANGUAGE" was so difficult to understand? Did you even read past the first word of the title?

Re:So...

[c0d3g33k]

Eh, I'll try it when they find a way to finally reintroduce female characters without it turning into some misogynistic sausage-fest.
~ censor.nudity false

http://www.penny-arcade.com/co...

What about "Rust PROGRAMMING LANGUAGE" was so difficult to understand? Did you even read past the first word of the title?

Thanks for noticing. That was deliberate. My attempt to hold back the rising tide of unclear and uninformative titles and summaries on /. Too bad it wasn't successful.

Or perhaps we're both the victims of *whoosh* and the folks above were just having some fun. :-)

Not dependently type

[Anonymous Coward]

Rust's raison d'etre is fast but safe programming. It seeks to achieve this by expanding the type system with the different pointer types owned, borrowed, and garbage collected, as well as explicitly unsafe sections of code.

Rust does not however attempt to address array length issues via such type level mechanisms. Instead, they use compile time lengths for arrays and offer for slices for arrays with run-time lengths. That's okay, but it ignores swaths of optimizations.

Ideally, you want a fully dependently typed language like Idris for this because dependent types let you tell the compiler to prove at compile time that two arrays must have the same size.

Idris itself is a research language that doesn't currently worry about speed, but one research topic they're exploring is uniqueness types, which hopefully should provide the "right" abstraction for Rust's pointer types.

Anyways, I sincerely hope that Rust eventually kills off the dumb C style languages like Go, but it's not the last word on fast but safe programming.

Re:Not dependently type

[MichaelSmith]

But with python and javascript being so dominant we are headed in a totally different direction for the bulk of our applications.

Re:Not dependently type

[TheRaven64]

for this because dependent types let you tell the compiler to prove at compile time that two arrays must have the same size.

I can think of very few optimisations where knowing this helps. Knowing exactly what the sizes of the two arrays are helps with various forms of vectorisation (especially if you also know their alignment). Knowing that two arrays don't alias is very useful for several kinds of optimisation. Knowing that they're the same length? Not so much.

Re:Not dependently type

[c0d3g33k]

But with python and javascript being so dominant we are headed in a totally different direction for the bulk of our applications.

I wouldn't bet on that horse staying in the lead forever (well, horses plural). Those of us with long enough memories remember when this wasn't true. Here's a thought experiment: How did they get dominant in the first place, since at one time they were new and different? Things change and improve over time, and that's a good thing. Besides, Python and JS developers aren't necessarily the target audience, though there may be some overlap between them and potential Rust developers. For some reason "The Blind Men and the Elephant" comes to mind, and the term "tunnel vision" as well. :-)

Re:Not dependently type

[drewm19801927]

Right now unless you use an "unsafe" block, all array accesses are bounds checked at runtime in rust. This isn't as big an overhead as you'd think thanks to branch prediction, etc... but it is still there. Also, it would be nice to be able to write a dot product function that is generic on the length of the vectors, but the lengths are strictly checked at compile time. So not a huge deal, but it would be nice to have someday soon.

Re:Not dependently type

[TheRaven64]

Existing compilers can handle that. It was a big focus of research for Java compilers 20 years ago, now it's a solved problem. You don't need to know that the sizes of two arrays are the same. Performing LICM on bounds checks is very common, and can sometimes be done by the language front end.

I have a student doing a miniproject (coursework for the MPhil compilers course, not his MPhil project) to implement this for Julia so that it can perform polyhedral loop next optimisations in code that's bounds checked. The basic approach is very simple: you hoist the bounds checks out and insert a single check for the largest bound and a branch on the result. If that check passes, you jump to the original loop, otherwise you fall through to a clone of the loop with all bounds checks removed. The compiler can optimise this aggressively, because it has few branches in it. You statically predict that branch as not-taken and ensure that the cold path (where a bounds check will fail - you're going to be doing expensive and slow things on that path anyway, so you don't care if it's slow) is emitted somewhere where it won't pollute your cache (you can even outline it as a new function and put it on a different page so you it won't be pulled from disk unless you hit it).

The only time that this is a problem is if another thread is able to change the length of the array. Rust makes it easy to statically check that this is not going to happen. Changing a language to make life easier for compilers based on 20-year-old designs is never something that I'd recommend.

Re:Not dependently type

[MichaelSmith]

How did they get dominant in the first place

Less work to do up front makes it easy to get started. Not your problem if a 100000 line code base is unmaintainable down the track

Safety?

[Anonymous Coward]

After a quick look at the language, it's certainly not something I'd use for safety. I'll stay with Ada, thank you.

Re:Safety?

[phantomfive]

Why? I think it's great that you prefer ADA, but why?

Re: Safety?

[Anonymous Coward]

Why? Incidentally I heard about a project where the produced the on-board software in both Ada and C to compare budget and bug counts. Turned out the C programmers spent more time testing, and less on implementation. The bug count and budget ended up the same.

Back to the topic. What part of Ada compared to Rust makes you want to stick with Ada?

Re:Safety?

[K. S. Kyosuke]

Because it saved Ariane 5's first flight, of course. Oh, wait...

Re:Safety?

[oneeyed2]

Readability ?

I'm not a professional programmer but Ada always seemed to me much more readable than say C, which is definitely an advantage for projects you had to maintain long-term.

Re: Safety?

[Anonymous Coward]

Having maintained both large C and Ada projects, I can tell you thar this is definitely not the case.

Re:Safety?

[Anonymous Coward]

because that error just couldn't have been made in any other language. Clearly Shit In Shit Out only applies to Ada. Oh, wait.

Re:Safety?

[TheRaven64]

Ada is not intrinsically more readable than C, but places that still use Ada tend to be places with code review cultures that are deeply ingrained in their workflow. This tends to lead to more readable code.

Re:Safety?

[phantomfive]

because that error just couldn't have been made in any other language.

Well, actually, yeah. It was caused by an overflow error down-converting an int. The list of languages that error couldn't have been done in is long, Perl, Python, Erlang, Javascript.......

Re:Safety?

[William Baric]

For example, and maybe I'm wrong, the language doesn't force the programmer to declare variables outside of the code (in fact it looks like the language allows the declaration of a variable anywhere in the code) and it doesn't force the programmer to specify the type of a variable when declaring it (a quote from the documentation : "Variables can be type annotated when declared. However, in most cases, the compiler will be able to infer the type of the variable from the context, heavily reducing the annotation burden"). That kind of thing is an open door for sloppy programming.

What irks me the most is the "heavily reducing the annotation burden". For me, that should never be a goal with a language whose objective is safety.

Re:Safety?

[William Baric]

Ada doesn't normally allow that error either. There are things like "unchecked_conversion" which allows the programmer to break language safety, but they are always explicit.

Re:Safety?

[phantomfive]

C#, Scala, and (the latest version of) C++ have similar implicitly-typed variables, so I do have some practical experience using them. If the compiler can figure out what type it is, then you don't need to write the whole type name. If the compiler can't figure it out, then you need to write it.

In my experience using this, it's makes a lot of sense in declarations like "var s = new String()." No need to write String twice, it saves some time, etc (though let's be honest, it's not a heavy annotation burden).

It becomes hard to read sometimes when a method returns an object, like "var x = math.InterpolateReadable()" and you can't remember if the method returns a String or a double. Then you have to look at the method definition to figure it out.

It becomes a crutch in C++ when the type returned by a method is a very complex mix of templates, and you can't even figure out what type your variable should be. In that case it makes your life easier, but I think your final two sentences also apply.

Re:Safety?

[Anonymous Coward]

The type inference is actually really useful. You can do things like:

use std::default::Default;
let mut map = std::collections::HashMap::new();
map.insert(Default::default(), false);
map.insert(5u16, Default::default());

The compiler will figure out that `map` is of the type std::collections::HashMap<u16, bool>, and which instances of Default to use.. It's still strongly typed, so if you try to insert, say, a string or some other type it will complain. Type inference is limited to inside function bodies, so you always have to explicitly supply the types of function arguments and return types. It works really well in practice.

Re:Safety?

[ChunderDownunder]

Type inference frees one from the boilerplate of, say, Java while maintaining static typing. You still get type safety in compilation.

It's the basis of functional languages such as ocaml and haskell.

Have a read about Damasâ"Hindleyâ"Milner typing.

Re:Safety?

[Cro Magnon]

Even if a language is more readable, the programs might not be. COBOL is supposed to be readable, but I've seen plenty of COBOL programs that could rival anything in C or Perl for unreadability.

Re:Safety?

[david_thornley]

In C++, the exact type is not necessarily important, as long as it's assured to work in a certain way. For any standard (and you'll make your own work this way if you're smart) container template class c, c.begin() is an iterator that points to the first element of c (if there is one) or c.end() (if the container is empty). Similarly, c.end() is the element past the last valid one. Therefore, "for (auto i = c.begin(); i != c.end(); ++i)" loops through the elements of c no matter what c is, and "*i" anywhere in the loop is the element that i currently points to. For such a use, knowing the type of i doesn't help anything, and "auto" is quite appropriate.

I've seen recommendations to use "auto" in places I don't really approve of. For example, with "auto w = new Widget();" w is a "Widget *". If you intended it to be a Wadget, and Widget and Wadget have member functions of the same names but aren't the same thing, you can create a hard-to-find bug, while "Wadget * w = new Widget();" is a compiler error.

Re:Safety?

[phantomfive]

I've seen recommendations to use "auto" in places I don't really approve of. For example, with "auto w = new Widget();" w is a "Widget *". If you intended it to be a Wadget, and Widget and Wadget have member functions of the same names but aren't the same thing, you can create a hard-to-find bug, while "Wadget * w = new Widget();" is a compiler error.

I don't disagree with your point here, it seems to me it actually is safer to write "Widget w = new Widget()," and certainly redundancy can give you an extra check.

As the next step after that though, I ask myself, "how often does this prevent me from making a bug?" To be honest I can't remember a single time I accidentally wrote something like "Wadget w = new Widget()." So while it does make you safer, I think in practice there's not much of a difference.

Tubed Televsion Static Crackle

[bellwould]

The static charge crackling for a second or two when switching on or off a CRT Television with tubes instead of solid-state circuitry.

Re:Tubed Televsion Static Crackle

[bellwould]

oops - replied to wrong question

Self-defeating name

[Futurepower(R)]

Rust? Programmers often choose self-defeating names. Imagine going to a top manager and saying you want to program a product in Rust.

What are some of the others? Gimp is one. GNU. LaTeX is written in both English and Greek letters. There is nothing "regular" about Regular Expressions.

NetLoony Apache Server GUI and Tools. (Looney is someone who is "Extremely foolish or silly".)

pGina

Bouncy Castle cryptography

Re:Self-defeating name

[Anonymous Coward]

Gimp would be a cool name if the program didn't suck so much.

And I personally think Rust is an awesome name. Rust isn't a necessarily negative thing. In fact, it can be quite beautiful.

Re:Self-defeating name

[Anonymous Coward]

Why do you think Gimp sucks? It does the job fine. Just has a bit of a learning curve, but once you figure things out it's quite good. Maybe not as powerful as Photoshop, but powerful enough for a lot of jobs.

Re:Self-defeating name

[Anonymous Coward]

> Programmers often choose self-defeating names.
> What are some of the others?

Google
Yahoo
Mozilla
Twitter
World Wide Web

"Self-defeating" is in the eye of the beholder. Ain't nothing wrong with "rust" unless you set out to find something wrong.

Re:Self-defeating name

[Anonymous Coward]

I actually worked at a place that wouldn't let me use Bouncy Castle cryptography just because of the name. At the time we needed somthing they did that no one else did, so I just ignored them. But you are correct, people will refuese to use things JUST based on name only.

Re:Self-defeating name

[KiloByte]

Or ,"go" the language. Utterly ungooglable, and conflicts with at least three other programming languages.

(It's a name that's good for humans but useless for other reasons.)

Re:Self-defeating name

[phantomfive]

I think you gave the primary reasons there.....a bit of a learning curve, and not as powerful as Photoshop.

Re:Self-defeating name

[Tailhook]

Everyone uses "golang" due to this. It works fine.

Re:Self-defeating name

[hawguy]

Or ,"go" the language. Utterly ungooglable, and conflicts with at least three other programming languages.

(It's a name that's good for humans but useless for other reasons.)

If you think that's bad, trying searching for "IOS" for tips on managing your cisco router. You can add the "cisco" keyword, but then you lose some useful results. This is entirely Cisco's fault for licensing the name 'IOS' to Apple.

Re:Self-defeating name

[Sir_Substance]

Actually, you just gave good examples of non-self defeating names. The reason they are great is they are unique. Easy to google, easy to talk about.

Every time someone talks about rust in the crucial next two years, they are going to have to say "what do you think of rust? the language, not the game".

Every time someone who hasn't searched for it before and thus hasn't acclimatised their search bubble to finding Rust No Not The Oxidation Result I Mean The Programming Language searches for "rust" it'll be on the third page.

Re:Self-defeating name

[Anonymous Coward]

Defeatist name, eh? Well, I DO have a little Python under my belt...

Re:Self-defeating name

[Tablizer]

And you have Postgre nasal drip. "Microsoft" is also a goofy name, I would note, and that didn't seem to slow the company. It's certainly not very manly.

If you want ideas for future OSS tools, here's a free list:

http://c2.com/cgi/wiki?FutureO...

I like "GazundWidth" and "GezundHeight" myself. "OraFiss" is also cool.

Re:Self-defeating name

[tgv]

Regular expressions are named after Kleene's description of regular expressions as an "algebra of regular sets". The only way to make the strings in the language accepted by an RE longer is by use of "*", which is as regular as it can be.

Re:Self-defeating name

[Anonymous Coward]

Eh? Out of all popular languages pretty much only ones trivially googleable are Perl, PHP and Javascript, all the rest either need "language" added or are only googlable due to popularity.

I mean, seriously. An Indonesian island? A precious stone? A large snake? A speech defect? A plan or a plot? To strike heavily and repeatedly? Italian word for "stairs"? And the worst offender, simply third letter of the latin alphabet (also used as chemical symbol for carbon, roman numeral "100", average grade in education and tons of other things)?

Re: Self-defeating name

[DrXym]

Rust isn't a good name but I guess it could have been worse. At least it's not called Taint.

Re: Self-defeating name

[countach]

Most people try and avoid rust.

Re:Self-defeating name

[angel'o'sphere]

I agree, the same happened with Subversion / Subversive etc.

Re: Self-defeating name

[Anonymous Coward]

Chef, kitchen,knife, recipe, brew, puppet ...

Re:Self-defeating name

[Half-pint HAL]

To add to this, "regular" is an adjective deriving from the Latin word for a "rule". The use of "regular" as meaning "normal" is not universal in English dialects anyway.

Re:Self-defeating name

[drinkypoo]

Why do you think Gimp sucks? It does the job fine. Just has a bit of a learning curve, but once you figure things out it's quite good.

So, which nine dialogs do I have to use to accomplish everything that I can do trivially with photoshop layer effects?

Re: Self-defeating name

[Blaskowicz]

Yahoo News (I think) decided to show me a video story about Kim Jong Un not afraid of showing off himself atop a rusty submarine.

That means rust doesn't have as much a connotation of worthless trash as it used to, and/or those stupid media automated system that are based on what's "trending" are happy to show Kim Jong Un stories because people clicked on the Kim Jong Un pictures. Next time the top story was Kim Jong Un flying a plane.
I even read a story about recent discovery of remains of a secret nazi base and ended up looking at a Hitler slideshow at the bottom of the story, nice high quality pics.

So, I'm lost regarding what people think about things and what is popular. (in the twittery web 2.0/web 3.0 scene)

Re:Self-defeating name

[c0d3g33k]

Eh? Out of all popular languages pretty much only ones trivially googleable are Perl, PHP and Javascript, all the rest either need "language" added or are only googlable due to popularity.

I mean, seriously. An Indonesian island? A precious stone? A large snake? A speech defect? A plan or a plot? To strike heavily and repeatedly? Italian word for "stairs"? And the worst offender, simply third letter of the latin alphabet (also used as chemical symbol for carbon, roman numeral "100", average grade in education and tons of other things)?

Don't forget the fourth letter of the latin alphabet (also used as the first letter in three elements on the periodic table though can't rate it's own, the Roman numeral 500, a poor grade in education and tons of other things. And apparently something the girls be wantin'.)

Re:Self-defeating name

[Waffle Iron]

Names don't necessarily hold back any language. For example, having a name that's exactly the same as a below-average schoolwork grade clearly doesn't prevent you from becoming one of the most prevalent programming languages in computer history.

Re:Self-defeating name

[Anonymous Coward]

And just try Google for any of these guys: William Shakespeare; William Shakespeare; William Shakespeare; William Shakespeare; William Shakespeare. There are many many pages of irrelevant links about some long-dead playwright to plod through before getting to anything relevant to these persons.

Re:Self-defeating name

[Anonymous Coward]

And just to stay on topic, there's also the Shakespeare programming language.

Re:Self-defeating name

[Anonymous Coward]

An Indonesian island? A precious stone? A large snake? A speech defect? A plan or a plot? To strike heavily and repeatedly? Italian word for "stairs"?

So, which of these is FORTRAN or COBOL? They're both trivially googled.

Re:Self-defeating name

[Anonymous Coward]

Meanwhile "go performance" has zero results for golang, "java performance" has a full page of results. The name "go" is a whole 'nother class of stupid. It's so colossally boneheaded that people have to use "golang" to get some results where somebody thought to include that word so that it would be searchable, while missing out on many other results that are all but completely unsearchable.

Not only did the "golang" creators not learn anything of language design since 1980, they didn't learn anything about naming either. They didn't learn to draw any better either, what with that retarded potato mascot.

Re:Self-defeating name

[Anonymous Coward]

Uh, no? Concatenation of two regular expressions is a regular expression, and this will (unless one of the two is epsilon, the empty string) make the strings accepted by the language longer.

Re:Self-defeating name

[vipw]

I think you're exaggerating D's success.

safety, performance and concurrency

[goombah99]

Pick 2.

Re:safety, performance and concurrency

[davester666]

OK. Swift and Ruby.

Re:safety, performance and concurrency

[swilver]

Safety and performance. Since I got performance, no need to have concurrency.

Meh...

[martin-boundary]

I'll just wait until next week, when the much more stable version 27.0 comes out.

Great!

[Anonymous Coward]

Just the other day I was remarking how few programming languages there are.

Rust is pointless because has a garbage collector

[Anonymous Coward]

A safety systems programming language sounds great but they had to ruin it by putting a garbage collector in it. This makes it useless for systems programming.

Device drivers ?

[savuporo]

Ok, if this is a systems programming language, where is the first RTOS kernel with all the necessary lowlevel bits and pieces to getting it running on a modest modren 32-bit MCU ? Say, any Cortex-M3 ? Device drivers for basics, register access ?
Because, it would be awesome to have all these theoretical safety guarantees and stuff, while programming hardware.
Is there even a cross-compiler ?

Re:Device drivers ?

[Anonymous Coward]

Once again, funding and engineers... :) Get some big company interested in those ideas and I'm sure the wheels will start turning quickly. Those are already too complex projects to be written solely by hobbyists on their leisure time.

Re:Device drivers ?

[ChunderDownunder]

Firefox OS (Boot to Gecko) has Raspberry Pi (armv6) as a porting goal.

So I imagine if the project ever evolved into BootToServo, rust on low spec ARM would be a prerequisite.

Re: Device drivers ?

[Anonymous Coward]

Google "bare metal rust"

Re:Device drivers ?

[Narishma]

http://zinc.rs/

Re: Device drivers ?

[Half-pint HAL]

Google "bare metal rust"

Oxy(disation)moron.

Re:Device drivers ?

[rmstar]

[...] Cortex-M3 ? Device drivers for basics, register access? Because, it would be awesome to have all these theoretical safety guarantees and stuff, while programming hardware.

Ada has that (google for "arm-none-eabi ada") and much, much more. Plus, it is a mature language with a fat piece of industry behind it.

This Rust language is yet another flashy thing that will not get anywhere.

Re:Device drivers ?

[c0d3g33k]

This Rust language is yet another flashy thing that will not get anywhere.

That remains to be seen. I've heard the same thing said about email, the internet, Linux, Java, the iPhone, tablets and many other things over the years. The truth is that in a viable and vibrant marketplace of ideas, many things fail but some survive, and predicting which is hard. Give it a chance to fail or succeed on its own rather than condemning it in the womb, and be glad you live in a time where people have the enthusiasm and energy to try new things. Your attitude leads to stagnation.

Re:Device drivers ?

[savuporo]

That looks actually pretty cool, thank you.

Re:Device drivers ?

[Anonymous Coward]

This Rust language is yet another flashy thing that will not get anywhere.

That remains to be seen. I've heard the same thing said about email, the internet, Linux, Java, the iPhone, tablets and many other things over the years. The truth is that in a viable and vibrant marketplace of ideas, many things fail but some survive, and predicting which is hard. Give it a chance to fail or succeed on its own rather than condemning it in the womb, and be glad you live in a time where people have the enthusiasm and energy to try new things. Your attitude leads to stagnation.

The compiler checking that Rust does is definitely something that can be backported to C, C++, Python and other languages. I also believe that experienced software developers already know about out of scope variable addresses being returned, and check for it consciously and subconsciously.

We did not become serious and skilled by birth, but from learning from our experiences.

It's about time

[hawguy]

It's about time we finally have a language that meets all of our needs, now we don't need so many different languages.

Re:It's about time

[shutdown -p now]

Rust is specifically not designed to be a "meets all your needs" language. It's a language that knows its niche well, and sticks to it.

Basically, this is programming language for systems and other low-level stuff done right. It competes primary against C++, and to a lesser extent, C, and does it really well. It's not yet another scripting language for the web or desktop GUI or some such, and it doesn't pretend to be one.

Re:It's about time

[c0d3g33k]

Rust is specifically not designed to be a "meets all your needs" language. It's a language that knows its niche well, and sticks to it.

Basically, this is programming language for systems and other low-level stuff done right. It competes primary against C++, and to a lesser extent, C, and does it really well. It's not yet another scripting language for the web or desktop GUI or some such, and it doesn't pretend to be one.

I agree with you in principle, except for the "it competes ... really well" part. That's an unfounded assertion since it hasn't actually competed in the real world yet. Because, you know, not being finished yet. The true challenges are still in the future. It seems to have successfully passed the early "get people interested" stage, which is nice, but there are a bunch more hurdles to be surmounted before I would call it even a marginal success. Let's wait and see.

Re:Rust is pointless because has a garbage collect

[Jeeeb]

A safety systems programming language sounds great but they had to ruin it by putting a garbage collector in it. This makes it useless for systems programming.

No they didn't: http://doc.rust-lang.org/compl...

Another programming language...

[Anonymous Coward]

... just what the world needs.

Most will want to wait for 1.0, or at least beta

[drewm19801927]

I have been using rust during development and eagerly awaited this release. Please be warned, however, that rust has a steeper learning curve than most languages, and be especially warned that the language has been changing faster than the documentation can keep up during the push towards alpha. Last I checked, even things as core as the names of the integer types differ between the documentation and the implementation. I want people to get excited about the language, but I don't want anyone to get an unnecessarily bad initial impression!

Rust in an interesting language

[complete loony]

I'm not completely sold on the syntax, but I find the design and runtime interesting. I'd like to find an excuse to build something with it, to see if it can live up to its potential.

I started thinking about how I would design a language recently, then I came across rust, and I saw quite a lot of the same conclusions I came to myself. Abstract classes, multiple inheritance, Interfaces with versioning, combining 3rd party libraries... With rust, you define the layout of memory without inheritance, and the implementation of interfaces for types without defining the layout of memory. Neatly side-stepping some of the issues faced by other languages.

All resources and object lifetimes are managed, avoiding .NET's IDisposable. You can combine structures together, which can exist exclusively on the stack, avoiding the "everything is an object on the heap" problem that Java seems to fall into.

Since there's no NULL, there's no NullPointerException. There's no unchecked exceptions, or any exceptions at all for that matter. Though, I might prefer to have them. Sure, there's the try! macro. But that's just syntactic sugar for checking the return code of every function.

Re:Rust is pointless because has a garbage collect

[angel'o'sphere]

Frist of all it does not rely on GC and secondly: why should that be an issue for system programming?

Re:Rust is pointless because has a garbage collect

[gnupun]

From your link:

1.8 No constructors

Functions can serve the same purpose as constructors without adding any language complexity.

How many good OO language exist without constructors? Maybe only javascript. This seems like a terrible decision.

Re:Most will want to wait for 1.0, or at least bet

[drinkypoo]

I want people to get excited about the language, but I don't want anyone to get an unnecessarily bad initial impression!

They're not going to do that if the devs can't even bother to keep the documentation up-to-date. It's absolutely critical to the health of a project that the documentation both exist and be correct. Until that happens, people are going to take the "effort" for what it is, an unprofessional joke. At least C++ is professional comedy.

I've Been Using Rust for A Number of Months

[Anonymous Coward]

It's called "Swift."*

*Not to be confused with The Swift Parallel Scripting Language.

Re:I've Been Using Rust for A Number of Months

[Anonymous Coward]

Har har. But in all seriousness, if you can't tell the difference then you probably shouldn't pretend to be a programmer.

Re:I've Been Using Rust for A Number of Months

[Anonymous Coward]

You can call me whatever you want. It's a free world.

I'll pretend to be a cat wearing a birthday hat.

Re:Most will want to wait for 1.0, or at least bet

[Anonymous Coward]

I agree. I've gone through the guide twice in the past and both times I ran into several example code snippits that failed to actually compile/run.
That combined with the ugly syntax I think the language is a joke. I'll stick with Haskell.

Re:Most will want to wait for 1.0, or at least bet

[Anonymous Coward]

The documentation will be great in short order; the doc writer has been doing a great job. The stuff I am talking about was changed literally only a few days ago.

Re:Rust is pointless because has a garbage collect

[c0d3g33k]

From your link:

1.8 No constructors

Functions can serve the same purpose as constructors without adding any language complexity.

How many good OO language exist without constructors? Maybe only javascript. This seems like a terrible decision.

Or maybe an informed one. Go and Rust -- objects without class

Besides, Rust isn't an "OO" language. It's a multi-paradigm language that supports pure-functional, concurrent-actor, imperative-procedural, and object-oriented styles. After 40+ years, a growing opinion seems to be that pure OOP isn't without its problems, and other approaches may fit development goals better. I'm not sure multi-paradigm languages are the answer (there seems to be a huge potential to be confusing, IMHO), but OOP isn't the evolutionary pinnacle of language design that the last few decades of hype would have us believe. I'm willing to give this approach a chance (and I'm always up for learning something new).

Critcisim of the OOP paradigm

(Aside: Not quite sure why, but the use of the term "paradigm" multiple times makes me feel slightly icky for some reason. Probably due to it's misuse in business jargon.)

Re:Rust is pointless because has a garbage collect

[TheRaven64]

Objective-C and Smalltalk also don't have constructors in the language, they merely have them as conventions in the standard libraries, which are adopted by most third-party code. There's no reason for constructors to be special, they're just methods that initialise the object and return a pointer / reference to it, and which (by API contract) may have undefined behaviour if used on an already initialised object.

Re:Most will want to wait for 1.0, or at least bet

[c0d3g33k]

That's a rather uninformed statement to make, given that you're referring to a rather short time period when the rate of change caused the docs to lag behind. That will be corrected soon, I'm sure. Besides, the API docs, which are generated from the code, *are* correct and have been kept up to date all along despite the rapid rate of change. So documentation exists and is correct. The GP was likely referring to the higher level docs, such as guides and tutorials, which aren't produced by "the devs".

But hey, at least you got your *zing* in, though you forgot the rimshot at the end.

Re:Rust is pointless because has a garbage collect

[Anonymous Coward]

Some people think that a garbage collector for all code is a good thing. They're morons.

Re:Most will want to wait for 1.0, or at least bet

[drewm19801927]

The "guide" and the "guides", recently merged into "the book", actually are professionally maintained by a Mozilla employee, who is doing a great job but is of course outnumbered by the rest of the devs making language changes. Among other things, "alpha" is a chance for him, not to mention writers of external libraries, to get fully caught up with the development branch before beta and eventually 1.0.

Re:Rust is pointless because has a garbage collect

[phantomfive]

The worst criticism IMO from your link is the "study by Potok et al. has shown no significant difference in productivity between OOP and procedural approaches." That's really depressing.

Re:Rust is pointless because has a garbage collect

[Raenex]

(Aside: Not quite sure why, but the use of the term "paradigm" multiple times makes me feel slightly icky for some reason. Probably due to it's misuse in business jargon.)

Probably because there's no reason to use such an awkward word in the first place. In this case, notice how you fall into using "style" instead? Also, the vast majority of time, when people use "paradigm", they could replace it with the much more common and simpler word "model" or another simpler term.

Re:Most will want to wait for 1.0, or at least bet

[c0d3g33k]

Thanks. I was going to mention that there was a dedicated person (Steve Klabnik is his name, BTW - http://www.steveklabnik.com/) who was doing a great job and has just been momentarily overwhelmed. I decided it sounded too much like an excuse that "drinkypoo" wouldn't find convincing, given that "drinkypoo" (*snicker*) clearly has high standards of professionalism. So I decided to mention the API docs instead, which have been most helpful when sorting out code breakage due a change in the nightly version of the compiler. Actually, much of the time, the extremely clear error messages emitted by the compiler have been enough to make the correct changes to fix errors, which is almost better than good documentation. The latter is more useful in understanding why the code was incorrect, even if the compiler message is often enough to correct the problem.

Re:Rust is pointless because has a garbage collect

[c0d3g33k]

(Aside: Not quite sure why, but the use of the term "paradigm" multiple times makes me feel slightly icky for some reason. Probably due to it's misuse in business jargon.)

Probably because there's no reason to use such an awkward word in the first place. In this case, notice how you fall into using "style" instead? Also, the vast majority of time, when people use "paradigm", they could replace it with the much more common and simpler word "model" or another simpler term.

Actually I looked it up and based on the definition of the word ("a distinct concept or thought pattern"), its use in the given context seemed appropriate, so I kept it in. "Style" seems to imply something more arbitrary, while "model" is a way of describing reality using simplified concepts (or a plastic thing I used to build as a boy, or something I found appealing as a teenager). Paradigm seems right.

Re:Rust is pointless because has a garbage collect

[Raenex]

And yet you instinctively fell into "style" later on, and nothing was lost by using that word. Instead, you gained in clarity of communication. You could also say "model" and it would have the same meaning. "Paradigm" is a fancy buzzword.

Re:Rust is pointless because has a garbage collect

[c0d3g33k]

You're being pedantic. (And I'm about to follow suit.) Paradigm *isn't* a fancy buzzword - it is a word with a clear definition that has been in use since the 15th century. It's fame as a buzzword comes from imprecise overuse during the last decade or so. The word itself is fine.

Here's another definition, this time from Merriam-Webster: "a theory or a group of ideas about how something should be done, made, or thought about". That seems to fit the discussion pretty well when referring to different ways to approach the decidely non-trivial task of defining at a fundamental and conceptual level how a programming language works.

You mention "style". I don't think it's really equivalent to paradigm, though it could apply to variations of a paradigm. Style involves the details in how you implement a paradigm - it's not a paradigm itself. Merriam-Webster supports this assertion: "a particular form or design of something" and "a particular way in which something is done, created, or performed" (emphasis mine).

But I grow tired of this nitpicky exercise. You may have the last word if you wish (preferably with concrete examples of why you believe you are correct rather than vague generalizations and unfounded assertions regarding awkwardness and clarity). I've said my piece and I'm done with this. Good day.

Re:Rust is pointless because has a garbage collect

[Raenex]

You're being pedantic.

I'm not. It's a garbage word. There are plenty of garbage words that stick around for no reason other than that people like to use them in place of simpler words.

You mention "style".

You used the word. Why did you use it? Because it's simpler and conversational and came naturally to you. People don't generally go around using the word paradigm.

I also used the word "model". Try this: The object-oriented programming model. Gee, does that not get the point across?

And there's nothing vague about simpler words and more common words versus less common words that have come into vogue. Nobody needs a clarification when you use those simpler words. I'm willing to bet at one point you said, "What the fuck's a paradigm?"

Re:Rust is pointless because has a garbage collect

[Anonymous Coward]

It's a multi-paradigm language that supports pure-functional, concurrent-actor, imperative-procedural, and object-oriented styles.

But it doesn't support modern object-oriented style, if it lacks constructors.

After 40+ years, a growing opinion seems to be that pure OOP isn't without its problems

It's not a "growing opinion", it's a bald truth, but RAII is not one of OOP's problems, it's one of OOP's greatest contributions. Language designers can't just ignore it because it makes their compiler simpler. It's not their job to make the compiler simpler, it's their job to make the language useful.

Two things that should never be in a software...

[Anonymous Coward]

Two things that should never be in a software version together: "1.0" and "alpha". You're either a 1.0 and ready, or not.