Here is my feedback:

1 - If memory management is a serious problem for the software you work on, I've never found the boost library lacking. This seems like the main selling point for RUST. Given the scope of the project: you guys must be doing something that is so different that it couldn't be rolled into a library - so I'm looking forward to your future posts to see if there is something here that I really am missing out on.

2 - I'm not a fan of the implicitness and I personally don't use 'auto' b/c it makes scanning code harder. I guess this is more of a personal preference.

3 - A lot of things are renamed. auto->let, new->box, switch->box You get the feeling that effort was put in to make the language explicitly look different from C++

4 - the Rust switch statement don't fall through... This one was truly mind blowing. The one useful feature of switch statement got ripped it out! If you don't really need the fall through, I'd just avoid using them completely...

5 - I've never really seen an equivalent to boost (in combination to the STL) in other languages (maybe I didn't look hard enough). Could you maybe make a post about the RUST standard library? Libraries are always the deal breaker

To that point, my last comment is maybe a little more wishy washy. The main reason I'm consistently happy with using C++ (and why I put up with the header files) is that everything is available. If you need to do X, and X has at some point been put into library by someone: you can be sure that that library will be available in C++. Since Rust seems so close to C++, does this mean that linking to C++ code is trivial? If I can seamlessly start programming parts of our codebase in RUST, that could potentially make a huge impact.

Memory safety and static checking.

> A lot of things are renamed. auto->let, new->box, switch->box You get the feeling that effort was put in to make the language explicitly look different from C++

* let comes from ML and similar languages (e.g. Haskell), which are a huge inspiration of Rust (e.g. the type system). Furthermore, let is not auto, it does pattern matching, it's not just a limited form of type inference (or it'd be after the colon, where the type goes).

* match is much the same, it's a pattern-matching construct not just a jump table

* box is for placement box, IIRC it's similar to a universal placement new. For instance it can be used thus:

    // looks like it returns a basic stack-allocated value
    fn foo() -> int {
        3
    }

    let stack_allocated = foo();
    let heap_allocated = box foo();

  the second one has no more overhead than if the function had returned `box 3` and a ~int (~unique_ptr<int>) in the first place. This also works for structs, the caller can decide where he wants the return value allocated.

Clearly, some of those folks have worked on ML or Haskell implementations.

Yes, that's the start of it but it was expanded to multiple box classes (and maybe eventually user-defined ones) rather than just boxed and unboxed values: a developer can currently use box(HEAP) and box(GC) (a bare `box` is an alias for `box(HEAP)`)

As a developer that isn't working with C++, I'm finding memory management in C++ to be a nightmare and no amount of libraries can solve it.

Say you receive a pointer from somewhere. Is the referenced value allocated on the stack or on the heap? If allocated on the heap, do you need to free it yourself, or is it managed by whatever factory passed it to you? If you need to deallocate that value, is it safe doing so? Maybe another thread is using it right now. If you received it, but it should get deallocated by the factory that gave it to you, then how will the factory know that your copy is no longer in use? Maybe it's automatic, maybe you need to call some method, the only way to know is to read the docs or source-code very carefully for every third-party piece of code you interact with.

All of this is context that you have to keep in your head for everything you do. No matter how good you are, not matter how sane your practices are, it's easy to make accidental mistakes. I just reissued my SSL certificate, thanks to C++.

Yeah, for your own code you can use RAII, smart pointers, whatever is in boost these days and have consistent rules and policies for how allocation/deallocation happens. Yay! Still a nightmare.

Even if manageable, there's a general rule of thumb that if a C++ project doesn't have multiple conflicting ways of dealing with memory management and multiple String classes, then it's not mature enough.

Here's your problem. In general I don't want to be receiving a single pointer from anyone. Lately, I've found it helpful to think of pointers in C++ as special iterators rather than a referential relic from C. In such a mindset passing pointers around without an accompanying end iterator, or iteration count, just makes no sense. Anywhere that implied iteration count is always a constant, I'm probably not structuring my code correctly.

