21–30 of 248 posts
On minor concern though, I don't see how "where clauses" are simplifying the language. Looks like something that could be added after the release.
Earlier quoted context omitted.
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.
> Curious to hear more about language-specific (though OS-agnostic!) package management systems. 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 dis…
And you should add Linux to your Windows/OSX as being an issue, which Linux package management tool would you build packages for? All of them?
The end user package management provided by the OS should be for installing end user packages and the language tool for installing and publishing libraries and dev tools.
Earlier quoted context omitted.
> Curious to hear more about language-specific (though OS-agnostic!) package management systems. 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 dis…
The problem with language package management systems is they've been used for installing user facing software. As a developer tool I think it is the perfect way to go. And you should add Linux to your Windows/OSX as being an issue, which Linux package management tool would you build packages for? All of them? The end user package management provided by the OS should be for installing end user packages and the languag…
Precisely so.
Earlier quoted context omitted.
Rust does not have any garbage collection, to be clear. All your other features are correct though :) (We have previously said "opt-in GC" but that was a lie. See https://news.ycombinator.com/item?id=8312327 for more.)
Yeah, I should have said that more clearly. Automatic memory management (never having to call free), not garbage collection. Which is arguably more awesome: whenever the compiler can figure out at compile time when you'll stop using memory, it can statically decide to reclaim it there.
I'm excited for the release too. Know many people who hesitate to touch Rust, even if interested, due to the fact language is still in active development. On minor concern though, I don't see how "where clauses" are simplifying the language. Looks like something that could be added after the release.
Where clasues simplify Rust code, they don't simplify the language itself. They're also important for associated items. For more: https://github.com/aturon/rfcs/blob/associated-items/active/...
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…
It's been a huge step up from makefiles in developing Servo. I can barely ever bring myself to go back to using make and git submodules now.
The workflow of breaking up your project into small, self-contained packages that people hack on independently and are all built with a package manager that natively understands the language and can build without a single line of shell is a huge improvement over vendoring dependencies and dealing with a maze of configure scripts or arcane make/(insert your preferred replacement here) files. It improved compilation time a lot too!
What I think is an important feature of this language is the ease with which it can interact with other languages. Especially the possibility for Rust code to be called from foreign languages such as C very easily. 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…
The second production deployment of Rust is a Ruby gem, written in C, that calls out to Rust. It's used in skylight.io, if you're curious.
> BTW is there an RFC on dynamically sized types?
IIRC, DST was before the RFC process even existed, it's just taken forever to implement. The Duke Nukem Forever of Rust. :) http://smallcultfollowing.com/babysteps/blog/2014/01/05/dst-... is what you want to read, IIRC.
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…
In separate compilation you have to annotate functions anyway, and in most large ML projects I've worked on people tend to annotate just because the error messages get much better. This is a common design in functional languages these days.
What I think is an important feature of this language is the ease with which it can interact with other languages. Especially the possibility for Rust code to be called from foreign languages such as C very easily. 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…
> Especially the possibility for Rust code to be called from foreign languages such as C very easily. The second production deployment of Rust is a Ruby gem, written in C, that calls out to Rust. It's used in skylight.io, if you're curious. > BTW is there an RFC on dynamically sized types? IIRC, DST was before the RFC process even existed, it's just taken forever to implement. The Duke Nukem Forever of Rust. :) http:…
Thanks for the info and the link!