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.
I don't love the $...$ syntax for executing commands. Using $ as a string delimiter is very strange to my bash-accustomed eyes.
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.
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!
I think that this does fill a niche. You can still compile to bash outside of this austere environment, and run the scripts within it. And python isn't very ergonomic for running external shell commands (or, say accessing environment variables), the syntax for doing so in amber looks much neater.
> 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.
This looks very promising! I've been wanting something like this for years, a nicer shell scripting language which compiles to Bash so I can run it almost everywhere. I don't think Amber is not quite there yet, missing some pretty essential shell features, but is off to great start. I'll be keeping an eye on this.
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.
I was confused by Amber Smalltalk's pivot. Turns out it is just a newer language deciding to use the same name as an existing one. The domain is almost exactly the same as well.
there's some precedent, there was a half-done programming language called "merd"[0], I recall the author had a tagline on the lines of "if it does not succeed I can blame the shitty name!".
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.
So you see this is an implementation of Pharo Smalltalk that runs on JS.
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.
Quick note to the creators: the website looks almost exactly like every other "here try this cool command-line utility so we can hook you and start charging a service fee for it" startup website and I instantly distrusted it. The design communicates that you're selling a product, not providing an open-source utility.
That said, very interesting syntax. I agree with others about the $...$ being kind of odd, but other than that this is really cool.
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 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.
This is the compiled to Bash part. Sed is used because `bc -l` can return a float when integer is expected. Not sure if can be done better in generic case but it isn't unheard. Certainly can be optimized for some cases. (Here e.g. can use Bash's built-in integer arithmetic.)
But why does it use bc in the first place? Bash does integer arithmetic perfectly well on its own.
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.
This is the first thing I noticed. Using ‘bc’ and ‘sed’ for integer comparison seems quite odd.
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?
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? ;)
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.
It's taken from "Free as in [Free] Beer vs Free as in [Free] Speech"
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.)
That is the nearest to an explanation in all the answers ie saying "Beer is NOT free' all the others still confuse me as I read its literally. and 'Free as in beer' makes no sense so the whole thing just does not compute.
I do understand what GPL does and the reasons for this just not this slogan.
GPL 3 isn't great for either. From a commercial perspective, you can only use it if you lock your stuff up in a datacenter, but not if you ship it on a device that customers own. In practice, that means GPL 3 is not only supporting surveillance capitalism, but is also banning use in commercial systems that do not spy on their users. (The US CLOUD Act says that you have to provide the government with access to all machines you have access to, even if they are overseas. In practice, that means that any commercial GPL 3 stuff that has a footprint in the US is globally subject to US-style dragnet surveillance.)
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.]
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 sort of get that but does this hypothetical system not have a c compiler? If it does, you can compile and install lua in probably under 5 seconds and actually have a sane language with respectable performance to target.
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.
GitBash is a POSIX environment that includes the titular bash, and it doesn't include bc, which is a direct counterexample to your original assertion. Lots of people who are stuck on windows for one reason or another still want or need to use bash, and that's why they use GitBash!
Clearly, if Amber did not have a dependency upon bc, it could then potentially provide value to those users.
> 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.
I have to agree. Bash works fine in its environment, and while there are times when another language might be more appropriate for whatever reason, Bash works. I can run it on any box I have access to and if I stay away from utils that aren't preinstalled, I don't need to worry about dependencies. I've found that python is far more version and dependency driven.
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.
It's interesting Amber doesn't seem to be leveraging Bash-native Regexes via:
if [[ "${foo}" =~ ^someReg[e][x][p][r]$ ]]; then ...
What value exists in going to such great lengths to target super old and anqtiquated versions of Bash? It becomes very limiting for this poor new language :-s
Maybe still just the earliest of early days? Javascript-style RegExs along the lines of:
Rust, except using existing executables (or dynamic libraries) instead of downloading packages and waiting ages for it to compile? Seems like a great idea.
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?
I guess I don't understand the point. Could someone summarize why I would use this rather than writing my utilities in something that doesn't compile to a quirky, limited programming language?
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.
It's not, really. The claim would be that it's portable, but bash can be a little finicky in that respect.
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 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 ]
Pipelines and subshells are "slow". Not tremendously. But it adds up. Also, what's the point of having types in your language if you're not going to use native arithmetic when applicable:
if (( __0_age < 18 ))
Perfectly fine to alert users that floats will require an external dependency (such as dc), but integers will be handled in native arithmetic contexts.
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?
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.
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.
Have learned a bit of bash but that's what has kept me going on always. There's no point in learning million little inconsistencies all of which aren't even documented anywhere like a MDN or MSDN if you will.
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.
That's about where I gave up too. You make it sound like you disagree with me when in reality you do.
There is no real reason to write any production code in bash or any other shell language.
Bash is for automation, not building services. It's used heavily in sys admin and devops tasks
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.
You know that your shell environment is not forced on you, right? You can just switch to ZSH, fish, etc.
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.
> 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 spent 2h debugging a script only to find out there was an extra space character that made the whole thing break silently.
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.
You're right. To be fair, I'm absolutely immune to these kinds of quirks in any technology, and just adapt. This causes me to dislike no languages, and just work with them if they fit to the problem I have at hand.
This trait baffles a couple of my friends with no end.
> 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.
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."
> need to know of a million tiny gotchas to implement even the simplest task safely and portably
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.)
> 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.
(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.
> I definitely think there's room for an improved bash.
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 reason why it is attractive is to enable people who aren't ever going to get proficient at writing/debugging bash/sh to the level that you're at, to write enough bash/sh to get their jobs done both quickly and safely.
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.
Maybe if those people started visibly failing at their jobs, they'd either upskill or be forced out, and then the magical hand of the market would raise salaries for the rest of us.
Oh look you're basically me in 2006 thinking that all the sysadmins that couldn't be bothered to learn a real programming language needed to be replaced by people in India who weren't intellectually lazy (because I was a bit of an asshole and wrong).
As carlinigraphy points out, shellcheck [0] exists, and can easily be put into pre-commits, a CI pipeline, etc. This would have almost certainly flagged your problem immediately.
> 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.
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.
Agreed. For instance, the piped bc sed thing's error handling is apparently broken, and no one has pointed that out yet. pipefail and $() don't play nice with each other:
#!/bin/bash
set -euo pipefail
echo $(false|true)
echo a
echo $(false)
echo b
false
echo c
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.
> 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.
What I really want for scripting usecases is a language that has modern language concepts (easy to use arrays and maps, text formatting strings, etc) but that allows me to call commands as easily as I could call functions.
Maybe there are existing scripting langs that make this so? Ambers approach is not bad but I feel it could be even better.
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
(there's a Shell.pm but it's not as helpful with errors; I should probably consider rewriting it a more modern way)
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}`;
(the template string's variable parts get autoquoted)
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.
It seems to generate very bad/odd shell so I won't use it.
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.
I was hoping for a solid way to handle subprocesses, and especially how to handle failures.
They have something in the docs, but it seems a bit underwhelming, in terms of how status codes and failures are handled. It’s probably better than straight bash, but I feel like there’s more to be done here.
Also: I don’t see mentioned how pipes affect the exit code propagation (i.e. pipefail).
> Variable declarations can be overshadowed - this means that you can redeclare the existing variable with different data type in given scope if you need to.
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.
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.
I quite like that pattern, but I think 'with a different datatype' should result in a small gnome climbing out the back of the computer and hitting the developer with a mallet.
I guess I haven't read enough Rust code to come across this patterns, but I don't think I particularly like it. Perhaps I would get used to it though :)
I'm not sure what you find incomprehensible about the first example. The syntax is pretty standard. The only exotic thing is `$`, which is basically just like putting brackets around the rest of the line. Here's the first example roughly translated to Python:
def main():
x = 2
[x] = ["foo"]
y = 3
[y] = ["bar"]
print(x + y)
Seems about the same level of comprehensibility to me. Is there anything in particular you find difficult to understand?
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.
329 comments
[ 2.4 ms ] story [ 270 ms ] threadhttps://github.com/batsh-dev-team/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.
Why do people make things this way? Let a plain old link be a link..
I'm unsure how to feel.
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.
https://nixos.asia/en/writeShellApplication
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.
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.
https://amber-lang.net/
https://en.m.wikipedia.org/wiki/GemStone/S
Bagsy Coprolite.
[0] http://merd.sf.net
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.
So you see this is an implementation of Pharo Smalltalk that runs on JS.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.
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.]
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?
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.
https://github.com/mvdan/sh
Maybe still just the earliest of early days? Javascript-style RegExs along the lines of:
Would be pretty nice and handy.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 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:
Pipelines and subshells are "slow". Not tremendously. But it adds up. Also, what's the point of having types in your language if you're not going to use native arithmetic when applicable: Perfectly fine to alert users that floats will require an external dependency (such as dc), but integers will be handled in native arithmetic contexts.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:
The `declare -n` line is where the magic happens: https://www.gnu.org/software/bash/manual/html_node/Shell-Par...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.
https://yosefk.com/c++fqa/index.html
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.)
(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.
[0]: https://www.shellcheck.net/
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
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.
I suspect some people have trouble with the syntax used by Bash, and languages like Perl. But I can't pinpoint what causes it.
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:
Disclaimer: I work at Microsoft, but not on PowerShell.
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
(the template string's variable parts get autoquoted)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.
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.
Also: I don’t see mentioned how pipes affect the exit code propagation (i.e. pipefail).
Download(file.gz)
and that gets converted to either a wget or curl based on what the system has.
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.
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.
It's better than having a variable named age and another one named age_num or the opposite, str_age and age.