Amber: Programming language compiled to Bash

Original Article ↗ Hacker News Discussion ↗

A new language called Amber aims to let developers write modern, strongly typed scripts that compile down to Bash, promising better ergonomics while still running anywhere Bash is available. Commenters are split: some see real value for CI, embedded, and “austere” environments where installing Python or Go is hard, while others criticize Amber’s generated shell code (e.g., heavy use of `bc`/`sed` for simple comparisons), missing core shell features like pipes, and the added complexity of debugging transpiled scripts. The project is often contrasted with simply learning Bash or using mature alternatives like Python, Perl, or newer shells, and its slick, startup-like website and naming clash with an existing “Amber” Smalltalk implementation also draw attention.

Overall Reception and Intended Niche

  • Many find the idea “horrifying but impressive”: a nicer language that compiles to Bash so scripts run almost anywhere.
  • Supporters see a niche for environments where you can’t install runtimes (Python, Go, etc.) but can run Bash scripts, e.g. CI pipelines, old servers, initramfs, embedded systems.
  • Skeptics argue that once you depend on extra tools (bc, sed, sudo, etc.), you’ve lost the main advantage over just requiring Python/Perl/Go or a configuration tool.
  • Some feel that once a script reaches Amber’s complexity level, you should just switch to a general-purpose language.

Language Design and Missing Features

  • Syntax: ECMAScript-like, but many dislike the $...$ command syntax and exceptions for built-ins like echo.
  • Types: only a single number type; no integers vs floats, limited maps, and no nested arrays, which several consider a major limitation for “real” scripting.
  • Features like pipes, redirection, robust subprocess failure handling, and pipefail semantics are described as missing or under-specified.
  • Variable “shadowing” (redeclaring with a different type) is controversial: familiar from Rust/Haskell for some, seen as bug-prone by others.

Generated Bash Quality and Performance

  • The showcased compiled Bash (e.g., if age < 18 turning into an echo | bc -l | sed pipeline) is widely criticized as ugly, slow, and over-dependent on external tools.
  • Commenters suggest using Bash arithmetic ((( ... ))), [[ ... ]], parameter expansion, or at least simpler constructs.
  • Concerns about debugging: error messages map to the generated script, which is hard to read; some suggest including original Amber as comments or source maps.

Dependencies and Portability

  • Project assumes bash, bc, sed are “always there”; others provide counterexamples (Debian, SUSE, Git Bash, embedded/busybox systems).
  • Debate over targeting ancient Bash vs modern Bash vs POSIX sh; some argue if the goal is maximum portability, target pure POSIX shell.

Comparison to Other Tools and Languages

  • Compared to Batsh (similar idea), Oil/YSH, Nushell, Xonsh, PowerShell, Ruby, Perl, Python, Go, and Nix’s writeShellApplication.
  • One camp: “just learn Bash, plus shellcheck/bats”; another: Bash is too quirky and footgun-heavy, so higher-level abstractions like Amber are welcome.

Website, Docs, and UX Feedback

  • The site is praised for polish but criticized for: very dark styling, gradient obscuring the install command, JS-only links, WebGL-based docs that break when WebGL is disabled, SVG text that can’t be copied, and layout bugs on Firefox/small screens.
  • Several say the branding and 3D animation make it look like a commercial SaaS or crypto product, not a simple open-source utility; they want clearer “open source / free” messaging and more practical code examples (especially with pipes).

Licensing

  • Code is GPLv3; discussion touches on implications for environments wary of GPLv3 and notes that modern Bash itself is GPLv3, which already causes issues on some platforms.