Bash is nice, but if we're going to all the effort of transpilation, I'd really like to see plain POSIX sh as the target
chme 108 days ago [-]
It isn't even pure bash, if it uses external commands like `bc` and `sed`. It should probably limit itself to posix shell (or bash, if they need to) and coreutils.
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.
chme 107 days ago [-]
I tested this a bit now, because I was curios, so it also requires `sudo` for the installation, installing it as `root` or as user with write permissions to `/opt` will not work and causes the misleading error:
Please make sure that your user can access /opt/amber directory.
Creating this directory, either manually or by the script before it fails to download amber, will cause the installer script think that amber is already installed. So not a very high quality shell installer script for a tool that generates shell scripts.
nerdponx 108 days ago [-]
The generated code already looks kind of insane, I can imagine it would only be worse without the benefit of Bash features.
sgarland 108 days ago [-]
THIS. Why does this:
if age < 18 {
echo "I'm not an adult yet"
} else {
echo "I'm an adult"
}
compile to this:
__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
instead of this:
__0_age=30;
if [[ ${__0_age} -lt 18 ]]; then
...
If you're going to compile to Bash, then use Bash-isms.
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
...
EDIT2: TIL that parameter substitution is POSIX [0] Section 2.6.2
There might be reasons to use `bc` like this if you don't know the type of `age` and it could be a non-numeric string. Buuuuut a programming language where a simple integer-comparison leads to two subprocesses is going to be slower than the slowest existing programming languages, by orders of magnitude.
chme 108 days ago [-]
Right. And the check/type validation shouldn't happen on comparison, but on assignment and only if it is dynamically assigned.
sgarland 108 days ago [-]
Am I missing something, like `bc` can parse `one + two`?
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"
}
So there is no input, everything is known statically. No sanitation required. Any additional checks done by amber in the bash code is unnecessary.
nick238 108 days ago [-]
So you want it to compile to POSIX sh but you're unhappy it doesn't use more POSIX-incompatible features? Maybe full POSIX sh compat is WIP, or in some simpler cases maybe it already is?
olejorgenb 108 days ago [-]
Retr0id, not sgarland want posix.
> Maybe full POSIX sh compat is WIP
Still - I sure hope it's possible to do a comparison in sh without spawning two processes.
sgarland 108 days ago [-]
As I've just updated my comment to reflect, TIL that parameter substitution is supported (with some exceptions) by `sh`.
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!
joveian 108 days ago [-]
"if ((age < 18)) ; then ..." works in bash.
Retr0id 108 days ago [-]
The alternative stance is that if it's already bad, can't hurt to make it worse ;)
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.
omoikane 109 days ago [-]
Assuming that these are typical outputs from Amber:
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.
5e92cb50239222b 109 days ago [-]
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.
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.
ape4 109 days ago [-]
And why is it using [ instead of bash native [[
weaksauce 108 days ago [-]
I think it's targeting a really old bash for max compatibility... and also it's super early alpha software
pubg 108 days ago [-]
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:
if (s.match(/my[R]egex[H]ere/)) { ..
Would be pretty nice and handy.
graypegg 108 days ago [-]
I kind of wish this was a tool to author bash, or better yet very compatible POSIX sh. (versus being using bash as a compile target that a human isn't meant to read)
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.
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.
carlinigraphy 109 days ago [-]
To my eye, this does not look good.
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?
xnickb 109 days ago [-]
> 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.
bayindirh 109 days ago [-]
> 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.
samatman 108 days ago [-]
> However this does not mean C++ is an insane language. It means it has quirks.
Any sufficiently quirky technology is indistinguishable from insanity.
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.
BTW, That's a great link. Thanks a lot.
107 days ago [-]
nativeit 108 days ago [-]
C++ is not dead, it just smells funny.
Thanks for this time sink.
carlinigraphy 108 days ago [-]
> 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.
carlinigraphy 108 days ago [-]
> 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.
lamontcg 108 days ago [-]
bash isn't even ubiquitous enough to be a fully qualified alternative.
people still get paid to care about things like solaris 9 and aix 6.
lamontcg 108 days ago [-]
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.
sgarland 108 days ago [-]
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.
lamontcg 108 days ago [-]
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).
sgarland 108 days ago [-]
I'm against intellectual laziness in general; I don't care what your nationality is, just don't be incurious.
sgarland 108 days ago [-]
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.
> 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."
wg0 109 days ago [-]
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.
xnickb 109 days ago [-]
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.
verdverm 109 days ago [-]
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.
deaddodo 109 days ago [-]
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.
xnickb 109 days ago [-]
> The only time this complaint is valid
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.
deaddodo 108 days ago [-]
> 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.
mywittyname 108 days ago [-]
> ... 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.
hedora 108 days ago [-]
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
Prints 'ab'.
partdavid 108 days ago [-]
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.
viraptor 109 days ago [-]
> 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.
forgotpwd16 109 days ago [-]
>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.
> 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.
xandrius 109 days ago [-]
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.
jnsaff2 109 days ago [-]
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.
ephimetheus 109 days ago [-]
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).
spooneybarger 109 days ago [-]
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.
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.
riffraff 109 days ago [-]
Same for me. There's still plenty of unused gemstones as programming languages so perhaps the authors may still decide to change their name.
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!".
There should be a link on the home page linking to the amber-lang.net to avoid confusion.
Strange. It seems to have gone down shortly after this Amber announcement.
It was up the day I read this announcement.
SuperHeavy256 109 days ago [-]
This looks abandoned lol.
supriyo-biswas 109 days ago [-]
I love the concept of a language like this, though I haven't evaluated amber in detail.
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.
chriswarbo 108 days ago [-]
One approach I've used for running arbitrary code, with arbitrary dependencies, without having to rely on much support from the host system, is to create an Arx file (a shell snippet followed by tar gz data, which is self-extracting/executing) using `nix bundle`. On one hand it feels like a "poor man's container image"; but it's better in some ways since it doesn't need any daemons, etc. to be running.
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).
hnlmorg 108 days ago [-]
There are lots of new shells around that does support everything you’re describing. Eg:
- nushell
- elvish (was featured on HN recently)
- powershell
- murex (disclaimer: I’m the author of that one)
jonathankoren 108 days ago [-]
Yeah. Sh needs to be abandoned. There's a million better alternatives, including those without such an asinine syntax.
nucleardog 108 days ago [-]
If I’m going to install a tool to run my code, why would I pick any of these alternatives instead of going straight to a “real” programming language?
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.
hnlmorg 108 days ago [-]
Because a shell is also REPL for interacting with command line utilities. It solves a different problem to “real programming languages”.
pubg 108 days ago [-]
This is a well-informed observation.
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>
fluidcruft 109 days ago [-]
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...
beefnugs 108 days ago [-]
I am wondering why not take an existing language like python, and compile that to bash?
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
pubg 108 days ago [-]
> I am wondering why not take an existing language like python, and compile that to bash?
You'll run into the Alternative Implementation Problem
> 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.
zem 108 days ago [-]
i guess the idea is that you can scp the output script to a machine that has only a minimal *nix install and run it there without having to install anything more. so bash, bc and sed but not python or ruby
fluidcruft 108 days ago [-]
That's an argument for POSIX sh, not bash.
zem 107 days ago [-]
that is definitely true! though i wonder whether bash is ubiquitous enough these days that it can serve as an acceptable "we can rely on this being there" shell.
lytedev 108 days ago [-]
I'm guessing because Bash is "more everywhere" than Python.
KerrAvon 108 days ago [-]
As slow as Python is, though, Bash is more slow. Much more slow.
hnlmorg 108 days ago [-]
It’s actually fork() that’s slow, rather than Bash itself.
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.
RodgerTheGreat 108 days ago [-]
I will make no claims or implications whatsoever that it's "production-ready", but a different strategy which could work is to use Awk (which is at least as omnipresent as bash) to bootstrap an interpreter for a richer scripting language: https://beyondloom.com/blog/lila.html
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.
albinekb 108 days ago [-]
Neat! We did something in the similar spirit after having too many beers once : https://github.com/LinusU/monofile
The idea was to be able to mix languages in a single file, including the implementation
poikroequ 109 days ago [-]
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.
LectronPusher 109 days ago [-]
I haven't seen a mention of the Oil Shell (https://oilshell.org) project's OSH/YSH yet and I'm quite surprised.
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?
biggestlou 108 days ago [-]
Oil shell requires osh to run. That means that you can't run Oil scripts on systems that only have Bash installed.
greggyb 108 days ago [-]
Osh is stricter than bash. Anything written to osh should run in bash with no issues whatsoever.
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.
partdavid 108 days ago [-]
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.
Too 108 days ago [-]
What’s the use case for that though? Nobody writes shell because they want a shell language. It’s written purely out of necessity because that’s the lowest common denominator installed on all systems. Something that Amber here provides a potential exit path out of.
Oil would have to reach a really critical mass before it can compete, which is sort of a catch 22 situation.
zem 108 days ago [-]
oil's idea is that you do want a shell language (e.g. if a lot of what your code is doing is job control and manipulating unix pipelines I can see shell being the best language to express that neatly in). you just want a better shell language than bash. but there is a ton of existing investment in bash itself and things like nushell their that away to start from scratch, and oil says what if we build a better bash instead.
108 days ago [-]
manlobster 109 days ago [-]
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.
chii 109 days ago [-]
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!
chrisjharris 109 days ago [-]
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.
freedomben 109 days ago [-]
> the requirement of having `bc` installed means you must also have the ability to run package installation
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?
mayli 109 days ago [-]
No, it's often not, it's one of the common package you install manually to compile a linux kernel
lelanthran 108 days ago [-]
> 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.
tredre3 108 days ago [-]
It's not pre-installed on Debian and SUSE.
rascul 108 days ago [-]
It's part of posix and should be available anywhere a posix like environment is offered.
RodgerTheGreat 109 days ago [-]
Shelling out to awk would be a more portable choice than bc, though awk would bring you much closer to the featureset of Amber to begin with.
vhmc41 109 days ago [-]
I was really confused because there's also a Amber Language that compiles to JS: https://amber-lang.net/
queuebert 108 days ago [-]
Fittingly the now-defunct Amber Rapid was a blindfolded chess tournament.
leni536 109 days ago [-]
I like the idea, but the example suggests that it invokes external programs for trivial stuff, like comparing a variable to an integer (invokes bc and sed). I would prefer if it compiled to pure bash, and only invoked external programs if explicitly called for. But I guess emulating some feature in pure bash is hellish, that's exactly I don't want to write that manually either though.
fluidcruft 109 days ago [-]
Maybe it's targeting that ancient GPLv2 bash (that MacOS still ships for ideological reasons).
jordemort 108 days ago [-]
I think this is a pretty interesting idea. I could see myself using this on one of my previous embedded jobs; we needed to stuff a bunch of complex logic into our initramfs and the only interpreter we could really fit in there was the sh from busybox. We ended up with a pretty hairy shell script that probably would have been nicer to write in Amber.
burky 109 days ago [-]
This looks similar to a tool I discovered a while back called Batsh. But Amber looks a lot more polished and has some nice safety about it.
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.
bogwog 109 days ago [-]
This is interesting, but I don't see why I would use this instead of Python or Go? With those I'd get portability, modern features, etc but with the added bonus of a powerful standard library and ecosystem.
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).
okennedy 109 days ago [-]
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.
ModernMech 109 days ago [-]
Why doesn’t Amber have equivalent issues? Such as depending on a specific version of bash, or specific executables to be installed.
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.
Sebb767 109 days ago [-]
> Why doesn’t Amber have equivalent issues? Such as depending on a specific version of bash, or specific executables to be installed.
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.
fluidcruft 108 days ago [-]
Only the ancient GPLv2 bash is actually ubiquitous and you might as well just target POSIX's sh if that's the argument.
sundarurfriend 109 days ago [-]
> Also does bash run on windows outside of WSL?
Git Bash is pretty ubiquitous on developer machines in my experience.
ModernMech 109 days ago [-]
"pretty ubiquitous" is what I'm referring to here. OP seemed to imply that because the other options have "non-zero friction" that targeting bash has zero friction. But you have to make sure bash is there, and if it's not, you have to install a toolchain that may include an entire operating system.
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?
freedomben 109 days ago [-]
Amber doesn't have equivalent issues because bash and the utilities it uses like bc and sed are incredibly stable. I've found nontrivial shell scripts I wrote decades ago that still run entirely unchanged.
ModernMech 108 days ago [-]
That only applies to platforms on which those utilities already run. We are talking about portability here, so that means Windows, and those utils don't run on Windows. So you're left with git bash, which isn't bash and isn't running the same utilities; and WSL, which requires installing an entire operating system.
So I ask again, why does targeting bash offer a better portability story than say the JVM?
freedomben 108 days ago [-]
I suspect we may have different ideas of the use case here. To me Amber is not a language I would develop an application in. I would use it in the same places I currently write bash.
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.
sgarland 108 days ago [-]
GNU and BSD tooling differs in small, but sometimes breaking ways. One example off the top of my head is that GNU sed accepts `sed -i`, but BSD requires `sed -i ''`, i.e. an empty string to tell it not to back up the existing file. Or GNU awk having sorting capabilities. Etc.
joveian 108 days ago [-]
Or the lack of a portable stat :(.
bogwog 109 days ago [-]
I didn't realize we were going so far back. In that case, Perl may be more convenient than Python/Go, and almost certainly a better choice than bash.
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?
hedora 108 days ago [-]
A few days ago, I tried running some code that hasn't been updated in about 5 years. The python launcher has bit-rotted, so now I need to rewrite it. The other 99% of the project compiles fine.
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.
rewgs 108 days ago [-]
But whenever people talk about writing Bash, you always have someone advocating that you should write POSIX sh instead if you want maximum portability. To paraphrase Qui-Gon Jinn, "there's always a more portable language."
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.
schmidt_fifty 108 days ago [-]
[dead]
michaelmior 109 days ago [-]
> 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.
mort96 109 days ago [-]
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.
mst 109 days ago [-]
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.
mort96 107 days ago [-]
Meh. I don't mind:
let thing = whatever();
let thing = thing.unwrap();
EDIT: what the hell I say I don't mind a particular pattern and that's enough for a downvote? Not that I care but I find this surprising
michaelmior 109 days ago [-]
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 :)
kbp 108 days ago [-]
It works the same way in Haskell, eg
main = do
let x = 2
let x = "foo"
y <- pure 3
y <- pure "bar"
putStrLn $ x ++ y
which is really the same as
main =
let x = 2
in let x = "foo"
in pure 3 >>= \y ->
pure "bar" >>= \y ->
putStrLn $ x ++ y
So it works pretty naturally where each assignment is kind of like a new scope. If the type system is good, I don't think it really causes issues.
mort96 107 days ago [-]
Haskell has got to be by far the least readable language in the world, all of that is incomprehensible
kbp 106 days ago [-]
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.
kbp 106 days ago [-]
Er, actually
x = 2
x = "foo"
[y] = [3]
[y] = ["bar"]
Sorry, I didn't re-read the code before translating.
adhamsalama 109 days ago [-]
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.
michaelmior 109 days ago [-]
I guess that's fair. I haven't seen that pattern in Rust before and I don't think I particularly like it, but I can see why some might.
IshKebab 109 days ago [-]
It's a pretty good way of preventing bugs actually. It prevents you from accidentally accessing the old value.
fforflo 109 days ago [-]
I don't share the "oh my, why bash, why not English then?" sentiment in the comments.
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.
viraptor 109 days ago [-]
I wish nushell had a similar compiler. It would help with using it on servers.
anonu 109 days ago [-]
Maybe I lack a bit in creativity: but what purpose does this serve? Almost all machines have a python or even perl interpreter if you really need to go there.
partdavid 108 days ago [-]
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.
saurik 109 days ago [-]
Something I noticed when I went to copy/paste something off the web page for this comment: at least some of the text on this page is in the form of an SVG?! That just feels gratuitous to me, particularly given how annoying it is to not be able to copy it :/.
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 ];
Look: I appreciate that this is a shell script, and they often aren't "fast", but if I'm writing code in a script and have a comparison it at least might be in some tight loop and the performance different of spawning bc and sed into a subshell is frankly brutal.
if [ "${__0_age}" -lt 18 ]; then
philmitchell47 109 days ago [-]
Seems horrendously brittle. I'd trust badly written bash over this.
slushy-chivalry 109 days ago [-]
I think a superset of bash with strong types makes more sense than a brand new language that compiles to it. This is what makes typescript so successful (aside from other things) is that you can just drop it into your project and incrementally adopt it.
ape4 109 days ago [-]
Call it "typebash" - easily understood by everyone
DemocracyFTW2 108 days ago [-]
> In Amber, there is a rule that allows you to use a : symbol where you intend to write only one statement, wherever you can write a block of code. This can be handy when you want to perform multiple conditions with a single statement each.
This feature, optional omission of delimiters in the special case of a single statement per branch, originated in early C and has since facilitated untold numbers of bugs, not least the spectacular Heartbleed bug (which has its own homepage, https://heartbleed.com).
adamtaylor_13 109 days ago [-]
I love the idea, but having spent so much time learning the ins and outs of bash I feel like I’d rather just use bash. To say nothing of the Lindy Effect. Bash will probably be here in 50 years. This probably will not.
This is equal parts horrifying and impressive and useful.
I'm unsure how to feel.
geocrasher 109 days ago [-]
Horrified and Impressed.
lifeofguenter 109 days ago [-]
Impressive project.
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).
DaSHacka 109 days ago [-]
> 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?
geocrasher 108 days ago [-]
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.
nickm12 109 days ago [-]
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.
thefaux 109 days ago [-]
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.
teo_zero 109 days ago [-]
On a machine where you can't easily install and maintain a runtime but you can install bash and amber and bc and sed?
IshKebab 109 days ago [-]
No, because you don't need to install Amber, and bc and sed are pretty much guaranteed to be installed already if bash is.
RodgerTheGreat 108 days ago [-]
GitBash (MinGW) doesn't ship with bc or dc, but it does ship with awk.
IshKebab 108 days ago [-]
This is targeted at Linux and Mac. If you're using Windows you are in the lucky position of probably not having or needing Bash.
RodgerTheGreat 108 days ago [-]
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.
HKH2 109 days ago [-]
Rust, except using existing executables (or dynamic libraries) instead of downloading packages and waiting ages for it to compile? Seems like a great idea.
karmarepellent 109 days ago [-]
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?
IshKebab 109 days ago [-]
This is not even remotely an alternative to Rust, nor is it intended to be. It's a replacement for Bash.
HKH2 108 days ago [-]
I know, but it looks like it is heading in that direction.
gmdrd 109 days ago [-]
There is a typo in the docs:
Notice that when executing a single expression, Amber automatically includes it's standard library for you.
robxorb 109 days ago [-]
As it's common - if someone doesn't realise what it is, it's: its it's should be its not it's.
wavemode 109 days ago [-]
I can't envision a circumstance where I would use this over perl. Every Unix system under the sun has perl. Even MacOS has perl.
msl09 109 days ago [-]
Great stuff. I hate having to write bash scripts and this seems like a great way to create scripts that will run on even old linuxes. Seems that there are a few sections missing in the documentation, stuff like the standard library and the extended documentation about handling failure, very alpha indeed :^D. I'll definitely be keep an eye on this one.
dpc_01234 108 days ago [-]
If I need an extra tool that will compile stuff, I might as well use a normal compiled or scripting language. Which I often do.
Retr0id 108 days ago [-]
But then your compiled binaries are not portable cross-architecture, or your scripts require a compatible interpreter to be pre-installed.
dpc_01234 108 days ago [-]
Worth it.
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.
fb03 109 days ago [-]
I think this is a cool concept, and all, but honestly, at this point, why just not use Python3 as your project's scripting language, and reap all the benefits of a simple, typesafe/autocomplete ready language with broad IDE support, and no intermediate 'compile step' which generates "don't touch" code?
aiisjustanif 108 days ago [-]
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.
aruametello 108 days ago [-]
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.
liampulles 109 days ago [-]
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.
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.
liampulles 108 days ago [-]
Oil/ysh looks very much like what I would like - thanks!
mst 109 days ago [-]
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.
inbetween 109 days ago [-]
Marcel the shell is surprisingly effective for that. It is python with seamless calling of external commands and piping:
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.
mattbessey 109 days ago [-]
try ruby. there are several ways to call commands but the simplest is simply the command string in backticks
nathan_compton 108 days ago [-]
This really can only work if the error messages map back to the right line number, right? I used to f with transpilation and if you can't get the error line at least, its a really huge overhead for not much gain, given that transpilation can only move the semantic needle so far.
queuebert 108 days ago [-]
Having some array syntactical sugar alone would be invaluable for us casual Bash programmers.
That looks like a render error, on mobile Firefox it looks fine and scales well with an adjusted layout and sizes.
Jaxan 108 days ago [-]
Could be. For reference my 4inch screen is 320px wide.
therealmarv 108 days ago [-]
I would use it if we can do a (best-effort) import of existing bash scripts into Amber.
VagabundoP 109 days ago [-]
This fits my use case where I want to run some system commands but Python is too heavy.
v3ss0n 109 days ago [-]
Why would someone need to compile to bash.. how about just use python instead
usrusr 109 days ago [-]
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.
fforflo 109 days ago [-]
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.
DaSHacka 109 days ago [-]
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.
IshKebab 109 days ago [-]
Python isn't nearly as likely to be installed already as Bash is.
yau8edq12i 109 days ago [-]
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?
kitd 109 days ago [-]
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.
yau8edq12i 109 days ago [-]
It's not much of a "runtime", though. How is it better than a plain executable?
plasticeagle 109 days ago [-]
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 doubt Amber fixes that problem in any case.
kitd 109 days ago [-]
Ok if your scripting language compiles to plain stand-alone executables and has good built-in support for processing shell commands and their IO.
Alifatisk 108 days ago [-]
The homepage is good looking and I applaude them for that, but I gotta admit, it's almost too dark for me to see some of its content. I think grey text on black background is risky move.
iansinnott 109 days ago [-]
Odd that (on desktop) the actual install URL is obscured by a gradient.
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.
1propionyl 109 days ago [-]
Looking at the output I find myself thinking: "if this kind of thing caught on, it would only be a matter of time until someone proposes a BASM (Bash ASM)..."
Humphrey 108 days ago [-]
Love the idea, but I've found myself switching to Python once my bash scripts get to complex. Easy to maintain, and doesn't need compiling.
krunck 108 days ago [-]
The Amber installer is itself created from Amber. I suppose that makes sense....
I would prefer that it produces code with a bit more whitespace for readability.
hi-v-rocknroll 108 days ago [-]
Adjacent: I've yet to find a good bash transpiler (to C at least), but I think it would help make some slower scripts usable.
throwaway894345 109 days ago [-]
Man, I'll bet that's a real joy to debug.
maupin 108 days ago [-]
I like how the website is as easy to read as a glossy magazine brochure in a gloomy cave entrance on an overcast day.
evnix 109 days ago [-]
I wish there was a solution for something like
Download(file.gz)
and that gets converted to either a wget or curl based on what the system has.
sgarland 108 days ago [-]
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
Can easily be turned into a function.
109 days ago [-]
pgt 109 days ago [-]
Would be great if a compiler existed that compiles ClojureScript or Babashka code to Bash.
cvrajeesh 109 days ago [-]
Is this a transpiler or compiler?
gloria_mundi 109 days ago [-]
Both, since a transpiler is a type of compiler.
snickerer 108 days ago [-]
I totally understand the drive to a more modern shell language. But why translate Amber into bash, why not execute it directly? Why there isn't an Ambersh?
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?
bar000n 108 days ago [-]
maybe you want to run scripts on machines where you can't install everything you want (alternative shells)
classified 109 days ago [-]
Is this some kind of hoax? The page just shows an image. This looks very suspect.
Very interesting. Don’t think I’ve seen anything like this before. How would the speed on something like this be compared to PowerShell, for example? Is it faster because it’s compiled? Could I write a web server in it?
notdefio 108 days ago [-]
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.
replwoacause 108 days ago [-]
Thanks that makes sense.
adityamwagh 107 days ago [-]
The design of the website is so damn cool.
v3ss0n 109 days ago [-]
Why would someone need to compile to bash..
kitd 109 days ago [-]
Bash is available by default on a huge range of OSes.
forinti 109 days ago [-]
I dunno, why not just use Perl or Python?
up2isomorphism 109 days ago [-]
Compile to Bash? Why not compile to English then?
ARandomerDude 108 days ago [-]
Why would a person go this route instead of a higher-level scripting language (Python, JS, Ruby, etc.) or a full-blown binary (Go, Rust, etc.)?
I don't get it. Asking not to be rude but to be educated.
tmvphil 108 days ago [-]
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.
srid 109 days ago [-]
Now someone needs to add this to Nix, by providing an alternative to `writeShellApplication`:
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?
feisuzhu 109 days ago [-]
'WebGL disabled' is a pretty strong fingerprint anyways
nicce 109 days ago [-]
"Disabled" is not metric among those who have disabled it, while WebGL enabled allows identifying different browsers with WebGL enabled.
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.
dartos 109 days ago [-]
You just self select as someone who wants to see privacy focused ads
murat124 109 days ago [-]
adblock/ublock/umatrix could get you out of that too.
dartos 109 days ago [-]
Sites can tell if you’re running Adblock too.
You’re always leaking some kind of information that advertisers will pay for.
The game is choosing what information you’re okay giving them
schmidt_fifty 108 days ago [-]
Doesn't really matter if you can block the ads anyway
Besides, advertisers are not who i worry about when it comes to "my data".
dartos 107 days ago [-]
You just self select as someone who uses Adblock.
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.
ruined 108 days ago [-]
and clearly parent is not okay with choosing to give the information behind the webgl api
109 days ago [-]
f33d5173 108 days ago [-]
It makes you look the same as everyone else with webgl disabled. This happens to be a reasonably large number of people, because it's the default setting in a variety of privacy focused browsers.
ActionHank 109 days ago [-]
What?
Not nearly as uniquely identifiable as your GPU model.
littlestymaar 109 days ago [-]
> 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.
barfbagginus 109 days ago [-]
I find WebGL driveby risk and fingerprinting risks remote and hard to compare. To wit, I've never experienced a recognized loss from any kind of drive-by or fingerprinting attack.
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?
alexvitkov 109 days ago [-]
If you disable WebGL you're putting yourself in the 2% of devices that don't support it.
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.
nativeit 108 days ago [-]
This is potentially a very interesting/useful site. My only problem is with some of the questionable statistics it's showing, that might suggest their dataset is not strictly representative. The time zones in particular seem to be significantly skewed compared to their respective population distributions. There's also a suspiciously large number of UTC0 fingerprints, which suggests they might have a large number of crawlers/bots in their dataset.
littlestymaar 108 days ago [-]
Thanks for the website, it's very interesting.
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).
mywittyname 108 days ago [-]
Using firefox on a mac is basically enough to put me as all time unique on that site.
nativeit 108 days ago [-]
Me too, my user agent was something like 0.01%.
108 days ago [-]
cqqxo4zV46cp 109 days ago [-]
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.
cess11 109 days ago [-]
I don't think it's incredibly unusual. On sensitive machines in corporate settings you commonly disable pretty much everything on every page that isn't in the 'trusted zone' or whatever.
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.
postalrat 109 days ago [-]
If you mean block all network traffic that isn't in the trusted zone then sure. But disabling features you personally don't like isn't a good security practice.
cess11 108 days ago [-]
Maybe I wasn't clear. First I described a somewhat common practice in corporate settings, which is ostensibly motivated by security policies. Then I described my personal preference, which I motivated with resource consumption and performance factors.
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.
ecef9-8c0f-4374 108 days ago [-]
Disabling features less attack surface
auxfil 109 days ago [-]
[dead]
orthecreedence 109 days ago [-]
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.
robxorb 109 days ago [-]
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? ;)
pmontra 109 days ago [-]
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.
PartiallyTyped 109 days ago [-]
Also a note about it being Free as in Beer.
533474 109 days ago [-]
Free as in Freedom, not free as in free beer...
mst 109 days ago [-]
In this case, as in both.
hedora 108 days ago [-]
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.]
pasc1878 109 days ago [-]
No as I really don't understand that - beer costs money.
DaSHacka 109 days ago [-]
Precisely, beer costs money so "free as in beer" means "free as in money" as opposed to "free as in freedom" that means "free as in ideology"
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.
Jenk 109 days ago [-]
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.)
0x457 108 days ago [-]
It's a difference between the freedom to say "I want a beer" and a free beer given to you. That it means it's free in a monetary sense.
pasc1878 108 days ago [-]
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.
epidemian 108 days ago [-]
"free beer" means something very different to "free speech". That's what the phrase refers to.
pmontra 109 days ago [-]
Yes, that should change to Free as in Air.
zxexz 109 days ago [-]
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.
forgotpwd16 109 days ago [-]
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.)
kwhitefoot 109 days ago [-]
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.
wrasee 109 days ago [-]
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?
queuebert 108 days ago [-]
You could also do the extremely readable `| cut -f1 -d.` which will do nothing for an integer.
ape4 108 days ago [-]
Its ugly code - why would they show it off.
karmarepellent 109 days ago [-]
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>).
nickm12 109 days ago [-]
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.
chrisjharris 109 days ago [-]
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.
Tao3300 109 days ago [-]
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.
SuperHeavy256 109 days ago [-]
I actually thought the UI was very nice, and more open source utilities need to have good UI on their websites.
108 days ago [-]
chimen 109 days ago [-]
[flagged]
Woeps 109 days ago [-]
What does this have to do with their comment?
The poster was giving feedback about a concern (maybe not a concern but something that they noticed).
galdosdi 108 days ago [-]
Cool idea. In practice: they already did this and it's called PERL!
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)
melodyogonna 108 days ago [-]
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.
galdosdi 108 days ago [-]
I'm trying to help people here. I know some young people may not even be aware of older options and not realize this problem has already been solved repeatedly. They are free to disregard my advice, so I find your objection more nonsensical
pvg 108 days ago [-]
I'm trying to help people here.
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.
tempaccount420 108 days ago [-]
How does this help though? Why should we stick to old software? Why advocate for inertia?
Minor49er 108 days ago [-]
Old software has had use, discussion, support, and resources that are usually still easily available. New software may have to reinvent a lot of wheels, so the barrier to entry may be higher despite the language's features. Choosing one over the other is all dependent on the problem that's being solved
mlhpdx 108 days ago [-]
Because solving new, current problems is more valuable than re-solving old ones? Is the new thing good? Yes. Is the old thing good? Yes. Both can be true. And, there is some value in better solutions to old problems.
But if you're looking for "reason" I think that falls on not re-doing the same thing over and over again.
galdosdi 108 days ago [-]
Because they've heard the "lol perl is line noise" jokes and taken them very seriously instead of the jokes they are. Perl is way more mature with way more libraries, stability, documentation, etc.
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
Legion 108 days ago [-]
Have you stopped to think that maybe people will use this "experimental 3 month old language" for their personal stuff, and that not everything in programming is for your "whole team"?
galdosdi 108 days ago [-]
Then they can disregard my advice obviously. But I saw plenty of others in this thread who seemed interested in it genuinely for practical reasons, and with all the times I've seen young devs disregard old mature solutions, I thought it'd be worth mentioning.
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.
melodyogonna 108 days ago [-]
My answer still applies to this long... ehh explanation?
gurtwo 108 days ago [-]
> 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
galdosdi 108 days ago [-]
Have you tried perl or are you just judging it based on strreotypes? The only weird syntax relative to something like JavaScript is $ at the front of variables.
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.
inhumantsar 108 days ago [-]
maybe this is outdated prejudice at this point but I learned early that perl as a language is fine, right up until you need to deal with scripts someone else wrote. particularly scripts written in anger.
HL33tibCe7 108 days ago [-]
> There's a lot of funky syntax and features available but you do not have to use any of them.
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.
pronik 108 days ago [-]
Perl was literally reborn with "Perl Best Practices". Perl::Critic has more rules that you'd ever wish for, Perl::Tidy is the most configurable code formatter there is. This had been true for 10-15 years already. Which part do you find painful and is this your idea of "no decent tooling"?
mlhpdx 108 days ago [-]
You're arguing against Perl or JavaScript?
mat_epice 108 days ago [-]
Perl is not quite as universally installed as you claim, especially in containers.
galdosdi 108 days ago [-]
Not in containers by their nature, but you have control over those so you probably won't use amber or bash or perl but just whatever you actually wanted..., but I assure you the underlying hypervisor has perl
Even bash or sh need not be installed in a container so that's a weird objection
gr4vityWall 108 days 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.
Suppafly 108 days ago [-]
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.
Retr0id 108 days ago [-]
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.
inferiorhuman 108 days ago [-]
Perl was taken out of the FreeBSD base system ages ago.
jahewson 108 days ago [-]
Why would I ever use perl5 instead of just using AWK?
/s
galdosdi 108 days ago [-]
Silly comment. Awk is nonstandardized, different in different environments. Perl5 is the same everywhere. don't you recall that that's actually the main reason perl was invented, as a more powerful and more uniformly compatible replacement for awk?
rascul 108 days ago [-]
> Awk is nonstandardized, different in different environments.
Awk has been standardized in posix since 1985.
RodgerTheGreat 108 days ago [-]
I've written some fairly complicated programs meant to run on a very wide range of Awks, and while there are minor differences between dialects, it isn't hard to stick to the POSIX-standard core language.
108 days ago [-]
jamesponddotco 108 days ago [-]
Slightly off-topic, but in many posts mentioning Bash, the overall consensus seems to be that when a script gets too big you should switch to using a more full-featured programming language instead. Which is fine, I get the reasoning.
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.
miggol 108 days ago [-]
I have no idea how I would tackle the problem with Go or Rust. But Python with pyinfra comes to mind as a sane enough solution. Since we decided to move from Puppet to pyinfra at work, I don't see myself writing any sysadmin scripts in bash again anytime soon.
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.
Pyinfra's documentation is definitely on my list of things to read.
praseodym 108 days ago [-]
You can use a tool like gorun (https://wiki.ubuntu.com/gorun) to run Go source code as if it were a shell script, by putting gorun in the shebang line.
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.
athorax 108 days ago [-]
I think bash scripts are perfectly fine for things like install scripts. The general advice isn't about the script getting too big, more so if its getting too complicated and you are already trying to use bash as a programming language.
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.
Karrot_Kream 108 days ago [-]
Go is definitely a decent solution but I'm surprised why you aren't using Python. Most Linux and BSD distros have access to a default install of Python. Even if the version is a bit old, if all you're doing is hydrating templated configuration and doing bookkeeping for eventually running a binary with some parameters, older versions of the standard library will do just fine.
jamesponddotco 108 days ago [-]
Not gonna lie, I have a certain prejudice against Python because of the whole packaging issue, something I definitely need to work on. I did ship Python code before, I just don't really like using it.
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.
maxloh 108 days ago [-]
I tried migrating my Linux setup script to Python, but the sudo thing is quite hard to solve.
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.
dragonwriter 108 days ago [-]
> 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).
You could have a separate python script you call via sudo.
Or you could automate the equivalent within python. Old discussion:
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.
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.
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:
EDIT2: TIL that parameter substitution is POSIX [0] Section 2.6.2[0]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...
Input sanitizing should be done before trying to hand inputs over to be summed.
> 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!
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.
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.
https://github.com/mvdan/sh
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.
Maybe still just the earliest of early days? Javascript-style RegExs along the lines of:
Would be pretty nice and handy.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:
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.
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.
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.
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.
people still get paid to care about things like solaris 9 and aix 6.
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/
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."
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.
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 would expect it uses bc instead of relying on bash's environment/version-dependent 32/64bit integers.
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 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).
https://amber-lang.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.
https://en.m.wikipedia.org/wiki/GemStone/S
Bagsy Coprolite.
[0] http://merd.sf.net
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.
For example, we had an EC2 machine whose init would fetch and run a shell script from S3, which spun up a big JVM application. We started getting strange errors from deep inside the JVM, which seemed to be caused by some security update somewhere in the stack (either ours or Amazon's); but that machine image had evolved via snapshots of snapshots, etc. and was a pain to figure out what it was running, let alone update and manage it in a sane way. As a quick fix I bundled a known-good JVM into an Arx file (along with other dependencies like Bash, etc. since it's Nix, so I might as well!) and put that on S3 in place of the old shell script. That got the EC2 machines working again, without having to mess with the (already messy) image; we gained a more sensible way of specifying dependencies (via Nix); and, since we were now building an artifact, rather than slinging a raw script, we could do stuff like running Shellcheck on the code. This definition was also easy to re-use when we eventually switched it to ECS containers (just changing the `nix bundle` options).
- nushell
- elvish (was featured on HN recently)
- powershell
- murex (disclaimer: I’m the author of that one)
Most of the value in sh to me is that it’s ubiquitous. I write a script and the runtime is already available across most devices, operating systems, containers, and everywhere else without an extra steps.
It's unfortunate Amber doesn't have a Map data type, pretty big limitation.
I can think of ways of doing it, e.g. something along the lines of:
* Set the constraint that all keys must be of type String
* Then abuse /dev/shm/.Amber/${pid}/${func}/${stackDepth}/<put keys and values in files somewhere under here>
Also for this to be really unique and good it needs insanity like being able to avoid all external dependencies, or else idempotently installing them in ways that can not affect anything else externally, or even temporarily, in multiple crazy various environments including nix? my mind never shuts up
You'll run into the Alternative Implementation Problem
https://pointersgonewild.com/2024/04/20/the-alternative-impl...
https://news.ycombinator.com/item?id=40337036 - 10 days ago, 84 comments
Relevant excerpt:
> You may read this and think that the key lesson of this post follows the old adage that “if you can’t beat them, join them”. In some ways, I suppose it does. What I want to say is that if you start a project to try and position yourself as an alternative but better implementation of something, you are likely to find yourself stuck in a spot where you’re always playing catch up and living in the shadow of the canonical implementation.
This concept doesn't exactly map 1:1, but gist seems correct. Who wants to program in a worse and very limited version of Python? Who's going to keep things up to date in e.g. Amber as Python continues to evolve? Not fun.
If you were to write Python code that did a of its business logic by spawning new processes rather than using its core libraries (which are written in C) then you’d find Python would be just as slow too.
But the exact point of Bash and other shells is to make launching new processes easy. This is the point that people miss when they say “write it in a real programming language”. Shells solve an entirely different problem to other languages. And “real” programming languages suck at working with other executables in a quick and convenient way.
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.
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.
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.
https://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.
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.
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.
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?
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.
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.
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.
Look: I appreciate that this is a shell script, and they often aren't "fast", but if I'm writing code in a script and have a comparison it at least might be in some tight loop and the performance different of spawning bc and sed into a subshell is frankly brutal.This feature, optional omission of delimiters in the special case of a single statement per branch, originated in early C and has since facilitated untold numbers of bugs, not least the spectacular Heartbleed bug (which has its own homepage, https://heartbleed.com).
e.g. https://github.com/amberframework/amber
https://amber-lang.net/
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).
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 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.
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.
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.
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.
The syntax is something like this:
Disclaimer: I work at Microsoft, but not on PowerShell.
But only if your target environment has python, and that's not a given, not a zero-cost change, in this age of short-lived containers. The use case for a "compile to bash" language would be compile in a dev-operated environment and commit both source and output, which would then run on later stages in the CI/CD pipeline that might very well not have python. And those stages will absolutely not have your "compile to bash" tool, which would ideally be included along with the source unless it's somehow as near-omnipresent as python. This one appears to be implemented in rust, I'd certainly feel more optimistic about depending on it as a script authoring tool if it was e.g. a python script that could be included with my "pre-bash" source, and/or packaged in, say, npm.
The same applies if one needs awk, sed, etc... The constructs are just there.
Also the fact that you can just pipe to bash, makes development much easier.
For all its faults, after a Bash script works once, it usually just keeps working.
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.
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.
https://nixos.asia/en/writeShellApplication
I have WebGL disabled in my main browser for privacy reasons (super-easy to fingerprint), and I only get to see 'Application error: a client-side exception has occurred (see the browser console for more information).' with an error about ThreeJS initialization in the console.
I assume it's for the fancy animation, and I find that ridiculous. Loading a whole 3D library just to show a fancy animation. This could have been done much simpler by using an animated image format, though admittedly with less functionality - but is it even needed?
I fear the whole industry suffers from overengineering and this is just a symptom.
Even if you're convinced you need the fancy animation, why not gracefully fallback to not showing it and still make the docs usable?
I know what you mean, but statistically, I don't think that it is easier to guess the person from those who have disabled it versus the list of all browser fingerprints where is that matching or very close unique fingerprint.
You’re always leaking some kind of information that advertisers will pay for. The game is choosing what information you’re okay giving them
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).
Personally, by default I shut down all the browser crap that might needlessly allocate RAM or allow memory leaks or slurp cycles without giving me some kind of value. I think this allows me to hold at least a few hundred extra tabs open. For technical documentation I expect text, hypertext and static images, if you're going to require JS and WebGL and whatnot I'm going to assume you aren't entirely honest with me about the information we're about to share and I'll probably sandbox a scrape of the documentation if I really need it.
I did not say that the corporate practice is a good one, I just brought it up as an example to refute the suggestion that limited web browsers are incredibly unusual.
That said, very interesting syntax. I agree with others about the $...$ being kind of odd, but other than that this is really cool.
I thought it was clear, functional, told me everything I needed to know in the order I needed to know it, and also looked nice - tying into the "amber" branding well.
Maybe I just don't spend enough time on websites that are designed to hook me in and start charging a fee? ;)
Maybe a tiny note about it being open source could help.
Granted, bash is now GPL 3 (which is why Apple has to ship an obsolete version, and now defaults to zsh), so you can't use Amber on machines where GPL 3 won't fly (unless it can also compile to posix shell, zsh, etc).
Anyway, if you're interested in freedom for your users, I'd suggest AGPL 3, since it prevents people from locking it up inside the cloud or shipping with proprietary operating systems. At least that way, you're not stripping users' right to privacy like GPL 3 (inadvertently?) does.
These days, Apache and BSD-style licenses are looking better than ever to me, at least when I'm at work.
[edit: You can sell machines with Coreboot (and maybe a proprietary BIOS) + bash. However, you can't ship things that use a secure boot mechanism.
From reading the FSF documentation, it's not clear to me if it's OK to ship a GPL 3 userland on a machine with secure boot enabled, even if it can be disabled later. Apple apparently decided that it is not.]
Gmail is free as in beer, but not free as in freedom, while RHEL is free as in freedom, but not free as in beer.
Gratis vs Libre - the former is zero cost (i.e., you're not paying for the free beer), the latter is some cost (i.e., there is a price for free speech - we need to defend the right, accept we won't like everything that is said, etc.)
I do understand what GPL does and the reasons for this just not this slogan.
Amber claims to be type safe so it should have enough information to avoid the the use of bc in this case.
Ah, just looked at the documentation. Amber doesn't have integer types just a number type. That means that any numerical operation in Amber is pretty much guaranteed to be very inefficient.
It's a very strange choice to make because the underlying 'machine code' supports both integers and floating point.
But then they chose this for their front page example, the one that everyone will see, so I assumed this was to demonstrate something clever I just didn’t understand.
I wonder what the motivation was to not have an integer type?
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)
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 if you're looking for "reason" I think that falls on not re-doing the same thing over and over again.
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.
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
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 I agree on the perl front.
/s
Awk has been standardized in posix since 1985.
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.
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.
1. https://janet.guide/scripting/
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.
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.
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.
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...
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.
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.