Amber: Programming language compiled to Bash
amber-lang.com
amber-lang.com
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...
> Maybe full POSIX sh compat is WIP
Still - I sure hope it's possible to do a comparison in sh without spawning two processes.
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!
Input sanitizing should be done before trying to hand inputs over to be summed.
// Define variables
let name = "John"
let age = 30
// Display a greeting
echo "Hello, my name is {name}"
// Perform conditional checks
if age < 18 {
echo "I'm not an adult yet"
} else {
echo "I'm an adult"
}
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.
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.
Please make sure that your user can access /opt/amber directory.
https://github.com/Ph0enixKM/Amber/blob/master/setup/install...
https://github.com/Ph0enixKM/Amber/blob/master/setup/uninsta...
The inconsistent indents and decorated variable names made them less readable than hand-written Bash scripts. I understand that most compiler outputs are not meant to be human readable, but generally we would get minification and/or obfuscation in exchange for losing readability, and Amber doesn't seem to offer those yet.
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/)) { ..
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.
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.
https://gist.github.com/nicerobot/53cee11ee0abbdc997661e65b3...
But you don't really need to spend any time learning them, just plug shellcheck itself into your editor and go write some scripts. I've written don't know how many thousands of lines of bash (and sh, depending on the task at hand) that work across five operating systems, and it's honestly a non-issue if you follow the warnings.
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.
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.
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.
Any sufficiently quirky technology is indistinguishable from insanity.
This trait baffles a couple of my friends with no end.
BTW, That's a great link. Thanks a lot.
Thanks for this time sink.
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."
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.
people still get paid to care about things like solaris 9 and aix 6.
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.
> 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.
Per docs[0], seems types are rudimentary. For numerics there's only one type for any number. Good remark regarding GNU vs others. This isn't seem be noted anywhere.
I would expect it uses bc instead of relying on bash's environment/version-dependent 32/64bit integers.
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 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).
Bagsy Coprolite.
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.
Strange. It seems to have gone down shortly after this Amber announcement.
It was up the day I read this announcement.
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<String, Map<String, Int>> 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.
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.
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.
- 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}/<put keys and values in files somewhere under here>
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).
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.
The thing I'm most proud of is the installation--you just put a single base64 encoded line at the top of your script, and everything works magically.
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.
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.
> 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.
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.
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.
Git Bash is pretty ubiquitous on developer machines in my experience.
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?
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.
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.
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.
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.
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.
let thing = whatever();
let thing = thing.unwrap();
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
def main():
x = 2
[x] = ["foo"]
y = 3
[y] = ["bar"]
print(x + y)
The second example is expanded out and not how a person would normally write it, but if you're familiar with the basic concepts it's using, it shows why it works very clearly; think of it like assembler.
x = 2
x = "foo"
[y] = [3]
[y] = ["bar"]
It's better than having a variable named age and another one named age_num or the opposite, str_age and age.
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.
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.
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 ]; thenThis 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).
e.g. https://github.com/amberframework/amber
https://ambermd.org/tutorials/
https://openjdk.org/projects/amber/
I'm probably grumpy, but I like unique names.
I'm unsure how to feel.
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).
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.
Clearly, if Amber did not have a dependency upon bc, it could then potentially provide value to those users.
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?
Notice that when executing a single expression, Amber automatically includes it's standard library for you.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.
Maybe there are existing scripting langs that make this so? Ambers approach is not bad but I feel it could be even better.
The syntax is something like this:
text=@(ls -lh).replace('a','b').split('b') ls /home/jao | map (lambda f: (f, f.size))
Disclaimer: I work at Microsoft, but not on PowerShell.
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.
Most high-level languages have packages that implement DSLs for running and connecting subprocesses. Python has both `subprocess` in stdlib and things like plumbum (https://plumbum.readthedocs.io/en/latest/index.html) or fabric as 3rd party packages. Scala has a little DSL ("echo 1" #| "cat" !) for this in stdlib. How lightweight the syntax is depends on how DSL-friendly the language is, so things like Ruby or Raku might be your best bets.
Just built a CLI a couple days ago with golang and it was an incredible experience where these things have come.
Things - acute product dev tools. Tools to create peculiar or not soo common tools.
Just built a CLI a couple days ago with golang and it was an incredible experience where these things have come.
Things - acute product dev tools. Tools to create peculiar or not soo common tools.
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.
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.
For all its faults, after a Bash script works once, it usually just keeps working.
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.
curl -s "https://raw.githubusercontent.com/Ph0enixKM/AmberNative/mast..." | $(echo /bin/bash)
I guess it would be too long to fit (aesthetically) on the page. The "copy" icon off to the left copies that line to your clipboard.
I would prefer that it produces code with a bit more whitespace for readability.
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
We got some great BASH alternatives: Zsh, Fish, Elvish, Nushell, Xonsh. I did not evaluate them all, but if Amber is even better, why not have Ambersh?
Can somebody please explain?
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.
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?
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.
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
Besides, advertisers are not who i worry about when it comes to "my data".
Unless you disable all JavaScript you’re leaking something. Honestly, you’re still leaking a bit without js, as long as where you’re connecting to is checking.
The game is just choosing what you’re okay telling wherever you connect to.
Not nearly as uniquely identifiable as your GPU model.
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).
That said, very interesting syntax. I agree with others about the $...$ being kind of odd, but other than that this is really cool.
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?
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.
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.
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.]
Why would I ever use this instead of just using perl5, which solves all these problems already and is preinstalled on every Unix machine I've ever seen (and I've seen a lot from HPUX to AIX) since there's always some ancient innards component that depends on it, so it's basically impossible to remove...
And even if you don't know perl, you're better off learning it than Amber, because perl may not be super popular anymore but it's still way way bigger with way more resources and libraries and documentation and even people you could hire etc etc (If you prefer python2, you can probably get close to but not quite the same level of universal compatibility)
I hope I don't have to work with some young fool who decided without trying that perl, an incredibly well documented language, is "too hard" and instead signed our whole team up to work with some experimental 3 month old language with who knows what weird bugs and quirks, none of which youll find info about on stack overflow, because almost nobody has ever used it Reminds me of the days about 10 years ago when all the kids were obsessed with no SQL and MongoDB for use cases that were smaller than SQLite -- purely because they were scared to learn SQL
You'll understand where I'm coming from after you get more experience and have had multiple jobs where you had to maintain architecture with poor choices due to an inexperienced original author using cool shiny tech that offers little advantage over the more mature tech, and you spend much of your time working around and maintaining something that has no stack overflow coverage at all
Besides, "runs anywhere bash does" isn't really useful for a personal project. Work is where you're likely to run into a weird variety of legacy machines, not in a personal project where you have more control.
Regardless, the weird aversion to hearing advice that can just be disregarded if it doesn't apply to your case baffles me.
But if you're looking for "reason" I think that falls on not re-doing the same thing over and over again.
It just starts a lame language war thread while being dismissive of and incurious about the thing being discussed. Things the site docs ask you to avoid as they reliably generate more noise than interesting conversation.
But I agree on the perl front.
Because the syntax in Amber is way easier to grasp. For me that's a very strong selling point
There's a lot of funky syntax and features available but you do not have to use any of them. If you are writing a new script from scratch it is easy to make it look almost the same as JavaScript but with every variable having a $ on front.
Also, amber is a new indie language. Perl has way more resources. I assure you amber will be harder to master including God knows what bugs are in the compiler you'll have to encounter and work around.
The problem is that it's difficult to know which features you should use and which you shouldn't. And good luck enforcing your desired style if you're working with other developers (it's possible, but painful).
Perl is a highly complicated language with many sharp edges that catch out even experienced Perl devs.
The Perl ecosystem is also completely dead: modules languish with no updates, there is no decent tooling to speak of.
Of course, this new language also has no ecosystem. But maybe one day it will. Let's not stamp out its flame for no reason.
Even bash or sh need not be installed in a container so that's a weird objection
/s
Awk has been standardized in posix since 1985.
Meanwhile, Amber looks perfectly readable, despite the fact that I've never used it. Maybe this is because Amber looks closer to languages that I'm used to. But I'd have a much easier time with it than any Perl script I've ever looked at. This is regarding personal, on-my-computer use cases.
Professionally, I think most of my coworkers would also have an easier time with this than Perl scripts, but of course, I could be wrong.
But imagine you need to deploy a server but for whatever reason you can't use Puppet, Ansible, or other configuration management tools. You need to write a deployment script using a "real" programming language.
How would you tackle the problem using Go, for example? Does anyone have examples of deployment or install scripts written in Go, Rust, or whatever else?
Thinking out loud I assume you would need a zypper (assuming openSUSE) package with Repository and Package structs and their methods, a secrets package to handle getting secrets from your secrets manager and setting them, and I'm drawing a blank on everything else.
As a system admin I picked up Go a few months ago to slowly reduce my Bash usage, but I still find myself using Bash whenever I have to write a install script because of how easy and fast it's to write compared to other languages.
Of course the disadvantage is that you need to Go have the toolchain installed everywhere you want to use the Go script, so it's definitely not as portable as using a regular shell script.
I do have the pyinfra documentation saved so I remember to take a look at it. I love Go for many reasons, but the distribution of binaries is probably at the top.
Although Bash is still king for small utilities, I have found myself writing such scripts in Janet[1] recreationally. Bringing the functional paradigm to shell scripts really is a lot of fun, if you belong to that conviction. Although the lack of portability and the fact that you need to "know Bash" to even use the Janet `sh` library kind of guarantees that it will always just be for fun.
Things like dealing with arrays, loops, calling APIs and parsing responses, etc. You certainly can do it all in bash, but at some point it becomes pretty unmaintainable.
Either I have to grant the whole Python process sudo privileges and manually change the ownership of all touched files, or I have to spawn a sudo rm process to remove the files owned by root (instead of using Python's standard library).
Neither of these makes the script simpler or easier to maintain.
You could have a separate python script you call via sudo.
Or you could automate the equivalent within python. Old discussion:
https://www.reddit.com/r/Python/s/tIYUq1Zgd3
Code (plus Python 3 & functionality updates; linked from the discussion, but knowing HN, some people will just wabt to skip straight to it):
https://gist.github.com/barneygale/8ff070659178135b10b5e202a...
Why do people make things this way? Let a plain old link be a link..
I also question the mindset that conflates programming with using a program. It seems until some philosopher explains the difference programming can't move forward.
Aside from that shell is the way many (most?) people interact with their computer, so some may find it offensive.