"hello world" contains Lovecraft quotes

[pcwalton]

Yes, really

[alexcrichton]

It looks like this is 2640 bytes of lovecraft quotes in each exectuable (out of 469320, 0.56%). Perhaps it's not so bad?

[thestinger]

2k is pretty bad, because a hello world binary should be ~10k at most. It's not the lowest hanging fruit right now but it will become a bigger fish as we fix the other problems. I think it's an indication of a larger issue rather than being a problem itself though...

[pcwalton]

I think there is no defensible reason to have that text in every executable.

[nddrylliog]

And thus poetry was killed...

[bharrisau]

Not particularly new - 29ad8e1 and 51abdee

[adrientetar]

2K? So that's what 2014 is about?

[thestinger]

@adrientetar: If you want Rust to be taken seriously as a systems language, you have to worry about that. It's not acceptable in many embedded environments for binaries to be this large. It makes the language unusable without writing the entire standard library again. It's fine for it to be in the standard libraries... just not every binary linking against them.

[tbu-]

Should be fine until other sources of bloat are removed.

[thestinger]

The problem here isn't the quotes, it's that the code containing the quotes is used or considered used at all. It's the canary in the coal mine. I'm sure we can cut down the runtime overhead to something much smaller, including getting rid of this.

[rcxdude]

It's not unreasonable for it to be considered used, considering it's part of the abort code, so even a trivial program might trigger it (e.g. on OOM, stack corruption, etc). Personally I'd add a no_horrors cfg option or something to disable it in the rare cases where 2k is considered important, unless the potential for user confusion is considered to great to keep the behaviour at all.

[thestinger]

It's not rare for people to compare the size of the binaries to C and decide against using Rust for their use case due to it being very unfavourable. You shouldn't have to compile Rust again to disable debugging features useful only to the developers. This is only the runtime abort code, it's not the generic abort which isn't even a function call.

Runtime errors should report real errors, and logic errors should be dealt with by improving the code so redundant checks aren't necessary in the normal release builds. It can remain around in a build that's not for regular end users... the code paths calling this just need some work to remove the need for debugging stuff.

[steveklabnik]

