OpenBSD 5.9 released early

New base stations don't typically have options for 11a-only 5 GHz, but 5 GHz capable 11n clients can still connect to older 5 GHz 11a networks. I imagine there is similar backwards compatibility to the other direction even without an explicit configuration option.

Gotcha. I thought the video would have explained this, but since it didn't get through, let me try :)

  fn take(vec: Vec<i32>)

In Rust, the default way that things operate is to _move_. So when you call take(), we'd say that the vector moves into the function.

Moving is always a memcpy. There's no way to change this behavior, so you can always know that it's true. But with a Vec, there's a subtlety: the Vec itself is three words: a pointer to the heap, a length, and a capacity. So when I say that the Vec is memcpy'd, I mean literally those three things. It doesn't try to follow the pointer and copy the data that it points to.

Incidentally, that pointer is why we say that it moves: because two copies of the Vec structure itself would mean an aliased pointer to the heap, the compiler doesn't allow the use of the older binding after take() is called.

For simpler types, like integers:

    fn take(i: i32)

they implement a trait called Copy. This means that when you call take, the i32 is copied, in the same fashion that the Vec was copied. The only difference is that there's no problem with having these two copies, as an i32 is, well, just an i32. So the compiler won't prevent the use of the binding outside the function like it would with a non-Copy type.

References are like pointers, but with the extra static checking that Rust does.

    fn take(vec: &Vec<i32>)

References also implement Copy, and so when you pass a reference to a Vec to this function, the same thing happens as in the i32 case. The reference itself gets copied.

This is sort of a long-winded way of saying that Rust is "pass by value", not "pass by reference." Some people like to call this "pass reference by value", since while it's always pass by value, references are themselves values.

What if we _did_ want to make a full copy of the Vec, including its elements? For that, we have to use the .clone() method.

    let v = ... // some Vec<i32>
    let v1 = v.clone();

Now, v and v1 will be full, independent copies of the same thing. In other words, if you don't see .clone(), it will never be a deep copy.

    let v = ... // some Vec<i32>
    let v1 = v; // a move, always a shallow memcpy
    let v2 = v1.clone(); // a deep copy

You can always see, syntactically, when you're making a possibly expensive copy of something.

Does that help? I'm happy to elaborate further.

> crashes all the time with segmentation faults

We would very much appreciate any bug reports, even if you don't have the time to reduce (if you have filed under another username, thank you!).

> Julia crashes all the time with segmentation faults, sorry, the quality of Julia is super low. I would not use it for anything serious.

I've seen a lot of Julia used in real world scenarios at companies and this is a pretty surprising claim. Segfaults are very rare – much rarer than in code written in C or C++. You may either have a messed up build of Julia or you could be using packages that call C libraries and do so incorrectly – that would certainly cause segfaults.

"There is something to C that I appreciate extremely, and that is the clarity and simple semantics: there is not much hiding and unintentional obfuscation that one can cause when writing C code."

It is pretty straight-forward. However, Modula-2 and Pascal's are even more so as you can represent everything with a simple BNF grammar. There's more consistency, less corner cases, and so on. Every change they make is specifically designed to improve it while maintaining simplicity. The most complicated and modern one can be described fully in around 30 pages [1]. The uppercase and declarations throw people sometimes but keep in mind people used text editors w/out syntax highlighting.

http://www.oberon.ch/pdf/CP-Lang.pdf

re mutually exclusive. Nah, there's still tradeoffs you can make. Cyclone and Rust both do that with better design decisions to allow safe, manual management. At some point, you have to choose one or the other though. Your language design matters at this point where the compiler has to know it can remove a check. C's design is so rough and allows so much unpredictable behavior that this is an ongoing research problem for it. Whereas, it happened with Modula-3 libraries in one academic project and happened for Ada with SPARK.

Re Modula. Oh yeah, it's not updated anymore. I was just illustrating a language as lean and efficient as C that was safer & easier to compile. A better foundation. It was rejected by C users when it did have compilers. Plus, there's a Modula-2 to C compiler floating around the net.

Re Free Pascal and Lazaurus. Interesting feedback. I'll look into that to see if I or developers could remedy it. Except for Emacs: Lazarus is the IDE and better suited. Emacs support might stay dead. Re D. Yes, it's more like C++ but can be used where C is many times. I see you're looking for simple stuff, though. Re Cyclone. It's not simple but not hard either. Remember C is deceptively simple: using it safey is HARD. Cyclone is slightly more complex but way easier to use. Unmaintained, yes, but people (esp GCC or LLVM types) could pick it up any day... if they weren't glued to C. Good call on the Rust connection.

https://doc.rust-lang.org/reference.html#appendix-influences

re Julia. That's not good... re Ocaml. I think you're focusing too much on complexity of semantics vs complexity of effective use. It's worthwhile to increase learning curve a bit to boost productivity, safety, and maintenance. re Haskell. That reaction surprised me and you're the first to call it simple. Ive been holding off cuz it seemed ridiculously hard and different. What did you use to learn it? Btw, I agree fast Haskell is usually ugly but look up Tolmach's Habit programming language. It's on hold right now cuz he had a better project.