Show HN: Getada: rustup-like installer for Ada's toolchain/package manager (getada.dev)
Getada was inspired by Rustup[2] and aside from the init script is written entirely in Ada.
It's completely open source and you can check out the readme and code on github[3]. It currently supports all non-windows platforms that Alire has an official release for, which at present is Linux (glibc) and MacOS. If you try running it on an unsupported platform, it tries to point you in the right direction. For example, you can install Alire on windows with an already-existing installer.
It downloads the latest version of Alire[4] (Ada's toolchain and package manager, similar to Cargo) for your platform as a zip file to a temporary directory and then extracts it to a binary directory. By default the temporary directory (configure with "-t /directory" or "--tmp=/directory") defaulted to $TMPDIR or /tmp. The config directory is ~/.getada (change via "-c /directory", "--cfg=/directory", or $GETADA_CFG), and the alr and getada binaries go in ~/.getada/bin (configure with ""-b /directory", "--bin=/directory", or $GETADA_BIN). It also tries to add the file to your path by dropping a "env.sh" file into ~/.profile/ (disable with -p or --no-path).
If you don't allow executables in temporary or home directories, you can change all of these via environmental variables or passing parameters.
You can remove it all by running: getada --uninstall
Now you can create a brand new Ada project with: alr init --bin my_project (How to use Alire[5] for more details)
Since one of the biggest complaints about Ada is getting the toolchain [6], I hope this can solve a lot of problems for newcomers to the language.
[3] https://github.com/aj-ianozi/getada
121 comments
[ 2.5 ms ] story [ 201 ms ] threadIt used to be hampered down by confusing licenses but around 2021 those constraints were lifted when Adacore's "GNAT Community Edition" was retired. This was around the time Alire (works similar to if you combined Rustup with Cargo) came on the scene which meant getting the FSF version of the compiler was as trivial as running "alr toolchain --select".
The most recent standard came out in 2022 along with a more centered community. Most of the ada community was living in a newsgroup (comp.lang.ada) until a year ago, and now ada-lang.io is gaining a lot of traction.
Then Alire 2.0 just recently came out which made everything even more streamlined.
Ada has been my favorite language for years, so I'm happy to see more people noticing it.
Great to know that's no longer the experience with Ada, I might finally get it and try to start a project using it.
Why one would use Ada now when it looks like there are much stronger contenders in this space: rust for close to metal and C#, Java, Go for slower programs?
Off the top of my head, Ada has "restricted types" (e.g: you can say a function takes an integer of the range 5-15 only), as well as pre-and-post conditions you can annotate your procedure definition with.
From what I have read, trying to do something like "type Element is Integer range 100 .. 1000;" in rust requires something along the lines of
On the other hand: these types make life hard. Kind of like Rust's lifetimes. Sometimes obviously correct code doesn't compile and you need to twist and tie yourself into knots in order to get a much more convoluted version to compile. Well, like Rust.
They are indeed very similar, and require approximately the same level of pain tolerance.
Sorry, can you elaborate on this? Rust was also designed to be close to the metal, so I'm assuming that there's some concrete difference that you're referring to.
> Ada has also been demonstrated to be more cost effective over a programs lifetime than C, C++ and Java.
Do you have a citation for this improved cost-effectiveness? Things like that are notoriously difficult to prove, so I'd be curious to know how this was measured.
Representation clauses are just beautiful for embedded memory-mapped registers and network protocols and driver registers received over spi/i2c etc.. There is even built-in validity checking. No need to shift generally as the compiler does everything for you.
https://learn.adacore.com/courses/Ada_For_The_Embedded_C_Dev...
The D.O.D study that includes Java would need to be dug up but this one is interesting too.
https://forum.ada-lang.io/t/comparing-the-development-costs-...
I only found out recently that the D.O.D. Ada mandate didn't say you had to use Ada. It said you had to demonstrate why your project would be more cost-effective than using Ada. Considering Ada was designed with cost-effectiveness/maintainability as a primary requirement then that was a difficult task.
Define stronger? C#, Go, Java probably by wide use in enterprise/industry, but Rust? Power of sunshine and rainbows? Wishful thinking?
adaptation, active community, more modern features, larger ecosystem
If you have to use dynamic allocation, you could also use the built in container libraries or controlled types for additional safety.
Though if you want the kind of memory safety that Rust has, there's always SPARK (a subset of Ada).
You can install gnatprove with alire via "alr install gnatprove"
I still preferred frama-c, because C, but it's a really nice toolchain.
https://web.archive.org/web/20230304061743/https://www.idont...
As others said, you must trust the domain you're downloading from in both cases.
I really don't understand why people still argue about it. When you study security threat models, you should immediately understand that there's no difference from a security point of view. Perhaps the only alternative that's more secure is when you install the package from a package manager or app store... as in that case you have some sort of guarantee that the binaries are "vetoed" by someone who knows what they're doing it, hopefully.. i.e. you transfer your trust to the package manager's owners/maintainers... but you still need to trust the package publisher is not bent on trying to get you, because if they are, they will still find ways around package managers.
:)
I've seen the last parts get newcomers tripped up so Getada takes the rustup approach.
It uses github's api to retrieve the latest published release of alire[1] and then downloads and extracts it to a specified directory in $HOME. Then it creates an env file[2] and sources that file in .profile and/or .zshenv. It also logs everything that it does so it can undo it later with getada --uninstall
[1] https://github.com/alire-project/alire/releases
[2] Here's roughly what the env file looks like that it creates https://github.com/AJ-Ianozi/getada/blob/main/src/shells.adb...
Is that considered a high bar for software developers to get right?
I don't know if this tool solves the problem, but on musl systems (eg. Apline) you have to build Alire from source... i.e. bootstrapping, dependencies... it's not pretty.
Not yet but it's on my list as a "phase 2" of sorts for getada. I have an alpine VPS that I'm playing around with but the main issue is that while alire can be built for alpine, any compilers it pulls from its toolchain won't work with it since none of them are built against musl. We've been talking about it here https://github.com/alire-project/alire/issues/792#issuecomme...
(I hardly...)
You can add it as a dependency to your Alire project: `alr with sdlada`
https://www.youtube.com/watch?v=MUISz2qA640
Raylib is cool, though.
I'm looking into getting it all automated through pragma's and gpr's.
Comprehensive IntelliJ-level IDE tooling could bring Ada to the forefront where it belongs. Would be nice anyway.
It might be just me, but Alire isn't great, I tried it multiple times, it's great for getting complicated dependencies e.g Utilada, but I go for GPRBuild as it just avoids all the fuss when programming across Linux/macOS.
I might try a hard switch at one point as I didn't use Alire 2.0.0 that much, so maybe it's better now.
alr init --bin new_project
cd new_project
alr edit
I mean, how long of a delay are we talking about?
----
As an aside, for me, a newcomer, GPRBuild is hard to deal with. I've dealt with at least a dozen of build systems, and GPRBuild isn't something I'm excited about. It belongs in the same category as Maven / Gradle / MSBuild / Bazel etc.: very bad at debugging, very limited documentation, impossible to tell what things are possible...
The way for me to deal with GPRBuild is to create a project file using Alire, and when something breaks -- use Web search to find what needs to be changed. GNAT's errors are in general very, very bad, but when it comes to GPRBuild, it's almost like MS: the only use for the error message is that it's hopefully unique enough that there's a KB article somewhere that references it by id.
alire doesn't let you use capital letters...
A lot of interesting tech died off or never took off because the tooling was just too cumbersome to setup and use.
If it was just rustc on it's own I doubt it would have people chest-thumping like they do.
I say this, as a lover of Rust: precisely because of Cargo, rustup and the crate system.
- run code
- build code
- format code
- generate code
- profile code including flame graphs
- run tests and report performance down to allocations
- benchmark code
- manage packages
- manage workspaces
- scan and vet suspicious code
It's amazing how much a 2 character command can do.
And it can be called from go command too: go fmt main.go
https://pkg.go.dev/cmd/go#hdr-Gofmt__reformat__package_sourc...
* C: make gave a standard way to compile/link a program. * Perl: CPAN as standard library/repository location. * Java: javadoc gave a standard format for low level documentation. Rules like 1 file=1 class, 1 folder=1 package gave a standard source tree layout. * Java/maven gave standard way to download, install and upgrade dependencys * Go: Built in formatter. * rust: cargo combines the strengths of Go standardization and Java/maven repositorys
Every iteration provides extras that the previous tooling generation sees as trivial. They'll say you can add them to the mix yourself if you want to. Their company likes things in a different way, and are happy to have the option.
But that's missing the point. The whole language ecosystems standardizes on a reasonable (but not 100% perfect) way of working. This has a lot of secondary benefits: * People move easily between organisations with minimal up-to-speed costs. * Somewhere in the ecosystem, someone still has your ancient tooling version, and the upgrade path is clear(er). * No discussion about in-house standards. (Try to get 2 C programmers agree on a coding style and watch the hours fly discussing what to take from ugly K&R vs ugly GNU.) * Real pain-points get solved, because someone feels your pain.
I've seen the in-house stack developed by a Cobol company. It's finely tuned to that 1 company, yielding huge benefits. It's also a very non-trivial investment and maintenance cost.
Speaking, myself, as someone who likes Rust but wishes people would be more clear-eyed and less obnoxious about it.
[0] Someone remind me what the standard term for this is? You know, the thing where people get really emotionally invested in things where they've invested a lot of time and effort, like Vi or Emacs or Dark Souls?
Would generally refer to this as a sunk cost dilemma
If you like rust, but hate Cargo, I'd suggest looking at building with Bazel :D
Bazel is a build system, but I don't use it as much as I'd like precisely because I'd have to manually write out all the DAG stuff.
Why Rust, then? It is not particularly good on this front. Hardly the worst, but is still pretty Mickey Mouse compared to the languages that excel here.
I expect the zealotry/chest thumping is entirely a product of fashion. There are some things about Rust that are truly great, but nobody would go out of their way to mention it if it wasn't what is in style.
At the end of day, people are afraid of functional languages. It doesn't matter how amazing they are if almost everyone is too scared to use them.
But so does, say, ATS and does a better job on the aforementioned merits. But, indeed, it is not in fashion.
> At the end of day, people are afraid of functional languages.
To be fair, they are also afraid of Rust.
Which is to say that he is not actually afraid, it's just a roundabout way to say that the only reason he is on the Rust trumpeting bandwagon is because it what is in fashion.
Compare that with the likes of JS, people learn that in a few weeks bootcamp.
Rust absolutely has hurdles, but you can be largely successful without ever touching them (you can get a surprising amount done without ever worrying about lifetimes).
I would say that applies much more for Go, where the language is decidedly meh, but the tooling is fantastic. Arguably even better than Rust.
I never had trouble with this? Apt-get install gnat or similar has always worked for me. I only played around with Ada though, never did anything serious with it. Installing from source wasn't too bad either. But, trying to install spark from source was a big mess back in the day. I don't know about now.
I do feel Ada as a language is way ahead of its time, but when I was learning it (a while before the first Alire release) I was also puzzled by dev environment setup. I guess the Rust experience has shown the importance of a friendly onboarding experience, so I’m very glad to see Ada is going this direction as well with Alire and now Getada :)