Yeah but I love it though :( Hehe.

[bstrie]

I also love it, but it's more important to be professional and chuck it out. Let's not make this Rust's equivalent to T_PAAMAYIM_NEKUDOTAYIM. Easter eggs are fun, but they have to have literally zero impact on users.

[IDisposable]

The key question isn't "is 2K big or small". The key question is "what value does this add".

[ghost]

Keeping these as default isn't very professional for many reasons, but I think value would be lost if lightheartedness was removed from Rust as a continuing policy. I've been amazed at how many people become interested in the language after I link them the abort messages in question. A human touch to the compiler output goes a long way.

How about a '-fun' flag that enables easter eggs being compiled in?

[adrientetar]

How about a '-fun' flag that enables easter eggs being compiled in?

Sounds a bit ridiculous tbh. The point of an easter egg is to have it everywhere, not to compile it purposefully.

[ghost]

Perhaps, but I'd argue the main point of an easter egg is to be entertainingly surprising. A flag enabling them wouldn't give away when they happen, just discourage unpleasant surprises. Wild Wasteland for a compiler.

Another option would be to strip the messages when optimizations are enabled. -O equals -nofun.

[liigo]

That's funny, wordy and mawkish. "what value does this add"? Nothing.
I'd vote +1 to remove them entirely.

[cvkline]

Besides Lovecraft, I see tons of text obviously related to assertion failures and references to my build directory. I assume there is a lot of debugging code left in the compiler and libraries that will eventually get turned off in a production compiler, yes?

[mjbshaw]

Am I the only one that's going to bring up copyright issues?

I work for a company that thoroughly reviews code with lawyers that will ban any and all uses of software that are even questionable in terms of their license or copyright issues. You might claim embedding these quotes (and without attribution) is fair use etc, but all it takes is for one of my company's lawyers to disagree with your conclusion and suddenly Rust is banned from use in the company.

I understand and appreciate the value of having some fun with a project, but these quotes:

1. Add unnecessary overhead to executable size and memory (and yes, in real life I work on embedded systems where a few k can make a difference).
2. Alienate potential users because a zealous lawyer has concerns regarding the quotes and bans Rust "just to be safe".

[steveklabnik]

Am I the only one that's going to bring up copyright issues?

Lovecraft's works are basically public domain, it's not a problem.

[bpicolo]

To be fair, pretty sure copyright is the wrong case to make. Lovecraft's works are in the public domain.

Edit: Dang, Steve beat me to it.

[adrientetar]

It's not acceptable in many embedded environments for binaries to be this large.

Won't the embedded environments you speak of use libcore?

[mjbshaw]

Lovecraft's works are basically public domain, it's not a problem.

True, but it wasn't Lovecraft's quotes I had in mind (but I probably should have been more specific because this issue specifically mention's Lovecraft's quotes and doesn't mention Zelda quotes).

I know I'm being a bit paranoid here when I bring up copyright stuff, but I'm not kidding when I mention zealous lawyers laying down strict rules...

[MattWindsor91]

This is only the opinion of a user on the outside looking in, but I'm not sure there's any sensible reason for this being in-- at best it's a waste of space and code, and at worst having Lovecraft spouted during an abort() could be seen by the user on the receiving end as being in poor taste. (Speaking from experience a month or two ago, when a build of rustc abort()ed after ages of tring to compile it)

[MatejLach]

I think that it should remain in. It sort of reminds people who stumble upon this that rustc has indeed been built by real people :-)
I also don't think that it is somehow "unprofessional", every program I ever came across has some sort of an easter egg in it,including Git, (starting with its name).
Having this compile only with a certain opt in flag kind of defeats the purpose, but maybe a flag that can explicitly opt out of this kind of thing is worth having for embedded developers.
@CaptainHayashi There's no sensible reason apart from having some fun, I think that's enough of a reason, but opinions will differ.

[thestinger]

It's not part of rustc, it's part of the runtime and is included in every Rust program without #![no_std].

An easter egg like this in rustc is different than putting it in every Rust program.

[Gankra]

I suggest its removal simply be the christening commit of 1.0-stable.

[MattWindsor91]

@gankro yesssss

[franc0is]

To those of you saying "2k, in 2014?" I will point out that there are a lot of platforms out there where 2k is still a big deal. If Rust is going to work for embedded systems work, you can't pull tricks like this.

[steveklabnik]

@franc0is those would not be using Rust's runtime anyway, and so would not have this in it.

[alexispurslane]

Why should we have poetry in a binary executable generated by a supposedly serious, non-esoteric programming language? One would think this wouldn't even need to be a discussion...........

[franc0is]

@steveklabnik that is not necessarily true. As I understand, the runtime is getting slimmer and slimmer with every RFC.

[MattWindsor91]

@ChristopherDumas aye. To my tastes, this sort of easter egg belongs in the compiler/toolchain, not a statically linked stdlib.

[MatejLach]

@thestinger True, it probably shouldn't be part of the runtime.

[stuartpb]

An embedded gag that only comes up when the program is frustrating the user with a catastrophic error? What could possibly go wrong?

[vgel]

Honestly, as someone outside the Rust community, seeing this puts me off using the language. I'm a Lovecraft fan, and if this was an easter egg in the toolchain I would love it, but embedding this statically into all the binaries I ship to end users is a step too far. There's a lot of negative interpretations a snooping end-user could get from finding these quotes talking about things dying and gods in the binaries (and running strings on a binary isn't exactly difficult). That negative interpretation would fall on me, who they see as the developer, not the Rust team, who they probably don't even know exists.

Rust is a tool. If my table saw has a tiny inscription on the underside with the name of the engineer who designed it - that's neat, a fun homage, and overall great. If my table saw contains a tiny router that engraves that engineer's name onto every piece of wood I cut with it - not so great. It degrades the quality of the tool. While I appreciate the entertainment value of the quotes, I think moving them into a developer tool like the Rust compiler would maintain that entertainment while also not degrading the quality of Rust by inserting unwanted data in generated binaries.

[gabrielecirulli]

@Rotten194 That's an incredibly fitting analogy.

Here are a complete outsider's 2 cents: why not change rustc instead to display a funny (or lighthearted) quote when something goes wrong, to sort of alleviate the pain of having your compilation fail? Of course, it shouldn't get in the way of you solving the issue (or it would be even worse), but if it manages to have some "decorative" value, I think it would be a perfect middle-ground between getting rid of this easter egg entirely or moving it to a more sensible place.

[marcoms]

I am very much in favour of removing the quotes. Put the quotes somewhere where humans will read them, not machines