I think hiring of devs might be good long term though provided funding is there. There are always areas which might not be something people would work for fun on but which might be important to ecosystem.
Framing Mozilla as the “steward of the language” is one reason why we’re making this move. Don’t get me wrong, Mozilla is important to Rust, but (in all things other than the trademark, which is a nuclear option they’ve given no indication of ever using) the relationship is much more of a “large supporter of” then “in control of” one. Having a foundation would make this much more clear to folks who aren’t deeply involved in Rust.
From the very beginning, the folks sponsoring the Rust effort from within Mozilla made sure that Mozilla couldn't directly control things. And Mozilla also just isn't that kind of organization to begin with, honestly.
These conversations have been going on a long time. This particular iteration of this conversation started before I left Mozilla. It has nothing to do with me personally, regardless of that relationship.
I have long (before, during, and after my employment at Mozilla) have thought that an independent foundation would be excellent for Rust, but am worried about the details. Foundations require active administration, which is even more work. And it's unclear who does that work. I think that we've grown to the point where it very well make sense now, though.
Friendly reminder for people on HN reading this:
I know this is actually quite interesting, but before you start worrying about the latency of the name servers of your TLD, you might want to do something about the metric ton of JavaScript on your site and the 25 different 3rd party servers from which you side load most of it. Also those 6 additional servers from which you load a bunch of TTF fonts. Especially if all your site does is just display some text and two or three pictures.
I assume it may not be a popular opinion here, but it would be so much easier if projects like Rust could have a DAO (decentralized autonomous organization) instead of a foundation, and a blockchain account managed by this DAO instead of a bank account.
The main issues I see with this idea are volatility of cryptocurrencies prices, inability of paying with cryptocurrencies in most cases atm, environmental issues regarding the blockchain and the infantry of DAO governing models.
But as an abstract idea I believe DAOs will replace foundations at some point in the future, making such discussions much easier.
1. What is the advantage of a DAO in your eyes? (Your comment mostly says that one could be done, not why.)
2. The Rust community is made of people who have been trying very hard to write, essentially, a bug-free compiler and a bug-resistant programming language, and they know it is incredibly unrealistic to be 100% bug-free. How would you convince them that a DAO with its terms specified in code and not in human legal documents would not have even a single exploitable bug?
You're right, I should have mentioned the advantages to begin with.
It's easier, cheaper and faster to setup a DAO than an international foundation, especially regarding registration, opening bank accounts and international members. Important questions such as "which jurisdiction to register the organization in" or "who manages the bank account" becomes irrelevant in a DAO.
It's also cheaper and easier to manage a DAO over time than a traditional foundation. There is no need of payments for bureaucratic stuff, since the protocol is in charge of organizing and executing decisions.
I don't belong to those convinced it's possible to write bug-free code, however, not every bug means immediate exploit, while exploits can also happen in legal contracts.
The immediate solution is a DAO where access is limited to known legal entities. In case a bug is exploited, you can always fall back on the good old legal system to resolve the conflict.
There are other possible solution, but I don't want to turn this comment into a lecture about DAOs.
We use a DAO in a project I've been involved with for a long time in the past, Bisq. I'm not sure how we could have managed it otherwise, since we were a small project, with contributors all over the world, most of them not knowing each other personally.
> It's easier, cheaper and faster to setup a DAO than an international foundation, especially regarding registration, opening bank accounts and international members. Important questions such as "which jurisdiction to register the organization in" or "who manages the bank account" becomes irrelevant in a DAO.
I never understood these arguments. People do not live in an abstract space outside existing social and economical structures. If one way or another, this DAO thing turns into an actor paying wages, the related laws will apply in some juridiction.
Now, what you might say is these questions become irrelevant for the structure creating the DAO, and are instead left to be solved by those receiving the benefit. It sounds dubious at best.
I didn't meant the DAO to be an actor outside the legal system.
The difficulty of answering your remark is that different legal systems probably have different point of views about it.
According to what I was told where I live, I'm allowed to organize activities, even such involved payments, with other people without registering an organization. Especially if those other people come from different countries. As long as I'm declaring my full income and pay taxes.
Such a thing limits what a DAO can do - for example, it can't sign agreements with regular companies (it's not a legal entity) or it cannot employ people.
But as long as you don't do such things, I was told it is allowed. I'm being careful with such statements since I'm not a lawyer.
You may see DAOs as a legal alternative for civil agreements, which are really difficult to make for individuals in the international market.
> Such a thing limits what a DAO can do - for example, it can't sign agreements with regular companies (it's not a legal entity) or it cannot employ people.
The article starts by saying that they want to demonstrate that Mozilla is not the sole entity behind rust.
After that, the very first reason they give for wanting to start a foundation is to sign contracts.
> Lately, though, the Rust project has started to hit the limits of what Mozilla can reasonably support. One common example that arises is the need to have some entity that can legally sign contracts “for the Rust project”. For example, we wished recently to sign up for Github’s Token Scanning program, but we weren’t able to figure out who ought to sign the contract.
I don't understand how a DAO would solve their problems.
One problem they listed is having a bank account which would hold onto money from a few sponsors temporarily for a particular conference, before paying it out to catering, venue, and airfare.
How would that work for a DAO? Would you have to write a new contract for each conference? What about paying for last minute arrangements (a flight gets diverted and you need to pay more for travel)?
Would the contract allow for that, or block that spending of funds?
Actually, how would it block the spending of funds, or tell what you are spending the money on? It's not like Delta has a bitcoin address you can specify in the smart-contract. You have to pay them in dollars.
> I don't belong to those convinced it's possible to write bug-free code, however, not every bug means immediate exploit, while exploits can also happen in legal contracts.
The legal system has had centuries of time with millions of people working out "bug-free" code. Something like a DAO might work for your situation but any organization with the sort of resources Rust has would be completely negligent to rely on such a comparatively untraveled path.
> should the Foundation be a 501(c)(3) (a non-profit, in other words) or not?
If you go the independent foundation route, choosing 501(c)(3) would be in keeping with the stated priority to have Rust's governance be independent. This makes it more difficult for corporations to control the foundation's direction through insisting that their donations be used for specific purposes, because donations to a 501(c)(3) cannot unduly advantage any commercial entity.
ETA: There are different types of "non-profit" organizations under IRS code 501. 501(c)(3) is a "Charitable Organization", and donations are tax deductible. (Tax-deductible donations cannot be used to unduly advantage a commercial entity because if they were, the business could avoid paying taxes on funds they use to further their own initiatives.) 501(c)(6) is a "Business League", where donations are not tax deductible, so donors have much more leverage.
The problem with trying to become a 501(c)(3) nonprofit is that you have to show a "charitable purpose", which can sometimes be hard to do ("supporting open-source software" is not a valid charitable purpose under current US law, sadly enough) [not legal advice]
I'm so incredibly not a lawyer, but my understanding is that educational 501c3s need to be predominately educational, in that they have classes and a physical location.
If the primary purpose of the Rust foundation is open source code and standardizing the language, it's not exactly educational.
I successfully started a 501(c)(3) private foundation for precisely the charitable purpose of "supporting (scientific) open source software" in 2017. The IRS granted it with no questions asked.
Also not legal advice, but I literally did it so...
I have a lot of experience in building open source foundations, from my time at Apache, Eclipse and the Linux Foundation, lots of pros and cons across different entities in terms of how much professional help you want (versus volunteer labor). I generally don't recommend standing up your own foundation from scratch unless you're extremely well funded. The Linux Foundation essentially offers "Foundation as a Service" for projects. It hosts a variety of projects and organizations, from LetsEncrypt.org, to Kubernetes (CNCF) to GraphQL to NodeJS (OpenJS) to the R Consortium and more. I created a presentation here not so long ago about the process/benefits: https://www.slideshare.net/caniszczyk/bringing-an-open-sourc...
I'm happy to have a conversation if you ever wanted to chat more about the details.
Governance can be set up in a number of ways, depending on the charter, with power allocated to different stakeholders in different configurations. See slide 42 from Chris's presentation. As a Rust user, I would follow the creation of such a charter with great interest.
Moving away from Mozilla, regardless of destination, presents an opportunity for the most powerful stakeholders within the community to exert greater influence, many of whom I would be less comfortable with than Mozilla.
To be honest I don't know what this means. I was expected a yes or no answer. Does the Linux Foundation have final say over the organization or does its members?
Projects can be set up so that one entity (possibly a company which is a Linux Foundation Member) exerts dominant influence. This is one reason that many companies are comfortable bringing projects to the LF — and that's arguably better on balance for the Open Source ecosystem than them keeping those projects in-house and their governance murky.
Rust, though, is already at Mozilla, whose influence seems to be benign.
I'm curious, which Mozilla entity holds the trademark: is it the 501(c)(3) Mozilla Foundation, or is it their for-profit subsidiary, the Mozilla Corporation?
> I'm curious, which Mozilla entity holds the trademark: is it the 501(c)(3) Mozilla Foundation, or is it their for-profit subsidiary, the Mozilla Corporation?
I never thought about this, but TESS says it's Moco, which is what I'd expect.
I wonder if it's reasonable to donate that trademark to the 501(c)(3) Mozilla Foundation and to then formalize a charter laying out Rust governance.
For what it's worth I would have greater confidence in such an arrangement than I would in a 501(c)(6) Business League version of a Rust Foundation, which would in my view undermine independence.
I saw you posted this in other places too. Several of us have some LF experience, so we're already broadly familiar, but I appreciate it! We'll reach out if appropriate, thanks!
It's a bit contentless and an example of the vapidity and 'community' that infects open source projects that get legs. Your e-mail is in your profile, and coffee between two human beings can be coordinated via such a mechanism, but then you wouldn't get to show off how connected you are, I suppose. You literally responded to someone criticizing the conversation to follow up that, no, indeed, the criticism has merit, and for some reason we care that you know who Myles is. That speaks a lot about what's important to you, and people who aspire to be like you, in this industry. I would have figured those who have watched other industries create "boards" and "foundations" and other charities where the seat on them becomes a brokered commodity would take pause before subjecting tech to the same drivel.
Also: what "baseball?" Are you alleging you're behind the scenes in tech and we should all be privileged for you sharing this glimpse into how the world works with us? What an honor. How do we get to be as cool as you, dropping first names in HN comments of people who've created authority for themselves with mailman and an open source project? There's no baseball here, just vanity positions created to pad resumes and people who follow you on Twitter fawning over two programmers getting coffee.
I have an @apache.org e-mail, too, it's not a status symbol, but you do you
Wow. You created a Hacker News account an hour ago just to say this?
Who cares if it's "contentless?" Interactions on HN are frequently petty, mean spirited, and uncivil. Two people who are extremely active and give a lot to two different communities but don't know each other in real life had a pleasant interaction here that could have a fruitful outcome. Was this an event of Earth-shattering importance? No. But to read it as an illustration of the "vapidity...that infects open source projects" strikes me as noxiously cynical.
Event planning resources for conferences, graphic design help, legal staff who specialize in OSS issues, money for infrastructure costs (CI/CD, compute and storage resources), money for day-to-day tools (JIRA, Slack, Zoom, Discourse), documentation and web design resources, and much more. Basically all of the background conditions necessary for collaboration and ecosystem growth to be as unimpeded by resource scarcity as possible.
ANSI C compilers are not required to still support K&R C, Annex K was compulsory on C99, became optional on C11, gets() was removed, some semantics corrected,....
Every non-toy, non-academic programming language should be non breaking. I know, there is a gray zone and some do not give a sh*. But as a company it is really hard investing into something that is breaking.
I'd prefer the evolution of Rust to slow down and stabilize. More like C and much less like C++. OTOH there are a few things I feel the language needs. Better control of memory layout, and a stable ABI in particular, so it can become a good foundation for more libraries and infrastructure.
And memory layout through repr(align). I also disagree that rust should slow down. There are a number of critical features that need to land for the language should “stabilize” (it is stable).
I agree a few more things need to get in. But AFAICT the abi is not stable and you may need to recompile all dependencies when updating the compiler.
I would like it to be "feature complete" without having regular churn like C++. Or the recent battle with Python that was a sort of last straw for Guido. C is almost completely stagnant and that's a good thing. Posix as well. If you want to be a long term systems language it seems stability is a critical feature and Rust needs to get that in the next few years. IMHO or course.
C++ didn’t have a pragmatically stable ABI until like a year ago on MSVC. You had to jump through hoops with extern C APIs or COM and the like. The same is true in Rust, and even in C++ with different tool chains on windows.
The only language with a stable ABI is C (and that is more accidental than explicit). It’s too hard a guarantee to provide with little ROI when you have a workaround, and it chains your implementation to ABI details.
Just as an example, rustc is very clever about struct layout and liberally pads fields to get superior alignment. This may change in the future depending on architectures and paradigms. You don’t want your ABI to define a padding scheme for your targets today, you want future compilers to be smarter.
If you want to guarantee stability you need to align the memory manually on the structs that cross ABI boundaries like shared libraries, and any kind of language construct that lets you do future tricks with ABI within a binary but provides escape hatches for things along the boundary would look identical to how you do things today via attributes.
TL;DR ABI stability in the compiler is simply not desirable. You can already do it manually and you should do it manually. It’s fairly ergonomic as well.
Furthermore, GCC/libstdc++ have maintained ABI compatibility for at least 15 years now, even across an incompatible change of std::string and std::list required for C++11 conformance, so in practice the situation with C++ looks better than with Rust.
There is a trade-off between "provide types a stable layout" (required for a stable ABI) and "optimize my program as much as possible" (e.g. change type-layout using profile-guided optimization to put hot fields inside the same cacheline).
In Rust, if you want to give a type a stable ABI, you just need to stamp `#[repr(C)]` on it. Otherwise, you get optimizations by default.
The amount of types and functions in a code-base is usually much larger than its surface API, and this decision balances optimizing properly, while still providing a stable API.
A classic example of this going wrong is the Gentoo Foundation. Not only did it make them lose the founder of Gentoo (which, admittedly, isn't as much of a problem with Rust: Hoare has already moved on to bigger things), but it caused a variety of organizational troubles that still can be seen in Gentoo today.
Note that this proposal is not about changing the governance of Rust the language. That is and will remain the responsibility of an independent group. This is purely about handling administration of the Rust project and having a legal entity which can sign contracts, hold trademarks, own domain names, etc.
Depending on how you set up administration, independent governance can become difficult to sustain. The more money you take from donors, especially "directed" donations with strings attached, the harder it is.
For example, you may fear offending a donor who wants to use the "Rust" trademark for their megabudget conference where they sell themselves as the preeminent Rust experts.
This comes into play if you consider funding development directly through a foundation, which requires large donations.
Yeah, that's why I'd prefer for the Rust Foundation to be as lean as possible, explicitly excluding raising donations for the whole project and paying developers from its scope. Funding development could then be done by other entities, not related to the foundation.
The time is right for this step, Rust will benefit from having a proper umbrella organization. Also, it's a very well-writen post on what could be a boring topic.
The Rust project has much more things under its wings than the C ISO group does. It’s a superset.
The Rust project sees Rust as more than just purely a language. For example, the C ISO group doesn’t run any web facing infrastructure, with all of the legal and financial obligations that implies, nor do they develop compilers, with all of the CI/hosting infrastructure that implies.
They’re just different in scope, which has been true for all of Rust’s lifetime.
That is common for toy languages without wide industry support. It doesn't inspire confidence.
There should be compilers from Microsoft, IBM, Apple, GNU/FSF, and several others. There should be a properly ratified international standard that describes the language. There should be support from 16-bit microcontrollers to mainframes.
Languages like C have lots of web facing infrastructure. It just isn't all run by one entity. The eggs are not in one basket.
An independent foundation for Rust makes a lot of sense. No doubt the Linux Foundation will pounce on this opportunity to absorb yet another project into its orbit... I would prefer if Rust steered clear of LF / CNCF if possible. Their governance and financials are opaque, they prioritize corporate sponsors and fancy events at the expense of every other priority, and there is already too much power concentrated in a very small group of people.
The Linux Foundation / CNCF people will tell you that it's really hard to setup a foundation, and you should leave it up to them. I don't think that's actually true. In my opinion LF gets much more value out of projects (through compounded brand value and revenue opportunities) than the other way around.
Nothing terrible will happen if you go with them... but nothing amazing will happen either. You will get the bare minimum support and infrastructure, and nothing more. Meanwhile, a few people who don't actually contribute any open-source code will benefit immensely from the Rust brand.
EDIT: I just realized that the Linux Foundation people are already on this thread making their sales pitch...
85 comments
[ 3.4 ms ] story [ 138 ms ] threadThese conversations have been going on a long time. This particular iteration of this conversation started before I left Mozilla. It has nothing to do with me personally, regardless of that relationship.
I have long (before, during, and after my employment at Mozilla) have thought that an independent foundation would be excellent for Rust, but am worried about the details. Foundations require active administration, which is even more work. And it's unclear who does that work. I think that we've grown to the point where it very well make sense now, though.
The main issues I see with this idea are volatility of cryptocurrencies prices, inability of paying with cryptocurrencies in most cases atm, environmental issues regarding the blockchain and the infantry of DAO governing models.
But as an abstract idea I believe DAOs will replace foundations at some point in the future, making such discussions much easier.
2. The Rust community is made of people who have been trying very hard to write, essentially, a bug-free compiler and a bug-resistant programming language, and they know it is incredibly unrealistic to be 100% bug-free. How would you convince them that a DAO with its terms specified in code and not in human legal documents would not have even a single exploitable bug?
It's easier, cheaper and faster to setup a DAO than an international foundation, especially regarding registration, opening bank accounts and international members. Important questions such as "which jurisdiction to register the organization in" or "who manages the bank account" becomes irrelevant in a DAO.
It's also cheaper and easier to manage a DAO over time than a traditional foundation. There is no need of payments for bureaucratic stuff, since the protocol is in charge of organizing and executing decisions.
I don't belong to those convinced it's possible to write bug-free code, however, not every bug means immediate exploit, while exploits can also happen in legal contracts.
The immediate solution is a DAO where access is limited to known legal entities. In case a bug is exploited, you can always fall back on the good old legal system to resolve the conflict.
There are other possible solution, but I don't want to turn this comment into a lecture about DAOs.
We use a DAO in a project I've been involved with for a long time in the past, Bisq. I'm not sure how we could have managed it otherwise, since we were a small project, with contributors all over the world, most of them not knowing each other personally.
I never understood these arguments. People do not live in an abstract space outside existing social and economical structures. If one way or another, this DAO thing turns into an actor paying wages, the related laws will apply in some juridiction.
Now, what you might say is these questions become irrelevant for the structure creating the DAO, and are instead left to be solved by those receiving the benefit. It sounds dubious at best.
The difficulty of answering your remark is that different legal systems probably have different point of views about it.
According to what I was told where I live, I'm allowed to organize activities, even such involved payments, with other people without registering an organization. Especially if those other people come from different countries. As long as I'm declaring my full income and pay taxes.
Such a thing limits what a DAO can do - for example, it can't sign agreements with regular companies (it's not a legal entity) or it cannot employ people.
But as long as you don't do such things, I was told it is allowed. I'm being careful with such statements since I'm not a lawyer.
You may see DAOs as a legal alternative for civil agreements, which are really difficult to make for individuals in the international market.
The article starts by saying that they want to demonstrate that Mozilla is not the sole entity behind rust.
After that, the very first reason they give for wanting to start a foundation is to sign contracts.
> Lately, though, the Rust project has started to hit the limits of what Mozilla can reasonably support. One common example that arises is the need to have some entity that can legally sign contracts “for the Rust project”. For example, we wished recently to sign up for Github’s Token Scanning program, but we weren’t able to figure out who ought to sign the contract.
One problem they listed is having a bank account which would hold onto money from a few sponsors temporarily for a particular conference, before paying it out to catering, venue, and airfare.
How would that work for a DAO? Would you have to write a new contract for each conference? What about paying for last minute arrangements (a flight gets diverted and you need to pay more for travel)? Would the contract allow for that, or block that spending of funds?
Actually, how would it block the spending of funds, or tell what you are spending the money on? It's not like Delta has a bitcoin address you can specify in the smart-contract. You have to pay them in dollars.
The legal system has had centuries of time with millions of people working out "bug-free" code. Something like a DAO might work for your situation but any organization with the sort of resources Rust has would be completely negligent to rely on such a comparatively untraveled path.
If you go the independent foundation route, choosing 501(c)(3) would be in keeping with the stated priority to have Rust's governance be independent. This makes it more difficult for corporations to control the foundation's direction through insisting that their donations be used for specific purposes, because donations to a 501(c)(3) cannot unduly advantage any commercial entity.
ETA: There are different types of "non-profit" organizations under IRS code 501. 501(c)(3) is a "Charitable Organization", and donations are tax deductible. (Tax-deductible donations cannot be used to unduly advantage a commercial entity because if they were, the business could avoid paying taxes on funds they use to further their own initiatives.) 501(c)(6) is a "Business League", where donations are not tax deductible, so donors have much more leverage.
I'm so incredibly not a lawyer, but my understanding is that educational 501c3s need to be predominately educational, in that they have classes and a physical location.
If the primary purpose of the Rust foundation is open source code and standardizing the language, it's not exactly educational.
Also not legal advice, but I literally did it so...
I'm happy to have a conversation if you ever wanted to chat more about the details.
https://www.slideshare.net/caniszczyk/bringing-an-open-sourc...
Moving away from Mozilla, regardless of destination, presents an opportunity for the most powerful stakeholders within the community to exert greater influence, many of whom I would be less comfortable with than Mozilla.
Rust, though, is already at Mozilla, whose influence seems to be benign.
I'm curious, which Mozilla entity holds the trademark: is it the 501(c)(3) Mozilla Foundation, or is it their for-profit subsidiary, the Mozilla Corporation?
I never thought about this, but TESS says it's Moco, which is what I'd expect.
For what it's worth I would have greater confidence in such an arrangement than I would in a 501(c)(6) Business League version of a Rust Foundation, which would in my view undermine independence.
Also: what "baseball?" Are you alleging you're behind the scenes in tech and we should all be privileged for you sharing this glimpse into how the world works with us? What an honor. How do we get to be as cool as you, dropping first names in HN comments of people who've created authority for themselves with mailman and an open source project? There's no baseball here, just vanity positions created to pad resumes and people who follow you on Twitter fawning over two programmers getting coffee.
I have an @apache.org e-mail, too, it's not a status symbol, but you do you
Who cares if it's "contentless?" Interactions on HN are frequently petty, mean spirited, and uncivil. Two people who are extremely active and give a lot to two different communities but don't know each other in real life had a pleasant interaction here that could have a fruitful outcome. Was this an event of Earth-shattering importance? No. But to read it as an illustration of the "vapidity...that infects open source projects" strikes me as noxiously cynical.
https://blog.cleancoder.com/uncle-bob/2019/11/08/OpenLetterL...
Go values not breaking current code much more than adding features.
"stability" is a tough word; some people use it to mean "doesn't change", and others use it to mean "append-only change."
Languages are software products, they are evolve to fulfill the market needs or they die.
ANSI C compilers are not required to still support K&R C, Annex K was compulsory on C99, became optional on C11, gets() was removed, some semantics corrected,....
I would like it to be "feature complete" without having regular churn like C++. Or the recent battle with Python that was a sort of last straw for Guido. C is almost completely stagnant and that's a good thing. Posix as well. If you want to be a long term systems language it seems stability is a critical feature and Rust needs to get that in the next few years. IMHO or course.
That is for the Rust ABI, which much like with for C++ doesn't exist.
The only language with a stable ABI is C (and that is more accidental than explicit). It’s too hard a guarantee to provide with little ROI when you have a workaround, and it chains your implementation to ABI details.
Just as an example, rustc is very clever about struct layout and liberally pads fields to get superior alignment. This may change in the future depending on architectures and paradigms. You don’t want your ABI to define a padding scheme for your targets today, you want future compilers to be smarter.
If you want to guarantee stability you need to align the memory manually on the structs that cross ABI boundaries like shared libraries, and any kind of language construct that lets you do future tricks with ABI within a binary but provides escape hatches for things along the boundary would look identical to how you do things today via attributes.
TL;DR ABI stability in the compiler is simply not desirable. You can already do it manually and you should do it manually. It’s fairly ergonomic as well.
Java, .NET languages have a stable ABI.
All IBM and Unisys mainframe languages have a stable ABI via their language environments.
https://docs.microsoft.com/en-us/cpp/porting/binary-compat-2...
Furthermore, GCC/libstdc++ have maintained ABI compatibility for at least 15 years now, even across an incompatible change of std::string and std::list required for C++11 conformance, so in practice the situation with C++ looks better than with Rust.
https://developers.redhat.com/blog/2015/02/05/gcc5-and-the-c...
There is a trade-off between "provide types a stable layout" (required for a stable ABI) and "optimize my program as much as possible" (e.g. change type-layout using profile-guided optimization to put hot fields inside the same cacheline).
In Rust, if you want to give a type a stable ABI, you just need to stamp `#[repr(C)]` on it. Otherwise, you get optimizations by default.
The amount of types and functions in a code-base is usually much larger than its surface API, and this decision balances optimizing properly, while still providing a stable API.
Hope this goes well!
For example, you may fear offending a donor who wants to use the "Rust" trademark for their megabudget conference where they sell themselves as the preeminent Rust experts.
This comes into play if you consider funding development directly through a foundation, which requires large donations.
https://internals.rust-lang.org/t/blog-post-towards-a-rust-f...
This seems to imply that the US is the only place a foundation would be incorporated? Other jurisdictions may have more favourable legal regimes.
For example, C is handled by ISO/IEC JTC1/SC22/WG14.
The idea that Rust would need a foundation is making me uneasy.
The Rust project sees Rust as more than just purely a language. For example, the C ISO group doesn’t run any web facing infrastructure, with all of the legal and financial obligations that implies, nor do they develop compilers, with all of the CI/hosting infrastructure that implies.
They’re just different in scope, which has been true for all of Rust’s lifetime.
There should be compilers from Microsoft, IBM, Apple, GNU/FSF, and several others. There should be a properly ratified international standard that describes the language. There should be support from 16-bit microcontrollers to mainframes.
Languages like C have lots of web facing infrastructure. It just isn't all run by one entity. The eggs are not in one basket.
Java isn't officially standardized (ISO or such), neither are C# nor Python, Ruby, etc.
The Linux Foundation / CNCF people will tell you that it's really hard to setup a foundation, and you should leave it up to them. I don't think that's actually true. In my opinion LF gets much more value out of projects (through compounded brand value and revenue opportunities) than the other way around.
Nothing terrible will happen if you go with them... but nothing amazing will happen either. You will get the bare minimum support and infrastructure, and nothing more. Meanwhile, a few people who don't actually contribute any open-source code will benefit immensely from the Rust brand.
EDIT: I just realized that the Linux Foundation people are already on this thread making their sales pitch...