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

[oleid]

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.

And how do those C compilers get built?

You can compile the official rust compiler and cargo already today and just fine with GCC (via mrustc).

[ssokolow]

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.

That could be said about every language that isn't C or assembly language. The reference Rust compiler does pretty well in supporting every platform LLVM has a viable backend for.

(I say "viable" because targets like AVR are blocked on shaking the bugs out of the LLVM backend that exists, and I say "every" because that list doesn't even include the out-of-mainline stuff, like the version of rustc you can build against Xtensa's recently released fork of LLVM for ESP32 microcontrollers.)

Are you arguing that we should never ever use a language other than C again? ...because that is basically what turned C++ into a godawful mess that prompts responses like this one from Scott Meyers in 2018.

As you may know, I retired from active involvement in C++ at the end of 2015, and in the ensuing two and a half years, I’ve forgotten enough details of the language that I am no longer able to properly evaluate bug reports regarding the technical aspects of my books. C++ is a large, intricate language with features that interact in complex and subtle ways, and I no longer trust myself to keep all the relevant facts in mind. As a result, all I can do is thank you for your bug report, because I no longer plan to update my books to incorporate technical corrections. Lacking the ability to fairly evaluate whether a bug report is valid, I think this is the only responsible course of action.

C++'s "design by committee" is more or less the inevitable result of having no alternatives that big, powerful corporations like Microsoft can focus on when they need to justify their additions to their compiler to make it easier for them to maintain whatever they dogfood it on.

If you forced everyone to stick to C, do you really think you could keep those same forces from acting on it to turn it into C++ 2.0?

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.

I'm going to throw a great big "citation needed" at you there, because, with hyperbolic language like "awful mess", "circus", and "infect", all I'm hearing is "Blah blah blah. I'm not a reliable source." ...especially given that I've been keeping an eye on ongoing development since before Rust 1.0 and they seem to be one of the the least circus-like efforts to develop a language that I've ever seen.

[Delgarde]

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.

Ah, well if you meant without writing your own classes, I'd agree. They're a very useful tool in general, but like any tool, you use it only when it makes sense (i.e. you want encapsulation et al)... and in a lot of projects, it's not strictly necessary.

[schmidtbag]

Ah, well if you meant without writing your own classes, I'd agree. They're a very useful tool in general, but like any tool, you use it only when it makes sense (i.e. you want encapsulation et al)... and in a lot of projects, it's not strictly necessary.

Yes - that is what I meant. I totally agree that classes are very useful; a few of my projects wouldn't have been possible without them, and many libraries wouldn't [easily] work without them either (I have no doubt GTK applies to this as well).

Though, I would argue in a lot of situations, classes can go beyond "not strictly necessary"; they are often unnecessary. In particular: any time the class will only ever have 1 instance. In such situations, the class is just making your code more bloated (and therefore harder to read) and your program more inefficient. There have been several times I have taken example code and reduced it to as little as 25% its original size just by removing unnecessary classes and variable definitions, while retaining the same functionality and adaptability. Frankly, if I have to dissect an example file where I have to weed out impractical code, it isn't a good example. It's even worse when they don't come with any comments...

Of course, there are some exceptions to what I said here.

[jjkk]

That could be said about every language that isn't C or assembly language. The reference Rust compiler does pretty well in supporting every platform LLVM has a viable backend for.

(I say "viable" because targets like AVR are blocked on shaking the bugs out of the LLVM backend that exists, and I say "every" because that list doesn't even include the out-of-mainline stuff, like the version of rustc you can build against Xtensa's recently released fork of LLVM for ESP32 microcontrollers.)

Are you arguing that we should never ever use a language other than C again? ...because that is basically what turned C++ into a godawful mess that prompts responses like this one from Scott Meyers in 2018.

Again? Point me where I said that once or this is just another rust sectarian demagogy. I keep saying that rust is a giant mess because of inability to bootstrap it using C compiler in a clean and reproducible manner. And you keep repeating the mantra of rustc which you never ever tried to build yourself because you wold knew that it is broken. Btw I hope you are aware that C and C++ are different languages.

Rust has some good ideas indeed and I would happily adopt it if not these hilarious bootstrap issues.

C++'s "design by committee" is more or less the inevitable result of having no alternatives that big, powerful corporations like Microsoft can focus on when they need to justify their additions to their compiler to make it easier for them to maintain whatever they dogfood it on.

If you forced everyone to stick to C, do you really think you could keep those same forces from acting on it to turn it into C++ 2.0?



I'm going to throw a great big "citation needed" at you there, because, with hyperbolic language like "awful mess", "circus", and "infect", all I'm hearing is "Blah blah blah. I'm not a reliable source." ...especially given that I've been keeping an eye on ongoing development since before Rust 1.0 and they seem to be one of the the least circus-like efforts to develop a language that I've ever seen.

I don't know what to cite here. This is just my opinion based on a long period of observations. The rust language development as I can see is "let's keep throwing in all the ideas we ever saw in other languages (yes, there are good ones among them) and then some of our own - the more the better". It well.. just grows into an overcomplicated mess with ugly syntax. The other big part of rust image is it's community with its members behaving exactly as religious sect adepts. Sad and funny at the same time.

[moltonel]

I'm going to throw a great big "citation needed" at you there, because, with hyperbolic language like "awful mess", "circus", and "infect", all I'm hearing is "Blah blah blah. I'm not a reliable source." ...especially given that I've been keeping an eye on ongoing development since before Rust 1.0 and they seem to be one of the the least circus-like efforts to develop a language that I've ever seen.

