Rust certainly isn't one of those languages where you can just pick it up, play with it for a day implementing an algorithm in it to get the feel of it and learn 'the complicated stuff' later.
Other languages let you get away with that quick start style; you can write a lot of python before you need to write a plugin, and a lot of c# before you start using unsafe code, etc.
Rust doesn't afford you that luxury.
Lifetimes, mutability and single ownership are BAM, right in your face from the start.
It probably puts a few people off... but hey, you know the analogy about tools and toolboxes.
Rust is for writing fast, secure, cross platform code. There's nothing else out there that offers the same; it's not a case of use Rust or Nim, or C++; rust is literally the only language that offers these features right now.
You can certainly write code that happens to be secure, fast and cross platform (eg. in C++), and if you don't need those features (or dont care), you're almost certainly better off picking a different language (like Go or Nim) that are 'fast enough' and 'secure enough', and don't restrict you in the same way Rust does, or something far more productive (like python or javascript) if all you need to do is smash out a product.
That's perfectly ok.
We don't need a language which is everything for everyone all at the same time.
Rust is very good at doing what it does; and it's the first time C++ has had a real challenger. I, for one, am really looking forward to the dynamics between the two crowds going forwards.
Rust is for writing fast, secure, cross platform code. There's nothing else out there that offers the same.
That's a weird way to put it. There are a lot of languages that offer the same (weak) security protections Rust does, and a lot of cross-platform languages, and a lot of fast languages, and lots of combinations of those attributes.
What I think you mean to say is that there aren't a lot of combinations that don't have a GC runtime.
I think the question is "what is the cost" of the more novel rust safety features? In my experience, the cost is pretty high.
When you set Rust next to, e.g. swift, swift is phenominally more productive and similarly performant. And it is also quite safe (relative to C) without having all of the Rust safety features that make me want to kill the borrow checker with a rusty spoon.
I really wish Rust walked back on the more esoteric forms of safety (like thread safety, which you can't really verify anyway, you just promise the compiler that it's safe) and it tried to drive a bargain like Swift.
Rust really isn't satisfied to adopt the safety features that are "fairly low effort", it wants to break new ground without really measuring developer cost (hard to do since it's not widely used). That's really my issue with it.
Fast, restrictive and secure have been done before - see ATS, Cyclone, etc. Almost everybody ignored those trailblazing efforts, probably because those languages are very intimidating.
The Rust position appears to be that sorting an array of floats is unreasonable and so you must be "punished" by not being allowed to use the built-in .sort() function.
Whenever I've seen people complaining about Rust religiosity, is mostly because other languages trained them to be careless about certain things.
Rust cares great deal about PartialEq and Eq because you can have stuff like non-deterministic float NaN sorting or Run-time errors as demonstrated by previous posts.
Or Rust cares about doing manual memory management safely, but since you are arriving from either C/C++ which cares little about doing it safely, or GC language which cares little about memory management, you find it obnoxious.
Hell, even the TFA mentions how hard it is to use Hash, I'm pretty sure that's because Rust is aiming for actually making the hash work correctly and not allow you to just randomly compromise yourself.
I find it amazing (for good) that Nim, a language that was made in obscurity by a handful developers managed to be compared to a high visibility language backed by many organizations and people.
Rust is trying to do something far more complicated. Memory-safety enforced by the compiler is a big deal, but it remains to be seen if it's practical. I am really looking forward if rust can make it work, zero-cost memory-safety would really be something amazing to have in a language.
Nim seems to be a nice, low-level, gc-ed and practical language. It doesn't do anything radical, it's pretty small and it does what's already there right. It could become big.
This kinda reminds of linux vs minix. Doesn't mean it will play out the same way, but still.
Rust feels a bit difficult to get into right now, but if they smooth over the impractical bits, it could become the systems language in 10 years. Nimrod feels like a faster version of python or ruby, something a lot of people would like to have.
My impression is that Nim was in the right place at the right time and unintentionally piggybacked on the interest surrounding languages such as Rust and Go. This perception may be completely wrong. However, I do remember all these languages started gaining popularity within the span of several months. Before that Nim (then Nimrod) existed, but remained in obscurity.
Exactly my feeling and I also feel that sometimes we underestimate the "ability and efficiency" of small teams. I start to believe that a small core team (not to read few contributors) can have a larger impact than an organization.
Language maturity takes time. When Go and Rust went public, there were already languages in the very same niche, aiming to be a C++ replacement, and developped in the open.
I think lots of programming languages are been created, and the vast majority of them fall into obscurity, but some have nice features and grain a bit of traction, which is what is happening right now with Nim. If you forgive me the comparison, I would say that Nim is to the programming languages what Flappy Birds is to the video games: a successful product built by a talented programmer in a place where lots of people try their own - of course, the analogy is not completely right since the barrier to create a programming language is much, much higher than to create a small video game.
The killer feature of Nim is its amazing syntax. If you know Python, Nim will instantly feel very, very familiar.
Rust looks incredibly useful to do systems level programming, and guaranteed pointer safety without GC costs is amazing, but it takes me much longer to figure out exactly what's happening in the code.
Surely what is or isn't amazing syntax depends entirely on your preferences and personal experiences. I can't stand the Python syntax. Significant whitespace is an instant turnoff for me. For me, figuring out Rust is a lot easier than figuring out Nim, because that's what I'm used to.
Looks like comparing apples and oranges. If Nim has a GC it would be more instructive to compare it with another garbage-collected systems language like OCaml.
Yes and no. In fact, Nim can be used without a GC. Actually the GC of Nim is written in Nim, which certinaly proves the point. Now, it is not really convenient to avoid the GC in Nim, and you certainly do not have the safety features of Rust, but it can be done when needed (and you are still writing in something more productive than C)
Okay, so I'm having one problem with nim. Disabling all unsigned arithmetic by-default. The logic is actually fairly sound (it's probably, generally, harder to overflow a signed than an unsigned), but nim doesn't compile to object code; it transpiles to C and then C compiles to object/machine code.
Edit: it's obviously much harder to overflow an unsigned than a signed; in the sentence above, I was thinking particularly of underflow (which is what the nim devs reference as their logic for disabling unsigned arithmetic by-default).
The problem here is that unsigned arithmetic, though much easier to hit underflow, is fully defined in C where signed {under,over}flow is UB. As a result, if you manage to hit this case in nim, you're now going to hit UB by-default. This seems crazy to me. Am I missing something?
While unsigned arithmetic is not "enabled by-default", a simple `import unsigned` and you have it.
If you want the language to handle overflows for you, you can enable runtime overflow checks for your whole code or any specific part of it.
Otherwise, if you opt for no runtime checks and release builds with all optimizations, you indeed go into the same undefined behaviour territority as in C, so you'd have to prevent overflows before they happen.
I love nim. I've been using it non-stop since I've learnt the ropes. The only thing I'd wish was better results when googling for things. "nim" is just a very common word it appears. The site itself is a wealth of knowledge. I can relate to the comment of "feeling it's too big". Sadly the doco is not newbie friendly for some part (hi there, async). I've had no issues with the compiler but be sure to always use the devel branch. Things move fast in nim.
-----
Well, it was named "Nimrod" before, but there were other problems with that name, which prompted the rename. "Nim" was a good choice because it was the file ending already. Also, easier to google than C and Go at least. Usually "nim-lang" works fine.
The Nim code's more concise in this case but the Rust code can be more clearly written:
impl Add for Point {
type Output = Point;
fn add(self, other: Point) -> Point {
Point(self.0 + other.0, self.1 + other.1)
}
}
The "type Output = Point" line isn't boilerplate, it makes it possible to define the result of an addition as something other than a Point. (Off of the top of my head I can't think of any use cases, but I'm happy with the capability personally).
For addition I can't either, but you could use it to overload multiplication of two (mathematical) vectors to a dot-product
impl Mul for Vec2{
type Output = double;
fn mul(self, other: Vec2) -> Double {
self.0*other.0+self.1*other.1)
}
}
Although I must admit I'm not (yet) sure why you need to explicitly state the output and define it for the function. But I have only just started with Rust.
That's a good commentary. As for Nim, do we really need another unsafe language with a part-time GC? If you can tolerate a GC, there are a lot of good language options.
I have some issues with Rust's verbosity, especially in the error handling area. I recently bugged the Rust crowd into changing their overly complicated replacement for C's "argc/argv" approach to command line parameters.[1] They listened. The Rust crowd is trying hard in a difficult area and succeeding.
In C and C++, lifetimes and mutability are in your face from the start. It's just that the compiler doesn't help you with them. For years, I've been saying that the three big problems with C/C++ are "How big is it? Who owns it? Who locks it?". C gives no help with any of those. C++ addresses "how big", but it's not airtight, and C++14 tries to address "Who owns it", but only for new code, and it's not airtight. Rust aggressively deals with all three problems.
I can understand the unhappiness with Rust, though. It's not a comfortable language for many modern programmers, especially ones who've never done any constrained form of engineering. For them, I'd suggest Go and Python. Go can do pretty much anything you need to do on a web server, and fast. That's why Google created it. So can Python, but more slowly. Both are memory safe (well, Go isn't in multi thread mode.)
Understanding the Rust mindset can be hard. That's a documentation problem. The "Rust for Dummies" book has not yet been written. The Rust tutorial glosses over the hard issues, and the Rust reference is written for people who are into language design, compiler design, and theory. Until recently the language design had so much churn that most of the Rust material on the web is out of date. In another year, there will probably be a decent Rust book.
With Rust, you need a plan for who's going to own what before you start. Then you just have to explain that plan to the borrow checker. For a complex, mutable data structure, such as a DOM or a GUI's collection of interconnected widgets, this may take design work and design documents. If you plow ahead without thinking through who owns what, including in the error cases, you'll get Rust compile time errors. You would have hit trouble in C or C++ too, but it would have been in the form of a memory leak, crash, or security hole. Now you have to fix it up front.
There are performance wins in this. Someone recently commented on HN that they'd discovered that typing into a dialog box produced some insane number (thousands) of allocation events per keystroke. That was partly because, at many places in the C++ code, a c_str was being copied into a fresh String object. That's a consequence of being afraid to borrow a reference to a string you don't own, for fear of creating a bug. It's safer to make a copy. In Rust, the compiler will tell you if you can do that safely. If you need to make a copy, you can, but if you just take a reference and Rust allows it, the code is good. Big step forward.
I love nim. I've been using it non-stop since I've learnt the ropes. The only thing I'd wish was better results when googling for things. "nim" is just a very common word it appears. The site itself is a wealth of knowledge. I can relate to the comment of "feeling it's too big". Sadly the doco is not newbie friendly for some part (hi there, async). I've had no issues with the compiler but be sure to always use the devel branch. Things move fast in nim.
[+] [-] shadowmint|11 years ago|reply
Rust certainly isn't one of those languages where you can just pick it up, play with it for a day implementing an algorithm in it to get the feel of it and learn 'the complicated stuff' later.
Other languages let you get away with that quick start style; you can write a lot of python before you need to write a plugin, and a lot of c# before you start using unsafe code, etc.
Rust doesn't afford you that luxury.
Lifetimes, mutability and single ownership are BAM, right in your face from the start.
It probably puts a few people off... but hey, you know the analogy about tools and toolboxes.
Rust is for writing fast, secure, cross platform code. There's nothing else out there that offers the same; it's not a case of use Rust or Nim, or C++; rust is literally the only language that offers these features right now.
You can certainly write code that happens to be secure, fast and cross platform (eg. in C++), and if you don't need those features (or dont care), you're almost certainly better off picking a different language (like Go or Nim) that are 'fast enough' and 'secure enough', and don't restrict you in the same way Rust does, or something far more productive (like python or javascript) if all you need to do is smash out a product.
That's perfectly ok.
We don't need a language which is everything for everyone all at the same time.
Rust is very good at doing what it does; and it's the first time C++ has had a real challenger. I, for one, am really looking forward to the dynamics between the two crowds going forwards.
[+] [-] tptacek|11 years ago|reply
That's a weird way to put it. There are a lot of languages that offer the same (weak) security protections Rust does, and a lot of cross-platform languages, and a lot of fast languages, and lots of combinations of those attributes.
What I think you mean to say is that there aren't a lot of combinations that don't have a GC runtime.
[+] [-] drewcrawford|11 years ago|reply
When you set Rust next to, e.g. swift, swift is phenominally more productive and similarly performant. And it is also quite safe (relative to C) without having all of the Rust safety features that make me want to kill the borrow checker with a rusty spoon.
I really wish Rust walked back on the more esoteric forms of safety (like thread safety, which you can't really verify anyway, you just promise the compiler that it's safe) and it tried to drive a bargain like Swift.
Rust really isn't satisfied to adopt the safety features that are "fairly low effort", it wants to break new ground without really measuring developer cost (hard to do since it's not widely used). That's really my issue with it.
[+] [-] gsg|11 years ago|reply
[+] [-] pjmlp|11 years ago|reply
Ada and Modula-3 were there first, they just weren't adopted by OS vendors at large.
[+] [-] alextgordon|11 years ago|reply
In Python, given an array xs = [3.1, 1.2, 4.3, 2.2], I can write
and get [1.2, 2.2, 3.1, 4.4]In Haskell
In Swift In Rust you have to spew this monstrosity The Rust position appears to be that sorting an array of floats is unreasonable and so you must be "punished" by not being allowed to use the built-in .sort() function.[+] [-] Ygg2|11 years ago|reply
Rust cares great deal about PartialEq and Eq because you can have stuff like non-deterministic float NaN sorting or Run-time errors as demonstrated by previous posts.
Or Rust cares about doing manual memory management safely, but since you are arriving from either C/C++ which cares little about doing it safely, or GC language which cares little about memory management, you find it obnoxious.
Hell, even the TFA mentions how hard it is to use Hash, I'm pretty sure that's because Rust is aiming for actually making the hash work correctly and not allow you to just randomly compromise yourself.
[+] [-] Peaker|11 years ago|reply
To me, this signals that they value long-term safety over short-term convenience. Any other choice, IMO and IME, is short-sighted.
[+] [-] heinrich5991|11 years ago|reply
[+] [-] whyever|11 years ago|reply
[+] [-] dodyg|11 years ago|reply
[+] [-] logophobia|11 years ago|reply
Nim seems to be a nice, low-level, gc-ed and practical language. It doesn't do anything radical, it's pretty small and it does what's already there right. It could become big.
This kinda reminds of linux vs minix. Doesn't mean it will play out the same way, but still.
Rust feels a bit difficult to get into right now, but if they smooth over the impractical bits, it could become the systems language in 10 years. Nimrod feels like a faster version of python or ruby, something a lot of people would like to have.
[+] [-] trwired|11 years ago|reply
[+] [-] andreiursan|11 years ago|reply
[+] [-] p0nce|11 years ago|reply
[+] [-] S4M|11 years ago|reply
[+] [-] Fede_V|11 years ago|reply
Rust looks incredibly useful to do systems level programming, and guaranteed pointer safety without GC costs is amazing, but it takes me much longer to figure out exactly what's happening in the code.
[+] [-] Tharkun|11 years ago|reply
[+] [-] guelo|11 years ago|reply
[+] [-] aphexairlines|11 years ago|reply
[+] [-] andreaferretti|11 years ago|reply
[+] [-] z92|11 years ago|reply
[+] [-] halosghost|11 years ago|reply
Edit: it's obviously much harder to overflow an unsigned than a signed; in the sentence above, I was thinking particularly of underflow (which is what the nim devs reference as their logic for disabling unsigned arithmetic by-default).
The problem here is that unsigned arithmetic, though much easier to hit underflow, is fully defined in C where signed {under,over}flow is UB. As a result, if you manage to hit this case in nim, you're now going to hit UB by-default. This seems crazy to me. Am I missing something?
[+] [-] def-|11 years ago|reply
If you want the language to handle overflows for you, you can enable runtime overflow checks for your whole code or any specific part of it.
Otherwise, if you opt for no runtime checks and release builds with all optimizations, you indeed go into the same undefined behaviour territority as in C, so you'd have to prevent overflows before they happen.
[+] [-] throawai|11 years ago|reply
I love nim. I've been using it non-stop since I've learnt the ropes. The only thing I'd wish was better results when googling for things. "nim" is just a very common word it appears. The site itself is a wealth of knowledge. I can relate to the comment of "feeling it's too big". Sadly the doco is not newbie friendly for some part (hi there, async). I've had no issues with the compiler but be sure to always use the devel branch. Things move fast in nim. -----
[+] [-] def-|11 years ago|reply
[+] [-] dom96|11 years ago|reply
[+] [-] keyle|11 years ago|reply
[+] [-] tmerr|11 years ago|reply
The Nim code's more concise in this case but the Rust code can be more clearly written:
The "type Output = Point" line isn't boilerplate, it makes it possible to define the result of an addition as something other than a Point. (Off of the top of my head I can't think of any use cases, but I'm happy with the capability personally).[+] [-] steveklabnik|11 years ago|reply
The post wasn't really updated.
[+] [-] Coding_Cat|11 years ago|reply
[+] [-] Animats|11 years ago|reply
I have some issues with Rust's verbosity, especially in the error handling area. I recently bugged the Rust crowd into changing their overly complicated replacement for C's "argc/argv" approach to command line parameters.[1] They listened. The Rust crowd is trying hard in a difficult area and succeeding.
In C and C++, lifetimes and mutability are in your face from the start. It's just that the compiler doesn't help you with them. For years, I've been saying that the three big problems with C/C++ are "How big is it? Who owns it? Who locks it?". C gives no help with any of those. C++ addresses "how big", but it's not airtight, and C++14 tries to address "Who owns it", but only for new code, and it's not airtight. Rust aggressively deals with all three problems.
I can understand the unhappiness with Rust, though. It's not a comfortable language for many modern programmers, especially ones who've never done any constrained form of engineering. For them, I'd suggest Go and Python. Go can do pretty much anything you need to do on a web server, and fast. That's why Google created it. So can Python, but more slowly. Both are memory safe (well, Go isn't in multi thread mode.)
Understanding the Rust mindset can be hard. That's a documentation problem. The "Rust for Dummies" book has not yet been written. The Rust tutorial glosses over the hard issues, and the Rust reference is written for people who are into language design, compiler design, and theory. Until recently the language design had so much churn that most of the Rust material on the web is out of date. In another year, there will probably be a decent Rust book.
With Rust, you need a plan for who's going to own what before you start. Then you just have to explain that plan to the borrow checker. For a complex, mutable data structure, such as a DOM or a GUI's collection of interconnected widgets, this may take design work and design documents. If you plow ahead without thinking through who owns what, including in the error cases, you'll get Rust compile time errors. You would have hit trouble in C or C++ too, but it would have been in the form of a memory leak, crash, or security hole. Now you have to fix it up front.
There are performance wins in this. Someone recently commented on HN that they'd discovered that typing into a dialog box produced some insane number (thousands) of allocation events per keystroke. That was partly because, at many places in the C++ code, a c_str was being copied into a fresh String object. That's a consequence of being afraid to borrow a reference to a string you don't own, for fear of creating a bug. It's safer to make a copy. In Rust, the compiler will tell you if you can do that safely. If you need to make a copy, you can, but if you just take a reference and Rust allows it, the code is good. Big step forward.
[1] https://github.com/rust-lang/rust/pull/21787#issuecomment-73...
[+] [-] steveklabnik|11 years ago|reply
I'm not disagreeing, this is more of a survey kind of question, but which issues are the hard ones, to you?
[+] [-] keyle|11 years ago|reply
[+] [-] thechao|11 years ago|reply
This was questioned, long ago, by Todd Veldhuizen in his Parsimony Principle paper[1]. The long-and-short of which is: do it!
[1] http://arxiv.org/abs/0707.4166
[+] [-] fiatjaf|11 years ago|reply
[+] [-] arbre|11 years ago|reply