Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Was Rust Worth It?

jsoverson.medium.com

Post reply on HN
Print view View original

691–700 of 736 posts

Re: Was Rust Worth It?

#691

Post by YuukiRey »

MuffinFlavored wrote: post #661
topspin wrote: post #209

Earlier quoted context omitted.

Tokio isn't the fastest conceivable runtime. Tokio isn't the smallest conceivable runtime. Tokio isn't the simpilist conceivable runtime. Tokio does not port to all conceivable environments. Tokio isn't the async-std runtime. And so, for some or all of these reasons, right or wrong, various Rust libraries wed themselves to runtimes other than Tokio. You can thunk around these things, but it's miserable, yielding subt…

Is this to say async-std is faster + smaller + simpler + more portable than Tokio?

I think what they were trying to say is that Tokio ended up being a general purpose async runtime so naturally it can't be the most optimal solution for every case. But because various libraries kind of force you into Tokio, it's very hard to use a runtime that's optimal for your specific problem. You'd have to give up on a lot of convenient libraries out there.

Re: Was Rust Worth It?

#692

Post by tialaramex »

lmm wrote: post #669
tialaramex wrote: post #547

Earlier quoted context omitted.

Many of the cases of IFNDR are semantic constraints, especially in C++ 20 and beyond. As a result of being semantic constraints it's generally impossible to diagnose this with no false positives. The ISO standard forbids such false positives so...

Can you give a more concrete example of the kind of thing you're talking about? Like, if you try to sort something and your comparator implementation for that type is not transitive, the compiler can silently produce a broken binary? Surely in the undecidable cases the compiler is allowed to produce a binary that errors cleanly at runtime if you did in fact violate the semantic constraint, and any sane implementor wo…

> Like, if you try to sort something and your comparator implementation for that type is not transitive, the compiler can silently produce a broken binary?

It's not merely about whether your comparisons are transitive, the type must exhibit a total ordering or your sort may do anything, including buffer overflow.

> Surely in the undecidable cases the compiler is allowed to produce a binary that errors cleanly at runtime if you did in fact violate the semantic constraint,

I don't think I know how to prove it, but I'm pretty sure it's going to be Undecidable at runtime too in many of these cases. Rice reduced these problems to Halting, which I'd guess means you end up potentially at runtime trying to decide if some arbitrary piece of code will halt eventually, and yeah, that's not helpful.

I've written about it before, but I should spell it out: The only working alternative is to reject programs when we aren't sure they meet our constraints. This means sometimes we reject a program that actually does meet the constraints but the compiler couldn't see it.

I believe this route is superior because the incentive becomes to make that "Should work but doesn't" set smaller so as to avoid annoying programmers, whereas the C++ incentive is to make the "Compiles but doesn't work" set larger since, hey, it compiles, and I see Rust's Non-Lexical Lifetimes and Polonius as evidence for this on one side, with C++ 20 Concepts and the growing number of IFNDR mentions in the ISO standard on the other side.

Re: Was Rust Worth It?

#693

Post by tialaramex »

defen wrote: post #690
tialaramex wrote: post #666

Earlier quoted context omitted.

If unsafe disabled the borrow checker, you wouldn't have needed that transmute. But it doesn't, so you needed the unsafe transmute to make this work.

I don't consider myself a Rust expert, but this feels like a semantic argument? You can use `unsafe` to erase lifetimes, right? I'm not saying it's a good practice, and it's not globally disabling the borrow checker or anything like that, but in theory it's possible to produce unbounded lifetimes that are incorrect. In practice it probably doesn't happen very often. Certainly less often than UB in C or C++

I don't consider this a semantic argument.

The exact same code, without the transmute (just returning x directly from an unsafe block), fails a type check related to borrowing. Specifically, the compiler can't see why (without a transmute) it should believe that the reference x now has a different lifetime 'b instead of 'a. Which is fair because it doesn't.

The transmute is you claiming it does, and since transmute is an unsafe function that's entirely on you to make sure you're right about that. So, lying has the expected effect.

The borrow checks aren't magic, they can't look into your soul - but they are running inside unsafe code too.

* Edited to make explicit that the alternative is still marked unsafe and yet doesn't work

Re: Was Rust Worth It?

#694

Post by deterministic »

api wrote: post #487
ernst_klim wrote: post #449

Earlier quoted context omitted.

