top 5 comments

sorted by: hot top controversial new old
[–] 16 points 11 months ago

For those curious like myself


What is Amber?

Amber is a programming language compiled into Bash Script. It was designed with a modern syntax, safety features, type safety and practical functionalities that Bash could not offer.

  • source
  • [–] 5 points 11 months ago

    Homepage:

    A language compiled to Bash.

    Also:

    A modern, type-safe programming language that catches bugs and errors at compile time.

  • source
  • [–] 2 points 11 months ago

    I'm glad this is still alive. It's a good idea. I keep thinking about doing the same for TCL.

    I do wonder if Bash is perhaps just a bit too insane to make this really feasible though.

    Reversed range support

    This is a misfeature.

  • source
  • [–] 1 point 11 months ago (1 child)

    It's bash, bash is easy now if you want to impress me make it compile into power shell.

  • source
  • hideshow 1 child comment
  • load more comments (1 reply)
    [–] 1 point 11 months ago

    I get that calling command line tools is a bit clunky, but python is always my go-to when shell scripting gets too painful

  • source
  • 38 comments in c/linux@programming.dev view that post
    [–] 21 points 11 months ago (9 children)

    This is an interesting idea and from the looks of it well executed, but I am having trouble imagining a scenario were I would prefer to use Amber over a scripting language like Python. If your bash scripts are getting long enough to warrant the use of Amber you are probably already in a situation where you can justify installing Python.

  • source
  • hideshow 9 child comments
  • [–] 6 points 11 months ago (1 child)

    I agree, but I can envision scenarios where you are integrating into someone else's workflow/machine and they (or their build system etc.) are expecting a shell script. Python is ubiquitous but sometimes you just want to work like everything else.

  • source
  • parent
  • hideshow 1 child comment
  • [+] 3 points 11 months ago (4 children)
  • [–] 2 points 11 months ago (3 children)

    Been there, done that lol. Nowadays, if I think that some script is getting too long, I just rewrite it in Go. It's faster to write than Rust (in fact, I find it almost as easy as Python), and performant enough for replacing scripts.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 2 points 11 months ago (2 children)

    @SinTan1729 @sga I've been toying with the idea of learning Go. I currently tinker in python and bash scripts. Is Go worth my time learning?

  • source
  • parent
  • hideshow 2 child comments
  • [–] 2 points 11 months ago* (last edited 11 months ago) (1 child)

    Oh, definitely. Its syntax is so simple, you can basically learn the basics over an afternoon. Outside of applications where consistent low latency is critical, if I can spare some extra RAM and CPU, I prefer Go to Rust.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 2 points 11 months ago

    One reason is that Python is not built-in on macOS anymore, so it's hard to justify using it for management scripts. Particularly when you do not have control of the execution environment to begin with. I've written some obnoxiously complicated bash (or zsh) scripts because I want to make sure it will run on a vanilla Mac with no additional dependencies. 10 years ago I would've done all that stuff in Python, but not anymore. Thanks, Apple!

    From a technical perspective, sure, I could push out a portable python environment and it wouldn't affect the rest of the system. But that comes at a cost. I don't want to fight for it, and I don't want to be responsible for maintaining it. It's easier to just use bash/zsh.

    Python is also too heavy for some embedded devices. Not sure if I can count on Amber scripts to run in a busybox environment but maybe?

    That said, if the question is "is it worth learning a whole new thing when I already know bash/zsh", I am not so sure. But in principle, I dig it, regardless of how practical it is with my specific background and needs. I mean, if I learned about this 20 years ago I feel like I might still be reaping rewards.

  • source
  • parent
  • load more comments (-1 replies)
    [–] 19 points 11 months ago (4 children)

    I didnt realize it could go to different bash versions.

    That could actually be really handy for me, write once and out for the versions I need...

  • source
  • hideshow 4 child comments
  • [–] 7 points 11 months ago (3 children)

    When do you need a newer or older version of Bash to target? I mean usually this is not a thing to concern about.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 11 points 11 months ago* (2 children)

    Client systems outside of my control.

    It is not usually a thing to be concerned about. It is something I end up having to be concerned about though.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 6 points 11 months ago (2 children)

    Interesting. There is this example in the docs:

    let result = $ cat file.txt | grep "READY" $ failed {
        echo "Failed to read the file"
    }
    

    https://docs.amber-lang.com/basic_syntax/commands

    How can we know for sure what failed here? Was it the cat or the grep? My instinct says the pipe returns the code of the last cmd or failure, which could be either.

    Perhaps it's just a contrived example and it would be better to separate testing file existence from grepping in real code...

  • source
  • hideshow 2 child comments
  • [–] [S] 3 points 11 months ago (1 child)

    Yep, the code you provided is compiled into this:

    command_0="$(cat file.txt | grep "READY")"
    __status=$?
    if [ "${__status}" != 0 ]; then
        echo "Failed to read the file"
    fi
    

    So, the outcome would depend on the pipefail option. (set -o pipefail)

    As you suggested, an Amberic snippet would be:

    import { file_read } from "std/fs"
    import { match_regex } from "std/text"
    
    const result = file_read("file.txt") failed {
        echo "Failed to read the file"
    }
    if match_regex(result, "READY"):
        echo "file.txt contains READY"
    
  • source
  • parent
  • hideshow 1 child comment
  • [–] 5 points 11 months ago (3 children)

    I'm reminded of the horrid example showcased on the amber-lang website previously.

  • source
  • hideshow 3 child comments
  • [–] 1 point 11 months ago (1 child)

    They know you can just do if ((age < 18)) in bash, right?

    Or rather if ((10#$age < 18)) because age=021 would not be adult 😉 Hopefully, they protect against that at least.

    (I had to double-check this stupid default is still a thing, since I moved to zsh many years ago.)

  • source
  • parent
  • hideshow 1 child comment
  • [+] 4 points 11 months ago (5 children)
  • [–] [S] 3 points 11 months ago* (last edited 11 months ago)

    Currently, Amber does not even support Bash 2 because Bash 2 does not support the += operator. (ticket) However, I believe that POSIX compliance is on Amber's long-term milestone, and that it will eventually achieve this as its support range expands.

  • source
  • parent
  • [–] 2 points 11 months ago (2 children)

    As someone who knows nothing about POSIX, what's the difference or in your opinion what would make it specifically better with the context of amber?

  • source
  • parent
  • hideshow 2 child comments
  • [–] 3 points 11 months ago

    I've been writing POSIX scripts as a sort of hobby and don't really have any Bash experience but I think I can still give some insight. Hopefully what I say is accurate but this is what I've learned so far.

    POSIX is a standard, to say it as simple as possible, it sets the minimum requirements for environment, programs, commands and options for those commands with the purpose of having those commands be as portable as possible. That way a POSIX script will work on any POSIX compliant system. For example a POSIX script could work on Arch, Debian, on a Raspberry Pi or even Mac products. In theory if could work on windows too. If an Operating System ships with a POSIX compliant shell, you are very likely able to run a POSIX script.

    Bash is a shell but it has a bunch of features that expand beyond the basic features set by the POSIX standard. Bash also has more features and flexibility for scripting which is why it's so common to see Bash scripts. Those scripting features are usually referred to as "bashisms." Since it expands on POSIX scripting, it can look similar to a POSIX script but would not work as intended if you ran a Bash script outside of a Bash shell.

    With a lot of modern OS's, they would likely have Bash installed and you most likely don't need to worry about anything. However, Bash is not a standard and not required to be installed on every system.

    If you care about your script working on as many systems as possible without the worry about what shell is being used, you will probably prefer writing a sh shell, POSIX compliant script.

    Since POSIX shells and scripts work on a much more basic level, it can lack some depth and finding work arounds for issues can start to look unreadable/insane. A good example is how arrays are handled. POSIX is limited to one array where Bash has much better support for arrays.

    There are advantages to using either but with the popularity of Bash, it's not really that big of a deal in the end.

  • source
  • parent
  • load more comments (1 reply)
  • load more comments (1 reply)
    [–] 3 points 11 months ago (1 child)

    My most recent Bash mistake was misusing test -n and test -z. In Amber, I can just use something == "" or len(something) == 0

    test -n can be [ "$something" ] and test -z can be [ "$something" = "" ]

    And this applies to posix shell, not just bash.

  • source
  • hideshow 1 child comment
  • [+] 3 points 11 months ago (2 children)
  • [–] 2 points 11 months ago

    I've never heard of this before but I'll make sure to check it out. 

  • source
  • [–] 2 points 11 months ago (2 children)

    I just installed fish shell a few years ago. Best scripting language I've come across. No need to remember all this weird bash syntax you have to look up every time you want to use it. All of fish shell fits in your working memory, seriously. It's tiny.

  • source
  • hideshow 2 child comments
  • [–] [S] 1 point 11 months ago* (last edited 11 months ago) (1 child)

    Fish is my main shell of choice and I use my self-written functions(https://github.com/lens0021/Lens0021_Personal.Fish/blob/main/conf.d/lens0021_personal.fish) daily. But it is hard for me to say Fish's syntax is not weird. Especially, I'm a little fuzzy on how to use argparse. I am sorry.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 2 points 11 months ago

    In which way is it weird? It's different, but how is it weird?

    No need to apologize, you're allowed your opinions and feelings.

    I would suggest reading the manual page for argparse thoroughly from top to bottom of you haven't already. I struggled with argparse at first too, but it's because I skimmed the manual instead of reading it.

    I would also read through all of the manual, and you'll find useful idiomatic fish things like not setting PATH directly, but using fish_add_path, among other things. 👍

  • source
  • parent
  • [–] 1 point 11 months ago

    Nice. I find the bash syntax so clunky...

  • source