Look, I changed the title now

[pie_flavor]

@Tsaukpaetra said in Time element not allowed in HTML:

@pie_flavor said in Time element not allowed in HTML:

@Tsaukpaetra that's all? What's confusing about Rust syntax?

Make a new thread.

Okay, now what?

[Tsaukpaetra]

@pie_flavor said in Re: Time element not allowed in HTML:

now what?

You didn't even change the title? Whatever.

First complaint: abbreviations. For everything. It's like the authorsomeone said, "You know what? int32 is too verbose! Let's make it i32! Public? Fuck too many letters, it's pub now! But derive? Nah, that's fine. Have fun guessing what serde means!"

Confusion A: What's the difference between ref and & and &' ?

Annoyance Init: Why does println need a bang? What even?

[pie_flavor]

@Tsaukpaetra said in Re: Time element not allowed in HTML:

@pie_flavor said in Re: Time element not allowed in HTML:

now what?

You didn't even change the title? Whatever.

First complaint: abbreviations. For everything. It's like the authorsomeone said, "You know what? int32 is too verbose! Let's make it i32! Public? Fuck too many letters, it's pub now! But derive? Nah, that's fine. Have fun guessing what serde means!"

It takes you two seconds to learn the abbreviations, much less than it will then take you to type out all the letters every time you use it. I sure name my variables id instead of identifier. Not that terse abbreviations are something to strive for; merely that, unless they're not totally obvious, they're not something to particularly complain at.

Serde is a general-purpose serialization/deserialization library. https://docs.rs/serde/ It gets exempted from the 'not totally obvious' part because it is a library name; it is a universal constant of programming that libraries are named something confusing and stupid.

Confusion A: What's the difference between ref and & and &' ?

&' isn't syntax, but 'foo is the syntax for defining lifetimes, i.e. what scope something lasts for/gets dropped at the end of. This goes after the & in a reference, or as a generic parameter. Most of the time they can be inferred; occasionally you need to specify them. 'static is the lifetime for statics; a reference stored in a static variable needs to have a static lifetime for obvious reasons. The 2018 edition was released after I wrote that code; most of the time you don't need 'static anymore since it's inferable.

ref is the syntax that the authors of lazy_static chose to use (personally I'd have made it static lazy instead of static ref), which is likely the use you're talking about; the actual use is something to do with pattern matching which you almost never run into.

Annoyance Init: Why does println need a bang? What even?

println is a macro, not a regular function. This is because of its need for both variable-type varargs and its compile time resolution and syntax checking. Anything with a bang on the end is a macro, to distinguish them from functions. Like lazy_static!, or rt_write!.

[Tsaukpaetra]

Okay cool? I guess?

@pie_flavor said in Look, I changed the title now:

inferable

Oh, so var on steroids then? Just what I want: More guesswork on what something actually is and where it's valid. Perfect.

[pie_flavor]

@Tsaukpaetra Rust inference is really good. If it can be figured out, the compiler figures it out. Pretty much the only times when you need an explicit lifetime is when a struct contains a reference, when implementing a trait designed to account for the former, or pre-2018-edition static strings.

[TheCPUWizard]

@pie_flavor said in Look, I changed the title now:

It takes you two seconds to learn the abbreviations,

And when looking at a language I do not regularly use, that "two seconds" really multiplies into (potential) comprehension issues [I have 120 seconds to look at 100 lines of your code]

[pie_flavor]

@TheCPUWizard said in Look, I changed the title now:

@pie_flavor said in Look, I changed the title now:

It takes you two seconds to learn the abbreviations,

And when looking at a language I do not regularly use, that "two seconds" really multiplies into (potential) comprehension issues [I have 120 seconds to look at 100 lines of your code]

@pie_flavor said in Look, I changed the title now:

unless they're not totally obvious

pub, where visibility modifiers go, is pretty clearly public. i32 is likely blindingly obvious. Various other abbreviations like std and fmt and mem too. I can't think of any abbreviations in Rust that aren't obvious at first glance. By two seconds to learn, I meant to learn to write in that position, not to learn to read.

[Benjamin Hall]

@pie_flavor I know nothing about rust, nor do I plan on learning. But "blindingly obvious" usually isn't, especially to those who aren't steeped in that particular thing. It's something DMs learn real fast--the "blindingly obvious" hints you've been dropping have been completely opaque to the players.

[pie_flavor]

@Benjamin-Hall no less blindingly obvious than double.

[Benjamin Hall]

@pie_flavor said in Look, I changed the title now:

@Benjamin-Hall no less blindingly obvious than double.

And? I happen to think that most type names in C, C++, and such languages are awful. Doesn't excuse rust from making the same mistake. In fact, since rust has no legacy baggage, it gets even less of a pass on this one imo.

Anyway, assuming some piece of jargon is blindingly obvious is most frequently a symptom of nerdview, the same form of unthinking blindness that leads to bad and confusing road signs, jargon-filled instructions to normal users, and other forms of user-unfriendly behavior.

[pie_flavor]

@Benjamin-Hall Rust at least has consistency - letter representing type, then the number of bits. So double becomes f64.

[Jaloopa]

@pie_flavor said in Look, I changed the title now:

double becomes f64

Blindingly obvious

F64 sounds like a car model

[topspin]

@pie_flavor said in Look, I changed the title now:

@Benjamin-Hall Rust at least has consistency - letter representing type, then the number of bits. So double becomes f64.

The real inconsistency C has isn’t that double is used for a double precision float, but that, unlike long int, it’s not shorthand for double float. And obviously long double is worse.

[dcon]

@Jaloopa said in Look, I changed the title now:

@pie_flavor said in Look, I changed the title now:

double becomes f64

Blindingly obvious

F64 sounds like a car model

More like a jet.

[HardwareGeek]

@Jaloopa said in Look, I changed the title now:

@pie_flavor said in Look, I changed the title now:

double becomes f64

Blindingly obvious

F64 sounds like a car modelcamera (lens) setting

[Gurth]

@HardwareGeek said in Look, I changed the title now:

@Jaloopa said in Look, I changed the title now:

@pie_flavor said in Look, I changed the title now:

double becomes f64

Blindingly obvious

F64 sounds like a car modelcamera (lens) setting

For when you want to photograph something right in front of your lens but also have the horizon in focus. On a beach.

[loopback0]

@Jaloopa said in Look, I changed the title now:

@pie_flavor said in Look, I changed the title now:

double becomes f64

Blindingly obvious

F64 sounds like a car model

Knock-off Chinese games console.

[dkf]

@pie_flavor said in Look, I changed the title now:

it is a universal constant of programming that libraries are named something confusing and stupid.

Not true. But all too often the good name is taken by an early library to tackle functionality in an area that turns out to be not very good.

[pie_flavor]

@Tsaukpaetra I assume there wasn't any more confusion then.

[Tsaukpaetra]

@pie_flavor said in Look, I changed the title now:

@Tsaukpaetra I assume there wasn't any more confusion then.

While technically correct, in that there is no confusion if no usage is experienced.... why?