Rust Programming Language Reaches 1.0 Alpha 161
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).
Obligatory (Score:2, Funny)
Re: (Score:1)
Probably because this is a topic that deserves actual commentary and discussion and not cheap jokes.
Re:Obligatory (Score:5, Interesting)
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: (Score:3, Informative)
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 o
Re: (Score:2)
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: (Score:2)
Re: (Score:2)
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-f
Re: (Score:2)
Re:Obligatory (Score:5, Informative)
> 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: (Score:2)
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: (Score:2)
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 t
Re: (Score:2)
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: (Score:2)
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: (Score:2)
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: (Score:2)
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: (Score:2)
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: (Score:2)
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: (Score:2)
Re: (Score:2)
Re: (Score:2)
But my code is better than yours.
Re: (Score:2)
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. [thc.org] If you can't trust your coworkers, language choice is the least of your problems.
Re: (Score:2)
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: (Score:2)
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
Re: (Score:2)
Re: (Score:2)
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: (Score:2)
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
Re: (Score:2)
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: (Score:3)
I think it's rather misleading to state that more advanced compilers have obviated the need for Java's approach.
Re: (Score:2)
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: (Score:2)
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: (Score:2)
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 y
Re: (Score:2)
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. biggestCirc
Re: (Score:2)
Re: (Score:2)
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.
So... (Score:2)
I always heard that Rust was like a 3D printed gun. Nifty, if they can ever get it to work.
Re: (Score:1)
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... [penny-arcade.com]
What about "Rust PROGRAMMING LANGUAGE" was so difficult to understand? Did you even read past the first word of the title?
Re: (Score:2)
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... [penny-arcade.com]
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 (Score:1)
Rust's raison d'etre is fast but safe programming [rust-lang.org]. It seeks to achieve this by expanding the type system with the different pointer types owned, borrowed, and garbage collected [rustbyexample.org], 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 [rustbyexample.com] for arrays with run-time lengths. That's okay, but it ignores swaths of optimizations.
Ideally, you want a fully dependent
Re: (Score:1)
But with python and javascript being so dominant we are headed in a totally different direction for the bulk of our applications.
Re: (Score:2)
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
Re: (Score:2)
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, performance and concurrency (Score:2)
Pick 2.
Re: (Score:2)
Safety and performance. Since I got performance, no need to have concurrency.
Re: (Score:2)
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: (Score:3)
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
Meh... (Score:2)
Great! (Score:5, Funny)
Just the other day I was remarking how few programming languages there are.
Device drivers ? (Score:2)
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: (Score:2)
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: (Score:3, Informative)
http://zinc.rs/ [zinc.rs]
Re: (Score:2)
That looks actually pretty cool, thank you.
Re: (Score:2)
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 ? (Score:5, Interesting)
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: (Score:2)
Google "bare metal rust"
Oxy(disation)moron.
It's about time (Score:2)
It's about time we finally have a language that meets all of our needs [xkcd.com], now we don't need so many different languages.
Re: (Score:3)
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: (Score:2)
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.
Most will want to wait for 1.0, or at least beta (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
Re: (Score:2)
Thanks. I was going to mention that there was a dedicated person (Steve Klabnik is his name, BTW - http://www.steveklabnik.com/ [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
Rust in an interesting language (Score:5, Interesting)
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: (Score:1)
Re: (Score:1)
> 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: (Score:1)
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: (Score:2)
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 (Score:4, Informative)
Re: (Score:2)
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: (Score:2)
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: (Score:2)
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: (Score:2)
Re: Self-defeating name (Score:2)
Re: (Score:2)
I agree, the same happened with Subversion / Subversive etc.
Re: (Score:2)
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: (Score:1)
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: (Score:3)
Re: (Score:2)
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 (Score:2)
Most people try and avoid rust.
Re: (Score:2)
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 bas
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
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: (Score:2)
Re: (Score:2)
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: (Score:2)
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
Re: (Score:2)
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" anyw
Re: (Score:2)
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.
Re: (Score:3)
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:Rust is pointless because has a garbage collect (Score:4, Informative)
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... [rust-lang.org]
Re: (Score:2)
From your link:
How many good OO language exist without constructors? Maybe only javascript. This seems like a terrible decision.
Re:Rust is pointless because has a garbage collect (Score:4, Insightful)
From your link:
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 [lwn.net]
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 [wikipedia.org]
(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: (Score:3)
Re: (Score:2)
(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: (Score:2)
(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: (Score:2)
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: (Score:2)
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
Re: (Score:2)
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
Re:Rust is pointless because has a garbage collect (Score:4, Insightful)
Re: (Score:2)
Frist of all it does not rely on GC and secondly: why should that be an issue for system programming?