Amber: Programming language compiled to Bash

I find all the "Why should I use this when X exist" nonsensical. If you can't see any use for it then it's not for you. There are a whole lot of people who will find this more attractive than Perl.

Why would I ever use this instead of just using perl5

Because the syntax in Amber is way easier to grasp. For me that's a very strong selling point

Why would I ever use perl5 instead of just using AWK?

/s

Perl is not quite as universally installed as you claim, especially in containers.

Perl was taken out of the FreeBSD base system ages ago.

Personal answer: I cannot read Perl. I've checked it out a few times and the syntax looks alien to me.

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.

Does PERL compile to bash? I thought it had its own interpreter. I can't figure out if you're one of those weird people that try to derail threads or if PERL is unique in a way that I never realized.

The problem with python2 is that it's getting (very slowly) phased out of distros now, but you can also write a python2/3 polyglot (which usually isn't so hard).

But I agree on the perl front.

It's not a big deal by I second that. I also thought, "let's see how they are making money out of this". I clicked on the github link and found out it's GPL 3.0, all of it, no open core or similar stuff.

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

I was more put off more by the initial example. Amber being used to calculate an age being less than 18. With sed. Seems almost like an attempt at humor, except the bit where one would laugh.

Somehow I didn't get that impression from the website at all.

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? ;)

I had the same exact reaction. Being an open source project doesn't mean the website has to be ugly or bare bones (though plenty are). But this is sending the wrong expectations about the project.

I think the project itself sounds very intriguing and I am sure to follow how it evolves. But I have to agree with you about the website. There are also some little inconveniences in there that are sure to annoy a technical minded person. Like the links on the upper right corner (GitHub etc.) that are not in fact links (<a>).

I agree. I think that these fancy visuals are not the right way to appeal to the target user base. I just want to read some text.

I think the biggest issue is the image of the floating chunk of amber plugged into computers. It looks 100% like something you'd see from yet another Ethereum hustle.

I actually thought the UI was very nice, and more open source utilities need to have good UI on their websites.

Just learn bash.

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.

... learn bash.

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.

Yeah, I stopped reading at that conversion. If it cannot handle a single "<" imagine more complicated logic, it would make debugging it a true nightmare.

Also, what's the point of having types in your language if you're not going to use native arithmetic when applicable:

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

I've done (some? a lot?) of bash scripting and failing correctly in the absence of dependencies is really important. And once you've incorporated them you've destroyed what was good about targeting bash in the first place, because you're back to giving the user a configuration management problem, and if you were going to do them, you might as well have them install $better_language anyway.

My reaction was that the bash version is a monstrosity indeed and I got shudders thinking about being an on-call operator getting a page and then having to read and understand what the hell is wrong with this script.

Surely it can't be harder to learn the fundamentals of shell scripting than to learn whatever flavor-of-the-month alternative is? I've been using GNU/Linux for ~10 years, and Bash never clicked for me. Meanwhile, picking up other (not all) programming languages in the meantime occurred naturally, without much effort. At the same time, some of my friends picked up unix shell scripting just fine, even if typical programming is harder for them.

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

having types in your language

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.

[0]: https://docs.amber-lang.com/basic_syntax/data_types

'WebGL disabled' is a pretty strong fingerprint anyways

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

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.

The reality is that in disabling WebGL, you have an incredibly unusual configuration and the author didn’t test for it. Stop making this a philosophical argument. Why does the documentation need WebGL? It doesn’t, but the web has moved beyond just addressing “needs”. Why do you need to be on HN? You don’t. Yet here you are. I’m not arguing that the juice is worth the squeeze here, but your argument has a false premise that you’re exploiting to make the situation sound more absurd than it is.

Bash is ubiquitous and stable, making bash scripts incredibly portable.

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.

I think the use case for this is where you need a bash script on a machine where you can't easily install and maintain a runtime.

Bash scripts should be simple glue between programs

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?

It's a common practice in Rust at least, where instead of having a mutable variable which you modify across several lines, you declare a new immutable variable with the same name on those lines. I like it, but I guess it really just comes down to preference and what you're used to.

It's useful in Rust where you might parse input as a string and then convert it to a number.

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

It's a pretty good way of preventing bugs actually. It prevents you from accidentally accessing the old value.

