> I feel like Rust might be missing out on the free lunch I expect Swift to provide
I think that it may be unfounded to expect Swift to spur drastic improvements to any aspect of LLVM. Apple is already the biggest benefactor of LLVM, which powers the C compiler their OS is built with, the Objective-C language that all their apps are written in, the IDE used to write those apps, and the Javascript engine that powers their web browser. Despite Swift's arrival, I wouldn't expect any greater investment in LLVM than Apple does currently (which is a shame, given the bazillion dollars burning a hole in their pocket). I'd like to also note that Apple has no external incentive to improve Swift. Objective-C was a dead language before Apple's fiat rocketed it into the position of world's third-most-popular programming language. Regardless of Swift's implementation or design decisions, it *will* be one of the most popular languages in the world come this time next year (likely accompanied by Objective-C's meteoric descent). If Swift were a fusion of RPG and Malbolge with an implementation written in INTERCAL, this fact would not change (thankfully, the Swift designers have better taste). Why bother straining yourself to satisfy a captive audience, when your only real competitor is whatever dialect of Java that Dalvik supports? On Mon, Jun 23, 2014 at 5:08 PM, Tony Arcieri <basc...@gmail.com> wrote: > On Mon, Jun 23, 2014 at 1:32 PM, Daniel Micay <danielmi...@gmail.com> > wrote: > >> It would be an enormous mistake to ship a language with region typing / >> move semantics and worse before than Java. > > > You keep saying that, but if the argument is to use Swift's approach, i.e.: > > Non-overflow operators: + - * / % > Overflow operators: &+ &- &* &/ &% > > Or let's swap Swift's defaults if you so desire: > > Overflow operators: + - * / % > Non-overflow operators: &+ &- &* &/ &% > > Or even change the syntax if you so desire: > > Overflow operators: + - * / % > Non-Overflow operators: +~ -~ *~ /~ %~ > > ...then any arguments about performance are really a false dichotomy. It's > just a question of syntax and defaults. Want to perform well at TIOBE or > other (micro)benchmarks? Use the overflow operators! Want to write safe > code? Use the checked overflow operators. I really think Rust should > support both approaches, be it implemented through a type or operator or > what have you. I'm not here to bikeshed that. I just want to make sure both > approaches have a first class position in the language, and would generally > prefer but don't insist upon checked overflow being the default. > > If the Rust developers insist on choosing overflow operators as the One > True Way To Do Math, well, that's your prerogative. I will probably still > choose Rust over Swift. But then I feel like Rust might be missing out on > the free lunch I expect Swift to provide, which is sad if that's the way > the cookie crumbles... > > -- > Tony Arcieri > > _______________________________________________ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > >
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