I agree. I feel far more productive in C and C++ than in Rust at that point. Rust feels like totally missing the sweet spot for me. It's way too pedantic about low level stuff for writing higher level applications, but way too complicated for embedded or writing an OS. In the former case I would rather take a C++, Java, Haskell, OCaml or even Go, and maybe sprinkle some C, and in the latter case C in macroassembly mo…

The problem with C and to C++ is that it’s 2023 and the CVE list is still loaded with basic memory errors. These come from everywhere too: small companies and open source all the way up to Apple, Microsoft, and Google. We as a profession have proven that we can’t write unsafe code at scale and avoid these problems. You might be able to in hand whittled code you write but what happens when other people work on it, it…

I maintain very large C and C++ application and very rarely have any memory issues. Tools like Valgrind and Helgrind are excellent for finding and fixing problems. So switching to Rust is a very bad ROI.

Re: Was Rust Worth It?

#695

Post by 1vuio0pswjnm7 »

afdbcreid wrote: post #467
1vuio0pswjnm7 wrote: post #353

"The Rust standard library is enormous." Years ago I tried compiling a rust sample program. The binary size was one thing that put me off. Today, I see the issue of large binary size has been addressed. The binary I get is sufficiently small. If this issue of ~500M standard library is fixed, e.g., if some of it is made optional not mandatory, I will give rust another try.

Rust binaries are by default nowhere close to 500MB. If they are not small enough for you, you can try https://github.com/johnthagen/min-sized-rust . By avoiding the formatting machinery and using `panic_immediate_abort` you can get about the size of C binaries.

Comment is based on the rust-std package I'm currently seeing in VoidLinux. It is over 500MB.

3 packages will be downloaded:

3 packages will be installed:

  libexecinfo-1.1_3 
  libexecinfo-devel-1.1_3 
  rust-std-1.73.0_1 

  Size to download:              136MB
  Size required on disk:         509MB
  Space available on disk:       never enough!
Cheacking Debian and NetBSD it seems like the Rust standard library is smaller, much less than 500MB.

The simple question is how much space is required for an installation of the Rust compiler. On VoidLinux, it's significantly more space than for a GCC installation. 509MB is just too much for my tastes.

Re: Was Rust Worth It?

#696

Post by pas »

jodrellblank wrote: post #350
pas wrote: post #312

Earlier quoted context omitted.

steel melts around 1600, the engine would blow up waaay before. the problem with that story is that if the "seal" is made from a simple material that melts by the engine heat, then it will not seal for long. (or at all.) but likely it's not what Steinbeck wrote.

At what temperature does copper soften enough to squish into a seal shape? I seem to remember my dad shimming a cylinder that had lost compression with a copper ring; I was a kid so I don't remember any details except it wasn't intended to melt, and whatever it was intended to do worked and we saw the car still being driven around town fifteen or twenty years after he sold it.

it's possible that the car got a replacement part eventually :)

