Low level programming in ada. Capture a signal,
https://gitlab.com/alaindevos/adatut/-/tree/main/11_signal/src?ref_type=heads
https://gitlab.com/alaindevos/adatut/-/tree/main/11_signal/src?ref_type=heads
Ada its quite easy:
with Ada.Text_IO;
procedure Erroneous is
type Int_Ptr is access Integer;
P : Int_Ptr; -- uninitialized
begin
-- ERRONEOUS EXECUTION
Ada.Text_IO.Put_Line (Integer'Image (P.all));
end Erroneous;open Microsoft.FSharp.NativeInterop
#nowarn "9" // allow NativePtr usage
let demo () =
// Allocate stack memory for an int, but DO NOT initialize it
let p = NativePtr.stackalloc<int> 1
// ERRONEOUS / UNDEFINED BEHAVIOR
let x = NativePtr.read p
printfn "%d" x
demo ()String: type == std::string;
auto& Cout = std::cout;
#define Format std::format
greet: (name: String) = {
Cout << Format("Hello, {}\n", name);
}
sum: (a: i32, b: i32) -> i32 = {
sum := a + b; // Type inference with :=
return sum;
}
main: () = {
x: String = "world";
greet(x);
s:=sum(10, 20);
Cout << Format("Sum : {}\n", s);
}I like it to an extent. I do think extensions of C (and C++) do have a lot of merit as a solution for a next gen language.
And you miss to name those things that you regard as important.
The limitations of C++ are well cited in a number of papers. I don't expect every technical conversation needs to be suitable for kids.And you miss to name those things that you regard as important.
Think about all these kids reading here ... do you think that they know??
.And this is where we wrap around to C being the lingua franca of programming. No matter what language you write in, if you want to talk to anything that isn't your language, you must speak some dialect of C.
extern "C", and you'll need a C header for those exported symbols to be usable. There is tooling to generate both the Rust bindings and the C headers. Naturally you'll want to verify the output, and correct it where needed, but that gets most of the heavy lifting done.From The rustc dev guide, Updating LLVM
See this long-standing PR 274743.
I read the link. If you suggest that it is important to be updated, it is a bad example. You can spend a lifetime studying only one fractal curve, a recent branch in topology, avoid this one.The limitations of C++ are well cited in a number of papers. I don't expect every technical conversation needs to be suitable for kids.
Similarly to before, I can only recommend people read around if they are struggling to keep up
They probably are thinking comparatively to Rails or Node.js, as many on-premise webapps in the self-hosting circles are written with those. Lemmy is an ActivityPub-based software, for which the big dominant big brother, Mastodon, is a Rails app. My bet would be on the target audience for this part of the homepage's text to be the people who already ran an instance of Mastodon and maybe think running such thing is resource intensive (they should mention the storage footprint, though, as ActivityPub can be *really* verbose
).I don't understand the persistent desire of it being in the base system. It makes me suspect corporate involvement. What exactly is it supposed to do, that apparently isn't possible while it's an external program? Are we sure that no other options are goimg to be limited for it? If not, the point of debate is bogus. It makes no difference apart from a pkg install command.
And I agree with that. Hence my message further up the thread: it's not a good idea yet, but that doesn't mean it'll never be.
Very much something to judge on a case-by-case basis. Also depends on how you handle deps and linking.
Just my two cents: Rust is a very nice language to work with (subjective, I know) that makes some things a lot easier to do, and that makes it much harder to get caught in some of the bugs and pitfalls of "obvious UB, but the compiler doesn't complain" that C(++) have. That also makes it much more approachable for little to no performance penalty. Which in turn is one of the driving forces of corporate adoption, because fewer bugs and easier entry means that it'll be cheaper to develop. Doesn't mean the drive for Rust in base is a corporate push though; companies using FreeBSD now clearly don't require it, and others wouldn't magically flock to it just because it has some Rust.
unsafe exists, but that comes with both more verbosity and having to uphold guarantees that the compiler stops enforcing. Writing good and reliable Rust that performs on par with C(++) can be a real challenge. It's not a free performance booster without bugs in that regard.You generally won't see Rust on many job apps during our lifetime. But there is still a push by small but vocal companies to "sell" you new products (IDEs, books, courses) because there is less market competition compared to industry standard languages like C and C++.
Plus, I don't think there is reason to be suspicious, it's following the exact same hype cycle all trendy techs have done before. It always peaks with people being frankly fanatical about their tech, until comes the time where it's not new anymore, when you can't anymore write tutorials about how easy it is because it's starting accumulating baggage, and before you know it, it's just a weird corner of tech and a new trend is replacing it. I remember a time when people were very seriously discussing if the Linux kernel should be rewritten in Ruby (they were not kernel developers, of course, just Ruby developers convinced they were almighty right on all things). Let it settle and we'll see what survives of it.
