How does the const { None } example type-inference work? The size of the option type can’t be known without knowing the type of the Somevariant.

Edit: aha, it doesn’t work as-is. It needs to infer the type of elements of foo from usage. https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=05a95c592626b6935ae812527aa6bbc6

In both cases, Go and Python, the operator will assign a variable a value and also use it as an expression.

That is absolutely not true. foo := <expr> is a statement in Go, full stop. Just try something trivial like assigning to the output of :=: https://go.dev/play/p/nPINGc7LO8B

It’s true that if and for let you use := but don’t let you use var, but you still can’t use the result of the assignment directly. So for instance you need if foo := <expr>; foo { ... } rather than just if foo := <expr> { ... }.

I was curious about the Python connection because multiple comments mentioned it, but I’ve worked on multiple Python projects over the past dozen-ish years and never seen that operator.

Turns out it was introduced in 3.8, released in 2019, so it was much too late to inspire Go, and most of the projects I’ve worked on were written to target an earlier Python version. It also has a substantially different meaning than in Go.

I don’t know if there’s an “official” rationale for the Go syntax, but := is a fairly common (but not ubiquitous) math notation meaning “define the thing on the left to be equal to the expression on the right”, i.e. to distinguish it from the other use of =, i.e. “the expression on the left must be equal to the expression on the right.” Go’s usage matches this mathematical meaning of introducing a new variable definition pretty well.

I read it a few hours ago. Was it substantially longer before?

This “full on rage essay” is nine sentences, including the tl;dr and the sentence fragments. There’s really not a big difference between telling your coworkers a story like this and posting about it on social media.

If only there were a good statically typed database, as opposed to thin wrappers over SQL.

What…? That is a terrible idea.

How is await like comefrom, any more than threading is like comefrom? The variable context is preserved and you have no control over what is executed before the await returns.

Does the catchphrase “blazing fast” ring any bells? Some people care.

(Arguably that’s just the pendulum swinging the other way; Ruby, Python, and Java ruled the software world for a while, and I think that’s a large part of why the Go and Rust communities make such a big deal about speed.)

Honestly, wouldn’t it be great if POSIX eventually specified a WASM runtime?

It’s relevant because there are still platforms that don’t have actual Bash (e.g. containers using Busybox).

sh is not just a symlink: when invoked using the symlink, the target binary must run in POSIX compliant mode. So it’s effectively a sub-dialect.

Amber compiles to a language, not to a binary. So “why doesn’t it compile to sh” is a perfectly reasonable question, and refers to the POSIX shell dialect, not to the /bin/sh symlink itself.

A language being compiled should be able to support higher-level language concepts than what the target supports natively. That’s how compiling works in the first place.

Compiled code is already effectively write-only. But I can imagine there being some efficiency gains in not always shelling out for arithmetic, so possibly that’s a future improvement for the project.

That said, my reaction to this project overall is to wonder whether there are really very many situations in which it’s more convenient to run a compiled Bash script than to run a compiled binary. I suppose the Bash has the advantage of being truly “compile once, run anywhere”.

No, I mean, analyzing the Amber expression to determine if Bash has a native construct that supports it is unnecessary if all arithmetic is implemented using bc. bc is strictly more powerful than the arithmetic implemented in native Bash, so just rendering all arithmetic as bc invocations is simpler than rendering some with bc and some without.

Note, too, that in order to support Macs, the generated Bash code needs to be compatible with Bash v3.

Yes, I agree package managers are much safer than curl-bash. But do you really only install from your platform’s package manager, and only from its central, vetted repo? Including, say, your browser? Moreover, even if you personally only install pre-vetted software, it’s reasonable for new software to be distributed via a standalone binary or install script prior to being added to the package manager for every platform.

No, I agree that a package manager or app store is indeed safer than either curl-bash or a random binary. But a lot of software is indeed installed via standalone binaries that have not been vetted by package manager teams, and most people don’t use Nix. Even with a package manager like apt, there are still ways to distribute packages that aren’t vetted by the central authority owning the package repo (e.g. for apt, that mechanism is PPAs). And when introducing a new piece of software, it’s a lot easier to distribute to a wide audience by providing a standalone binary or an install script than to get it added to every platform’s package manager.

But…“just execute this .exe, bro” is generally the alternative to pipe-to-Bash. Have you personally compiled the majority of software running on your devices?

It’s probably just easier to do all arithmetic in bc so that there’s no need to analyze expressions for Bash support and have two separate arithmetic codegen paths.

Yeah, agreed.

I haven’t worked on any teams where all members committed “every 24 hours”, and there have always been some branches that live longer than we’d like (usually just unfinished work that got deprioritized but still kept as an eventual “todo”), but most teams I’ve worked on have indeed followed the basic pattern of only one long-lived branch, reviews and CI required prior to merge, and all feature-branches being short-lived.