> things that should be dirt-simple in Rust, like string concatenation, are unreasonably difficult
This is how hard adding String objects is in Rust:
a + b
A more full example shows only small complexity, really, and I include it only for completeness and fairness:
fn main() {
let a = String::from("Hello,");
let b = " world.";
let c = a + b; // this is the only part that concats, really.
println!("{}", c);
}
The String::from call converts from a str& — which is effectively a pointer and length to UTF-8 data, to a managed string, more akin to std::string in C++; str& doesn't implement +, I presume b/c it doesn't know what the resulting type should be (and doesn't presume).
A C programmer should easily comprehend why you can't simply add two char * s together; compare:
(that's just the `a + b` line from Rust, in C, essentially)
(hopefully I got that right. stpcpy avoids an extra iteration through a that strcat cannot; I do know about strcat.)
Essentially, in all of Python/Go/Rust, if you has the right type, string concatenation is `a + b`.
> Contemplate this bug report: Is there some API like "select/poll/epoll_wait"? and get a load of this answer:
> > We do not currently have an epoll/select abstraction. The current answer is "spawn a task per socket".
It would need to be cross-platform; so I can understand why Rust isn't there yet in the standard library. There are third-party libraries out there that do this. (And C has nothing here, either…)
You can always call epoll directly, and write the required abstraction yourself. (There are even third-party wrappers for calling epoll, so you don't even have you write that yourself either; see the excellent "nix" library.) If you want a 10 year solution…
> Relatedly, the friction cost of important features like the borrow checker is pretty high.
At first, this is true. Then I felt like I started realizing that what all the "friction" of the borrow checker was it pointing out serious bugs in my code.
Regardless, NTP would be better off in either Rust or Go instead of C, IMO.
fn main() {
let a = "Hello,";
let b = " world.";
let c = a + b;
println!("{}", c);
}
And the result is:
rustc 1.15.0-beta.3 (a035041ba 2017-01-07)
error[E0369]: binary operation `+` cannot be applied to type `&str`
|
5 | let c = a + b; // this is the only part that concats, really.
| ^
|
note: an implementation of `std::ops::Add` might be missing for `&str`
|
5 | let c = a + b; // this is the only part that concats, really.
| ^
timeout triggered!
What?
PS. looks like hacker news can't handle rustc error format, a pity...
This is how hard adding String objects is in Rust:
A more full example shows only small complexity, really, and I include it only for completeness and fairness: The String::from call converts from a str& — which is effectively a pointer and length to UTF-8 data, to a managed string, more akin to std::string in C++; str& doesn't implement +, I presume b/c it doesn't know what the resulting type should be (and doesn't presume).A C programmer should easily comprehend why you can't simply add two char * s together; compare:
(that's just the `a + b` line from Rust, in C, essentially)(hopefully I got that right. stpcpy avoids an extra iteration through a that strcat cannot; I do know about strcat.)
Essentially, in all of Python/Go/Rust, if you has the right type, string concatenation is `a + b`.
> Contemplate this bug report: Is there some API like "select/poll/epoll_wait"? and get a load of this answer:
> > We do not currently have an epoll/select abstraction. The current answer is "spawn a task per socket".
It would need to be cross-platform; so I can understand why Rust isn't there yet in the standard library. There are third-party libraries out there that do this. (And C has nothing here, either…)
You can always call epoll directly, and write the required abstraction yourself. (There are even third-party wrappers for calling epoll, so you don't even have you write that yourself either; see the excellent "nix" library.) If you want a 10 year solution…
> Relatedly, the friction cost of important features like the borrow checker is pretty high.
At first, this is true. Then I felt like I started realizing that what all the "friction" of the borrow checker was it pointing out serious bugs in my code.
Regardless, NTP would be better off in either Rust or Go instead of C, IMO.