So my recommendation is to use references (foo&) for passing down (well, up) the stack, never to heap allocated objects. Because you can't use delete on a reference there's no longer an ambiguity. Use smart pointers to manage the heap. Write RAII wrappers (it's not a lot of code) to manage external resources. RAII wrappers are especially useful for encapsulating smart pointers so big things can be passed around with value semantics, which gives you even stronger ability to reason. Implementing optimisations like copy-on-write becomes fairly trivial.

> I just reissued my SSL certificate, thanks to C++.

If you're referring to Heartbleed then OpenSSL is written in C, not C++. Generally only a language that inserts array bounds checks for every access would have shielded you from this bug... C++s <vector> does this if you use the at() function of <vector>, but op[] doesn't by default for performance reasons.

But all of that are patterns of use, enforced mostly by convention. In Rust, that's enforced by the language itself, and violating it will be a compiler error. The following kind of shenanigans won't be allowed outside of unsafe regions:

  int main()
  {
    int on_stack;
    int& ref = on_stack;
    int* ptr = static_cast<int*>(&ref);
    delete ptr;
    return 0;
  }

    void operator delete(void*) {  }

    int main()
    {
      int on_stack;
      int& ref = on_stack;
      int* ptr = &ref;
      delete ptr;
      return 0;
    }

Passing around two iterators is still not safe, due to iterator invalidation.

Memory safety in the C++ model is a hard problem.

> So my recommendation is to use references (foo&) for passing down (well, up) the stack, never to heap allocated objects.

I don't think this is practical. Consider `operator[]` on a vector, which returns a reference to a heap allocated object. If that were to copy out, you'd have a lot of overhead, and if it were to move, then a lot of very common patterns would be annoying to write.

?

There is an overhead to having to think and plan for it, but in my experience of using it for things ranging from realtime systems through to high performance, multi-threaded image processing and rendering applications, at least if you're in control of most of the code and it's pretty good code, it's not really an issue.

Memory management issues cause tons of security issues in C++ applications. In the recent Pwn2Own, all of the security vulnerabilities in Firefox would have not been possible had Firefox been implemented in Rust.

Hmm… How can I tell maturity from rot?

I would say that Rust's defining feature is the borrow checker[1], which eliminates an entire category of pointer related errors at compile time.

>3 - A lot of things are renamed. auto->let, new->box, switch->box You get the feeling that effort was put in to make the language explicitly look different from C++

Rust is strongly influenced by the ML family of languages. I believe that's where some of the keywords came from.

>4 - the Rust switch statement don't fall through... This one was truly mind blowing. The one useful feature of switch statement got ripped it out! If you don't really need the fall through, I'd just avoid using them completely...

Rust doesn't have a classical switch statement. Instead, it has a 'match' keyword that performs pattern matching on the input so you can easily destructure a complicated blob of data into more manageable pieces. This is also a concept borrowed from the ML family. If you really wanted to, you could write a macro that emulates the C style switch statement.

>5 - I've never really seen an equivalent to boost (in combination to the STL) in other languages (maybe I didn't look hard enough). Could you maybe make a post about the RUST standard library? Libraries are always the deal breaker

There's a great overview[2] of what the standard distribution contains on the Rust website.

[1] http://static.rust-lang.org/doc/master/rustc/middle/borrowck...

[2] http://static.rust-lang.org/doc/master/index.html#libraries

A key feature of Rust is being memory safe by default without sacrificing too much performance. In C++ it's not really possible to be completely safe, and pretty much all real-world C++ I've seen doesn't even come close to that ideal, using raw pointers frequently; the result is that crashes can be relatively mysterious and, perhaps more importantly, that in large C++ codebases with lots of attack surface, like browsers, security vulnerabilities are extremely frequent. So yes, memory management is a serious problem.

In particular, there is no way to replicate Rust-style borrowed pointers in C++, which make safe low-level programming easier.

