BatmanAoD @ BatmanAoD @programming.dev

Posts

1

Comments

295

Joined

2 yr. ago

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.

I've met people with C++ Stockholm Syndrome, and I think their trajectory is different. There's no asymptotic approach toward zero; their appreciation just grows or stays steady, even decades into their career.

The logo and "join our Discord" text are more than half cut off for me. Is that the original cropping, or is it a client (Jerboa) issue?

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.

Rust is extremely geared toward maintainability at the cost of other values such as learnability and iteration speed. Whether it's successful is of course somewhat a matter of opinion (at least until we figure out how to do good quantitative studies on software maintainability), and it is of course possible to write brittle Rust code. But it does make a lot of common errors (including ones Go facilitates) hard or impossible to replicate.

It also strongly pushes toward specific types of abstractions and architectural decisions, which is pretty unique among mainstream languages, and is of course a large part of what critics dislike about it (since that's extremely limiting compared to the freedom most languages give you). But the ability for the compiler to influence the high-level design and code organization is a large part of what makes Rust uniquely maintainability-focused, at least in theory.