Our friend jjkk is fueling flamewars in every Phoronix article mentioning Rust. Nobody's denying that Rust has its flaws, but his rants are consistently over the top, grounded in legit worries but devolved into dogma.

The bootstrapping issue is irrelevant for most people but it is real, and the Rust community is addressing it, with projects like mrustc, cranelift, gcc frontends, and language specs. It's not yet as ported as C (being decades older helps), but it is just as portable (the only real exception being hardware where a "byte" isn't 8 bits... which is really rare). Note that if you're creating a new processor today you're not likely to write a "C compiler" for it, you're going to write an llvm or gcc backend, and get all the accompanying language frontends with very little extra work.

Rust (and LLVM FWIW) isn't disappearing any time soon; it's expanding both in scope and in uptake, quickly and consistently. C/C++ are guaranteed eternal life at this stage, but their appeal and market share compared to Rust and other languages keep diminishing. Maybe someday a new systems programming language will emerge that will make people want to ditch Rust. But it'll take many years, so the quickest timeframe would probably be at least 10 years from now. Neither an evolved C nor C++ could be that language, there are just too many fundamentals that would need to break first. Swift with less reference counting and dynamic dispatch ? Zig with more safety and functionality ? A new language developed by a Google AI ? I'm looking forward to it In the meantime, let's use and improve Rust.

[kpedersen]

Well, GCC has been around more than 30 years now

Exactly. And does that compiler infrastructure provide a Rust compiler?

So in 20 years when LLVM is long in the tooth (and GCC is ancient in the tooth), a new compiler infrastructure will be the cool kid on the block. It will provide a backend for C and C++; not Rust.

I guess what I am saying is that the first quantum compiler allowing for a conventional programming language will probably be C, followed by C++. Things like Go, Rust, Java and .NET will remain lagging behind.

[moltonel]

I keep saying that rust is a giant mess because of inability to bootstrap it using C compiler in a clean and reproducible manner.

Against my better judgement, I'll try to reason with you by pointing at one example : the recent mrustc release bootstrapps a rust compiler using C++ code and achieved a binary-identical build of rust 1.30 (from which you can move on to more recent rust versions). including building it for Guix.

And you keep repeating the mantra of rustc which you never ever tried to build yourself because you wold knew that it is broken.

I have built rustc from source out of curiosity, and I don't find it particularly horrible, as far as compilers go.

Rust has some good ideas indeed and I would happily adopt it if not these hilarious bootstrap issues.

I don't know what to cite here. This is just my opinion based on a long period of observations.

The rust language development as I can see is "let's keep throwing in all the ideas we ever saw in other languages (yes, there are good ones among them) and then some of our own - the more the better". It well.. just grows into an overcomplicated mess with ugly syntax. The other big part of rust image is it's community with its members behaving exactly as religious sect adepts. Sad and funny at the same time.

I'm looking forward to you reevaluating Rust with a sceptical, neutral mind.

[ssokolow]

I'll keep this brief, because the other have already said things I'd otherwise day.

Again? Point me where I said that once or this is just another rust sectarian demagogy. I keep saying that rust is a giant mess because of inability to bootstrap it using C compiler in a clean and reproducible manner.

I'm pretty sure that it was here that either I or someone else has already pointed out that bootstrapping any self-hosting compiler is difficult and bootstrapping GCC from a non-GCC compiler is at least as involved as bootstrapping rustc from C++ via mrustc.

As I understand it, GHC (the big name in Haskell compilers, which is also written in Haskell) also does something similar, having a special mode to emit a C bootstrapping shim which serves as an equivalent to mrustc for the purpose of porting to new platforms.

Bootstrapping from somebody else's compiler easily enough to make it the standard approach for compilation just isn't part of the typical design specification for a self-hosting compiler.

Btw I hope you are aware that C and C++ are different languages.

Yes. The comment you replied to was explicitly predicated on that understanding. Specifically, I said that the "C++ is drawing away the 'aid' of companies like Microsoft who want to legitimize whatever hacks they're already using in their own compilers" is the only reason C has remained as simple as it is when it's attained such adoption and ubiquity.

Rust has some good ideas indeed and I would happily adopt it if not these hilarious bootstrap issues.

See my above comment about GCC's "hilarious bootstrap issues".

The rust language development as I can see is "let's keep throwing in all the ideas we ever saw in other languages (yes, there are good ones among them) and then some of our own - the more the better".

Now I know you're full of it, because Rust developers fear the prospect of becoming the next C#, design-wise, and work very hard to do just the opposite of what you describe...as you'd know if you hung out in the RFC discussions and pre-RFC discussions as I do.

(eg. I was the guy who pointed out how my preferred choice out of the proposed syntaxes for inclusive ranges ( ..= ) was to the "less than or equal" operator ( <= ) as the exclusive range syntax ( .. ) was to the less than operator ( < )... and there was a lot of bikeshedding over whether Rust should even have an inclusive range syntax or whether it was acceptable to require everyone to deal with having to work around the special case of having to handle a range which includes the highest value a variable of that type can represent.)

In fact, they take pride in being the language that doesn't embody the latest and greatest, but, instead, gave some overlooked good ideas from the 90s a second chance.

[jacob]

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 personally believe there are two kinds of coders: great coders who know what sorts of bugs can and do occur and will adopt methodologies and tools to help them deal with them, and then there are the l33t Real Programmers (tm) who are too dumb to even understand why their code is buggy.