markus2012

If you follow the best practices for using Cargo you don't have a Cargo.lock file for libraries.

This means your library tests will not be deterministic.

Using the Cargo.lock file for libraries does solve this, but then every binary package you build that references your library will have to be specifically tied to the versions in the library.

We do this internally because it's the only way to provide deterministic builds over time.

Over time I suspect it will get harder and harder to keep this rigid web of dependencies working.

One thing we might try is to enforce the rule 'no library will contain any tests'. At first glance this kinda makes my skin crawl, but maybe if we could find a way where every project that used a library could somehow share the tests for that library it could actually work.

git submodules might actually be able to provide these tests for each binary package. If only git submodules would stop corrupting our git repos... :-(

Well, now you can do that in Cargo as well :-)

What we do currently is we lock everything to an explicit version - even libraries.

At least it's possible to get deterministic builds if you are willing to do a bit of work carefully / manually updating all of your dependencies at once.

I built myself a setup like this a few years ago. Everything about it seemed glorious - but I soon started having trouble with the back of my head.

I never noticed how heavy my head was before. I started to have dizziness problems because of blood flow issues and gave it up.

I am really curious if anyone here has tried it for some long stretches for a couple of days - and if they had any issues with dizziness or not.

I haven't read anywhere that they failed. Isn't the timeline:

- Akamai mitigates attack just fine

- After the attack is over, Akamai does the cost/benefit analysis and decides to stop providing the free service.

The first day in radar class the instructor put a piece of steel wool in front of a small dish and it instantly melted white and dropped molten metal onto the floor.

It always made me nervous when the class goofballs turned the horns on other people so you could feel the microwaves.

Goofball 1: 'accidentally' radiates goofball 2 Goofball 2: What? What are you doing? Oh, I'll show you - just watch me increase the power on this baby...

It turns out your testicles and eyes are a bad place to receive microwaves.

I submit to anyone thinking of attempting this: you are probably going to get the power calculations wrong and cooking human cells is not fun at all.

I think it's an inside joke:

2 people bet each other a dollar they could take a fundamentally simple concept and wax poetic insanity around it until the text was so insane no one could actually read through it - so people just shrug, wash the virtual slime off and move on. Their will power so drained by reading the BS they can't even be bothered to complain.

Then comes the fake accounts to gush how 'serverless' and 'function-as-a-service' are completely new and different and awesomer bra.

The next bet will probably be "mathematicsless": how we solve collision detection without math - and you should too!

Amazing Rust announcements (core and third party) have been coming in constantly for quite a while now.

So much win.

Yeah, I can't help but feel like I'm just 'walking the spreadsheet'.

I do find helping my kids to 'save the world' is still enjoyable!

Losing to my 12 y/o daughter at Rocket League (seriously trying my hardest) makes me wonder WTF is wrong with me.

Lol... sometimes I think 12 year old kids should be tasked with figuring out the hardest problems.

As part of a recent project I had to: - build an AST from a large and complicated DSL - transform the AST into something that could be compiled into a DSO.

I chose to write both parts in Rust. Fwiw the semantics of the language really didn't match Rust at all (though, I suspect you weren't thinking of DSLs when you wrote your paragraph).

In the end I had all the benefits of _safe_ Rust when compiling the transformed code into the DSO.

This DSO is a critical component and can not fail. I can't imagine transforming the AST into C or LLVM - I wouldn't be able to sleep at night. I'm only human; I know I'd fall into a number of traps that humans fall into when coding in C - especially when I am _generating_ C from an AST...

Your 8-bit adder will have to wait ~225 CLKs (possibly x 2) to get the data it needs to add.

Add a ton of transistors to intelligently prefetch and cache will in some cases decrease those 225 CLKs.

A great deal of transistors are added to cache and cache intelligence to get around the terrible latency of DRAM.

Where I work client auth is used for a good (and growing) number of internal services.

Client auth is simple to use - our internal services are given the username from the CN, which they use to perform authorization checks. For a lot of simple internal services that don't require two-factor auth it works great.

Am I missing something better?

(We already have the infrastructure in place to deal with client keys)

I'm just now completing a rather large event-driven system in Rust. It's also callback-based and has to interoperate with C.

I do struggle with the ownership rules sometimes but it's pretty much always because I'm clashing with the bad habits I learned coding in C/C++, or I'm shooting my future-self in the foot because my limited cognitive capabilities can't always keep all code paths in memory perfectly all the time.

The borrow checker came with an upfront cognitive cost that ultimately saved me from multithreaded async I/O madness later on. I can sleep at night knowing my multithreaded async system is more sound and easier to safely extend/maintain than it would have been had I created it in C/C++.

I can see why some people might give up on Rust. In C++ you can take the easy way out (use mutable aliasing etc.) and you can quickly get things 'working'. You don't have it so easy in Rust because you have to carefully think about end-end ownership.

Also in Rust I found that when I did make bad design decisions it was sometimes a lot more work (redesigning structs, shifting ownership responsibility) than it would have been in C/C++ (because I probably would have laid land-mines for my future self by mutably aliasing things etc.).

I quit doing the survey when I read the color question.

If you had worded it something like, 'do you feel welcome' I would have answered (yes) and kept going.

So... build more detectors and pinpoint the direction the gravity wave is coming from?

Memory is terribly expensive and I have to fight all of the other developers/product folks/upper management for every byte in my environment (hundreds of thousands of servers).

I have no choice but to use DSOs for our Rust code.

