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

701–710 of 736 posts

Re: Was Rust Worth It?

#701

Post by mejutoco »

TylerE wrote: post #679
mejutoco wrote: post #490

Earlier quoted context omitted.

Couldn't one use Arc and similar boxed types to avoid thinking about memory until later?

Why not just something like nim and that point, and straight up ditch 90% of the complexity?

I was answering to this other user:

> This is factually impossible.

> For anything larger than (very) small programs, Rust requires an upfront design stage, due to ownership, that it's not required when developing in GC'ed languages.

It seems that is not factually impossible.

Now, answering your question: It could be useful to use boxed types and later optimize it, so you get the benefits of rust (memory safety, zero cost abstractions) later, without getting the problems upfront when prototyping.

Re: Was Rust Worth It?

#702

Post by imtringued »

ostenning wrote: post #364
kuon wrote: post #231

I wrote a lot of rust, but after some years it still feels unproductive. I do a lot of zig now and I am like 10 times more productive with it. I can just concentrate on what I want to code and I never have to wonder what tool or what library to use. I know rust gives memory safety and how important that is, but the ergonomic is really bad. Every time I write some rust I feel limited. I always have to search libraries…

Opposite experience for me. Writing Rust on embedded systems greatly improved my confidence and speed. When using C a small mistake often leads to undefined behaviour and headaches. Rust theres none of that - its been a game changer for me.

When you are developing hardware on an FPGA, a lot of hardware bugs look like they have locked up the CPU and strangely enough, a lot of undefined behavior looks exactly like a hardware lockup...

Re: Was Rust Worth It?

#703

Post by imtringued »

GuestHNUser wrote: post #396
csomar wrote: post #372

Earlier quoted context omitted.

Depending on what seamlessly means, Rust can also interop with C libraries. I wrapped a bunch of them.

Truly seamless because the zig compiler is also a C compiler, so the type information and calling convention works across languages at a level above any other I've encountered.

It is impossible to do C interop without a C compiler, by the way.

Re: Was Rust Worth It?

#704

Post by cztomsik »

epage wrote: post #560
freilanzer wrote: post #465

Earlier quoted context omitted.

Why is there no need to improve Zig code but there is for Rust code? You'd need the same abstractions in Zig as well, no?

Can't speak for why Zig doesn't have a problem but Rust is cursed by its success: it lowers the barrier for improvement enough to entice you to always improve it.

No. Rust forces you to spend endless hours doing mental gymnastics which shouldn't be needed in the first place (linked data-structures, owned arenas, or even just boxed slices are impossible in safe rust).

And you just keep refactoring/improving/desperately trying different ideas, because it never feels right.

It's ok if you don't agree but pls don't try to make my responses look like I like Rust, I don't and I'd happily get those years back if it was possible.

Re: Was Rust Worth It?

#705

Post by cztomsik »

mst wrote: post #579
cztomsik wrote: post #480

Earlier quoted context omitted.

No, usually you don't. Rust has closures, iterators, generics, different traits for operator overloading, smart pointers, etc. Zig doesn't have any of that. It's very interesting combination of low-level, predictable code, with meta-programming, where you get some of that abstraction back. i.e. Zig does not have generics, but your function can return type, so generic list is just a function which returns a newly crea…

Could you expand on the generics point, please? That sounds interesting but I can't quite get my head around it.

Functions in Zig can be called both in runtime and in compile-time. You can force some expression to be called during comptime using a keyword, and sometimes the comptime is implied (like when you define top-level const)

If a function is called in comptime, it can also return types. So for example:

    // this is a function which accepts a type
    // if you accept type, you also have to restrict the arg to be comptime
    // if the arg is comptime it still does not mean that the function cannot be called in runtime,
    // but in this case, it returns type, so it is comptime-only function
    // there are also cases where this is not true, like std.mem.eql(u8, a, b) which accepts type,
    // but can be called in runtime because it does not return type
    fn Wrapper(comptime T: type) type {
        return struct { value: T };
    }

    const F32Wrapper = Wrapper(f32);

    // @TypeOf(x.value) == f32
    var x: F32Wrapper = .{ value: 1.0 }

Re: Was Rust Worth It?

#706