> 4 - the Rust switch statement don't fall through... This one was truly mind blowing. The one useful feature of switch statement got ripped it out! If you don't really need the fall through, I'd just avoid using them completely...

Most C++ code uses switch frequently, usually without taking advantage of fallthrough. Rust match is good for this, but it can also be used for more complex things (destructuring); using this frequently makes for code that looks quite different from C++.

> The main reason I'm consistently happy with using C++ (and why I put up with the header files) is that everything is available.

The bad news: as Rust is still a very unstable language, there isn't much of a library ecosystem.

The good news: by release, Rust will have a standard package manager, which should make importing libraries easier than in C and C++ where every package has its own build system. I think Go has been pretty successful with this approach.

> Since Rust seems so close to C++, does this mean that linking to C++ code is trivial?

Nope... I would personally like this feature, although it would be difficult to make reliable because Rust has different semantics in various areas - OOP is very different, templates are (intentionally) not as powerful, etc.

However, you can import C headers using rust-bindgen [1] and fairly easily link to C code.

https://github.com/crabtw/rust-bindgen

I am not so sure about this. Thinking back on my uses of switch in C and C++, I am not able to remember using switch without taking advantage of fallthrough. Maybe I am just not a typical C++ programmer...

  switch (x) {
  case 0: case 1: foo(); break;
  case 2: case 3: bar(); break;
  default: baz();
  }

  match x { 
      0 | 1 => foo(),
      2 | 3 => bar(),
      _ => baz()
  }

The much more rare use of fallthrough is executing code for one case, and then continuing on to execute the code for the next case. This seems to be much more rare. In fact, in my large Android application, I turned on warnings for this type of fallthrough, and out of hundreds of switch statements, only eight used it, and all but one was a mistake.

When use-after-free becomes a security concern that commonly leads to remote code execution, as it is for us in the browser space, it becomes very apparent just how inadequate modern C++ is at the task. Everything works fine, the tests pass, people use it in production, and yet all the time someone discovers some way to make the stars align to produce a use-after-free bug. This has happened over and over again, despite all the smart pointers and modern C++ techniques.

The fact is that modern C++ just isn't memory safe, and after digging deep into the problem to try to solve it with Rust I'm convinced now that it can never be. The language just has too many core features, such as references, iterators, and the "this" pointer, that cannot be made memory safe without sacrificing backwards compatibility.

No, the main selling point is memory management with guarantees for safety but full performance. You don't get that just with boost, it's mostly a GC.

>2 - I'm not a fan of the implicitness and I personally don't use 'auto' b/c it makes scanning code harder. I guess this is more of a personal preference.

Type inference removes redundant information.

>4 - the Rust switch statement don't fall through... This one was truly mind blowing. The one useful feature of switch statement got ripped it out!

Huh? The fall-through has been known to be a bug hazard and bad style for ages. And for what, to save a few lines with a not that clever trick? The only useful abuse of the Switch was Duff's device, and that's stretching it already.

You can still declare variables types explicitly: 'let x: int = 5'

'match' is also much more powerful than 'switch'. You can match on several patterns, ranges of numbers, as well as use guards.

http://rustbyexample.com/examples/match/README.html

And it's true that Rust is edging closer and closer to C++ in some ways. It certainly didn't start there, old ("old", 2010 or so) Rust looks pretty weird with lots of esoteric features (effects! structural types!) and built-in magic. Over time Rust probably ~focused on its core values~ etc, which resemble that of C++, and also grew more powerful as a language so that most things can now live in the library rather than in the compiler, which is I guess something that C++ also prides itself with.

But more seriously, the whole motivation for Rust isn't what features it gives, but what it takes away. All the traits and algebraic datatypes and type inference and other shiny Rust features, if someone walked up to the Rust people with an implementation of that as a source filter for C++ or whatever, it still wouldn't sell. The mission of Rust (as I see it, from the distance) isn't to make a more convenient or powerful C++, it's to make a language convenient and powerful enough that people won't miss C++'s laissez-faire attitude towards memory safety.