copper becomes ductile between 300-600 C ( https://www.engineeringtoolbox.com/docs/documents/1353/tempe... )

piston ring seals are usually made of cast iron or steel. copper would probably work too for a while, it's good at conducting heat, there's ample cooling in engines, so it wouldn't melt, just wear out very quickly ... and then the engine performance degrades as the sealing gets worse and worse (and it starts to eat oil, soot gets everywhere, exhaust becomes visible), mpg goes down, but ... the car would probably run. (loss of 1 out of 4 pistons is not a catastrophic failure)

Re: Was Rust Worth It?

#697

Post by benibela »

Borg3 wrote: post #619
benibela wrote: post #536

Earlier quoted context omitted.

I was making Windows 98 apps with Delphi 4, and they were 350 KB large And I was upset that they were so big. Sometimes I used UPX. Or I kicked out all Delphi GUI libraries, and created the GUI with the Win32 API calls directly. I got 50 KB Hello Worlds.

50kB hello worlds? Uhm.. thats still big. 15k May 3 2019 quickrun.exe* Win32 GUI Application that spawns Window and ask for alias to run. Pure Win32 API, written in C (Mingw). I literaly looled at 11MB hello world of .net or 1.2MB Go..

Well, it is what I remembered

I do not have Windows 98 anymore. But I still have Delphi 4 installed under Wine, so I just tried it out.

Just showing a messagebox from windows gives 16k

Using the sysutils unit though, puts it at over 40k. And with classes, it becomes 57k. Not sure what they pull in. sysutils contains number/datetime parsing and formatting, and exception handling. classes has basic containers and object oriented file handling.

Re: Was Rust Worth It?

#698

Post by tialaramex »

_gabe_ wrote: post #685
tialaramex wrote: post #677

Earlier quoted context omitted.

First of all, and most importantly, we're not talking about Undefined Behaviour, which happens at runtime, but about IFNDR (Ill-formed, No diagnostic required), which means at compile time your program has no meaning whatsoever because it's not a well-formed C++ program after all but your compiler doesn't tell you (and because of Rice's Theorem in many cases cannot possibly do so as it can't determine for sure itself…

> First of all, and most importantly, we're not talking about Undefined Behaviour, which happens at runtime, but about IFNDR From the link I posted, from cpp reference, which gives a definition for what constitutes undefined behavior: >> ill-formed, no diagnostic required - the program has semantic errors which may not be diagnosable in general case… The behavior is undefined if such program is executed And as for th…

> the one question that matters. Is an executable file with machine code well-defined?

While you've insisted that's somehow the one thing which matters I don't agree at all. Are programmers getting paid to produce "any executable file with machine code" ? No. Their employer wanted specific executables which do something in particular.

And there aren't "different types of undefined behavior" there's just one Undefined Behaviour. Maybe you've confused it with unspecified behaviour ?

In the integer overflow case, because that's UB (in C++) it's very common for the result to be machine code which entirely elides parts which could only happen under overflow conditions. Because overflow is UB that elision didn't change the program meaning and yet it makes the code smaller so that's a win - it didn't mean anything before in this case and it still doesn't - but of course the effect may be very surprising to someone like you.

The excuse that "We've done it for decades therefore it can't be a bad idea" shouldn't pass the laugh test. Did you notice you can't buy new lead paint any more? Asbestos pads for ironing boards? Radium dial wristwatches? "That's a bad idea, we shouldn't do that any more" is normal and the reluctance from C++ programmers in particular shows that they're badly out of touch.

Re: Was Rust Worth It?

#699

Post by Const-me »

tkubacki wrote: post #684
Const-me wrote: post #525

Earlier quoted context omitted.

I think Java is only good for long-running servers. Java doesn’t support C interop. For many desktop and embedded projects this is a showstopper, here’s an example https://github.com/Const-me/Vrmac/tree/master/VrmacVideo That C# code directly consumes V4L2 and ASIO Linux kernel APIs, and calls unmanaged user-mode DLLs like libfdk-aac.so and liba52-0.7.4.so. Native stack and value types in C# reduce load on GC, and th…

Well maybe you should use C++ or Rust instead of Java or C# in that case? My point is if you are doing business (especially web) apps. Use one of JVM langs insted of C# because ecosystem is much bigger (and it has fresher langs as well like Kotlin - if that's what you care about)

> use C++ or Rust instead of Java or C# in that case?

Despite having to spend extra time translating C API headers into C#, the productivity gains of the higher-level memory safe language were enormous.

Another example, I have shipped commercial embedded software running on ARM Linux, and based on .NET Core runtime. The major parts of the implementation were written in idiomatic memory-safe C#.

> doing business (especially web) apps

Well, these business web apps are precisely the long-running servers I have mentioned. Still, the software ecosystem is not limited to that class of problems, and due to different tradeoffs Java is not great for anything else.

Re: Was Rust Worth It?

#700

Post by benibela »

maxbond wrote: post #634
benibela wrote: post #592

Earlier quoted context omitted.

Still someone might call unwrap on an Option and then run into some kind of null pointer exception

Sure, you can panic unwrapping a None, but there are two important distinctions. First, this is a controlled panic, not a segmentation fault. The language is ensuring that we don't access the null pointer, or an offset from the null pointer. Null pointer access can be exploitable in certain circumstances (eg, a firmware or kernel). Your use of "exception" suggests you're thinking about it in Java terms however, and J…

>First, this is a controlled panic, not a segmentation fault.

But a segmentation fault is also controlled

>Your use of "exception" suggests you're thinking about it in Java terms however, and Java is equivalent here.

No, I am thinking in Delphi terms. It is overspecialized to Windows userspace. Windows gives an Access Violation, and that can be caught, and Delphi throws it as exception

>Second, you can only encounter this in explicit circumstances, when you have an Option. Wheras in languages with a null type, any variable can be null implicitly, regardless of it's type.

Delphi has both nullable types and null-safe types

Post reply on HN