:-) Ok -- that's quite a convincing argument against Python! My experience with it is casual.
However, I still believe the following: - Rust should have a standard build tool that is able to handle complex cases. - This build tool needs a programming language. - This programming language should not be Rust (to avoid the complexity of recursive builds) and indeed should be interpreted. Any similarly convincing arguments against those beliefs? Dean On 2/20/13 7:31 AM, "[email protected]" <[email protected]> wrote: >On Wed, Feb 20, 2013 at 2:50 PM, Dean Thompson ><[email protected]> wrote: >> >> My suggestion: Python. >> > >Please. Not Python. Everything but not this. > >I admit: I hate Python with passion, so I may be biased. I hate not so >much the language itself but all it's tooling and constant problems >with it and people constantly putting it everywhere because the only >language they grasp or assume everyone else should know it to. (No >intention to offend the original poster, it's just a fact of life that >Python is quite easy to learn and university courses often pick it and >,,when hammer is all you got, everything looks like a nail''. > >In 2011, I've spent 2 weeks rewritting (removing or decoupling, >really) the `scons`-based build system that was meant to be "flexible, >powerful, fast, easy to use, with interactive features, etc.". An in >reality it was unmaintenable, complex, big and slow and the 3rd-party >components used to build it were becoming abandoned. > >Python : > >* Is not designed for handling dependencies from groundup like eg. >`make`. So it needs some custom foundation code to handle it, probably >with 3rd party dependencies. >* Is not really efficient for gluing external tools like shell scripts >are. >* Is not solid (things break in runtime, and many times just because >newer minor Python version came out). >* It's not providing support for ancient tools like autotools, neither >Rust needs this, as there will be no legacy software using Rust yet. > > >Besides I don't understand why normal projects in Rust would require >anything more to be built other than: > >rustc main.rs > >or something similarly simple. > >As long as Rust building system support the mentioned "escape hatch", >with complex project people will be able to build using any complex >logic they like, written in any language, using any 3rd-party software >they choose. For 99.9% mainstream projects though any simple solution >will be fine, and the less potential problems and dependencies it >introduces, the best for all of us. > >Imagine the scenario: > >"Why did this Rust package failed to build? Some weird Python error... >. Should I use different version of Python? Which one: 1.x, 2.5, 2.6, >2.7, 3.x, 4.x, 5.x ? Because programs breaks randomly (in runtime!) >between Python versions. Must I use `virtualenv` (or what's the >current/best version of this idea ATM)? Are all the pips installed and >configured correctly? Maybe one of these many funny python environment >varibles is wrong for some reason... ?" > >So let's not import Pythons problems into Rust world. > >Regards, >-- >Dawid Ciężarkiewicz _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
