>Development time is absurdly faster
That definitely sounds like you have never made/contributed to anything non trivial that's made in Rust.
Development time is significantly slower for any non toy project where the problem domain hasn't been solved/the person/s don't have experience with.
I had a similar experience when i was in highschool and learning python. I wrote a image->ascii image convertor using PIL as you did, one image would take a few hundred ms and it was fine, but as i played with it and added more features/learned more i tried to do it on video frames extracted with ffmpeg and it would take atleast 4x the duration of the video or even more to convert it in ascii video.
Few months ago i coded it in go since i got back into programming and it was significantly faster(The overall code was also smaller but maybe that's just because i have a bit more experience now) even tho in both cases the implementations was the most naive one i could come up with, without any optimizations.
Edit:
I went ahead and tested both, took me 30 mintues to set them with identic parameters on 3602 frames(roughly 1 minute video)
Keep in mind that this is just a naive implementation with 2 nested loops itereting in a step of 12 over the pixels of the image, no fancy math or numpy used in the python version. Image for reference[0].
Also keep in mind that the step and length of the ascii charmap used affects performance but here i used a simple one "_^:-=fg#%@" so it's a bit easier for the python code, here are the results on my i7 9th gen laptop
1 Minute video 720p 60fps
GO - Execution time: 359647 ms, 5.9 minutes ("asciifying the frames") + 30~ seconds ffmpeg video conversion
Python 3.12.3 - Execution time: 0:16:25.002945, minus ~25-30 seconds ffmpeg
A lot of these notes follow a similar pattern: we start with Python, get a working program, and then rewrite it in X with a huge performance gain.
That’s fair. We use the easy language to get a correct program, then we use the “hard” language to get a fast program, now that we know what a correct one looks like.
This is the key here. If you try to start with the lower level language, you might spend a much longer time getting to the correct program.
It’s much easier to optimise a program that’s working than to debug one that isn’t.
There are other candidates, only listing the ones with good out of the box REPL experience, JIT/AOT toolchains in the reference implementation, and not going crazy with their type systems for strong typing.
One of the strengths python has is its ecosystem. All the languages you listed don’t come close to python’s ecosystem except perhaps TypeScript/nodeJS (whose quality of ecosystem is questionable although improving in recent times).
No, this was very much NOT my point. The java version of my program was just as easy if not easier to write, precisely because I COULD write the naive version and trust that it would work out fine performance wise.
Hell, the java version didn't even require the extra library (Pillow/PIL) that python required!
But even if it was true (I'd contest it's not) can't you ignore it and judge the language on its merits? We are not teenagers for a long, long time now, we should be making up our own mind about things.
I have not done either. "Curmudgeon" is a "get off my lawn, kids!" grandpa btw. :)
I have not denied you anything, I implored you to ignore the zealots that exist IN EVERY ECOSYSTEM and judge the thing based on what it can actually do.
Please don't misrepresent what I said, that's not arguing in good faith.
Heh, this grandpa has written like 3x more python than C this year. And the C part was no choice - that was all I had on these devices.
Edit: from what I hear from my peers (translation: other programmers that I have coffee or drinks with), if I started a new server application today and I needed the performance of a compiled language, I should use Go not Rust.
I believe servers are where the propensity of C like languages to allow you to shoot yourself in the foot is the problem, isn't it?
Before the current "AI" hysteria, HN was full of "I've rewritten this thing that was working just fine in Rust". No mention of how it's better, has more features - or even has all the original's features - or anything about why you should use the rewrite instead of the original.
Am I supposed to use a tool just because of what it's made of, or because it solves a problem for me?
I don't need a 100% drop-in. Barely anyone does. I've observed at least 80% of all of the coreutils features are not used by 90% - 99% of programmers and sysadmins.
Ask people if they used all flags of `sort` and report back results as a test of my hypothesis.
> The right questions according to who?
This is tiring. I told you twice that I'd prefer you engaging in technical merits. You keep drawing attention to what is annoying you but you'll have to talk to your friends and family about that because I am not interested.
I don't see many CVEs in coreutils. Maybe one or two, in several decades? I do on occasion use obscure flags (or at least ones that are obscure to me).
I am getting tired of being misinterpreted, not of the argument itself because the argument ended several comments ago and the person focused on being a little rebel ("who gets the determine the right questions" is his favorite pet peeve apparently).
There is no argument currently, just people trying really hard to miss the point that was stated very clearly.
Mine was that some people needlessly -- and very immaturely -- rebel against using Rust because of something they saw on HN 5 years ago. There's no Rust zealotry here for a long time.
I chased after a few people asking them if they really tried it or they simply resist something because it's gaining popularity.
It is but there are other technical and non-technical merits too. "Security" doesn't trump all. If you need secure, turn off your computer.
I tried Rust and downloaded some projects that should be comparatively simple (e.g. text editor). "cargo build" downloaded and built about 500 dependencies. The Rust ecosystem had a chance to convince me, and it sure has some convincing results. But it wasn't my cup of tea.
If you included hundreds of dependencies to do what you can't easily do yourself within the "safe" framework, that may or may not be the language's or the ecosystem's failure. But the attribute "secure" for such a project is questionable. As NPM history or a certain guy or the recent events around the xz project illustrate well.
It's bizarre. Gazan social media happily shows the malls and beach clubs, car dealerships, supermarkets etc, that existed before Hamas started the war. There's literally nothing flag-worthy about my comment asides from it debunking a narrative about Gazan life.
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.
