As someone who learned programming with scratch in elementary school, the next step they did was using DrRacket but honestly I did not like it. I don’t remember anything I made with it but still remember my scratch projects. I think pygame would be a good next step as it is batteries included and let’s you build similar gui applications with an event loop. However, I haven’t used scratch since around 2010 so it could have evolved a lot since I used it and the concepts might not translate anymore.
What’s powerful about nix is the language IMO. I was able to build an automatic WireGuard setup[1] with tagging that automatically works on each new machine thanks to the ability to do config as code. Just provide some basic config for each machine and the code turns it into an interface with peers.
The issue to me isn’t the language persay (it’s really a tiny surface area language, see the built in/lib functions [2]) but the tooling built around packaging is a hodgepodge mess of semi-documented workarounds (with Nixpkgs blessed ways vs user libraries) and is extremely difficult to approach and understand.
Back in middle school we went on a trip and saw them doing the deconstruction of the elwha dam. They were around halfway done. We stood on the banks and saw the process of the reservoir turning back into a river. There was around 50 feet of sediment with old flooded trees sticking out. It is hard to overstate the effects these dams have on nature. Seeing the photos of the elwha coming back to life is always awesome :)
100% this. The language is designed for its use case which is packaging and configuration (nothing more or less). It has a learning curve due to being lazy and functional but works great once you get the hang of it. But the documentation of all its functions is so annoying. You have builtins and the nixpkgs functions[1]. There is learning the language, and then learning how to use it. Then there is the entire ecosystem of custom packaging functions that have their own pros/cons [2]. The issue isn’t with the language but the difficulty with trying to make existing tooling work the Nix way. That part is where I agree with the curse of nix. But the effort is worth it because once the packaging is complete it just works (forever).
I see the issue being the email was formulated in a way that is easily perceived as a legal threat. I don't see how it is ethical for a study to be sending out legal threats to see how someone responds. Now if the goal is to understand how websites respond to the CCPA/GDPR then it shouldn't be too difficult to ask how they would respond to a request and note that it is part of a voluntary study.
while not necessarily on how gondolas work, this is a great documentary on the engineering and design behind the peak2peak gondola at whistler: https://www.youtube.com/watch?v=xEAJmxe27h0
chairs/gondolas detach from the primary rope that carries them up/down the slope. So while the primary rope is moving the same fast speed, the chair isn't attached to that rope anymore. This is what allows detachable lifts to go so much faster than fixed (non-detachable lifts), the speed of them isn't dependent on people being able to board. If a ski resort wants to speed up their fixed grip chairs without spending the money on a detachable, they will use a loading carpet to move up the max speed of loading people (see: https://liftblog.com/2016/01/02/the-loading-carpet-solution/)
If your interested in digging deeper into building docker containers with nix this is my favorite post on the topic: https://thewagner.net/blog/2021/02/25/building-container-ima.... Essentially you can use any nix package (including your own) to create the environment.