21–30 of 120 posts
Coming from C#, that syntax looks completely alien to me. I need to write a very small monitoring app to run on a tiny armel box so I may try Go. I will still miss Visual Studio's debugger, though.
Go is shit. Trust me, Rust will suit you better. Coming from C# it will be a lot closer to what you're used to than the bizzaro-world of Go.
Earlier quoted context omitted.
I've been tempted to try getting rust going on some of the small arm micros I've got lying around. The memory safety would be tremendous boon for a lot of development there, same with the ownership/lifetime management. I think I'd probably have to strike most of the standard library but it'd still be really useful.
For me I keep seeing buffer overflows in router management stacks. It seems like rust would help protect routers from attack, while allowing low footprints.
Earlier quoted context omitted.
What would benchmarking say the slowest part of rustc is? Typechecking/semantic analysis, llvm, or something else. LLVM is a great innovation when it comes to making new languages from scratch, High performance will hopefully be one of rusts strong points, so its good to have so many companies working on llvm performance for free.
On debug builds, it's about evenly split between typeck/borrowck and codegen (including LLVM IR construction and LLVM passes). On release builds, LLVM optimization time tends to dominate everything. Niko Matsakis is actively working on improving typechecking time--there should be plenty of tricks we can try once we have enough data as to the lowest-hanging fruit. Felix Klock and others are working on reducing the amo…
:D Regarding your borrow checker example, note that your code is now prone to blowing up if `step` is modified too much. You have created the necessity of an invariant (step should not pop out of the vector) which may be broken by later cleverness.
See http://manishearth.github.io/blog/2015/05/17/the-problem-wit... for more details.
Note that in this specific case you could just use `&str` over `&String` everywhere and push "some new thing" directly; `&String` is a double-pointer, whereas &str is a fat pointer.
> Nor am I totally sure what the tradeoffs are between having a self argument and not.
It's not a tradeoff thing; it's a "do I want a static method, or a member method" thing.
> Some kinds of constraints cannot be used in where clauses, so I believe the former is strictly more powerful.
Actually where clauses are much more powerful. With the type constraints stuff like `A: Foo` works but not `Vec: Foo`, but the latter is allowed in where clauses.
Overall, loved reading this post! It identified some areas of diagnostics that we can try to improve (I'm very interested in fixing diagnostics), and is a pretty accurate picture of the language :)
Earlier quoted context omitted.
On debug builds, it's about evenly split between typeck/borrowck and codegen (including LLVM IR construction and LLVM passes). On release builds, LLVM optimization time tends to dominate everything. Niko Matsakis is actively working on improving typechecking time--there should be plenty of tricks we can try once we have enough data as to the lowest-hanging fruit. Felix Klock and others are working on reducing the amo…
Is rustc able to run typechecking without doing codegen?
> The Rust community seems to be populated entirely by human beings. :D Regarding your borrow checker example, note that your code is now prone to blowing up if `step` is modified too much. You have created the necessity of an invariant (step should not pop out of the vector) which may be broken by later cleverness. See http://manishearth.github.io/blog/2015/05/17/the-problem-wit... for more details. Note that in thi…
It's an awkwardly construed example. Here is the actual code - https://gist.github.com/jamii/ae46e8e0c9757330e9ea . There the borrow makes more sense since the value is being created by calling a function on the current solver state.
I've edited the post to include a solution that was suggested in the reddit discussion - replace &'a Value with Cow.
> It's not a tradeoff thing; it's a "do I want a static method, or a member method" thing.
> Actually where clauses are much more powerful.
I really don't understand this part of the language yet, but...
I linked to an active rfc about constraints that cannot currently be expressed in where clauses (https://github.com/rust-lang/rfcs/blob/master/text/0135-wher...), including the example you gave.
In cases where a function takes two arguments it isn't always obvious which argument should be self. If that affects whether constraints end up being A: Foo or B: Foo or `where Foo` it seems like one could run up against those limitations?
Earlier quoted context omitted.
Both are really great. I think Go is better for servers and rust can be great on embedded and high performance applications.
I've been tempted to try getting rust going on some of the small arm micros I've got lying around. The memory safety would be tremendous boon for a lot of development there, same with the ownership/lifetime management. I think I'd probably have to strike most of the standard library but it'd still be really useful.
Go is primarily for server-side web applications. That's Google's main business area, that's what they built it for, and that's where all the libraries are well-debugged.
Coming from C#, that syntax looks completely alien to me. I need to write a very small monitoring app to run on a tiny armel box so I may try Go. I will still miss Visual Studio's debugger, though.
After some time I got the hang of it, and I am sure you can do it too. It is surprising how much I _didn’t_ miss the Visual Studio debugger. The VS debugger is amazing and in my opinion there is no debugger that comes close, but Rust has a much higher “if it compiles it works”-factor than C#. There are still times where I wish for a debugger like that of Visual Studio, but this is relatively rare. Instead of spending time debugging, you spend your time staring at compiler errors in denial until you eventually accept that the compiler is right and your code is wrong.
Earlier quoted context omitted.
Both are really great. I think Go is better for servers and rust can be great on embedded and high performance applications.
The truth is that rust is in its infancy its all guesses at this point. Go didn't attract c++ people as people first guessed.
Nobody today is running C/C++ unless they need either A) complete speed or B) bare metal. Go can't do either, so there was going to be very little transfer from C/C++ to Go.