5 ms·

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 i

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.

fluidcruft 2y 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...
- lytedev 2y ago
  I'm guessing because Bash is "more everywhere" than Python.
  - KerrAvon 2y ago
    As slow as Python is, though, Bash is more slow. Much more slow.
    - hnlmorg 2y 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.
- beefnugs 2y 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 2y 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 https://pointersgonewild.com/2024/04/20/the-alternative-implementation-problem/ https://pointersgonewild.com/2024/04/20/the-alternative-impl... https://news.ycombinator.com/item?id=40337036 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.
- zem 2y 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 2y ago
    That's an argument for POSIX sh, not bash.
    - zem 2y 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.
hnlmorg 2y 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 2y ago
  Yeah. Sh needs to be abandoned. There's a million better alternatives, including those without such an asinine syntax.
  - nucleardog 2y 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 2y ago
      Because a shell is also REPL for interacting with command line utilities. It solves a different problem to “real programming languages”.
pubg 2y 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>
chriswarbo 2y 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).
RodgerTheGreat 2y 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 https://beyondloom.com/blog/lila.html

fluidcruft 2y 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...

lytedev 2y ago
I'm guessing because Bash is "more everywhere" than Python.
- KerrAvon 2y ago
  As slow as Python is, though, Bash is more slow. Much more slow.
  - hnlmorg 2y 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.
beefnugs 2y 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 2y 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 https://pointersgonewild.com/2024/04/20/the-alternative-implementation-problem/ https://pointersgonewild.com/2024/04/20/the-alternative-impl... https://news.ycombinator.com/item?id=40337036 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.
zem 2y 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 2y ago
  That's an argument for POSIX sh, not bash.
  - zem 2y 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.

hnlmorg 2y 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 2y ago
Yeah. Sh needs to be abandoned. There's a million better alternatives, including those without such an asinine syntax.
- nucleardog 2y 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 2y ago
    Because a shell is also REPL for interacting with command line utilities. It solves a different problem to “real programming languages”.

pubg 2y 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>

chriswarbo 2y 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).

RodgerTheGreat 2y 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 https://beyondloom.com/blog/lila.html