Rothon posted:

Rust By Example is in a similar style to the Go tour. There's also the Rust Book which a more traditional format.

Rothon posted:

It allows format arguments to be verified by the compiler. You could write the string literal directly to the stdout writer if you wanted to, but it's much more common to just use println!. It's basically equivalent to doing

code:

#include <stdio.h>

int main() {
    printf("hello, world!\n");
}

in C, except that compilation will fail if you accidentally put a format specifier in the string instead of maybe warning and reading some trash off the stack.

Ralith posted:

The author of error-chain has posted a nice introduction to the newest release which reveals that my use of foreign_links above was somewhat less than idiomatic and makes a better case for why it's worth using beyond saving boilerplate.

Ralith posted:

You can chain_err any Result type if you have the symbols from a module containing an error_chain! invocation in scope. The method comes from a macro-generated ResultExt trait, and it returns the type of Result defined by that macro. For simple command-line tools, I often just have "error_chain! {}" at the top of the file so I can provide nice detailed information-preserving textual error messages everywhere.

Ralith posted:

The tools I've been writing recently wouldn't make much sense to share, but I hear ripgrep is pretty neat. If you're looking for examples of error-chain use specifically, the best I can do is suggest you page through the reverse dependency list. Maybe Xargo?

Ralith posted:

You can explicitly specify type parameters by calling a function with syntax like "parse_from_bytes::<MyMessageType>(m)". You may also get better results from inference once you've actually entered some cases that entail a specific concrete discriminant type.

Alternatively, you could switch to cap'n proto!

I assume you're aware that in real code you shouldn't call unwrap like that, and should instead define an error type which can clearly express/embed the cause of a failure, for example using error-chain.

Asymmetrikon posted:

I think my least favorite thing about refactoring so far has been trying to isolate parts of a chain of iterators. The result of a .map().filter().whatever() has a gnarly result type.

Sagacity posted:

I think this is a pretty bad idea too but, to be fair, languages like Java do a ton of this stuff at compile time too, e.g. Jooq. What I dislike most about macro based DSLs is that inevitably they will end up like C++-style template monstrosities that are poorly documented and where there is no hope of sane autocompletion.

Ralith posted:

Procedural macros should generally be the exception, at least once declarative macros 2.0 lands. Hell, any kind of macros at all should be the rare exception, much less complicated ones. It's good to have escape hatches in a language, even if some people will always be tempted to treat the escape hatch more like a revolving door.

Beamed posted:

VS code shows me compiler/syntax errors immediately,

quote:

lets me ctrl+click into library code to read some APIs,

quote:

in-built terminal

Beamed posted:

Nope, don't get this.


FAKEDIT: By the time I finished adding that to imgur and writing this post, it finally showed a red line. That.. I dunno, took awhile to recognize when I added the semicolon too. Doesn't spot the type error, either way.



Didn't say that IntelliJ didn't have these features, just meant to say VSCode supports the most necessary things pretty quickly.

REALEDIT: Perhaps ironically, I feel like IntelliJ will be the way to go in the future; the more fully fleshed out features it provides will be better than I think RLS will support.

Khorne posted: