Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: Getada: rustup-like installer for Ada's toolchain/package manager (getada.dev)
194 points by ajdude 7 months ago | hide | past | favorite | 115 comments
One of my goals with Ada is to have a one-liner copy-paste terminal command for people to install Ada so they can get to coding in just a few minutes. After extensive testing I feel like it's ready for general release[1].

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.

[1] https://www.getada.dev

[2] https://rustup.rs/

[3] https://github.com/aj-ianozi/getada

[4] https://alire.ada.dev/

[5] https://www.getada.dev/how-to-use-alire.html

[6] https://programming.dev/comment/9438211




As a current Rustup maintainer with a bit of Ada background I gotta say: nice work!

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 :)


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

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.


I believe you'll find its actually utilada

alire doesn't let you use capital letters...


Alire is a frontend to the toolchain, including gprbuild, it just handles grabbing the projects as well.


Yes, but it kinda locks you into running 'alr build' and adds other things inside 'config' directory like user's distro and other things. My guess it's probably great when you already have a done project and want to publish it, but if you want to compile your code ASAP, it's much easier to avoid it completely (except for pulling packages)


Alire puts "/obj/", "/bin/", "/alire/", and "/config/" into its .gitignore when creating a new project so the platform-specific stuff shouldn't end up on other developer's machines. After your initial "alr init --bin myproj" you can dive into your "myproj.gpr" and do more than what alire supports in its toml file.


Turns out putting "config" in .gitignore isn't a very good idea. Or, at least, there's a problem with what setting go into "config". In particular, compiler options, end up ignored... I had to undo it in the project I'm working on because I got tired of having to restore these options every time I change something else in dependencies / other project configuration.


We use SVN in our university lab, so no, that didn't work when I tried it initially. obj and bin was obvious to ignore, but I wasn't so sure about config and alire, might be helpful though


which is fine if you're using git. Just like asking me for my github login would be fine, if I used github and expected to ever distribute sdl_helloworld.


literally

alr init --bin new_project

cd new_project

alr edit


What's the need to compiler code ASAP? I understand it that you mean the initial effort, as running whatever command you normally use to build will have just the same amount of effort regardless of its length... But, even if for some reason you are typing it out every time: the difference will amount to just a few characters...

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 is similar to virtualenv, yes? Every time you create a project, a fresh Ada toolchain will be downloaded.


The toolchain is cached, so it only gets downloaded once.


Really? Hmm let me check Alire again.


This is amazing. devX matter a lot for adoption. I keep hearing about Ada a lot but the learning experience were difficult when I tried it.


Did you come across? https://learn.adacore.com


> One of my goals with Ada is to have a one-liner copy-paste terminal command for people to install Ada so they can get to coding in just a few minutes. After extensive testing I feel like it's ready for general release[1].

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.


What's cool about rustup is having many different versions of the same toolchain installed at the same time, and automatically using the appropriate toolchain version for a project. That's downright magical.


Yeah, that's another major benefit; I can get different toolchain versions or even cross-compile to different architectures via "alr toolchain --select"


Distro package managers often lag by a bit, hence the explosion of language-level package managers in the last... when did NPM come out... 14 years


I got my start programming through an avionics apprenticeship. My first project was porting an Ada project to C. Still hurts my heart to think about now that I'm experienced enough to appreciate a lot more of the implications.


I'm a little confused - is this just a wrapper around https://alire.ada.dev/ ? That tool itself isn't very hard to install.


Getting alire installed involves downloading the zip, extracting the binary, and moving the binary to a directory in $PATH. If you're on a mac, you also have to run an "xattr" command on the tool to get it running.

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


> Getting alire installed involves downloading the zip, extracting the binary, and moving the binary to a directory in $PATH. If you're on a mac, you also have to run an "xattr" command on the tool to get it running.

Is that considered a high bar for software developers to get right?


In practice, yes.


We're doomed.


yeah, g-d forbid that any routine busywork gets automated by software, otherwise all those lines of code might actually have a point!


That is literally a bash oneliner - pipe curl into tar, and have it unpack to ~/.local/bin.


Shouldn't a good package manager just take care of those steps?


That is literally a bash oneliner - pipe curl into tar, and have it unpack to ~/.local/bin.


Alire is kind of a bummer on musl systems...

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.


> I don't know if this tool solves the problem

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


Bringing Ada into the 21st century bit by bit.


Yep, happy to see it, well deserved. Def a sleeper with tons of potential.

Comprehensive IntelliJ-level IDE tooling could bring Ada to the forefront where it belongs. Would be nice anyway.


Other ecosystems are still catching up in some ways


How is this not called "Byron"?


Is this supposed to be a reference to something? I'm not following this logic :(


Byron (the poet) was Ada Lovelace's father


Stop being smart. The tool is called GetAda, what does it do? It gets ada. What would byron do? will you remember 3 years from now?


What happens when the community decides this one isn’t good enough and comes up with a replacement? The problem I’ve always had with these descriptive names is (a) they are often hard to google because they conflict with all sorts of documentation about the problem space and (b) when they’re deprecated, they become a trap for beginners. “Cute” project names are better for the same reason as we don’t name children and pets random English phrases describing them.


The replacement can just be called getada2. It worked for Python's standard library (unittest2 and all that).


Or fetchAda or grabAda, english is filled with synonyms.


Imagine if this happened with stream processing systems: “here at Acme Corp we decided that Apache Stream Processing wasn’t nearing our needs so we switched to Apache Creek Processing after evaluating it and Microsoft’s River Processing solution”


Well then surely it should be "UpdAda"?

(I hardly...)


How about "AddUp"?


On a related note, here's a throwback for old-timers: https://adagide.martincarlisle.com/


one of my old professors. Blast from the past!


Does this make it possible to use Ada and SDL2 on Linux?


SDLAda has been around for a while: https://github.com/Lucretia/sdlada

You can add it as a dependency to your Alire project: `alr with sdlada`


Why can't you use sdl on ada? You can use raylib fine enough.

https://www.youtube.com/watch?v=MUISz2qA640


I've had issues with the combination of Ada + SDL2 + Linux in connection with https://github.com/xyproto/sdl2-examples.

Raylib is cool, though.


Look at the "Linking" section https://github.com/ada-game-framework/sdlada

I'm looking into getting it all automated through pragma's and gpr's.


This! Tooling ease of use matters!

A lot of interesting tech died off or never took off because the tooling was just too cumbersome to setup and use.


Honestly I think a lot of the Rust zealotry is because the tools are amazing.

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.


I would be slightly more cynical and suggest that the easy tooling enables people prone to cheap chest-thumping to get into the language, when otherwise those types would probably wander somewhere else. The difficulty of the borrow checker will already create investment-induced loyalty[0], but if the first difficulty isn't even unique to the project, then the interesting difficulty doesn't have a chance to work.

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?


> investment-induced loyalty

Would generally refer to this as a sunk cost dilemma


I thought about trying to use "sunk cost", but I usually see it written as "sunk cost fallacy" and that's a (closely related, but) slightly different thing.


I often use the phrase "[I/he/she/they/we] have already sunk so much time into ..." Not dissimilar to "sunk cost".


Eve more so in Go where the single standalone executable can:

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


Since I started programming, I see every generation of programming languages slowly raise the bar. From the top of my head, in the order I encountered them.

* 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.


gofmt is actually a separate command.


Indeed!

And it can be called from go command too: go fmt main.go

https://pkg.go.dev/cmd/go#hdr-Gofmt__reformat__package_sourc...


And yet, the number of times 3rd party Go code has died on my macOS machine due to a segfault...


I agree. Same with Go. When I started with Go, I quickly forgave it all little rough edges in the language itself because they were offset by a tooling that was just miles ahead the state if the art of the time.


They have improved go modules since but if you didn't use github gos tooling wasn't so great. I actually dropped Go for Ada and prefer Adas packaging.


The package management story before go.mod was sad but I have to plat devil's advocate and point out that GitHub did have special treatment by go get, you could use any domain name to host your code and you just had serve a <meta name="go-import"> tag in a html file and you could tell go where to fetch your code (several version control tools including Mercurial are supported)


I chest thump because more errors happen at compile time, and fewer at runtime. The tooling is what I would consider basic competency these days. Go has a similar tooling story and, while I do enjoy the language, it doesn't inspire chest thumping.


> I chest thump because more errors happen at compile time, and fewer at runtime.

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.


People get pretty riled up about the likes of Haskell, Elm, and OCaml. Rust brings some of the virtues of functional into procedural code/average developer hands, and out of "monads are just a monoid in the category of endofunctors."

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.


> Rust brings some of the virtues of functional into procedural code/average developer hands

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.


I'm not afraid of functional programming. I just dislike it. I avoid recursion in Ada personally (others like it). I think OOP is over rated and the clarity of imperative is under rated. Though I do like how Ada provides object oriented design to imperative programs even without touching Adas OOP features (tagged types).


Why are people afraid of functional languages?


This sums it up pretty well (I disagree that "functional sucks"). https://youtu.be/nuML9SmdbJ4?si=DEBaHcAvvxO_Ez93 There is a lot of jargon, and that presents an extremely high hurdle for newcomers (especially for those without formal mathematical education). Bizarrely, C++ has a worse version of the same problem: the "modernization specs" are tribal jargon heavy.

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).


Great video! Are you saying that if functional programmers explained FP like the video (i.e. focusing on the benefits of simpler code) then fewer people would be scared of it?


Exactly.


People meaning him, which is why he won't "chest thump" anything related to functional programming. After all, chest thumping is a display of dominance. The others witnessing the chest thumping are meant to be scared. You wouldn't hold back because they are scared.

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.


I'm a hater of rust because of cargo and cargo - while it makes getting started easier, it is one of several opinions rust forces on me that are not compatible with my current code and so it make it more difficult to figure out how to incrementally start using rust in my code base. For small greenfields projects it is nice, but I'm not in that world and rust is fighting me.


That's fair, opinions are annoying when they don't align with your own (for me for example; I really hate that go-imports are URLs and the monorepo story for them is really bad... which I find ironic).

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.


