It's a bit of a stretch, but comparing it to something like MJML for HTML emails. [0] It doesn't make great HTML, but it's not unreadable and standard quality for HTML emails. It just handles all of the weird things you have to consider for maximum email client compatibility. It's basically a bunch of HTML macros, with react being an implementation detail under the hood. It's not like it's bringing any new features to HTML emails, because if it did, the output WOULD be unreadable.

If this was just some type hints, and cleaner syntax around sh, that I think would be really useful. This in it's current state is just sort of a tech debt generating machine. If something is built in amber, it's because we can only use bash for some reason, but if we can use bash we could either... use bash, or we could call something else (Ruby, Python, etc), from a 2 line bash script.

[0] https://mjml.io/try-it-live (click "View HTML" to see outputted source.)

Edit: Idea, it would be cool if you could define the environment available to the final script when using the compiler. That way, if there was something you wanted to distribute, the person building your project could say "this docker container I'm running this in won't have sed, but it will have bc and awk" or something.

They are only listing `bc` and `bash` as a prerequisite, but the example uses `sed`, so this is also not complete. So a full list of all required tools would be the first step.

But I am working on embedded systems where I write lots of POSIX shell scripts that run in tiny initramfs, etc. so I am very picky with my dependencies. If I had a better language to target busybox, that would be welcome as well.

    if age < 18 {
      echo "I'm not an adult yet"
    } else {
      echo "I'm an adult"
    }

    __0_age=30;
    if [ $(echo ${__0_age} '<' 18 | bc -l | sed '/\./ s/\. \{0,1\} 0\{1,\}$//') != 0 ]; then
      echo "I'm not an adult yet"
    else
      echo "I'm an adult"
    fi

    __0_age=30;
    if [[ ${__0_age} -lt 18 ]]; then
    ...

EDIT: `-gt` is POSIX, but tbf if there's no input sanitization, then bash (or sh) will choke on the float. In that case, as long as you aren't trying to round, you could use parameter substitution to truncate:

    __0_age=17.6;
    if [[ ${__0_age%%\.*} -lt 18 ]]; then
    ...

[0]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...

More broadly though, yes, there's a tendency for people to pop sub-shells without giving it a second thought. Those aren't free; use shell built-ins whenever possible!

Something you could do to alleviate this is to interleave comments with the original Amber source, along with line numbers (which would balloon the script size, but probably not a huge deal).

Edit: you could also bundle a tool to recover the original Amber source from those comments, to allow for easy in-the-field script edits and/or audits.

would be nice if it was the source and script at the same time. as in a comment at the bottom or top is the source or something.

    if [[ "${foo}" =~ ^someReg[e][x][p][r]$ ]]; then ...

