They have a bunch of differences under the hood, particularly when you want to give perms. It makes sense, sort of, on its face, that a user can’t have teams, but why? That decision is pretty arbitrary, to me. Then in GHE, users and orgs have all sorts of fun differences when you consider things like internal/public/private and how people can interact with them; to wit, if you’re in ANY team you can see ANY internal repo in an org, but if you’re limited to just personal repos, you can see no such things.
The Cue integrated Kubernetes project I'm most excited about is KubeVela[0]. Effectively, you can create an "operator" for just the YAML bits to narrow your Kubernetes API and provide best practices via the Components and Trait overrides, and it should allow platform teams to standardize how their teams are deploying software on large Kubernetes installations.
My initial misread was about classroom sizes, and I came to the same conclusion before I thought "huh, that's... not how you reference classroom size".
"Yesterday morning" and "tomorrow morning" is my favorite example. Several previous Indian coworkers of mine would say "today morning", which always made me smile a bit. It's not an unreasonable phrase to exist, given the others do as well.
In German the word for morning and tomorrow is the same, "Morgen".
But "tomorrow morning" becomes "Morgen früh" which is "tomorrow early" (or "early tomorrow" in English). "Morgen vormittags" ("tomorrow before noon") is also a variation.
DateTime was added in Elixir 1.8.0. Timex filled a vacuum for a long time, and still has a few nice convenience functions. In new codebases, I of course drop Timex, but it was very much needed until those APIs were added.
It had them. But if you did a System.get_env inside the config.exs/dev.exs/prod.exs etc it would be at compile time. Various patterns arose to do that at runtime, by using things like `{:system, "FOO", Integer}` as conventions, but it was always a bit ad hoc. If a lib saw that they would know to punt the actual reading to runtime, which is what many folks did before releases.exs, which runs at RUNTIME, so things like System.get_env work as expected.
The mechanism that Elixir used for providing different configuration values for dev, test, and prod (via dev.exs, test.exs, and prod.exs files), did not work well with environment variables, since those configuration files were evaluated at build time, which wouldn't work if you built, e.g., a single prod app and wanted to run it with different ENV vars in staging and prod.
Meanwhile, as of Elixir 1.10, there was a file called releases.exs which you could use to configure your release (basically a compiled artifact that included the BEAM VM runtime system that you could drop on your server to run, the preferred way of deploying production apps). However, those values didn't affect running the app not as a release, which is common when developing locally.
In the end, our organization kind of standardized on an approach of reading the ENV vars in the app start up, at the top of the supervision tree, which kind of worked in all scenarios.
But then in Elixir 1.11 there's finally a great (IMO) way of configuring: a new file called runtime.exs which is the best of all worlds. Like the old dev/test/prod files, it's evaluated when you run a mix project, so it's used during local development, and has access to Mix.env, so you can set variables based on environment. But it instead of being evaluated at build time, it's evaluated at run time, so you can refer to environment variables, too. And, it's used by releases!
So now there's a very slick standard way to configure your app, that works in all situations.
When entering the camps, they made sure to document well, because they knew no one could possibly believe the extent of the atrocities without seeing themselves.