To that effect, Rust isn't really aiming to compete with C++ on a feature-for-feature basis, but it has to include features that enable a style of programming that is competitive with C++ performance and convenience without relying on memory-unsafe features.

(I guess the `unsafe { }` sub-language comes off as an admission that that won't work, but it's arguably just a way to introduce new safe primitives that requires particularly careful manual checking, just like adding features to the language that the compiler assumes are safe, and anyway it's mostly equivalent to linking to arbitrary C code without which the language would pretty much be a non-starter anyway.)

> 1 - If memory management is a serious problem for the software you work on, I've never found the boost library lacking. This seems like the main selling point for RUST. Given the scope of the project: you guys must be doing something that is so different that it couldn't be rolled into a library - so I'm looking forward to your future posts to see if there is something here that I really am missing out on.

Generally every non-trivial program has bugs(possibly excluding tex which was written by one of the greatest computer scientists of all time and after years of being open with bragging rights for anyone who finds a bug, but I'm not even sure about it). Rust aims to reduce bugs including memory bugs as much as possible with static typing. It's probably the language that most concentrates on preventing bugs with static typing/analysis this side of haskell. Even if c++ could have some similar feature if some library used carefully this is not the same as people could still abuse unsafe features not allowed in rust outside of unsafe blacks.

> 2 - I'm not a fan of the implicitness and I personally don't use 'auto' b/c it makes scanning code harder. I guess this is more of a personal preference.

It is a matter of style but as someone who puts var in front of everything but basic types in c# I think its a good default. An ide can help a lot by showing type on hover.

> 3 - A lot of things are renamed. auto->let, new->box, switch->box You get the feeling that effort was put in to make the language explicitly look different from C++

Although rust is somewhat influenced by C++ aiming to take over its problem domain it is probably more influenced by functional languages like Ocaml. let comes from ocaml, match instead of switch also comes from ocaml(note that match is more powerful then switch). Also note that let isn't exactly the same as auto, let allows declaring local variables, rust default to implicit typing for local variables but you can specify them and it will still have let. ex.

    let monster_size: int = 50;

There aren't that many useful switch statements that fallthrough for reasons other then matching multiple values to one execution path and rust allows you to match one of a number of values or in a containing range. ex.

    match my_number {
      0     => println!("zero"),
      1 | 2 => println!("one or two"),
      3..10 => println!("three to ten"),
      _     => println!("something else")
    }

    println!("my number is {}!", match my_number {
      0     => println!("zero"),
      1 | 2 => println!("one or two"),
      3..10 => println!("three to ten"),
      _     => println!("something else")
    }

I think that if there are multiple ';' seperated expressions in an if/else or => result wrapped with {} it will return the last expression if it isn't followed by a ; otherwise it returns unit(a type meaning something similar to void). But I could be wrong.

> 5 - I've never really seen an equivalent to boost (in combination to the STL) in other languages (maybe I didn't look hard enough). Could you maybe make a post about the RUST standard library? Libraries are always the deal breaker

The equivalent of Boost in what way? Boost is a collection of many(>80) different libraries some of which (ab)use the language in very interesting ways. Some of these eventually move into the standard and stdlib. I don't think any other languages have this sort of feeder collection. That said many languages have officially or unofficially blessed libraries which sometimes make it to the stdlib. Rust is fairly young and a moving target so there aren't many 3rd party libraries yet but hopefully that will change once it stabilizes and the package manager is mature.

Rust is inspired by more languages than just C++, believe it or not. :)

I've been to a number of high-class fundraisers/events held in back yards. It's pretty standard (obviously everything is spruced up nicely) to hold nice events in the yards of mansions.

that's not the only option. The company could remain privately owned - in which case you want to have below 100 shareholders so that you can remain a C corp

But it's exactly one year since the hack and everyone is back to talking about how amazing Linode is

http://news.softpedia.com/news/Hackers-Claim-to-Have-Gained-...

The issue was with how they handled the public disclosure of the hack. Instead of immediately alerting their clients that there has been an issue (so that - as you say - people could take mitigating actions) they stalled on giving information and tried to cover up the whole fiasco. This should give people ZERO confidence in their moral integrity.

If you run a service like Linode or DO, you need to provide certain guarantees on disclosure of security failures and maybe get an externally audit from time to time.

Because no one is doing that... I'd have to guess there is more going on

Real estate, data center space is likely to be under long-term leases with penalties for early termination.

Personnel layoffs are not a trivial thing either - there are severance costs which in case of upper management can run into tens of millions - http://sacramento.cbslocal.com/2014/04/17/fired-yahoo-coo-ge... And that's just US - Yahoo! has a network of European offices which likely have more protective labor laws.

But it might be difficult to acquire a controlling interest in Yahoo without driving up the price.

Except there is not a lot of reason to believe that either:

1. Yahoo could dump its holding of Yahoo Japan shares at current market prices (current share price is a good rough estimate of realizable value if you aren't trading enough to move the market, but selling off around a third of Yahoo Japan isn't that small of a block...)

2. Yahoo could actually find a buyer for its Alibaba holdings (a non-public firm) at the analyst estimate of its value used in the article.

> The now-isolated core business would have positive value.

The article doesn't really make the case for that. It says the core business is profitable, but current profitability doesn't mean positive value; it could be in debt, profitable, and not expected by the market to remain profitable long enough to get out of debt -- that would give it negative market value.

Really, all the facts in the article tell you is that at least one of the following is false:

1) The author's implicit assumptions about the market value of Yahoo's core business, or

