11–20 of 248 posts
I only ever looked at Rust from a 500 foot view while toying with it at a Hackathon, but I had no clue it had so many different types of threading models. This seems like a step in the right direction, indeed. If Task is going to your unit of concurrent execution, as much transparency around that as possible is a good thing.
It'd be wonderful if they kept the ability to define that a certain destructor does zero memory. Sometimes, you need that.
Zeroing out memory isn't sufficient, as discussed here: http://www.daemonology.net/blog/2014-09-06-zeroing-buffers-i... That said, this was discussed on reddit[0], it sounds like there is a way to guarantee that you did zero out memory (but not necessarily copies of that memory, as discussed in the link above), and because Rust is intended to be memory safe, it's not as much of an issue if you don't/can't. http://www…
That means it has the hope of getting it right.
I just wish Rust was a bit less verbose. Requiring, for instance, type annotations on function arguments because it's sometimes helpful is such a weird decision. Let the programmer decide when an annotation is needed. This gets annoying when you get into functions with complex arguments. Especially for local functions where the signature could be messy, but the limited scope means annotations just clutter things. I'm not sure why Rust forces us to compromise here.
I used to describe my preferred family of languages as: - C when I absolutely had to (kernel/modules/plumbing). - Python for scripting and broad accessibility. - Haskell when I had the choice and I knew everybody who would work on the project. I was skeptical of Rust when it first came out, due in large part to the many different kinds of pointers it originally had, many of which involved significant manual memory ma…
OpenSUSE's Open Build System would be great to ship independent packages, but those are again heavily tied to Unices, hence leaving other platforms behind.
Rust looks fantastic, and has a lot of things I wish I could do while in a higher level language like F#. I just wish Rust was a bit less verbose. Requiring, for instance, type annotations on function arguments because it's sometimes helpful is such a weird decision. Let the programmer decide when an annotation is needed. This gets annoying when you get into functions with complex arguments. Especially for local func…
> This gets annoying when you get into functions with complex arguments.
Have you seen the where clauses yet? This should significantly help complex function declarations.
I'm looking forward for even better support of iOS with the support of arm64, I think it is really important to offer an alternative.
BTW is there an RFC on dynamically sized types? I can't find any, I'm looking to learn of it works.
Rust looks fantastic, and has a lot of things I wish I could do while in a higher level language like F#. I just wish Rust was a bit less verbose. Requiring, for instance, type annotations on function arguments because it's sometimes helpful is such a weird decision. Let the programmer decide when an annotation is needed. This gets annoying when you get into functions with complex arguments. Especially for local func…
Haskell and other extremely strongly typed languages can infer the types of function parameters, yet the community still agrees it is good practice to annotate your work.
Earlier quoted context omitted.
Zeroing out memory isn't sufficient, as discussed here: http://www.daemonology.net/blog/2014-09-06-zeroing-buffers-i... That said, this was discussed on reddit[0], it sounds like there is a way to guarantee that you did zero out memory (but not necessarily copies of that memory, as discussed in the link above), and because Rust is intended to be memory safe, it's not as much of an issue if you don't/can't. http://www…
Not in C. Rust is, as you say, intended to be memory safe. That means it has the hope of getting it right .
[0] http://doc.rust-lang.org/std/intrinsics/fn.volatile_set_memo...
I used to describe my preferred family of languages as: - C when I absolutely had to (kernel/modules/plumbing). - Python for scripting and broad accessibility. - Haskell when I had the choice and I knew everybody who would work on the project. I was skeptical of Rust when it first came out, due in large part to the many different kinds of pointers it originally had, many of which involved significant manual memory ma…
Curious to hear more about language-specific (though OS-agnostic!) package management systems. IMO composer is the best thing ever happened to PHP, Ruby gems are huge, Python eggs also make a very useful ecosystem. OpenSUSE's Open Build System would be great to ship independent packages, but those are again heavily tied to Unices, hence leaving other platforms behind.
As far as I can tell, one of the main justifications for most language package management systems is "we also run on Windows/OSX, which has no package management, so we'll invent our own". As a result, users of systems that do have sane package management get stuck with multiple package management systems, one for the distro and one for every language. Even then, I find it disappointing that nobody has built a cross-platform package management system for arbitrary languages to unify those efforts.