I wonder if times are changing again. It just seems that meeting vendors or walking down the street for resistor strips is no longer necessary.

Rationale: you now just need to bulk order the raw materials / components and "feed the machine".

We aren't there yet, but jeez we seem to be racing there quick?

Incredibly impressive!

I solved this. The center required all of my soldiers to be maxed out, and all of them carrying lasers. Iirc... it feels like several lifetimes ago...

I'd give it a go but after moving about 15 times there's no way I have that CD.

What about for using it as a headless browser with javascript and Rust manipulation of the DOM?

We have a http proxy that would like to analyze html responses and rewrite parts of the page.

Is servo ready for that or should we use something like PhantomJS?

Thanks!

I've always felt that if I had done all of my calculus with Mathematica I would have left college with an excellent grasp on how to use higher level functions provided by Mathematica that would have largely abstracted away all of this.

Of course, the higher level functions might get covered in cobwebs - but I suspect not the same way; I would have kept these higher level skills up to date because:

- I recently went though a couple of books on Bayes and computer vision. I would have used Mathematica - refreshing my memory. - I sometimes need to do some stats / analysis - Refresh... - I recently picked up a Student's guide to Maxwell's equations - Refresh... - I need to help my children with Calculus...

If I had been using a high level tool my whole life I think I actually would make use of calculus and other mathematics.

I'm curious if anyone else feels the same.

I randomly lie about my gender, age, and anything that could be used to identify me. I learned this from others, and have also encourage my spouse/children/etc. to do the same (which they seem to do).

There is no compelling reason for me to provide any real information about myself online.

Related: we're wondering how to use Rust because currently all non-Rust dependencies in our org are pulled from:

- corporate source code control systems

- corporate central repositories

- caching/proxying immutable repositories

These ensure all projects are built from known sources. We _know_ we can get consistent builds.

When using Cargo:

- Project owners update projects and don't bump the version. New bugs / security problems could be injected even though we haven't changed a thing internally.

- crates.io isn't always up.

- Trust: we legally can not trust (PCI compliance violations - 2015 rules (viral) ) the public crates.io repository. Besides PCI compliance, it's not possible for crates.io to guarantee perfect security (so many reasons, obviously).

* I'm hoping folks who have addressed this issue (or are addressing it, or are planning on addressing it) would comment.

Ok, just to summarize:

foo(some_struct) == memcpy() for both copy and move.

foo(&some_struct) == copy usize ref/pointer value onto stack

So, mostly the same as C++. The exception is that Rust can use a ref under the hood for foo(some_struct) if it wants.

Here's something I find confusing about Rust references/borrowing. Please correct me:

The '&' character does not seem to mean 'pass by reference' ala C++ - it simply means borrow. Put another way, using '&' is not forcing the compiler to pass a 64-bit pointer reference - Rust will ALWAYS memcpy() the params.

Rationale: existing Rust documentation states that both copy semantics and move semantics are implemented with memcpy(): http://doc.rust-lang.org/std/marker/trait.Copy.html

The only way to pass a reference (like C++) to a function seems to be by using Box. This way Rust can memcpy() the Box struct - which is essentially a unique pointer to some memory on the heap.

It works(?) this way because the called function may spawn a thread that depends on one of the params. If such param was a reference/pointer to something on the caller's stack and the caller's stack was unwound the reference would be invalid.

I realize the borrow checker should be able to determine all of the lifetimes and it should be able to pass pointers to data on the caller's stack in some cases. Does Rust do this?

I completely agree. unwrap() is a huge mistake in Rust. There are brilliant ideas implemented in Rust (primarily the borrow checker) but their advantages seem to be wiped out by the kludge of unwrap.

What bout HSAIL / LLVM: https://github.com/HSAFoundation/HLC-HSAIL-Development-LLVM

(HSA Intermediate Language LLVM support)

It would seem an IR is already available and it's already integrated on an existing LLVM branch. From skimming around it seems AMD has been working hard to do what is necessary to get things merged into LLVM mainline.

<quote> My highest priority is to get the backend upstreamed as soon as possible, so I would appreciate feedback about any kinds of blocking issues on that.

Thanks

Matt Arsenault </quote>

http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-May/085545.h...

It seems AMD's Kaveri CPU implements HSA.

Some HSA benchmarks from AnandTech: http://www.tomshardware.com/reviews/amd-a10-7800-kaveri-apu-...

Note: the tests seem to use OpenCL and while they mention, "Looking at the HSA-based results..." I find it strange they are comparing the numbers against an Intel Core i3.

It might be more interesting to compare OpenCL HSA vs OpenCL non-HSA.

Completely disagree.

What helps today is skipping the translation phase (syntax checking only) using rustc -Z no-trans.

This makes the edit/fix syntax cycle 20x faster.

A way to configure this in vim: https://www.reddit.com/r/rust/comments/3kc6s7/fastest_editco...

bug?

- (click) Clean text using regular expression

- Load external lib: https://vega.github.io/datalib/datalib.min.js

  - Impossible (because there is no 'load external lib' functionality)

I have also switched to Rust for backend work.

I'm using Iron instead of Nickel. Not sure who will become more popular over time...

Because of the language (no null, bounds checking, option/result types, etc.) and borrow checker I find I rarely have to 'hot reload' or even test my code. I realize that sounds surprising. I'm not doing any HTML templating in Rust - that's better done in JavaScript on the client - so I don't have the edit/compile/test cycle for every tweak to the UI.