Maybe still just the earliest of early days? Javascript-style RegExs along the lines of:

    if (s.match(/my[R]egex[H]ere/)) { ..

I consider myself to be quite proficient in bash. I write a lot of bash professionally. I've written a compiler (transpiler?) for a strongly typed configuration language that outputs bash.

There are three main problems I see here.

(1) Pipelines, subshells, and external dependencies.

The example on the website compiles a conditional `if age < 18` into this monstrosity:

    if [ $(echo ${__0_age} '<' 18 | bc -l | sed '/\./ s/\.\{0,1\}0\{1,\}$//') != 0 ]

    if (( __0_age < 18 ))

Seems mildly insane that a conditional this simple would require a pipeline including `echo`, `bc`, and `sed`. Now the user needs to ensure the correct external CLI tools are installed, and match the expected versions. Hope they account for BSD vs. GNU variants. Eek.

(2) Namerefs.

> Arrays cannot be nested due to the Bash limitations

Arrays absolutely can be nested... with some trickery. Consider:

    # Top level array w/ pointers to children.
    declare -a arr1=( arr2  arr3 )

    # Child arrays.
    declare -a arr2=( item1  item2 )
    declare -a arr3=( item3  item4 )

    for ref in "${arr1[@]}" ; do
       declare -n sub_array="$ref"
       printf '%s\n' "${sub_array[@]}"
    done

This is a fairly trivial operation that I'd assume the authors would know about. It's fast and allows for the creation of arbitrarily complex objects. Even rudimentary classes.

(3) Just learn bash.

I'm perpetually confused by people taking every opportunity to not just... learn bash. An otherwise skilled programmer will somehow forget everything they've learned when beginning a shell script.

Surely it can't be harder to learn the fundamentals of shell scripting than to learn whatever flavor-of-the-month alternative is?

There are many reasons why it is to be avoided. For me the deal breaker was that one time I spent 2h debugging a script only to find out there was an extra space character that made the whole thing break silently.

I would be willing to learn a sane language, but bash isn't one. If you need to know of a million tiny gotchas to implement even the simplest task safely and portably, then there isn't any reason to _learn_ bash.

When I was learning C++, I lost 2 days because of an extra ";" in an if statement. However this does not mean C++ is an insane language. It means it has quirks.

> I would be willing to learn a sane language, but bash isn't one

I kindly, but strongly disagree.

> If you need to know of a million tiny gotchas to implement even the simplest task safely and portably

Then you'd absolutely hate Perl, to the level of pulling your or The Camel's hairs out.

This is how programming languages work. They have straights and curvy parts, and there are some chicanes (quirks). So yeah, if you need to use bash, you need to learn it.

This trait baffles a couple of my friends with no end.

BTW, That's a great link. Thanks a lot.

> I would be willing to learn a sane language, but bash isn't one.

It's a general language that has to be both an interactive interpreter and script executor, and it needs to support a huge variety of architectures and kernel versions, as well as historical decisions. It's going to have some cruft.

[0]: https://www.shellcheck.net/

While this is clearly exaggeration, I'm not sure I find much merit in the argument.

C is full of gotchas, footguns, and a tremendous threat vector. But it is also the standard for many uses.

Yes, bash has legacy cruft, and potentially confusing ways of doing things. But for the realm in which it operates, it is extremely effective. We can make an argument for what we believe the perfect shell scripting language would be--but that doesn't exist. Bash is the current tool for addressing this category of problems.

The intention of this bullet point was to illustrate that just as I wouldn't work in an industry/role requiring C tools, and instead turn to some weird, novel, riddled-with-problems transpiler... I'd just learn C.

(P.S., bats[0] and shellcheck[1] address many problems noted in this thread.)

  [0] https://github.com/bats-core/bats-core
  [1] https://www.shellcheck.net/

(I'm not GP)

Yes, and the same way there's a plethora of bash-alternatives in the making, there are multiple languages trying to essentially be a "better C", such as Go, Rust and so on, not to mention C++ and its descendants.

I definitely think there's room for an improved bash. The biggest question is whether an alternative can become ubiquitous enough to be a fully qualified alternative.

Absolutely! I wholeheartedly agree, and would love for such a project to exist, and see sufficient adoption such that it's a standard at my job.

I may not have articulated my prior point precisely enough.

Too often I'll see a professional JS programmer (for example) who will forego everything they've learned the second they touch a shell script. No useful comments, no functions, poor design & implementation, no care towards idioms, no regard for readability/maintainability.

Given that bash is currently the standard, someone is better served by actually learning it than a worse, novel alternative.

Any successor must encompass the power and feature-set that exists within contemporary shell scripting.

The majority of people doing DevOpsey kind of stuff aren't remotely experts with what they're working on, and won't ever be experts, but work still needs to get done.

The reason to learn it is that it can make your dev experience better. Make falls into this category as well. Both are great ways to combine multiple tools together.

That being said, I'm using more Dagger for this purpose these days, which provides you SDKs for your fav langs.

This sounds like using `a = b` instead of `a=b`, something you learn in an introductory Bash tutorial. It's not a good argument to say "I didn't learn Bash and it cost me 2 hours, therefore I should continue to not learn Bash."

The only time this complaint is valid is if you're in a professional environment and you're not allowed to use alternate shells in your account, for some reason.

I've dealt with bash scripts running in high load production systems and I'm very happy I don't have to any more.

There is a reason my comment was a response and not a standalone statement. The OP was explicitly speaking about using it a professional setting.

Note the little asterisk at the end there?

I've worked as a systems administrator/engineer and a DevOps Engineer at quite a few companies. Very few of them cared what shell your personal account used (and usually had zsh, if not also fish). And they wouldn't run shell scripts in production; but if they did allow that, they probably wouldn't care which one you included in your shebang (as long as the package was in our standard deploy set).

Obviously that doesn't represent all places, thus why I added the caveat. However, the number of places that A) allow you to run shell scripts in production and B) are also so overly paranoid as to limit user account shell interface are probably the exception, not the rule.

I've been writing bash code regularly for my entire 20 year career. I'm not convinced that I've "learned bash" yet.

Bash has too many different ways of doing things, and it can be hard to determine which variant is the right way.

   #!/bin/bash
   set -euo pipefail
   echo $(false|true)
   echo a
   echo $(false)
   echo b
   false
   echo c

I would expect it uses bc instead of relying on bash's environment/version-dependent 32/64bit integers.

I suspect some people have trouble with the syntax used by Bash, and languages like Perl. But I can't pinpoint what causes it.

Also: I don’t see mentioned how pipes affect the exit code propagation (i.e. pipefail).

I want to do more complex things using bash for devops stuff, because it's mostly working with other command line tools. You could directly use APIs and SDKs of cloud providers, but then things become an order of magnitude more complex than just writing the bash script.

However, when you do that you encounter bash's weaknesses, like not supporting a nested structure like Map> and so on. Having to wrangle tools like jq, sed and awk all together to work around the lack of proper data structures and string manipulation is no fun either.

Something like amber could bridge the gap while still being portable across systems.

For example, we had an EC2 machine whose init would fetch and run a shell script from S3, which spun up a big JVM application. We started getting strange errors from deep inside the JVM, which seemed to be caused by some security update somewhere in the stack (either ours or Amazon's); but that machine image had evolved via snapshots of snapshots, etc. and was a pain to figure out what it was running, let alone update and manage it in a sane way. As a quick fix I bundled a known-good JVM into an Arx file (along with other dependencies like Bash, etc. since it's Nix, so I might as well!) and put that on S3 in place of the old shell script. That got the EC2 machines working again, without having to mess with the (already messy) image; we gained a more sensible way of specifying dependencies (via Nix); and, since we were now building an artifact, rather than slinging a raw script, we could do stuff like running Shellcheck on the code. This definition was also easy to re-use when we eventually switched it to ECS containers (just changing the `nix bundle` options).

- nushell

- elvish (was featured on HN recently)

- powershell

- murex (disclaimer: I’m the author of that one)

Most of the value in sh to me is that it’s ubiquitous. I write a script and the runtime is already available across most devices, operating systems, containers, and everywhere else without an extra steps.

It's unfortunate Amber doesn't have a Map data type, pretty big limitation.

I can think of ways of doing it, e.g. something along the lines of:

* Set the constraint that all keys must be of type String

* Then abuse /dev/shm/.Amber/${pid}/${func}/${stackDepth}/

Also for this to be really unique and good it needs insanity like being able to avoid all external dependencies, or else idempotently installing them in ways that can not affect anything else externally, or even temporarily, in multiple crazy various environments including nix? my mind never shuts up

You'll run into the Alternative Implementation Problem

https://pointersgonewild.com/2024/04/20/the-alternative-impl...

https://news.ycombinator.com/item?id=40337036 - 10 days ago, 84 comments

Relevant excerpt:

> You may read this and think that the key lesson of this post follows the old adage that “if you can’t beat them, join them”. In some ways, I suppose it does. What I want to say is that if you start a project to try and position yourself as an alternative but better implementation of something, you are likely to find yourself stuck in a spot where you’re always playing catch up and living in the shadow of the canonical implementation.

This concept doesn't exactly map 1:1, but gist seems correct. Who wants to program in a worse and very limited version of Python? Who's going to keep things up to date in e.g. Amber as Python continues to evolve? Not fun.

If you were to write Python code that did a of its business logic by spawning new processes rather than using its core libraries (which are written in C) then you’d find Python would be just as slow too.

But the exact point of Bash and other shells is to make launching new processes easy. This is the point that people miss when they say “write it in a real programming language”. Shells solve an entirely different problem to other languages. And “real” programming languages suck at working with other executables in a quick and convenient way.

However, having looked at this case I'm not against it for several reasons.

First, it looks like the project has been abandoned. There hasn't been an issue closed in 2 years, and the latest copyright date is 2019.

That might not be enough to sway me, but then you have to realize the project doesn't even really call itself a language. They are "Amber Smalltalk". This is an implementation of Smalltalk, not a language itself.

  Amber is an implementation of the Smalltalk language that runs on top of the JavaScript runtime.

  Pharo Smalltalk is considered as the reference implementation.

Finally, and the nail in the coffin, over the past couple years in the mailing list there has been little activity -- nominally a monthly message from a single user advertising the "UK Smalltalk User Group Meeting" which sounds interesting but not really about Amber Smalltalk as a project per se.

No one is using it, no one is working on it, and it wasn't a language in the first place. I would say that it's fine for an actual language project to pick up the name.

Oils goal is that OSH is just a new Bash implementation (although not bug-for-bug) but with an upgrade-path to the more modern YSH for real programming with type safety etc, but still as a shell language. One of their exciting ideas is using code as data in a somewhat lisp-like manner to allow function introspection in YSH etc.

Based on other comments it seems like Oil Shell is much more principled in working to actually understand Bash as it exists and presenting an alternative language. I would be interested in what differentiates Amber and whether they have a response to Oils?

Ysh implements new, non-compatible syntax and semantics.

Osh and ysh are two different shell languages from the Oils for UNIX project. The release build generates a single binary, oils-for-unix, and installation creates two symlinks for the two different shell personalities, similar to how the bash binary will behave in its POSIX-compliant mode when it is invoked as sh.

There is no "Oil shell" now, at least not without ambiguity.

Oil would have to reach a really critical mass before it can compete, which is sort of a catch 22 situation.

Maybe this is still early in development, but I don't see anything for pipes or redirection. Is this a planned feature? That's an essential feature of any shell and I can't see myself getting much done in Amber without it, especially pipes.

I suggest adding more examples to the home page, especially side by side comparisons with Bash. The home page is somewhat lacking in content right now.

It's a shame that they provided such weird syntax for the most important thing you tend to do in a bash script, while providing fairly nice syntax for everything else.

Overall, it is cute and neat, but i find that if you are looking to write bash scripts that require this level of programming, you'd be better off writing it in python, or perl. Only in very austere environments can this be utilized, but the requirement of having `bc` installed means you must also have the ability to run package installation, so might as well run the package installation for a full on programming language!

I don't remember ever installing bc, but I use it frequently and it's always there. Are you sure it's not already part of most base systems?

In my bash scripts, using `bc` makes my script not work on git-bash under Windows. Almost everything else I do in a script that isn't linux-specific (including netcat/nc usage) runs in git-bash for Windows.

Don't get me wrong, I hate writing shell scripts, so this is definitely an improvement over that. It just doesn't seem like the most practical solution (unless I'm missing something).

All of the other languages you bring up are great for authoring code, but have a non-zero amount of friction when running code in the wild. Python may be omnipresent, but you can rarely count on a specific version or the presence of specific libraries. Go requires compiling platform-specific binaries. Even JVM- or JS-based software requires installing a separate toolchain first.

If you want to write some code (e.g., a launcher, installer, utility code, etc...) that is almost certainly going to run on any computing device created in the last several decades, bash is your language.

Still,

> If you want to write some code (e.g., a launcher, installer, utility code, etc...) that is almost certainly going to run on any computing device created in the last several decades, bash is your language.

Can you give an example of a "several decades" old device for which you'd want/need to write a launcher or installer?

Things like perl (without CPAN) and bash generally take backward compatibility more seriously than python does.

My experience with python (even ignoring the 2 to 3 debacle) is that you can run code on machines that were setup +/- six months from when the software was written. That's unacceptable for non-throwaway use cases unless your company is willing to burn engineering time needlessly churning software that's feature complete and otherwise stable.

Also does bash run on windows outside of WSL? Amber seems to argue that it doesn’t support Windows because Windows doesn’t support bash.

That would cut against the idea that bash can target more devices than Python, which runs natively on all platforms.

Because it's easy (for most cases) to write backwards-compatible or portable shell scripts and, since Amber is compiled, it can simply generate backwards-compatible code.

> That would cut against the idea that bash can target more devices than Python, which runs natively on all platforms.

The point is that Bash is more ubiquitously available, which is important if you write something like an install script.

I guess I just don't understand how having the user install git bash or WSL any different from having them install Python or JVM?

So I ask again, why does targeting bash offer a better portability story than say the JVM?

Given that, my production systems are likely a big target. None of my production systems have a JVM/JRE installed, and installing one just to run shell scripts would be (IMHO) a huge increase in attack surface for little to no gain. It would also bloat the hell out of my container images.

If I'm writing a GUI application or a web server or something, then I would agree JVM is more "portable." But if I just want a script that will run equally well on Ubuntu 18.04 and Fedora 40, and across all production machines regardless of what application stack is there (node.js, ruby, python, etc), and regardless of what version of node or python or ruby is installed, Amber feels highly portable to me.

Underlying all of these discussions is an attempt to reduce issues of portability to 0. It's a good goal, but IMO interpreted languages will by-definition never be the solution.

I've started reaching for Go in situations in which I'd usually reach for Bash or Python, and it's a godsend, because I can control for portability at compile time. If you make compiling for various GOOS and GOARCH targets the norm, portability is never an issue again.

This feature, optional omission of delimiters in the special case of a single statement per branch, originated in early C and has since facilitated untold numbers of bugs, not least the spectacular Heartbleed bug (which has its own homepage, https://heartbleed.com).

I don't think Python is as ubiquitous as you think is is; but regardless, mere presence is not the only problem. What Python are you even talking about? Which version? How is the user supposed to handle dependencies?

If something like this has utility, it's to minimize the configuration management problem you're giving the user. "Use Python" is definitely not the answer to that.

This doesn't seem to be a terribly good implementation of the idea, but it's not a bad idea, on its own.

> Both Bash and Batch are messy to read and tricky to write due to historical reasons. You have to spend a lot of time learning either of them and write platform-dependent code for each operating system. I have wasted lots of time in my life struggling with bizarre syntaxes and unreasonable behaviors of them, and do not want to waste any more.

https://amber-lang.com/pipelines/compile.svg

It also, hilariously, feels a bit fitting given my actual complaint ;P.

    if [ $(echo ${__0_age} '<' 18 | bc -l | sed '/\./ s/\.\{0,1\}0\{1,\}$//') != 0 ];

    if [ "${__0_age}" -lt 18 ]; then

I've done a bunch of DSLs (CLI with some elaborate syntax really) that compile to bash as a target. It just works for me. Bash is always available; the constructs you can use are there (coreutils are mostly enough for the primitives and xargs for parallelization) It has been great so far for basic cases. Where things get complex (as other's have said) is handling failures, errors and intrinsic cases. That's when you're reminded why people didn't stuck with bash in the first place and we got other scripting languages.

With Amber (and anything like it) you need an Amber compiler to be able to work on the script. And half of the reason to use a "script" is the ability to edit them if need arises.

Also since I'm 100% Nix now, I require `nix` installed everywhere anywhere, and if there's `nix`, anything else is available in a reproducible way.

besides that? probably nothing.

But I always feel that if you reach a certain complexity in your bash scripts, you should rather pivot to any other $lang.

Bash scripts should be simple glue between programs (unix-principle).

If a script is literally just running a list of commands and occasionally piping the output from one to another, you may as well make it POSIX compliant (therefore a sh script) since you're not using any features of Bash anyway.

> But I always feel that if you reach a certain complexity in your bash scripts, you should rather pivot to any other $lang.

This is a common critique, but what other lang?

I make Bash scripts all the time for system administration tasks, and they largely just werk™ as long as you have Bash (90% of the time pre-installed) and the necessary commands. From there, any command can be readily called, piped, or saved to variables/arrays, and Bash has powerful (enough) native math and string manipulation capabilities.

Meanwhile with Python there's always some hassle installing dependencies with pip(x) and virtual environments, plus the unfortunate rare Python 2 encounter where you either gotta rewrite the whole thing in python 3 or figure out how to install the old Python 2 runtime and 3rd party python 2 libraries used in the script on your distro.

I don't see the appeal of sonething like the OP though. I can't imagine the "precompiled" scripts are so much more readable its worth the incomprehensible mess it appears to generate with the "compiled" script.

Why are people so afraid of Bash?

Clearly, if Amber did not have a dependency upon bc, it could then potentially provide value to those users.

It also seems odd to me that a place that would be so rigid about installing a tiny language runtime would be ok with checking in the artifact of an experimental programming language.

    Notice that when executing a single expression, Amber automatically includes it's standard library for you.

Maybe there are existing scripting langs that make this so? Ambers approach is not bad but I feel it could be even better.

  use IPC::System::Simple qw(capture);
  use Sub::Install qw(install_sub);
  
  foreach my $command (qw(foo bar baz)) {
    install_sub $command => sub { capture($command, @_) }
  }
  
  ...
  
  my $output = foo($x, $y); # will throw if calling 'foo $x $y' returns non-zero

Note that if you're distributing code p3rl.org/App::FatPacker will produce a single fat script that has (pure perl) dependencies included so you don't need to install anything (except for having a perl VM in $PATH).

There's also multiple libraries that provide a '$' function in JS (which may be why amber picked that delimeter) and then you can do

  let output = await $`foo ${x} ${y}`;

Note that bun.sh has a 'bun compile' subcommand that bolts together your (pure JS) code and the static bun binary to produce a single file you can also copy around.

I'd suggest avoiding backticks in ... everything. In shell, $() is nicer, and both perl's and ruby's backticks require effort to use safely.

No idea re python but I see no reason you couldn't do the function generation thing if you wanted to, and somebody's probably librarified it already.

Disclaimer: I work at Microsoft, but not on PowerShell.

I'm having a hard time deciding why I would want this. It seems more likely to result in bugs than being a useful feature.

  main = do
    let x = 2
    let x = "foo"
    y <- pure 3
    y <- pure "bar"
    putStrLn $ x ++ y

  main =
    let x = 2
    in let x = "foo"
       in pure 3 >>= \y ->
                       pure "bar" >>= \y ->
                                        putStrLn $ x ++ y

It's better than having a variable named age and another one named age_num or the opposite, str_age and age.

I would prefer that it produces code with a bit more whitespace for readability.

But only if your target environment has python, and that's not a given, not a zero-cost change, in this age of short-lived containers. The use case for a "compile to bash" language would be compile in a dev-operated environment and commit both source and output, which would then run on later stages in the CI/CD pipeline that might very well not have python. And those stages will absolutely not have your "compile to bash" tool, which would ideally be included along with the source unless it's somehow as near-omnipresent as python. This one appears to be implemented in rust, I'd certainly feel more optimistic about depending on it as a script authoring tool if it was e.g. a python script that could be included with my "pre-bash" source, and/or packaged in, say, npm.

The same applies if one needs awk, sed, etc... The constructs are just there.

Also the fact that you can just pipe to bash, makes development much easier.

For all its faults, after a Bash script works once, it usually just keeps working.

Download(file.gz)

and that gets converted to either a wget or curl based on what the system has.

    dl_tool=$(command -v curl || command -v wget)
    if [[ ${dl_tool} == *curl* ]]; then
      dl_cmd="${dl_tool} -sLO $1"
    elif [[ ${dl_tool} == *wget* ]]; then
      dl_cmd="${dl_tool} -q $1"
    else
      printf "%s\n" "ERROR: curl and wget not available, exiting"
    fi

Amber code gets turned into bash code, and run by a bash interpreter. So at best Amber's performance will match Bash's performance.

I've seen people say bash is faster than PowerShell, but I don't have benchmarks to back it up. Even so, I wouldn't recommend using it for performance intensive tasks such as writing a web server.

The great advantage I see for Amber is being able to write scripts in a sane language (bash is not enjoyable to write), and have those scripts be able to run anywhere that Bash is installed.

I don't get it. Asking not to be rude but to be educated.

The documentation didn't mention what version of bash is required, but it'll be something. And plenty of systems will have old versions of bash - especially once you move out of the world of "my laptop" - obviously.

As has been mentioned elsewhere, it makes many times more sense to just learn bash, than to learn this. You likely already know some, and it excels at the jobs it's designed for - which is chiefly to launch processes and pipe output around. Subshells are elegant, even if making sure everything launched by your script is 100% finished before you exit can be a pain.

I doubt Amber fixes that problem in any case.

I have WebGL disabled in my main browser for privacy reasons (super-easy to fingerprint), and I only get to see 'Application error: a client-side exception has occurred (see the browser console for more information).' with an error about ThreeJS initialization in the console.

I assume it's for the fancy animation, and I find that ridiculous. Loading a whole 3D library just to show a fancy animation. This could have been done much simpler by using an animated image format, though admittedly with less functionality - but is it even needed?

I fear the whole industry suffers from overengineering and this is just a symptom.

Even if you're convinced you need the fancy animation, why not gracefully fallback to not showing it and still make the docs usable?

I know what you mean, but statistically, I don't think that it is easier to guess the person from those who have disabled it versus the list of all browser fingerprints where is that matching or very close unique fingerprint.

You’re always leaking some kind of information that advertisers will pay for. The game is choosing what information you’re okay giving them

Yeah, it's not like adding a try/catch block around the webGL invocation was hard anyway…

But I agree with the sibling comment about disabling WebGL likely being a fingerprinting liability more than a win.

However the severity of drive-by risk is so high, just in theory, that I am tempted to dismiss the risk of fingerprinting. But my reasoning is not very well informed.

What principles and information sources do you use when deciding that avoiding fingerprinting is more important than avoiding WebGL drivebys?

That's not fantastic, but with WebGL enabled just the extension list can be used to narrow you down way further than that - according to https://amiunique.org/ 0.35% of users share my exact supported extensions list. My `gl.getParameter(gl.RENDERER)` seems to be unique to me, for some ungodly reason. The output from rendering a single triangle also narrows me down to 0.8% of all users.

From their statistics, it seems that WebGL gives far less info than things like the list of fonts, the Canvas properties, or the audio input, and more comparable to effective height of the screen (or even just user agent in my case, using Firefox on Linux, though I have to admit I'm surprised about that: 0.02% sounds really low).

Personally, by default I shut down all the browser crap that might needlessly allocate RAM or allow memory leaks or slurp cycles without giving me some kind of value. I think this allows me to hold at least a few hundred extra tabs open. For technical documentation I expect text, hypertext and static images, if you're going to require JS and WebGL and whatnot I'm going to assume you aren't entirely honest with me about the information we're about to share and I'll probably sandbox a scrape of the documentation if I really need it.

I did not say that the corporate practice is a good one, I just brought it up as an example to refute the suggestion that limited web browsers are incredibly unusual.

That said, very interesting syntax. I agree with others about the $...$ being kind of odd, but other than that this is really cool.

I thought it was clear, functional, told me everything I needed to know in the order I needed to know it, and also looked nice - tying into the "amber" branding well.

Maybe I just don't spend enough time on websites that are designed to hook me in and start charging a fee? ;)

Maybe a tiny note about it being open source could help.

Granted, bash is now GPL 3 (which is why Apple has to ship an obsolete version, and now defaults to zsh), so you can't use Amber on machines where GPL 3 won't fly (unless it can also compile to posix shell, zsh, etc).

Anyway, if you're interested in freedom for your users, I'd suggest AGPL 3, since it prevents people from locking it up inside the cloud or shipping with proprietary operating systems. At least that way, you're not stripping users' right to privacy like GPL 3 (inadvertently?) does.

These days, Apache and BSD-style licenses are looking better than ever to me, at least when I'm at work.

[edit: You can sell machines with Coreboot (and maybe a proprietary BIOS) + bash. However, you can't ship things that use a secure boot mechanism.

From reading the FSF documentation, it's not clear to me if it's OK to ship a GPL 3 userland on a machine with secure boot enabled, even if it can be disabled later. Apple apparently decided that it is not.]

Gmail is free as in beer, but not free as in freedom, while RHEL is free as in freedom, but not free as in beer.

Gratis vs Libre - the former is zero cost (i.e., you're not paying for the free beer), the latter is some cost (i.e., there is a price for free speech - we need to defend the right, accept we won't like everything that is said, etc.)

I do understand what GPL does and the reasons for this just not this slogan.

Amber claims to be type safe so it should have enough information to avoid the the use of bc in this case.

Ah, just looked at the documentation. Amber doesn't have integer types just a number type. That means that any numerical operation in Amber is pretty much guaranteed to be very inefficient.

It's a very strange choice to make because the underlying 'machine code' supports both integers and floating point.

But then they chose this for their front page example, the one that everyone will see, so I assumed this was to demonstrate something clever I just didn’t understand.

I wonder what the motivation was to not have an integer type?