Post by darthrupert »

SJMG wrote: post #662
darthrupert wrote: post #319

Earlier quoted context omitted.

You should try diving into num for like a month and see how you like it. It's different enough that you need to go past a certain kind of ledge to start liking it. Or at least that was my experience. For me, it shares the most important benefits of Rust but with quite a lot more ergonomic coding model.

Nim on paper is great; it has many advantages over Rust in the general purpose "niche". Tragically, it's kind of stillborn. It's older than Rust, has orders of magnitude less mindshare, and has no companies with serious technical reputations backing it.

Yeah, you're not wrong about the mindshare problem. But it somehow at least in my mind differs from other "stillborn" older languages in that it keeps improving. The end result is that it still feels modern in the year 2023.

Re: Was Rust Worth It?

#707

Post by kprotty »

rstuart4133 wrote: post #196
RantyDave wrote: post #128

Re: async, rust is a down to the metal language. IE library yes, runtime no. Async implementations are all either runtimes (Javascript), or libraries that implement a runtime (Python). Under the circumstances I think it's fair that rust has less than ideal async. I still like threads, but the I'm old and uncool.

> I still like threads, but the I'm old and uncool. Hey, I resemble that remark. But I disagree with it. Green threads give you all the advantages of async, but with less of the hairs. In particular no special syntax or change of programming style is required. Yet underneath green threads and async just different styles of event driven I/O, so both run at similar speeds and excel at the same tasks. (Actually green th…

> Green threads give you all the advantages of async

They require more memory over stackless coroutines as it stores the callstack instead of changing a single state. They also allow for recursion, but its undelimited meaning you either 1) overrun the guard page and potentially write to another Green thread's stack by just declaring a large local variable 2) enable some form of stack-probing to address that (?) or 3) Support growable stacks which requires a GC to fixup pointes (isn't available in a systems lang).

> green threads should run faster, as storing state on a stack is generally faster than malloc.

Stackless coroutines explicit don't malloc on each call. You only allocate the intial state machine (stack in GreenThread terms).

> The primary objection seems to be speed

It's compatibility. No way to properly set the stack-size at compile time for various platforms. No way to setup guard pages in a construct that's language-level so should support being used without an OS (i.e. embedded, wasm, kernel). The current async using stackless coroutines 1) knows the size upfront due to being a compiler-generated StateMachine 2) disallows recursion (as that's a recursive StateMachine type, so users must dynamically allocate those however appropriate) which works for all targets.

Re: Was Rust Worth It?

#708

Post by estebank »

CGamesPlay wrote: post #664
estebank wrote: post #614

Earlier quoted context omitted.

That is a different problem than the one I thought you were seeing. We do spend a lot of time trying to silence errors that are irrelevant. We also get a lot of complaints when fixing a single error produces a wave of new errors that were hidden due to failures in earlier stages. It's a balancing act. Also, specific errors are verbose in order to give people a fighting chance to fix their issue. An error that is too…

> Could I ask you why you didn't consider doing so when you first encountered this problem? Thanks for looking into it. I have a filed a bug against Rust before, but that was a clear bug, not a poor error message. Remember, the only time a user sees something like this is when they are trying to do something else. The only reason I looked into it just now is because you explicitly asked.

We consider poor error messages to be bugs. I know most people don't, so I've made it one of my missions to yell it from the mountain tops to encourage people to report more often. We can't fix what we don't know about. The majority of the current good errors were a reaction to things people filed in the past.

Re: Was Rust Worth It?

#709

Post by Borg3 »

benibela wrote: post #697
Borg3 wrote: post #619

Earlier quoted context omitted.

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 objec…

Ahh, Delphi. Then I suppose its all right for it. Still, much better compared to Go or Java :D

Re: Was Rust Worth It?

#710

Post by riku_iki »

MrRolleyes wrote: post #300
riku_iki wrote: post #227

Earlier quoted context omitted.

I think more importantly it is reference counting across threads, meaning mutexes and breaking memory barrier with large performance penalty.

I believe you're discussing 'Arc'. 'Rc' is not thread safe.

then this is not "closest to GC languages", since GC langs usually provide memory management with respect to concurrency.
Post reply on HN