Librsvg Continues Rust Conquest, Pulls In CSS Parsing Code From Mozilla Servo

[jacob]

Ever heard of a debugger?

Program received signal SIGSEGV, Segmentation fault.
main () at test.cpp:9
9 std::cout << *v[50] << '\n';
(gdb) p v[50]
$1 = std::unique_ptr<int> = {get() = 0x0}
(gdb)

How good is gdb or lldb with Rust?

In gdb at least it's as good as with C++, give or take. But the point is that you shouldn't need a debugger for bugs like this one. Rust is all about static provability: it's no use telling the passengers of an airplane "sorry ladies and gentlemen, the autopilot system just crashed but don't worry, there is a debugger".

[oleid]

In gdb at least it's as good as with C++, give or take. But the point is that you shouldn't need a debugger for bugs like this one. Rust is all about static provability: it's no use telling the passengers of an airplane "sorry ladies and gentlemen, the autopilot system just crashed but don't worry, there is a debugger".

Lldb works fine, too.

But even a debugger doesn't always help. I've seen bugs with dangling references at work where even a debug build just crashes somewhere and where it's not obvious where the source of the problem lies. Sure, in a five line snippet - easy. But wait until there are 1000 LOC and more. Then you either take your sanitizers or even more static code analysis. Debugging can be 'bigger at the inside'. So I'm glad for everything the compiler catches. And even if YOU are a l33t coder and you never code any bugs. You rarely work alone

[kpedersen]

LLVM being long in the tooth. That's laughable. Right up there with Clang being long in the tooth, and I'm not even defending Rust.

You don't think in 20 years time there will be a new compiler infrastructure more flexible than LLVM? Guess you will have to wait and see

[ssokolow]

Lldb works fine, too.

But even a debugger doesn't always help. I've seen bugs with dangling references at work where even a debug build just crashes somewhere and where it's not obvious where the source of the problem lies. Sure, in a five line snippet - easy. But wait until there are 1000 LOC and more. Then you either take your sanitizers or even more static code analysis. Debugging can be 'bigger at the inside'. So I'm glad for everything the compiler catches. And even if YOU are a l33t coder and you never code any bugs. You rarely work alone

I just saw a conversation on /r/rust/ maybe a week ago. lldb still has room for improvement in the code to decode Rust type signatures and the person was advised to use gdb instead.

[oleid]

I just saw a conversation on /r/rust/ maybe a week ago. lldb still has room for improvement in the code to decode Rust type signatures and the person was advised to use gdb instead.

Really? I'm using it via CLion. But now that you say it... I think CLion comes with it's own set of renderers, for both gdb and lldb. Read that somewhere in the menu.

[Delgarde]

You don't think in 20 years time there will be a new compiler infrastructure more flexible than LLVM?

Well, GCC has been around more than 30 years now, and and had been going well over 20 before LLVM became a serious rival. So, maybe?

[schmidtbag]

kpedersen schmidtbag uid313 jo-erlend

Thank you for your replies. I was thinking about C++, but I started to learn C two months ago. I did take a look at Java as well, but I didn't understand a thing - I need to know what every thing means and the tutorial didn't explain the syntax and classes at the beginning. When comes to C I'm feeling I have a full control of what I am doing.

For my personal rule-of-thumb: if you can write an entire program without using classes, do so (note that I don't work with Java lol). The funny thing about classes is they dramatically simplify your code when you need them, and greatly over-complicate your code when you don't (which IMO, is most of the time).
Except for particularly complex programs (like GIMP), I'd argue your run-of-the-mill GTK program can easily be made without classes. Since you've already begun learning "vanilla" C, just keep at that. Expand an object-oriented C flavor when you feel you need it.

[Delgarde]

I'd argue your run-of-the-mill GTK program can easily be made without classes.

That's a funny thing to say, given that GTK is fundamentally a very class-based OO toolkit... it's just implemented in a language that doesn't actually support classes, and so does a reasonably good job of faking it with what's available.

[schmidtbag]

That's a funny thing to say, given that GTK is fundamentally a very class-based OO toolkit... it's just implemented in a language that doesn't actually support classes, and so does a reasonably good job of faking it with what's available.

Well that's the thing - just because a library is heavy on objects, doesn't mean the code using that library needs to be. Most of the work I do is in python and just about every library I use is filled with classes, but often my code has none at all.

[jjkk]

What's not portable about Rust? And do all your projects need to run on x86, ARM, MIPS and RISC-V at the same time?

Oh, not that crap again. It is not portable because it builds itself only with a number of supplied pre-built rust binaries. That is, you can build rust only if rust maintainers decide to build it for you. As mentioned already, there is and there will be C compiler on any platform. And you can cross-compile for a new target with minimum effort.

No, but there is an ongoing effort to add an gcc backend to the rust compiler. So once that landed, you can use that instead of something llvm backed.

Until it lands, you can use mrustc, a rust to c transpiler - for exotic platforms or as bootstrap mechanism, until rust compilers are more common.

Not going to happen. The current state of rust is just an awful mess. To such degree that rust team themselves can not pull that task. Witnessing all that rust circus for few years already and even started learning it. IMO it will just collapse and die. The sooner the better. So that they infect less software projects with this bullshit.