Rash (https://rash-lang.org/) and Oil (https://www.oilshell.org/release/latest/doc/ysh-tour.html) come to mind. Xonsh, too, as mentioned. Powershell too.

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.

It's generally quite doable to write functions for that, e.g. in perl -

  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.

try ruby. there are several ways to call commands but the simplest is simply the command string in backticks

Marcel the shell is surprisingly effective for that. It is python with seamless calling of external commands and piping:

    ls /home/jao | map (lambda f: (f, f.size))

Xonsh maybe?

The syntax is something like this:

  text=@(ls -lh).replace('a','b').split('b')

Have you taken a look at PowerShell? It can infer whether you're invoking a command or function.

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

and i dont like how it's inconsistent that echo is not using the $ syntax (which makes sense internally, as it's a built-in, rather than executing the $echo command).

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!

The generated code already looks kind of insane, I can imagine it would only be worse without the benefit of Bash features.

Same for me. There's still plenty of unused gemstones as programming languages so perhaps the authors may still decide to change their name.

This looks abandoned lol.

At first I felt the same way, because as a language designer I feel there are enough good names out there that new projects should be able to go find one that isn't taken.

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.

Because the runtime for those utilities is available on just about every Linuxy OS there is. Saves you having to install the runtime separately, eg in your CI pipeline.

You certainly should. Even if you know some bash and zero python I suppose, because bash is just so "special".

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.

I had done a SQL-like ->Bash "language," and the reason was that I wanted to have access to CLI tools as-is, in my case, curl programs. Had I chosen Python as a target, I'd have to use requests/urllib, which would be much more verbose.

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.

Python isn't nearly as likely to be installed already as Bash is.

And enjoy a mad scramble to rewrite everything after Python 4 releases?

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

And why is it using [ instead of bash native [[

Nothing can be done about variable names, but format inconsistencies can be autofixed with shfmt. I've been using it for years and it's been solid.

https://github.com/mvdan/sh

i think they do this since there's no source map or symbol mapping support on the debugger (which is just bash errors lol)

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.

Oil shell requires osh to run. That means that you can't run Oil scripts on systems that only have Bash installed.

It's an entirely different problem; the problem being solved here is not "use a better shell than bash". It's targeting bash as a universal runtime because it's (kinda sorta) ubiquitous.

Seems to render fine on Firefox mobile for me, but maybe I'm just not noticing what's broken.

yeah the landing page is pretty broken on Firefox for me, but the docs site works: https://docs.amber-lang.com/

It's not compiled in the way that C is compiled. Transpiled would be a better term (though there are debates on where the line is).

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 can see some very niche cases where an embedded system has bash not much else and "taking the most you can out of bash" could end up being useful.

besides that? probably nothing.

Because the project might require a script that is delivered to many Linux servers with less dependencies and not having to install a new language.

But then your compiled binaries are not portable cross-architecture, or your scripts require a compatible interpreter to be pre-installed.

That looks like a render error, on mobile Firefox it looks fine and scales well with an adjusted layout and sizes.

Adding to your point, I also instantly regarded Amber as an alternative to other higher-level languages. Especially scripting languages that require elaborate ahead-of-time setup. Amber will surely score some points here due to its portability in the Linux world. But other commenters seem to see it as an alternative to writing Bash scripts. So which will it be?

This is not even remotely an alternative to Rust, nor is it intended to be. It's a replacement for Bash.

Fittingly the now-defunct Amber Rapid was a blindfolded chess tournament.

Bash is available by default on a huge range of OSes.

I sort of see that, but at the same time why not just compile to python instead? I get that python can be less convenient syntactically for "scripting" type things, but if you're writing in what's effectively a DSL that gets transpiled for a different interpreter anyway...

Call it "typebash" - easily understood by everyone

Maybe it's targeting that ancient GPLv2 bash (that MacOS still ships for ideological reasons).

You mean this text below "Download for $OS"?

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.

As it's common - if someone doesn't realise what it is, it's: its it's should be its not it's.

    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

Both, since a transpiler is a type of compiler.

Both tools look useful (although I lean toward Amber's ECMAscript syntax). I liked this comment from batsh:

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.

What you think is ubiquitous is actually pretty narrow, and your perspective is biased based on your own experience; by "machines" you could mean containers, VMs (of a dozen different virtualization technologies), on a bunch of OSes and OS variants let alone distributions of same. You probably think something like an embedded Linux on a fleet of soft switches is a "niche case" but in the real world people work on these kinds of things all the time.

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.

Horrified and Impressed.

I would assume because bash is deployable to more locations with fewer assumptions. Scripting requires environments to be set up correctly to run, and binary makes architecture assumptions.