2) The estimated value of privately-held Alibaba, or

3) The assumption that realizing the value of its holdings in YJ and Alibaba would be transaction-cost free for Yahoo (and thus that those holdings should be undiscounted when aggregate to determine Yahoo's worth), or

4) The efficient market hypothesis.

I have no problem believing that all four are false, and misleading in this case.

> The article doesn't really make the case for that. It says the core business is profitable, but current profitability doesn't mean positive value; it could be in debt, profitable, and not expected by the market to remain profitable long enough to get out of debt -- that would give it negative market value.

Stock can't have negative value. If a company becomes insolvent, its stockholders aren't forced to pay its debts.

The article agrees: "Unless the probability of that outcome is 100 percent -- a rare thing in this life -- then Core Yahoo should have some positive value."

A component of a business can. Ignoring the problems that make marginal stock prices problematic for overall valuation, and transaction costs, etc., the stock price of a corporation should be max(0,sum(value of all components of the business)). The fact that this value should never be less than zero doesn't mean that no component of the business has a negative contribution.

I'm just saying that if Yahoo sold its major stock assets and transferred most of its cash to shareholders, the remainder of the company (consisting of "Core Yahoo" and not much else) would have positive value.

Also, $100 chunk of Alibaba shares is not $100 distributed to you if you're a Yahoo! shareholder - first there's US corporate tax on that income, and then a dividend tax on top of that, which could be qualified or non-qualified depending on your shareholder status.

Apple doesn't have any goals to spend half their cash on hand (Other than the iphone 6 being 11% larger/smaller/whiter/lighter)

Buffet isn't a fan of tech stocks (or any bussiness he doesn't understand) http://wallstcheatsheet.com/stocks/heres-why-warren-buffett-...

I'd be more honest =)

Yeah, sure, they worked hard, but in the end they get a big fat F for the end result.

Services don't last forever, but I'm not gonna congratulate someone who runs around in circles for 3 years purporting to deliver a product of value, and then gives up when offered a better deal for themselves.

They didn't build a product, they built a nothing. It's like reverse vaporware, and I won't respect it.

If you just made several mil I honestly doubt you're thinking about making the "transition as smooth as possible". You're thinking "should I buy a Lambo or a Ferrari?"

They probably got a memo from Dropbox saying "now that we own your ass, here is a press release that you'll publish asap"