3 ms·

Related to "Unless it's JavaScript", what I mean by "not hard" is that a conservative static analysis can determine whether your code can possibly reference the

by gue5t 10y ago

Related to "Unless it's JavaScript", what I mean by "not hard" is that a conservative static analysis can determine whether your code can possibly reference the built-in eval function. A static analysis can't tell whether a eval will be run if it is present (halting problem, and there are escape-hatches like filesystem+exec()) but I think it's very reasonable to expect people to forbid them outright in high-assurance code. Anecdotally, I've rewritten fair amounts of code from Go to Rust and it seems like Rust takes about 60% the lines of Go, which is mostly due to library reuse for control-flow constructs (higher-order functions rely heavily on generics to be usable and not merely confusing footguns) and simplified error handling. The biggest pain point when porting is usage of goroutines, because these dictate the threading and communication architecture of your Rust code, and unlike goroutines it isn't cheap to spawn large numbers of real threads. This would be better with a coroutine library, but I haven't tried that approach in a ported codebase. I do think explaining the language clearly and precisely is a big challenge and hope we can make it happen. It's true that Rust forces you to be explicit and precise in many places C doesn't, but coming from a long time of programming C I loved to see that Rust was enforcing universally the guidelines that C projects slowly develop after years of developer experience: explicitly state memory ownership (in comments, in C), explicitly state which shared memory is protected by which locks (again, in comments or variable names in C), call destructor functions for all live local variables before returning from a function (done automatically by the Rust compiler), and so on. Rust is, in many ways, shorthand for well-written C. It makes you jump through hoops to express many sloppy C practices. If you're just learning C, after you understand the basics I think the most important thing to understand is the abstract machine around which the language is defined; that's how you learn to reason about UB and which optimizations and transformations compilers will or won't do, along with how to guide the compiler to the translation you want. C isn't defined against a single huge byte array of memory, and pointers aren't indices into such!

i336_ 9y ago
Sorry this reply took a bit long (if you see it at all) - had a bit of a notification failure. > Related to "Unless it's JavaScript", what I mean by "not hard" is that a conservative static analysis can determine whether your code can possibly reference the built-in eval function. (...) Oooh, like that. I get what you mean now. > Anecdotally, I've rewritten fair amounts of code from Go to Rust and it seems like Rust takes about 60% the lines of Go, which is mostly due to library reuse for control-flow constructs (higher-order functions rely heavily on generics to be usable and not merely confusing footguns) and simplified error handling. Hmm. > The biggest pain point when porting is usage of goroutines, because these dictate the threading and communication architecture of your Rust code, and unlike goroutines it isn't cheap to spawn large numbers of real threads. This would be better with a coroutine library, but I haven't tried that approach in a ported codebase. I'm curious if this is because there's no consensus on which coroutine library to use yet. The example I linked last message (http://esr.ibiblio.org/?p=7294 http://esr.ibiblio.org/?p=7294) also whined about Rust not having a select() primitive or equivalent functionality in the core language - https://github.com/rust-lang/rust/issues/27800 https://github.com/rust-lang/rust/issues/27800 remains open since Aug 2015 as of my writing this comment, but I don't know if there are any standardized (ideally stdlib-level) solutions known outside of this communication channel. > I do think explaining the language clearly and precisely is a big challenge and hope we can make it happen. Cool :D > It's true that Rust forces you to be explicit and precise in many places C doesn't, but coming from a long time of programming C I loved to see that Rust was enforcing universally the guidelines that C projects slowly develop after years of developer experience: explicitly state memory ownership (in comments, in C), explicitly state which shared memory is protected by which locks (again, in comments or variable names in C), call destructor functions for all live local variables before returning from a function (done automatically by the Rust compiler), and so on. That's fair. I get the impression Rust's vision is to be the go-to language for low-level enterprise-scale (ie, long-term) stuff, while also being accessible and suitable for hobbyist scripting. I can completely appreciate that. > Rust is, in many ways, shorthand for well-written C. It makes you jump through hoops to express many sloppy C practices. That's pretty cool. :> > If you're just learning C, after you understand the basics I think the most important thing to understand is the abstract machine around which the language is defined; that's how you learn to reason about UB and which optimizations and transformations compilers will or won't do, along with how to guide the compiler to the translation you want. I've only very recently started to notice this and grasp the importance of the difference between the hardware and what C abstracts that hardware as; thanks very much for the recommendation, I'll focus more closely on it. On that note, I find it remarkable how platform-agnostic yet hardware-accessible the C abstract machine is; I'm not sure whether to be mildly scared at the engineering ingenuity of the language or merely duly impressed that the developers just happened to stumble upon a really good design :)

by gue5t 10y ago

i336_ 9y ago

Sorry this reply took a bit long (if you see it at all) - had a bit of a notification failure. > Related to "Unless it's JavaScript", what I mean by "not hard" is that a conservative static analysis can determine whether your code can possibly reference the built-in eval function. (...) Oooh, like that. I get what you mean now. > Anecdotally, I've rewritten fair amounts of code from Go to Rust and it seems like Rust takes about 60% the lines of Go, which is mostly due to library reuse for control-flow constructs (higher-order functions rely heavily on generics to be usable and not merely confusing footguns) and simplified error handling. Hmm. > The biggest pain point when porting is usage of goroutines, because these dictate the threading and communication architecture of your Rust code, and unlike goroutines it isn't cheap to spawn large numbers of real threads. This would be better with a coroutine library, but I haven't tried that approach in a ported codebase. I'm curious if this is because there's no consensus on which coroutine library to use yet. The example I linked last message (http://esr.ibiblio.org/?p=7294 http://esr.ibiblio.org/?p=7294) also whined about Rust not having a select() primitive or equivalent functionality in the core language - https://github.com/rust-lang/rust/issues/27800 https://github.com/rust-lang/rust/issues/27800 remains open since Aug 2015 as of my writing this comment, but I don't know if there are any standardized (ideally stdlib-level) solutions known outside of this communication channel. > I do think explaining the language clearly and precisely is a big challenge and hope we can make it happen. Cool :D > It's true that Rust forces you to be explicit and precise in many places C doesn't, but coming from a long time of programming C I loved to see that Rust was enforcing universally the guidelines that C projects slowly develop after years of developer experience: explicitly state memory ownership (in comments, in C), explicitly state which shared memory is protected by which locks (again, in comments or variable names in C), call destructor functions for all live local variables before returning from a function (done automatically by the Rust compiler), and so on. That's fair. I get the impression Rust's vision is to be the go-to language for low-level enterprise-scale (ie, long-term) stuff, while also being accessible and suitable for hobbyist scripting. I can completely appreciate that. > Rust is, in many ways, shorthand for well-written C. It makes you jump through hoops to express many sloppy C practices. That's pretty cool. :> > If you're just learning C, after you understand the basics I think the most important thing to understand is the abstract machine around which the language is defined; that's how you learn to reason about UB and which optimizations and transformations compilers will or won't do, along with how to guide the compiler to the translation you want. I've only very recently started to notice this and grasp the importance of the difference between the hardware and what C abstracts that hardware as; thanks very much for the recommendation, I'll focus more closely on it. On that note, I find it remarkable how platform-agnostic yet hardware-accessible the C abstract machine is; I'm not sure whether to be mildly scared at the engineering ingenuity of the language or merely duly impressed that the developers just happened to stumble upon a really good design :)