Anyone having used both can share their thoughts about how solvespace and OnShape compare?

On my end I’ve been loving OnShape and find it pretty intuitive. I also tried fusion360 but closed it after 5 minutes, it felt too sluggish.

If you're alone in a codebase? Probably not.

In a company with many contributors of varying degrees of competence (from your new grad to your incompetent senior staff), yes.

In large repositories, without extremely diligent reviewers, it's impossible to prevent developers from creating the most convoluted anti-patterny spaghetti code, that will get copy/pasted ad nauseam across your codebase.

Terraform as a tool and HCL as a programming language leave a lot to be desire (in hindsight only, because, let's be honest, it's been a boon for automation), but their constrained nature makes it easier to reign in the zealous junior developer who just discovered OOP and insists on trying it everywhere...

Infrastructure needs to be consistent, intuitive and reproducible. Imperative languages are too unconstrained. Particularly, they allow you to write code whose output is unpredictable (for example, it'd be easy to write code that creates a resources based on the current time of day...).

With infrastructure, you want predictability and reproducibility. You want to focus more on writing _what_ your infra should look like, less _how_ to get there.

It’s based on Cue and doesn’t rely on templating.

[1] timoni.sh

I would never do either. But one is less weird than the other.

What's difficult with programming isn't the language itself, it's everything else: understanding concepts, algorithms, programming patterns, the science.

It feels a bit like trying to reinvent the language of mathematics. It'd be really inefficient writing math in plain English.

Most tutorial out there encourage you to download someone else's configuration to get going. I don't want to do that. I want to understand at its core how this thing works.

I've read the official nix language documentation, watched YouTube tutorials, read 3rd party tutorials, and still couldn't get going with a simple configuration that would install a few packages.

The nix language is also really unpalatable to me. But I could deal with that if the examples out there showed a consistent way of doing things – that's not the case. It seems one same thing can be done many different ways – but I want to know and do it the right way. I would generally turn myself to the official best practices documentation, except nix' is very short and doesn't help much.

I really want to use nix. There's no question about its advantages. But nix just won't let me (or maybe I'm too old to learn new things).

That being said, I'll probably give it another try this month...

I don't have experience in this world, indeed.

But isn't "multiple release versions of an app" just "one application, with multiple different configurations"? The application code is the same (same version), the configuration (which is external to the application) is different.

Your build system takes your application code and the configuration as input, and outputs artifacts for that specific combination of inputs.

That's why git also offer tags. Tags are immutable.

That's an important distinction.

There is when you stop thinking in terms of dev, staging and prod, and you realize that you might have thousands of different environments, all named differently.

Do you create a branch for each one of them?

Using the environment name as branch name is coupling your repository with the external infrastructure that's running your code. If that infrastructure changes, you need to change your repository. That in itself is a cue it's a bad idea to use branches this way.

Another issue with this pattern is that you can't know what's deployed at any given time in prod. Deploying the "production" branch might yield a different result 10 minutes from now, than it did 25 minutes ago. (add to the mix caching issues, and you have a great recipe for confusing and hard to debug issues)

If you use tags, which literally are meant for that, combined with semver (though not necessarily a requirement, but a strong recommendation), you decouple your code and the external environment.

You can now point your "dev" environment to "main", point staging to ">= v1.25.0" and "prod" to "v1.25.0", "dev-alice" to "v2.0.0", "dev-john" to "deadb33f".

When you deploy "v1.25.0" in prod, you _know_ it will deploy v1.25.0 and not commit deadb33f that so happened to have been merged to the "production" branch 30 seconds ago.

Absolutely. And it doesn't help when people write guides actively encouraging mis-using tools

At [company x] someone wrote a starter guide that tells developers to create a "production", "staging" and "dev" branch for any new repo. We have tons of repositories that follow this pattern.

For many of them, each branch has taken of its own life and could be considered its own completely different codebase. It's a nightmare to manage and it confuses developers on a regular basis.

Don't do this.

If you want to deploy different versions of your software in different environments, use SEMVER and git tags. Don't create 1 branch per environment...

I have since edited that starter guide and crossed out this recommendation.

I don’t understand what « grug » is supposed to mean for example.

That being said I still enjoy the blog.

If your original comment is solely about this revised 6 words statement, then, yes, you are correct, the claim is objectively untrue.

I'm no mind reader though, I assumed you were talking about the whole thing ¯\_(ツ)_/¯.

> The creators knew that when they wrote that disclaimer and we all know that reading the disclaimer.

This is the idea I'm pushing back against.

Yes, you are very likely correct in your assessment that the creators know that their software will be used illegally.

No, you are incorrect, in saying this is 1- "objectively untrue" and 2- implying the statement might _not_ have some protective qualities.

To take a purposefully exaggerated analogy: you can believe all day long someone committed murder, it still doesn't make it true. You can argue all day long the authors aren't being truthful, it still doesn't make it true.

> Yet the disclaimer is still placed there like it has some reason for existing beyond allowing everyone to pretend something that is happening isn’t happening

I'd agree with this, and, add that, at the same time, (assuming the USA here) it's probably placed there for legal reasons (whether it factually matters legally or not is a question for an actual lawyer, which, objectively, I am not).

> I’m just remarking on the silliness of the disclaimer.

It feels a bit silly, yes, and at the same time... needed?

The statement "We do not endorse, promote, or facilitate copyright infringement, illegal streaming, or piracy in any form", might be poorly written with regards to the fact that just by existing this torrent streaming program _does_ facilitate piracy, but I don't think this was your original argument.