I wish a GCC Rust compiler, but it's not planed for 2017. Hope this can change in 2018 :)
Rust's 2017 Roadmap
211–220 of 274 posts
Re: Rust's 2017 Roadmap
#212I wish it have a good history for mobile development (iOS, mainly). I think a modern language without a good foot inside the mobile is non-ideal. Also, a nice history for UI native widgets will be a plus. This is ask a lot, I know. Right now I have some projects where the less-worse option is .NET, swift if only iOS+Linux, Delphi is because cost (and free pascal is unfocused). Then obviously C++, but that is where I…
If you like Delphi/Pascal, have you seen Nim?
Re: Rust's 2017 Roadmap
#213Earlier quoted context omitted.
> What about the warts part? I'm not sure enough time has passed to tell what Rust's warts truly are. I always joke String should have been called StrBuf... I do this, yes. This is one of the reasons I hang out in IRC so often; it's an effective way to collect these kinds of things. More data is always better, and collecting it across multiple venues. I don't think IRC is inherently going to be a representative sampl…
So I'm only a Rust amateur (I mean I don't get paid to use it), but I'm on my third round trying to build something with it, and I feel like I'm finally starting to get it. A couple warts I've encountered: - No support for default struct fields: https://github.com/rust-lang/rfcs/issues/1594 - Terrible signatures for functions that return iterators: https://www.reddit.com/r/rust/comments/2h26cj/functions_retu... If th…
I think if you don't mind the overhead you can box the iterator
Re: Rust's 2017 Roadmap
#214I once said that Rust would never become really, Java-level, popular. Mostly because I thought it focused too much on performance to the detriment of elegance and productivity. I'm not so sure anymore. This is a step in the right direction. That said, what makes me most nervous about Rust is pointers and mutability being mandatory for certain things, rather than the absence of books. Maybe that's just me, though. Any…
For my curiosity, what do you find in Java that you think is more elegant than rust?
Re: Rust's 2017 Roadmap
#215> fast, reliable, productive--pick three I love it. Short and simple, describes what Rust is. Between that and "an anti-sloppy programming language", pretty sure the marketing is there. Well done community leads, this is exciting.
It reminds me of the SQLite motto :
Small. Fast. Reliable. Choose any three.
Re: Rust's 2017 Roadmap
#216Earlier quoted context omitted.
That's a good point. It's slightly reminiscent of Haskell, where you have to start trying to understand the IO monad and do notation to do the most trivial real-world examples. In other languages, you might do File.ReadAllLines("foo.txt"), and bam, you're done.
Unless foo.txt is too big, in which case, bam, out of memory.
No, Python, ruby and such have a common interface for all lazy iterations.
In Python you can just loop on anything declaring the __iter__ method, and it will lazily yield results little by little.
IO related objects implement it plus an additional layer of interface so that you can do:
with open('file', [mode, encoding]) as f:
- for `line in f` to lazy read it line by line. This calls __iter__.
- `f.read([byte_count])` to read it all or some bunch of bytes. `f.seek(index)` to move around, etc.
- `f.readlines()` to get a list of all lines in memory.
- `f.close()` if you wish to close the file manually instead of letting the `with` keyword doing it work you.
This interface works for most IO, including files, sockets, in memory buffers, etc.
So you can choose an automatic lazy loading, a manual loading, load everything in memory, etc. And still have a lot of control.
I think rust should get some traits to expose such a common high level interface on top of the current way it deals with files, to ease simple operations. Just make sure the documentation states what you can do to go lower level.
There is a similar trend with many basic topics trying to do that as 3rd party libs too. click makes creating cmd UI very easy on top of argparse which is lower level. pendulum is higher level than datetime. requests higher than urllib. etc. Those all make doing those very common operation super easy.
Now rust is not meant to be Python/Ruby/whatever, being very low level, and checking safety at compile time implies very different requirements.
But those communities have some good concepts on API ergonomics and it would be a shame to not steal ideas from them.
Re: Rust's 2017 Roadmap
#217I'm surprised cross-compilation is not on the roadmap. I've heard that it is ready and that it's not quite ready.
Can I create a Windows executable for Windows on Linux?
Re: Rust's 2017 Roadmap
#218I wish a GCC Rust compiler, but it's not planed for 2017. Hope this can change in 2018 :)
The closest to that is mrustc [1], a reimplementation which skips the borrow checking part can generate C code. Eventually you might be able to compile rust code on more platforms, though you should still develop with the official rustc for the borrow checking.
Re: Rust's 2017 Roadmap
#219Earlier quoted context omitted.
We did. The ML family has been around for about 4 decades now. Not sure why they never caught on until Rust.
Pretty sure F# adoption dwarfs rust.
Right. Though I checked in Google trends and found Rust to F# interest went from 1/40 to 2/3 in 5 years or so. I think Rust will become more popular in next 2 years.
Re: Rust's 2017 Roadmap
#220Earlier quoted context omitted.
> Rust's genius is going after the market that can't use GC But the problem with that is that the market that really really can't use GC is vanishingly tiny. Rust throws the baby out with the bathwater and tries to pressure others into thinking that they are in this market. Most developers on most projects aren't. And then Rust implements reference-counted pointers in the library, which is the slowest possible way of…
> But the problem with that is that the market that really really can't use GC is vanishingly tiny. If you write a library in C#, you can use it from .NET languages. If you write a library in Java, you can use it from JVM-based languages. If you write a library in Python, you can use it from Python. If you write a library in Rust, you can use it from any language that can bind to C, which is virtually every language…
> If you write a library in Python, you can use it from Python.
Or from C. Or from any language that can bind to C. Like Rust. I'm fairly sure the other languages you listed also allow calling from C and hence from Rust, as well as among each other.
> not every object requires its own heap allocation
Sure. That doesn't change if you add a GC to Rust: Objects won't magically become non-stack-allocable if they were stack-allocable before.