Live data from Hacker News

Amber: Programming language compiled to Bash

amber-lang.com

261–270 of 330 posts

Re: Amber: Programming language compiled to Bash

#261

Earlier quoted context omitted.

> 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…

> 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 descendant…

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.

Re: Amber: Programming language compiled to Bash

#262

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 "re…

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.

Re: Amber: Programming language compiled to Bash

#263

Earlier quoted context omitted.

Also a note about it being Free as in Beer.

No as I really don't understand that - beer costs money.

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.

Re: Amber: Programming language compiled to Bash

#264

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?

maybe you want to run scripts on machines where you can't install everything you want (alternative shells)

Re: Amber: Programming language compiled to Bash

#265

Earlier quoted context omitted.

> 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…

The reason why it is attractive is to enable people who aren't ever going to get proficient at writing/debugging bash/sh to the level that you're at, to write enough bash/sh to get their jobs done both quickly and safely. The majority of people doing DevOpsey kind of stuff aren't remotely experts with what they're working on, and won't ever be experts, but work still needs to get done.

Maybe if those people started visibly failing at their jobs, they'd either upskill or be forced out, and then the magical hand of the market would raise salaries for the rest of us.

Re: Amber: Programming language compiled to Bash

#266

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 "re…

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.

1. https://janet.guide/scripting/

Re: Amber: Programming language compiled to Bash

#267

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 "re…

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.

Re: Amber: Programming language compiled to Bash

#268

Earlier quoted context omitted.

The reason why it is attractive is to enable people who aren't ever going to get proficient at writing/debugging bash/sh to the level that you're at, to write enough bash/sh to get their jobs done both quickly and safely. The majority of people doing DevOpsey kind of stuff aren't remotely experts with what they're working on, and won't ever be experts, but work still needs to get done.

Maybe if those people started visibly failing at their jobs, they'd either upskill or be forced out, and then the magical hand of the market would raise salaries for the rest of us.

Oh look you're basically me in 2006 thinking that all the sysadmins that couldn't be bothered to learn a real programming language needed to be replaced by people in India who weren't intellectually lazy (because I was a bit of an asshole and wrong).

Re: Amber: Programming language compiled to Bash

#269

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, li…

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)

Re: Amber: Programming language compiled to Bash

#270

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

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.

Post reply on HN