Follow

I'm only on chapter 2 of Rust's "The Book" and I'm already seeing things that I like more about Rust than Javascript/NodeJS.

Example: How Rust handles variable interpolation within string literals

@brandon

> I'm already seeing things that I like more about Rust than Javascript… Example: How Rust handles variable interpolation within string literals

Interesting. I like nearly everything about better than , but I'm not sure I'd put that on the list. I think I prefer

function greet(name) {
return `Hello, ${name} how are you this fine ${timeOfDay()}?`;
}

to

fn greet(String name) {
println!("Hello, {}, how are you this fine {}?", name, time_of_day())
}

@codesections @brandon

and rust is particularly annoying if you use named substitutions:

fn greet(String name) {
println!("Hello, {name}, how are you this fine {time}?", name=name, time=time_of_day())
}

I sometimes use the ifmt crate for this, then you can do similar stuff to the JS version

@piggo @codesections I didn't yet know you could do named subs 🤔 I still prefer index mentions like my previous toot: {}1, {}2, or {}a, {}b

@brandon @codesections you can put numbers in the {} to indicate which one you are replacing. you can also use {:.3} and such for printf-style transformations, it's very powerful if sometimes annoying

@piggo @brandon

In contrast, I've been writing more lately, which has ~15 different ways to write strings, allowing pretty fine-grained control over interpolation. docs.raku.org/language/quoting

(I believe someone mentioned something about there being more than one way to do it?…)

The basic equivalent, though, would be

sub great($name) {
"Hello, $name, how are you this fine &time-of-day()?"
}

Which seems pretty clean to me!

@codesections @piggo *sounds* like a security risk, just because I know there are some real sloppy devs out there but I don't see anything too bad with that. Question of preference of course

@brandon @codesections seems fine if it doesn't magically happen to strings loaded from user input and such

@piggo @brandon

> seems fine if it doesn't magically happen to strings loaded from user input and such

Yeah, no magic or interpolation of user input. (Well, unless you use `EVAL` and then a) you probably know what you're doing and b) you get the following error:

> ===SORRY!=== Error while compiling:
EVAL is a very dangerous function!!! (use the MONKEY-SEE-NO-EVAL pragma
to override this error but only if you're VERY sure your data contains
no injection attacks).

@codesections I prefer rusts way of doing it simply because it's not extremely obvious at first glance that those are backticks rather than single quotes.

I feel like there are some who may get tripped up by something like that.

Though I might make a single change to Rust's implementation in that I would prefer some sort of indication as to the enumeration of variable being used. Ex: {}a, {}b, {}c, and so-on.

It would be more obvious at a glance which variable is ref'd in longer pars

@brandon
Oh wow, I was looking at that example and wondering, if they didn't have a way to activate substitution, because I didn't see those backticks at all. Sure, if you know it, you might spot it more easily, but yeah, I see your point.
@codesections

@codesections
I usually find specifying the parameters at the end more readable, because you generally know from context what's going there, so when there's just "{}", my brain fills in the blank and continues reading.

With the in-place substitution, you get weird punctuation marks in the middle of a normal sentence, and the description of a thing is just not the same as a concrete value, i.e. it trips my brain up when it reads "Hello, name, how are you this fine time of day?".
@brandon

@codesections
Also, anecdotally, you missed the comma after ${name}. You might not have cared too much about writing it correctly here, but yeah, I just find these kind of mistakes happen less when you don't have a ${name} in your sentence.
@brandon

@brandon great news! I'm actually on the fence between Rust and Go for my next language, coming from a Python background.

@kzimmermann I have a bias coming from open source in sort of preferring Rust due to it being developed mostly(?) at Mozilla rather than Golang which was developed mostly(?) by Google

But I would say go with Rust (almost capitalized the word go there :P). The culture seems pretty laid back in comparison to Golang circles. That's just been my experience though

@brandon alright, that's some good insight! Maybe I'll look into Rust with a little more detail in the coming weeks. It's time I brushed up and tried a language that's a little lower level at last.

Sign in to participate in the conversation
Fosstodon

Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.