domenkozar

Rust, mostly because:

- haskell exceptions and laziness are devastating for production

- too small ecosystem, had to write 10+ SDKs (now with AI that's less of an issue)

- haskell ecosystem is too fragmented due to prima donna prevalence

We at Cachix have also moved on from Haskell about two years ago and I'm sure someone is going to make a comeback with a language that takes the lessons from it but starts from skratch.

We need more general purpose Elm languages in the space.

We see project specific environments superior to having global packages installed.

You can do things like creating ad-hoc environments:

$ devenv -O languages.rust.enable:true shell

Once you teach your coding agent to use it, it will just use it to get packages if needs any: https://devenv.sh/integrations/claude-code/#global-configura...

We're going to see more social networks struggle and something like world.org or similar that protects privacy is needed.

What if GitHub Actions were local-first and built using Nix (proper locking)?

https://github.com/cachix/cloud.devenv.sh

You guys need to figure out how to create Slack shared channels in Zed and we're all switching until they won't be needed anymore.

Look at the problem statement, it's exactly the same. When I designed secretspec, I researched the space and no other tool approached secrets in such a way.

Syntax of toml is almost identical, the CLI as well.

It even has the same vocabulary.

I didn't dig deeper though, but I'd be surprised not to find more :)

I'm really excited about what teams will build using profiles, they enable all kinds of cool things.

We're aiming to take Nix to its most simple form, while devbox uses json for configuration.

Think of devenv as systemd of developer environments.

Yes, it does vendor all the crates to Nix store.

It results into speed up in a way that if your application doesn't change, you'll just get the binary package.

That's why the two interfaces are exposed: one for development feedback cycle and one for distribution.

I'll reply, even though I don't like the tone the first sentance sets :)

I'm not sure exactly what parts of the comment are about secrets rather than how infrastructure should be done, but I see that secrets and configuration have very different lifetimes so they should be provisioned separately. The config can for example be in the git if it's free of secrets.

Secrets are provisioned at runtime, while config is build time.

`secretspec.toml` is in the version control and it tells you all about what's going to happen at runtime.

I'm not advocating that different locations of secrets IS something we want, but rather it IS the sad state of reality.

By having a secrets specification we can start working towards a future that will consolidate these providers and allow teams to centralize it if needed, by having simple means of migrating from a mess into a central system.

The example is more of a way to show how to keep backwards compatibility and migration to secretspec.

We hope that one day github actions would integrate secretspec more tightly, leaving aside using environment variables as a transport.

That's going to be a long journey, one worth striving for.

I hope that this will be one of the tools that allow that transition to happen those who'd like to migrate from LastPass :)

We've removed telemetry a long time ago, see https://github.com/cachix/devenv/issues/1733

We've been building https://devenv.sh for that reason, I expect more companies to go back to local development once they see DX has improved locally.

It would be bring less complexity using https://devenv.sh/ to provide the tooling :-)

That was a mistake, for some reason it left a thumbs down instead of thumbs up.

Do you have a particular in mind or does the general number bother you?

It's a very ambitious project, so a lot of issues are related to either Nix or general support for each language/service.

In devenv.sh:

  difftastic.enable = true;

Hey folks,

We've shipped a pretty big update this time, incorporating a lot of feedback and issues from the last year.

Here's a 5min demo: https://twitter.com/domenkozar/status/1770444437505929637

Domen

Better composability and abstraction, see for example how you can configure a process in https://devenv.sh/services/ that has first-class support for development environments using Nix.

No need to use containers too, which bring cognitive/workflow overhead.

That's a mouthful for 14 lines of native development that can generate a dev container using https://devenv.sh

$ cat devenv.nix

{ pkgs, ... }: {

  languages.c.enable = true;

  packages = [ pkgs.ceedling pkgs.cmake ];

  enterShell = ''
    cmake --version
  '';

  pre-commit.hooks = { 
    clang-format.enable = true;
    clang-tidy.enable = true;
  };

$ devenv shell

(Note that pkgs.ceedling has been recently added and will only hit the cache in 6-12h).

Note that warm waters is a typical strawman argument against nuclear power.

These are rare anomalies and there's dry-cooling of nuclear power plants (although it's less efficient and costs more).

A lot of these pitfalls and boilerplate, we've removed in https://devenv.sh :)

The best talk I know about this is https://www.youtube.com/watch?v=t6goF1dM3ag

Do you still experience these UX issues and lack of documentation?

Hey! We've been working at Cachix to address this using https://devenv.sh/.

It's primary targeted to improve DX and on-board users quickly.

Hey folks,

Cachix founder here. Here are a few links for getting started:

- https://nix.dev Nix tutorials

- https://devenv.sh Fast, Declarative, Reproducible, and Composable Developer Environments

Let me know if you have any questions. Domen

If you decide to try https://devenv.sh, it has OCaml support built-in:

  $ cat devenv.nix
  { config, ...}: 
  let
    ocamlPackages = config.languages.ocaml.packages;
  in { 
    languages.ocaml.enable = true;

    packages = [ ocamlPackages.janeStreet.async ];
  }

  $ devenv shell
  ...

Let me know if you give it a try :)