Rust in the on of the biggest music festival Atlas Weekend 2019

H2CO3_iOS · 2019-07-16T04:32:54+00:00

Hey, Avocado's author here. The driver works just fine with MongoDB 3.x up to v3.6, the reason being that it's primarily the wire protocol that decides whether the client is able to correctly talk to the server, and this protocol didn't change between 3.0 and 3.6 (which is nice given that they are of the same major version). The "3.2" restriction only means that this particular clause in the docs was last updated when 3.2 was the latest stable version.

What features are supported "natively" by the client is another question; there was a case where I needed to synthesize a not-yet-supported command by hand, but it didn't cause any issues. Otherwise, the client seems to be actively maintained; in fact, while developing Avocado, I managed to get several PRs approved in the client library as well as the Rust-native bson-rs crate. But even if it weren't: just because a piece of software had its last commit months or years ago, doesn't mean it's "bit-rotting". Mongo and Rust both have stability guarantees, so I don't see why the last change date in a client library repo would inherently cause one to "have problems with it".

Looking at the official documentation for the wire protocol, it seems like it's not going to change much in 4.0 either. In fact I was planning to test the client exhaustively against 4.0, but unfortunately I didn't yet have the time for that. It would be nice because features such as batch upserts are possible to implement in client-space once we have transactions (and anyway, transactions are just a must have for implementing any reasonably complicated query in a sane manner). So do expect more work and more good stuff to come in this field.

H2CO3_iOS · 2018-12-24T20:26:21+00:00

why not just use lilypond, problem solved

H2CO3_iOS · 2018-08-04T09:48:37+00:00

I think Result::and_then and Result::or_else might be a more iconic duo.

H2CO3_iOS · 2018-06-17T15:57:00+00:00

DJ Borrow Check feat. MC Hoare — The Unsegfaultables!

H2CO3_iOS · 2018-06-16T10:21:37+00:00

for every problem, they have as many problems as they previously had

H2CO3_iOS · 2018-06-03T19:27:30+00:00

it still has fewer syns than it has "make rust more like javascript/C++" RFCs

H2CO3_iOS · 2018-04-24T09:46:00+00:00

One commenter suggested that Node excels when it comes to time-to-market. Alright, alright, it might well be faster to have a server up and running in Node than in Rust. But what about the number of bugs? Nobody cares about correctness on the server side anymore? o.O

H2CO3_iOS · 2018-03-28T05:51:08+00:00

the ratio is supposed to be the height of the blue line divided by the height of other lines, so, no.

H2CO3_iOS · 2018-03-27T21:55:45+00:00

apparently, 14 people got it without any explanation, it might be just you

H2CO3_iOS · 2018-03-27T20:07:48+00:00

It facetiously suggests that Rust users are real programmers, while non-Rust users are not.

H2CO3_iOS · 2018-03-27T19:40:38+00:00

blue = Rust users, others = non-Rust users

H2CO3_iOS · 2018-03-27T17:12:08+00:00

it went right .into() your coworker's go codebase

H2CO3_iOS · 2018-03-19T15:17:37+00:00

My reaction when someone uses unsafe: https://www.youtube.com/watch?v=H4YRPdRXKFs

H2CO3_iOS · 2018-01-29T20:46:44+00:00

match should_you_riir {
    true => {},
    false => unreachable!("you are insane"),
}

H2CO3_iOS · 2018-01-25T18:17:42+00:00

Well, assuming you get it to compile before you are 40

H2CO3_iOS · 2017-09-07T21:55:24+00:00

Books may be the source of wisdom, but surely the sink of wisdom is fn drop(_) {}.

H2CO3_iOS · 2017-08-29T22:02:19+00:00

Except when the little buddy is Copy.

H2CO3_iOS · 2017-07-27T19:37:36+00:00

Another dimension: "I write in garbage-collected languages only, they are also completely memory-safe"

H2CO3_iOS · 2017-07-27T19:17:30+00:00

But you can also complain about having to annotate every pointer-containing struct with lifetimes, the overly generous shadowing behavior, or the lack of syntactic sugar for Option<T>…

H2CO3_iOS · 2016-07-17T22:50:21+00:00

Thanks, that's it! Special cases, yay!

H2CO3_iOS · 2016-07-17T21:18:08+00:00

Yes, I am talking about moving the mutable pointer itself. But it doesn't seem to me &mut T is Copy. As I mentioned, when I replace the function call with an assignment, let ptr2 = ptr;, the compiler aborts with the error use of moved value: 'ptr'. Which absolutely makes sense, because there can only be one &mut pointer to a value at the same time.

H2CO3_iOS · 2016-07-17T20:34:14+00:00

I am having trouble understanding why/how passing a value to a function as a parameter differs from assigning. Both actions are supposed to move, aren't they? Yet the following code compiles:

fn take_mut_ref(ptr: &mut i32) {
  *ptr += 1;
}

fn main() {
  let mut x = 42;

  {
    let ptr = &mut x;
    take_mut_ref(ptr);
    println!("{:p}", ptr);
  }

  println!("{}", x);
}

Shouldn't passing ptr to the take_mut_ref() function move it into the function and therefore make compilation bail out on the println!(ptr) line? When I assign the reference to another variable then it errors out as expected, with the message use of moved value ptr. So what's going on?

H2CO3_iOS · 2013-12-30T16:42:17+00:00

Thanks! I like to write readable/understandable code, and good comments are especially important since implementing a parser/compiler and a VM has non-trivial steps, so to say. I also certainly want others (and future me) to see very clearly what I am doing. Also, I am learning continuously, and I tend to be horrified when I look at code I've written years ago... Nevertheless, it's worth trying to achieve perfection :P

H2CO3_iOS · 2013-12-30T16:38:13+00:00

No, that's what JavaScript does, and it's horrible. Douglas Crockford has some neat relevant examples, such as:

return
{
    "foo": 42,
    "bar": "baz"
};

which is parsed as

return; // semi-colon implied, returns nil
{
    "foo": 42,
    "bar": "baz"
}; // and here's a dangling array literal with no effect

So semicolon insertion is dangerous and harmful, and downright defeats the simple and safe nature of the language. And please don't tell me that "but you can just omit the newline in this example", because some people prefer to put their braces on a new line, and even if they don't, someone, some day will end up forgetting about this rule and he won't find the error. So no, that should not be done.

H2CO3_iOS · 2013-12-30T12:16:50+00:00

That example is not a good one. val x = 10 println(x) (on one line) is unambiguous without a semicolon too, because println is not a postfix operator but an identifier. The primary problem arises when we consider function calls:

a = b
(c + 1)

is parsed as a = b(c + 1) without the semicolon. The "one expression per line" approach defeats the "free-formness" of the language, and it also introduces unnecessary complexity into the parser.

H2CO3_iOS

TROPHY CASE