Part of it is, but the language is also great. It isn't Zealotry. Rust really is that great. Not flawless (async is a big wart), but still fantastic.

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.


Ah yes, when using your package manager is too cumbersome...


I don't know if it's the algorithm but for the past few months i've been seeing bits and pieces in random places about ada. Is there a reason the language is seeing more traction lately? I would assume the whole White House "approved" languages had something to do with it


Ada's been steadily making a reassurance I think since safer languages like Rust had started to gain traction. It appeared for the first time ever on the stackoverflow survey for example.

It 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.


I tried learning Ada a few years ago and was really put off by GNAT. Installation was something straight out of the 80's and I just forgot about it after a little fussing around without getting anything working.

Great to know that's no longer the experience with Ada, I might finally get it and try to start a project using it.


> Ada's been steadily making a reassurance I think since safer languages like Rust had started to gain traction

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?


Ada has features built in that those languages do not have.

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.


It sounds like this can be implemented as some 3p libs, and not necessary be a part of language?


I like in Ada's type system in that I can do constraints such as "type Positive is Integer range 1 .. Integer'Last;" to give me a number that I know must always be in the positive range of an integer, and it's easily readable in plain text.

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

     struct BoundedU16<const MIN: u16, const MAX: u16>(u16);
     impl<const MIN: u16, const MAX: u16> BoundedU16<MIN, MAX> {
         pub const fn new(value: u16) -> Result<Self, BoundError> {
             if value >= MIN && value <= MAX {
                 Ok(Self(value))
             } else {
                 Err(BoundError(value, MIN, MAX))
             }
         }
     }


Now how about using this type as an array index? In Ada, when you declare an array with this kind of type as an index, it automatically knows its size, generates a bunch of methods to help with iteration and element access, and these methods are "generic" in a sense that the programmer doesn't need to know the lowest or highest index of an array in order to iterate over it.

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.


Rust tries with a crate and traits but it misses out on e.g. record memory overlays which are so powerful in Ada. Type design is beautifully intuitive for the main part in Ada too. Restricting your parameters with ease means there is less logic to write and mistakes and refactor fallout gets caught early.


Honestly Ada is far better than Rust for close to metal as it was designed for it. It is also safer and easier to use than Rust. Ada has also been demonstrated to be more cost effective over a programs lifetime than C, C++ and Java. I also dropped Go for Ada and prefer the quality and memory control that Ada offers. The only thing I miss are the stdlib docs and the ease of cross compilation.


> Ada is far better than Rust for close to metal as it was designed for it.

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.


Adas specification was developed competitively over a number of years with embedded development as well as the ability to replace all 450 languages in use by the D.O.D. at the time as requirements. Rusts first official specification is still in the works aside from the one created by AdaCore.

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.


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

Define stronger? C#, Go, Java probably by wide use in enterprise/industry, but Rust? Power of sunshine and rainbows? Wishful thinking?


> but Rust? Power of sunshine and rainbows? Wishful thinking?

adaptation, active community, more modern features, larger ecosystem


Oof! You were going so well .


My guess? There have been a few high profile security CVEs lately and the "why are we still using C" crowd is louder than usual. Ada's a viable alternative for performant system code, and it's kind of the underdog to Rust.


Ada is not memory safe language tho, while it might make it a bit harder to introduce those bugs.


Ada is memory safe if you just work with the stack or avoid Unchecked_Deallocation. Since functions can allocate and return entire arrays and other data structures completely on the stack, you don't need to mess with the heap that often (and when you do, you can also define your own memory pools).

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).


Is there a free version of SPARK? Proven correct code appeals to me, but I don't enjoy trying to get anything past purchasing.


SPARK is free by default, and readily available. You can use it as-is in ada by adding " with SPARK_Mode => On" to your code; here's some examples: https://learn.adacore.com/courses/intro-to-spark/chapters/01...

You can install gnatprove with alire via "alr install gnatprove"


It's been a while since I looked at SPARK and Ada, but the last time I did, SPARK was very well integrated with the GNAT Studio IDE.

I still preferred frama-c, because C, but it's a really nice toolchain.


Ada goes beyond memory safety.


I saw a fairly popular programming Twitch streamer / Youtuber put out a bunch of Ada content recently, don't know if it's cause or effect but content creators seem to have a bit of influence these days. Was definitely the case with the recent htmx wave.


[flagged]


Whats the viable alternative?


    sudo apt install gnat
:-)


bash: sudo: command not found

:)


Thank goodness, someone with a decent distro


If you

   curl > install.sh
   sh install.sh
then you have a copy of what you just executed


Because downloading an installer from the same website you curl from is so much safer, right? /s


Yes, it is. Because the server can detect curl | sh, serve different content and you will never know about it. Discussed numerous times on this site.

https://web.archive.org/web/20230304061743/https://www.idont...


When you download an installer, unless you reverse engineer it you also have no idea what it's doing.

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.


Under what threat model would that matter?


Yeah, but your trust is always on the domain owner anyway.


Just use Nix


Or Guix




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: