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.
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.
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.
> 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"
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.
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
> 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?
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...
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.
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”
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?
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.
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.
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.
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.
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).
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?
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.
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.
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.
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?
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 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).
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.
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.
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 :)
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.
alire doesn't let you use capital letters...
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.
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'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...
Comprehensive IntelliJ-level IDE tooling could bring Ada to the forefront where it belongs. Would be nice anyway.
(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.
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.
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
- 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.
* 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.
And it can be called from go command too: go fmt main.go
https://pkg.go.dev/cmd/go#hdr-Gofmt__reformat__package_sourc...
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.
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).
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.
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.
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.
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.
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.