Not sure whether this is the right forum to post this. Let me know if it is not and please guide me to the correct forum where I could post this message:
I was wondering if Rust compiler could provide options for various profiles i.e. say if some developers from the embedded community wants to evaluate and use Rust for their project, then their first port of call should be the embedded profile of the Rust language; and if they want to then further explore the language then they could look at, enable and use the other features of the language. Similarly for the smart-contracts community there could be a separate profile of the language available(where only specific features of the language could be available to compile a smart contract), same for the HPC community and so on. In addition to the compiler providing a switch to enable profile(s) during compilation, the development and community organisation would also need to be formed based around this idea. Each profile community will decide on the RFCs for their specific profile/domain and in consultation with the core profile team implement the RFCs.
What problem will this solve? Well, this will solve the problem that will arise down the line if not taken careoff now before the language grows with more features. Officially supporting different profiles will help newcomers to the language to not get overwhelmed by the whole language and help them concentrate on the specific profile of their domain. C++ is plagued with this problem. For Rust to avoid being in the same situation it will be helpful if language profiles are officially supported at this early states of language creation. I remember reading long back, may be more than 18 years ago, that there was a proposal sent to the C++ standards committee to officially support embedded profile(EC++). But that proposal was rejected and then compiler writers had to, in a non standard way, support various incompatible compiler switches to unofficially support that profile!
Hmm, imo, this job is mostly provided by keeping more functionality in crates than not. As in, if a feature were needed by smart-contracts only, it has no place in the standard library, but instead in a crate.
This is mostly already provided by working groups focusing on specific things, no? For example, there is a specialised Embedded WG dealing with deploying Rust on embedded systems.
That kind of reminds me of the portability working group, but on a higher level. You should be able to find some discussions about it here or on the internals forum.
I was suggesting more of a compiler-level support for switches to activate/deactivate language features/constructs and not library/crate-level implementations e.g. some smart-contracts may want to disable looping constructs for security reasons, so when a developer uses, say --smartcontract switch, then the looping construct is not available in the language. So rather than provide feature-wise switches I am suggesting domain/industry wide switches e.g. for embedded, hpc, financial, security etc. Each working group decides what language features are enabled and disabled when a compiler switch for that domain is used during compilation. Documentation of the language also then needs to be from the point of view of the domain/industry rather than a monolithic language applied for all sectors. This separation of the "user facing" language into separate domain/industry specific profiles will help newcomers concentrate on the specific profiles rather than the whole language. Similarly all officially developed crates(which are now included in the mix of 15K+ crates, and growing) should be categorised to match the profiles so that newcomers know what category of crates are available for their chosen language profile.
Yes, there are. Other languages, such as C++, too have similar working groups. But what I am suggesting is changing the organisation and mandate of these working groups in such a way that they become the interface to the newcomers from their respective domains rather than the newcomer having to directly face the monolithic language that is being developed also by additions from other various working groups. The present working groups are formed and work from the point of view of the language developers, but I am suggesting that they should also work and organise themselves from the perspective of the language user. This will require a different outlook, organisation and mandate of the working groups. Take an analogy from the Linux kernel and device driver development world. The kernel is huge and a complex piece of code. For any new device driver developer it will be scary to understand all the kernel and the device driver code infrastructure. Instead what the Linux kernel community has done is divide the driver infrastructure into subsystems. So when a new graphics device driver developer starts driver development, s/he knows where to look at and does not have to be concerned about what the disk driver or network driver subsystems is, nor does additions from those subsystems proliferate unwarranted into the graphics driver subsystem. This reduces the cognitive load on the driver developers and it becomes very easy for driver developers to use the kernel and device driver infrastructure in an ever increasing system. This same mechanism can be used for language development; here the core language profile is analogous to kernel and the various add-on domain/industry specific profiles are analogous to device driver subsystems. Some might think that this is not required for languages because languages are not as complicated as OS kernel and device drivers. But look at the situation of C++. As Rust is young we may not feel the requirement of this approach now, but think of the situation 15-20 years down the line when more features are added to the language by each and every working group. If a policy and development approach keeping the working groups as the interface to the language rather than the monolithic language itself is setup now, then this approach to language development will be consolidated by the time the language becomes ubiquitous; and it will help newcomers to the language for years to come.
What I am suggesting is that the specific working groups should be the main interface to the newcomer of a domain/industry rather than the monolithic language as a whole. The language as a whole is a result of additions by various other working groups. This complicates matters for newcomers to the language. Instead if working groups decide what language features are enabled and disabled for the profile that they are responsible for, provide compiler switches for their respective profiles and document those profiles(along with information on officially supported crates for those profiles), then any user new to Rust will know what profile to look for to solve his/her specific domain problem. Please see my reply to @IsaacWoods above for details and the comparison to the Linux kernel and device driver subsystems as an example. At present the setup is bottom-up where as my suggestion is for top-down approach; at present the working groups are behind the walls of the monolithic language but it will help if the working groups are at the front acting as filters to the monolithic language. What filters to use is decided by the users of the language. It is like Model-View from UI world i.e. single model but multiple views of the same model depending upon the user of the model. Here model is the whole Rust language itself and views are the different profiles.