Rust Gets A 2018 Roadmap, Big "Productivity" Edition Planned This Year

[barendregtscubeprime]

- The borrow checker library only has compile time cost , types as function parameters ( replacement of generics ) result in static dispatch so no performance loss there ( but mir may have to be modified to keep the benefit of pre monophormization optimizations ) , emulated traits would be like a transcompiler ( think c with classes ) , ( so again the problem would to keep the compile times quick ? )

-the first one is only currently worse because c++ wasnt designed for that kind of metaprogramming , first class types are more flexible and introduce new kinds of api safety yet they result in a less bloated language , i dont know if rust's syntaxis is up for the task of practically emulating traits/oop with metafunctions

I took a quick look at zig over lunch and it looks like it's significantly less powerful than Fomega. It's difficult to tell because the compiler crashes when I test interesting computations over types (granted I was only able to compile 0.1.1, I'll get master working when I can spare some free time to fight llvm).

The term "first class types" is used on the website but it's not clear to me what this means because as far as I can tell there's a clear phase distinction and reduction doesn't appear to be possible on terms with free variables. Having not yet properly investigated it's unclear what affordances are offered over templates, it's also less powerful than macros (which as ssokolov noted, solve a different problem). Do you know if there's a prototypical example of what can't be done with templates?

I hope I've not come off as argumentative as I'm genuinely curious to know more about zig and hear your thoughts as I'm unfortunately short on time recently.

[ssokolow]

- The borrow checker library only has compile time cost , types as function parameters ( replacement of generics ) result in static dispatch so no performance loss there ( but mir may have to be modified to keep the benefit of pre monophormization optimizations ) , emulated traits would be like a transcompiler ( think c with classes ) , ( so again the problem would to keep the compile times quick ? )

-the first one is only currently worse because c++ wasnt designed for that kind of metaprogramming , first class types are more flexible and introduce new kinds of api safety yet they result in a less bloated language , i dont know if rust's syntaxis is up for the task of practically emulating traits/oop with metafunctions

I don't see how your comment is a response to what you quoted, so I can only treat that non sequitur as an attempt to change the subject and I'm not interested enough to follow along as you do so.

[mmstick]

I had a mini-project a few weeks ago to write a very basic webapp for myself. I thought "hey, why not make it a bit more exciting and write it in Rust?" which I did and found worked very well. I looked at rest server libraries and found that Rocket was the only one that really fit my needs, it works really well and the APIs are clean and easy to use

BUT

I had to use rust-nightly to be able to use this library? rustup made it very easy to get rust nightly installed and I got it working within 5 minutes, but it still concerns me that a library needs the nightly version of the language to work.

Rocket's creator is keen on using every unstable language feature he can get his hands on. Which, in a way, is a good thing, because if no one were to do this, then there'd be no one to give any feedback and live demonstrations of those features in practice. There will always be unstable features, and libraries which use those unstable features, no matter how mature the language is. Yet the general consensus in the community is to stick with stable when releasing a library, especially if that library is marked as stable (v1.0+).

If a library is in such a desperate need of new language functionality that it requires the nightly version of the language it just doesn't seem like Rust is mature yet.

There are plenty of other similar libraries that don't require a nightly version of Rust. Gotham, for example, is a good alternative to Rocket. It even says it right on the front page:

Stability Focused Gotham targets stable Rust. This will never change.
Gotham is also automatically tested against Rust beta and nightly.

[GunpowaderGuy]

C provides features which would allow me to reinvent function calls rather than using the built-in support. That doesn't mean I'd want to do it.

Also, just because something can be used to reinvent something else doesn't mean they communicate the same semantic constraints to the optimizers.

- The borrow checker library only has compile time cost , types as function parameters ( replacement of generics ) result in static dispatch so no performance loss there ( but mir may have to be modified to keep the benefit of pre monophormization optimizations ) , emulated traits would be like a transcompiler ( think c with classes ) , ( so again the problem would to keep the compile times quick ? )

-the first one is only currently worse because c++ wasnt designed for that kind of metaprogramming , first class types are more flexible and introduce new kinds of api safety yet they result in a less bloated language , i dont know if rust's syntaxis is up for the task of practically emulating traits/oop with metafunctions

[barendregtscube]

ctfe can be used to build a borrow checker as a library ( https://medium.com/@bhuztez/emulate-...g-db4b5e94449f ); first class types can make generics redundant ( as explained in the zig programing language website ) , if my understanding is correct , both features coupled with first class modules can be used to emulate traits / classes ; and they also reduce the need for macros , directly ( again , as in zig ) , and indirectly ( no traits means no custom derive )

Edit : almost forgot , cfte can also be used as a replacement for link time optimization , which cretonne is going to lack

I'm unfamiliar with zig and not able to have a detailed look at the moment so please take my remarks with a pinch of salt.

As ssokolov noted although Fomega is expressive enough to encode classes and the interesting bits of modules it's rather painful to work with directly. I had a cursory look at zig and it appears to be some basic compile time evaluation likely without a proper formalism underlying it (please excuse me if I'm mistaken, I'm unfortunately not able to look closely at the moment). Perhaps someone can try to get the typechecker to diverge (evaluation likely occurs with an upper limit on the allowable steps).

Regarding the remarks about Haskell. In my opinion Haskell's encoding of dependent types is right for the context but wrong in general (again basically an embellishment of Fomega). I've also always found it somewhat bizarre that no one brings up dml/ats which basically already solved this problem (including with the addition of linearity).

[ssokolow]

My impression is that there are several aspects to that. One is that, while the language itself is fairly mature, the same is not yet true of the library ecosystem around it... there's work going on to filling the gaps, but there's a lot still to happen. A second is that a lot of the people building libraries are the kind of people who like to work on nightly, who like to take advantage of new language features that are in the pipeline... but by doing so, their work isn't accessible to those who just want to build on a stable platform. And that in turn is partly because some of those new features are actually kind of important building blocks... notably the async stuff...

Also, Rocket is very noteworthy in that its author intentionally chose a "Here's what I want. I'm not compromising. Let other web frameworks aim for near-term stability." relationship with unstable language features.

[ssokolow]

ctfe can be used to build a borrow checker as a library ( https://medium.com/@bhuztez/emulate-...g-db4b5e94449f ); first class types can make generics redundant ( as explained in the zig programing language website ) , if my understanding is correct , both features coupled with first class modules can be used to emulate traits / classes ; and they also reduce the need for macros , directly ( again , as in zig ) , and indirectly ( no traits means no custom derive )

Edit : almost forgot , cfte can also be used as a replacement for link time optimization , which cretonne is going to lack

C provides features which would allow me to reinvent function calls rather than using the built-in support. That doesn't mean I'd want to do it.

Also, just because something can be used to reinvent something else doesn't mean they communicate the same semantic constraints to the optimizers.

[Azpegath]

What's wrong with the Ruby syntax?
Do you also hate other things you don't understand?

Do you not understand Michael?

[Delgarde]

I guess I made the mistake by assuming that Rust was somewhat mature due to it having a 1.0 release, but now I realize that the 1.0 release only means that it's stable rather than mature.

My impression is that there are several aspects to that. One is that, while the language itself is fairly mature, the same is not yet true of the library ecosystem around it... there's work going on to filling the gaps, but there's a lot still to happen. A second is that a lot of the people building libraries are the kind of people who like to work on nightly, who like to take advantage of new language features that are in the pipeline... but by doing so, their work isn't accessible to those who just want to build on a stable platform. And that in turn is partly because some of those new features are actually kind of important building blocks... notably the async stuff...

[johanb]

I had a mini-project a few weeks ago to write a very basic webapp for myself. I thought "hey, why not make it a bit more exciting and write it in Rust?" which I did and found worked very well. I looked at rest server libraries and found that Rocket was the only one that really fit my needs, it works really well and the APIs are clean and easy to use

BUT

I had to use rust-nightly to be able to use this library? rustup made it very easy to get rust nightly installed and I got it working within 5 minutes, but it still concerns me that a library needs the nightly version of the language to work. If a library is in such a desperate need of new language functionality that it requires the nightly version of the language it just doesn't seem like Rust is mature yet.

I guess I made the mistake by assuming that Rust was somewhat mature due to it having a 1.0 release, but now I realize that the 1.0 release only means that it's stable rather than mature.