Looks like flying cars are back on the menu, boys!
In what is called inflation, the space-time of the initial event immediately expands into the enclosed space created by curvature, as it transitions state from infinite empty to finite space-time. As it does so the total energy of the universe rapidly increases, along with total curvature, so the actual area also shrinks. When the thus rapidly shrinking universe meets the inflating event, inflation ends; the latent energy driving inflation becomes matter. This part is well explained elsewhere.
The universe also dissipates, though different mechanism, is analogous to how black holes do. As the universe dissipates, it's total energy content becomes smaller, so the total curvature of space-time decreases and the enclosed space-time becomes larger; it expands. The rate of dissipation is proportional to the total enclosed "surface area" of space-time. Eventually it returns to the uniform empty symmetric and infinite flat state it began in.
The main thing I see holding back @go is @google. Once you disregard what #google people said about how to use #golang, such as having a common ~/go directory for all sources (dumb) and always building from tip (dumber) as utter nonsense, and just use go modules with a project level makefile or cmake to run go build and make up for the utterly stupid #fail lack of proper project level metadata in the go mod file, it actually becomes somewhat sane and convenient to actually use.
C++20 would change the way I make applications with modules and the ability to really use type inference universally for function returns without the header vs source split which limits use to inline or local functions. This is the one real disappointment I find in #rust in that they chose not to do type inference for function returns, though they already have what modules now does for C++20, and very similar reasons to have done so since complex types are often returned in rust.
Well, I joined @codeberg as a supporting member of the non-profit. It just seems too good not to support a EU-hosted, modern code forge.
I am not put off by #rustc rapid changes as I hear Stallman seems to be, since I think this is already addressed by specifying rust "editions", which only changes every few years, as specified in cargo toml, unless there is something I am missing.
At least I now have all of my current packages relocated to @codeberg . Now I just need to update many repos with corrected links in documentation and things like that.
@Venezuela Colonial economics never died. Venezuela has sufficient urbanization, diversity, and now access to education to develop and sustain a vibrant and advanced tech economy, but was never permitted to do so last century. Colonial capitalism also favors concentration of industry in only limited domains that can also be controlled under a few hands.
@codeberg I am happy, I have finally been able to take my first repo (#produceit) thru a production release cycle hosted on #codeberg, as I had to update my release workflows and deployment support scripts. This will make it much easier to start migrating my other repos to codeberg now. One quirk is that tags are out of order in the repo branch|tag chooser, with the new tag on the bottom of the list, after the imported ones, but are correctly ordered on the release page itself.
@ilyess gitea makes it easier to run pr's without having originating issues because they can have all the properties of an issue, be together with issues on project boards, and have non-overlapping id numbering. This changes how I use issues to avoid unneeded duplicate tracking of issues and pr's on boards and feels different than gitlab which prefers having all pr's tied to issues and assumes branches will be named based on an issue #, too.
@codeberg this actually also touches upon workflow. In github, of course, forking to work in personal repos is the common practice, and gitea seems to follow this. gitlab usually has everyone work in the project repo directly so all work is public if the repo is. In the case of codeberg policy, while the main project repo obviously should be public, do the personal developer forks need to be as well?
I develop secure communication solutions and I am chief for the Cherokees of Idaho
Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.