What amber is

[b1ek]

we should figure out what amber is, and/or wants to be.

there have been already a few problems because there isn't a clear definition of exactly what goals does amber has, mainly about runtime dependencies.

so, there are a few questions that need answering so that we could actually know what it is that we are building:

1. are we doing strict or loose typing?
2. should a user be able to run it everywhere or we save up the generated code size and development time (don't implement everything in bash/amber)?
3. which bash version do we target?
4. should the compiler be used directly by the user or via a manager like cargo or clang?
   1. if it should be used by a manager like cargo, that would mean we would be adding a lot of CLI arguments and then some higher level program will wrap it nicely in a config file or something

i have probably missed a few more important questions, so either edit the post to add them or comment them down

[b1ek]

i feel like we shouldn't optimize for portability. it will obviously be nice to have, but not with bash's limitations. as well as we just don't have enough brain power to work around every possible aspect in bash.

we are going to need to either build our own runtime binary library thingy or depend on a hell lot of shit (like jq and bc)

[arapower]

I had the same issue as @b1ek .

If I were to add a question, it would be the following:

• Should we consider compatibility with sh instead of just bash?

Personally, I think it's better to reduce the dependency on external commands as much as possible and simplify Amber. I think it would be better to enrich the ecosystem for writing scripts with Amber.

In addition to that, we could prepare a separate Amber extension library. For example, by specifying a Git repository with import, it can be incorporated into the generated shell script. The dependency on each extension library can be determined by the user individually. If we make such an assumption, I think it would be possible to maintain compatibility with sh.

[Mte90]

• I think that should be strict in this way is more portable and more safer, I think that as first goal can be generate a Bash code that is fine for shellcheck
• It should be able to run it everywhere based on the builtin stuff and std, so if we do a download function we should have some fallbacks for the various commands
  • This means maybe check if on OSX commands are different (I know that sed has some different parameters)
  • At same time just for the stuff that is shipped natively, for other everyone will do compatibility layers
• The most used? Or the latest? I think that as the first goal is enough to be compatible with Bash and maybe when the project is more solid add the others like sh.

[Ph0enixKM]

@b1ek @arapower @Mte90

1. Amber was build with progressive typing in mind. The user is in control of how much typed they want to write a script. Small scripts could be too small to force developers to use types everywhere. Big scripts could benefit from the fact that you can type everything.
2. I think it should run on many even small environments where Bash is typically used too. We could actually build that Amber runtime in Go to easily cross compile it and ship it for other people. I think that runtime should be a part of Amber project and should be versioned like the compiler or else we could end up having a total mess of incompatibility when old Amber 0.5.2-alpha script tries to fetch the newest stable runtime from the github releases and fails, because a lot has changed.
3. I think that max 3.0 so that we can support macOS as well. In the (near) future we could just support sh and only rely on the runtime... which would be really cool and more future proof. For a stable release I think that we should go this route.
4. I feel like for now the amber should be treated like the full package. I think that we have to iterate a bit to see whether we need to pivot and build something external i.e. "the manager"

To be honest I don't see Amber to work at all with a ton of dependency commands. We need to build a one runtime that can work with Amber. The only problem will be to handle permissions and where to store the runtimes. Perhaps we will build the runtime installer into an Amber script that will ask the questions if the person wants to download the Amber runtime installer and where shall it be stored.

[Ph0enixKM]

We'd also have to answer this question:

[Ph0enixKM]

This should be a discussion instead of an issue. Converting.