oscargrouch

They can, this doesnt affect the normal, quasi-organic way of BTC payment processing. But in the traditional Bitcoin processing, the shop providing any service or good that can be payed with BTC must have a private wallet, as we know.

This, on the other side, propably means that you, the customer can choose to pay with BTC instead of debt or Visa and the shop will receive the money in the local currency without the need to deal with BTC or you to directly move the value from your digital wallet.

They are just doing what they alredy do, being just the middle-man who gets its cut just for being the middle-man.

I just cant wait for the time they choke our legislators with so much money, that they will push to regulate bitcoin in a way where the traditional peer-to-peer payment becomes forbidden, and we all have to use the greedy middle-man, that we didnt even need to use anymore, thanks to the inovations like the blockchain.

Welcome to the future, were all things old are new again.

I think so, but with the Javascript VM i think this is more clear, to the spot.

As far as i know, the web rendering engine of Firefox in C++ were pretty old, coded in old c++ style. So in this particular case a rewrite would have some leverage.

The thing is, in the end, i dont know if this part C++, part Rust codebase wont start to create more problems than it solves.

Should the layout and rendering engine be rewritten in C++ or Rust? They decided to go with Rust, and now they will be forced to continue replacing C++ codebases with Rust, for consistency, workforce, etc..

In the end they will fight a lot to recode the browser, and meanwhile the competion can optimize, inovate and create more features.

Rust will gain a lot for sure, but not Firefox, not Mozilla. And with this Mozilla will be in a place where it will need to bet everything in Rust, as its only chance of survival.

End users dont care what technology go on their browsers, they care about perception, and its not clear that a browser will work better just because its in Rust as compared to C++ which is already a high performance language. (Maybe they will spend less resources in tests or in correcting bugs, but thats pretty much it)

Firefox is much better now than it was before? Yes, but my point is it could have been this better version of itself sooner, if they did not use Firefox to fight Rust´s cruzade to relevancy.

The topic of rewrite, i think it depends a lot of the context. Some things might make perfect sense for a rewrite, but i still think that a very optimized with huge amount of man-hour piece of sophisticated and complex C++ codebase like Spidermonkey VM are not one of those things.

Theres no gain in clear performance, unless theres a better algorithm being implemented, no clear gain in productivity, as C++ and Rust are both equaly complex beasts, and with not much gain in security, if you already implemented in "modern c++" and are using smart pointers, including in API´s and moves correctly.

The other gains in security/safety that you might have with Rust, are maybe lost if you think that the C++ codebase have been used and tested in every possible scenario, so a lot of bugs are corrected, and if you think that given this is a Jit VM you will have to use Rust´s unsafe{} in a lot of places, i still think, giving the context, that is not a smart thing to do, and it will be more like a trophy to Rust, but without a more pragmatic and realistic approach to the matter, not focusing properly on results.

Not much gain, you will end with a worse and more buggy JIT in the end, and will have to spend more years, only to get parity to the VM you already had in the first place.

This is not my field of expertise, so forgive me if im mistaken, but isnt 'Ohad Rodeh B-trees'[1] a simple and more elegant solution than a journal/WAL?

As far as i know its already used in Linux Btrfs and in LMDB, and i wonder why, if they were designing this from scratch, why they didnt go for this in the first place. Familiarity perhaps?

By the way i have code that deals with the SQLite Btree directly and by reading your comment now i understand why theres a need for a two-phase commit as expressed in:

BtreeCommitPhaseOne()

BtreeCommitPhaseTwo()

[1] - https://liw.fi/larch/ohad-btrees-shadowing-clones.pdf

I understand how this might be cool and exciting for the Rust community, and even for the enginnering team who might be more inclined to work in a Rust codebase.

I worry that every risk taken to improve Rust, might have a severe cost by alienating Firefox userbase, and with that Mozilla get into troubled waters.

But as you have clarified, inner pieces are being slowly replaced, which is not as bad as rewrite the whole thing from scratch in Rust, while at the same time, leaving the current C++ codebase without any improvement.

Anyway, from the enginnering perspective, kudo for you guys, for being able to make the browser work with all this complication going on under the hood.

Hope it all works out even with all the complication, challenges and risks taken, as we all need good players like Mozilla to lead us to a better future, as we rely more and more on technology to improve our daily lives.

Of course they can do it. I just dont think is a clever move for them to do it.

Firefox is having a hard time to compete with Chrome, and they took too long pursuing other goals, and just remembering one key feature they took a lot of time to implement, was making Firefox a the multi-process browser as Chrome.

I mean, you would be ditching all this effort, rewriting it in Rust, spending key resources only to have some parity with the same browser you already had in C++, spending years, and loosing more market share, as Chrome can spend this time in optimization and features.

For the record, i think Rust is what will save Mozilla, but it must reinvent itself. Do the best they can with the firefox codebase they have, and use Rust for new projects.

Like, creating Cloud, backend system software, and reinvent itself like Ubuntu is doing right now.

They have to be very strategic and pragmatic right now. Two big moonshots, Firefox OS and Rust, and only one of them has paid out their time and resources.

If they want to bet in more moonshots, great, but they must do it in "blue ocean" places, being more innovative on where they should use Rust, were Rust can shine.

I just think that from a strategic (and even technical) point of view, they are just spending precious resources, while at the same time eroding even more their browser market share.

To be fair i think this is an exercize in vanity and why not say it, stupidity.

Javascript VM´s these days are fairly complex beasts with huge amount of man-hour and expertise. Also technically this would be a inferior solution as compared to what V8 did with its interpreter in Turbofan (and SpiderMonkey are doing now as presented in the article), by generating pure assembly through the turbofan backend (the same technique used by LuaJIT before with great success).

By the way lets not forget we are talking about Mozilla here, were a couple of more misguided projects could mean the abrupt end of the organization who is suffering to keep its market share in the browser wars.

There are a couple of things that could take some advantage for being re-coded in Rust, but modern super-powered javascript VM´s are hardly one of those things.

Of course, if in the sidelines someone craft a JS VM in Rust, and after IDK, 4 years, you have a mature enough JIT VM, maybe there will be a reason to move, but Mozilla itself investing its unsustainable, limited and in the brink of extinction funds on something that will require a lot of money and that in the end will get you basically the same perfomance as the old C++ jit, its a pretty bad move.

Swift is built on top of LLVM, the same way C,C++ and Rust are. Also note that the language was created by the original creator of LLVM.

So you can use any backend LLVM does.. theres a little runtime friction in porting a small Swift runtime to the target (but you would only need to worry about that, if its not a popular LLVM backend).

But given Apple is a first class consumer of Swift, arm is definetely a strategic backend for Swift, given it needs to run on iOS.

(its a little alpha i guess, but you can even compile your Swift code to run on WASM nowadays)

I think it´s funny with that much comments, none of them are really on the core issue here.

Just imagine if Tim Berners-Lee banded together with Mark Andreessen to create a closed and centralized platform, were they could centrally control everything.

Thats why i think the mobile phone plataforms are a real danger to a world were the information flows freely and were no government or company can control.

People are giving to much power to those companies, and when they do what a lot of people know they would do, they just wip, and try to contact his digital lord to just have mercy.

Dont neal, dont help them kill the spirit behind a world were people can access the things they want without any sort of centralized control.

Its beyond me how many people are so worried about government controlling their freedom, but are ok with companies doing it.

We do not need to accept this. The problem is in the app store model.. (they could create it, as long other could compete, but they could NEVER choose what you can access) and guess what, now our governments are too are weak to regulate them.

They can spy on us, know what we are doing, help shady government agencies, control what you see, listen, access and in the end shape what you think (Remember all the mess the simple 'like' Facebook algorithm did to the world.. its too dumb. It reminds me "Donnie Darko" with that shady coaching of "everything should be on the hate-or-love axis").

The despotic government of the future for me is a bunch of big tech companies who control information, and the lives of all of us united to have a world were they will be all powerful and always relevant.

People dont seem to know the dangers we are facing. This is very serious, and its a glimpse of the future. Think how much of what you understand as your right will be suddenly terminated by despotic tech companies who are too powerful to be controled or regulated.

It´s even worse, if you think we are in the dawn of the AI and what a very powerful player can do to keep the control.

You can think im exagerating, and i really hope im wrong, but its a real possibility, and we should not let this awful future be materialized because we did not see how this could be possible.

And to help you figure it out, if you travelled back in time to tell your 2010 self how the world would be in 2019, do you think he would believe it? We are living in idiocracy all over the world, and we use to laugh to those sort of movies. (Dr. Strangelove will soon look a lot like a documentary of the modern days)

The current trends on Browsers and OS´s is one of the things that drive me to try to create first what the next iteration over a platform like browsers, based on organic p2p tecnologies should look like, and then iterate a little more and create a optional OS on top of it.

I hope that in a couple of months i can launch this platform here on HN so i can see what you all think, as i have a great respect for the community formed here.

But we need to not rely on companies that tend to make a profit from the cloud computing, analitics, big data and of what people make and publish for free, if we really want to have our privacy and our freedoms in general, respected in the end.

Anyone that can sum 2 + 2 can see how this can lead to severe consequences into our private lives, and civil liberties in the end if we keep following this path. As we might be only depending of the good will of the status-quo that can change depending on the political context of du-jour. (And i must remind you all that this good will and the more generous environment might reach to an end, as the circustances may lead to economical and political crysis, environmental crysis, shortage of primary resources, political instabilities, war, or just a simple power-hungry drive to control all things)

The problem is that only the political/social point of view is not enough, as we need to respond with a technology good enough, or even better, in a way the end users, and the devs will be naturally inclined to use the platform to reach their own personal goals.

And it´s my believe that organic, p2p forms of content distribution and communication in general, can deliver a superior environment compared to what we have today with browsers. And even if the big players could create themselves this kind of platform, they would not want to, because in the end they are trying to reach absolute control of our data, and our digital representation of life.

The trick is to have the right building blocks carefully combined to make it work in a way that it will make people want to develop for it from the perspective of the devs, and to use it as a medium from the perspective of the users.

A very small and fast javascript interpreter. It will create a small library file for the programs who depends on this and according to the benchmarks it runs faster than the other javascript interpreters.

If you want a very fast javascript engine and dont have problems with binary size, memory constraints and executable memory pages, you can pick a JIT like V8, Chakra or Spidermonkey. As those JITs are pretty advanced optimizing JIT compilers and will run javascript code very fast, much faster than the fastest interpreted VM implementation can.

People who tend to choose this instead of V8 for instance need to run this in a microcontroler for instance, or a OS without executable memory pages (and therefore where JIT´s are forbidden).

Thats one of the reasons why need to rely more on micro-kernel design OS first, so it's easiar to advance and experiment with different designs for the storage layer.

The "everything is a file" mindset was great to move us from the chaos they were in back in the day to where we are right now. But with the modern ecosystem is holding us all back, because is too rigid, and a abstraction that its a poor fit to a lot of modern scenarios.

With micro-kernels, we could have the kernel dealing only with persistent storage blocks and leave the storage abstraction to the userspace where it belongs.

If im not mistaken, The Zircon kernel go even further by abstracting through pages.. so you could just map a collection of blocks to those pages and deal only with the pages in memory, no matter they source (if disk, network or only on memory).

Leaving the abstractions to userspace and by doing so, enabling us to download, install, and mix those abstractions in a way that is a good fit for a giving scenario.

As we have seen, the monolithic kernel have trouble with the bazaar approach as those experiments have to be shipped in kernel-space, with all the trouble this entails.

Well, good luck with that, i guess.

But being realistic, i dont think any non-GC´ed language has a chance to become the next corporate darling as Java is now.

In that sense, Go, Swift, C#, etc are much more fit to become the next kings in this area, and even them will do it very, very slowly.

The script family of languages also dont make a good fit, giving they tend to be bad at creating big, performant and constantly evolving kind of programs (Javascript, Python, etc).

I guess the languages which are AOT compiled, GC´ed and mostly objected oriented with some mix of FP will probably be more of a fit the take the crown jewels of the king Java.

The problem Rust will face in this scenario, is that it requires people with a level of brain power that contrary to 'high tech' is not that much available in the corporate level, (and the ones that have dont want to spend all of their lives behind a computer screen).

And also is a "productivity hog", when we compare to sophisticated languages like C# or Swift, as productivity in Rust is on par with C++, which is not good enough when compared even with the verbose and over-enginered Java codebase.

It´s basically the same reasons why, C++ is not the prefered language there. And i dont think just using the magic word 'safe' will have any charm for this kind of crowd. Giving while Rust can use this trick against C and C++, it doesnt work for productivity minded languages like Go, Kotlin, Swift and C#.

Mind you that modern GC´ed languages are pretty safe, and also pretty fast. So it will be very hard to convince the corporate layer to use a language where there will be scarcity of labor, and that means they will have to pay more and be able to have less employees.

The smartphone revolution gave performant and resource aware languages a renaissance and Rust is surfing in this wave. Rust has a lot of chance in smartphone, embedded, libraries and utilities and even in specific scenarios on the server.

But even for the "rewrite all in Rust" mantra for C++ (a language Rust is competitive with) it will stop going forward, giving the Unix, C and C++ codebases are pretty much very influential and with a lot of sophisticated and complex stuff already out there.

Anyway, i dont understand this urge to use just one language for everything. I think this is unrealistic and illusory, and i think its a better approach to elect two or three languages with fitness in some fields and just use them.

The "one language to rule them all" was already the Java approach since the nineties, and while it make it a very popular language, it was in a time where the competition were not that great and even then, it proved to not work really well in all scenarios (and i think thats a good thing because it means we are free from a computer language monopoly, which would slow down the evolution in the field).

I have checked this earlier. Its pretty cool stuff, but its more in the direction of userspace emulation like what GVisor do.

The OP expressed he wanted to use (or create idk) a micro-kernel based OS, and that in the end he would like to scrap the Linux kernel.

Of course the solution you are pointing out will deliver in one of those axis, but the solution im pointing out would deliver in both, Linux emulation/sandboxing and a micro-kernel based OS controlling all of this.

I just think that the direction Fuchsia is going, has a little bit more to do, to what he is trying to achieve.

But he can totally mix the 'syscall proxy' solution of ChromeOS and a micro-kernel, even if this would still be Zinc or something else. And depending on the goal, maybe having this in userspace level would make more sense. He just need a good and flexible IPC communication (like the one in Chrome, or something on the kernel level).

I think if you dont have a strong opinion about it, this is exactly what they are trying to achive with Zircon/Fuchsia kernel.

A micro-kernel, with a linux virtualization layer, being abble to run Linux executables as if they were native.

My hunch is that in the long term, Google will probably use Zircon as the 'first-level' kernel, and run the android apps using some emulation layer.

Maybe it could be the answer for what you are trying to accomplish, without having to create a whole micro-kernel OS from scratch, while at the same time benefiting from whats already there.

I bet that with such a thing in place, the Linux kernel could totally go away, with only a emulation layer in place if you want to.

> I’m not sure about Brazil, but in general it is very difficult to compare a developed country with a developing one.

The context for Brazil is mostly that it is a democracy from 1888 til nowadays, but with a shadow institutional period from the 60´s to the mid-eighties.

So the country had to rebuild it´s own institutions from the eighties til now, to serve a democracy instead of serving the wills of a dictatorship.

Now, its in a point of testing its institutional maturity, and the rule of law, by the ongoing crackdown on corruption and organized crime. A lot of big political figures from all sides (and executives) are in jail right now, and theres a current crackdown going on in the organized crime front.

But the big test right now is the current Brazilian government with its backwards policy. Will the organized institutions from the society, and the other powers besides the executive able to make a stand against going backwards?

Theres a big test going on in Brazil right now, if 'we' are able to pass this dangerous phase and still have the democratic institutions and balances in one piece, than i guess it will probably move foward and get stronger with time.

In this sense also, the US was lucky to have England as a cultural parent, because England was/is great in making solid institutions. From government to the academy.

The colonization process of the countries colonized by the spanish and the portugueses, were mostly a vampire-like kind of relation. Where they took everything they could, leaving a trail of exploitation and slavery behind.

The portuguese colonizers even used to forbid Brazil of the colonial/empire era to have a University, which we only manage to create the first one here in the 20´s.

Anyway, i guess the answer to the rule of law, is both; is "good enough for most things", and "we are getting there". Not something to be proud of, not something very advanced, but not bad either..

I used swift on WSL1 and even compiled natively for Windows.

But i guess the pure Windows ecosystem is rough on the edges right now, but doable. And in WSL(1) things have worked pretty the same as in Linux.

Just download the packaged binary distributed on their site, and you are ready to go.

(Oh, a note; its not the tensorflow branch, if is thats what you want)

As far as i know, Swift is the only one embedding the graph flow of the TensorFlow directly in its compiler, so those idioms can translante from IR to machine code with paralelism and a fine-tuned machine code.

As its very common to target this sort of code to GPU´s, and LLVM can target them as output, i think is mostly because you can design and shape the langage right on its high level representation and tune for high performant code in the low level.

The why, i think, its about opportunity.. Chris Lattner going to Google, and people from the language and the compiler side of the fence being open about bake this right into the compiler when necessary.

Opera has a chrome-based engine since 2013 more-less. I guess their old engine were called Trident, and its gone. Also i think they are now owned by a Chinese company.

Edit: oops, Trident was the Microsoft browser engine.. i guess i meant 'Presto' as the name of the old ditched Opera web engine.

The problem is not in they using digital signatures, as this is a trend that is here to stay. The problem is when they are the sole provider of the trust model.

As others have pointed out, at least they should allow third-parties in where users could let trusted parties (from his point of view) provide him software for a machine he owns.

People are being näive thinking this is really about security, when in fact, its about control, power and profits. And when (some) people wake up to this fact, it will probably be too late to take any action. And i bet the majority wont even know what they have lost.

Its clear they are not thinking in their users insterests first with this move, because they are giving security with one hand, and taking freedom with the other hand.

For instance, if some app compete with them in things they think is strategic, with the control they have, they can make the app vanish and not be a problem at all for them.

We see this happening with Google everyday in search results for instance. We saw this with Windows before, but this time i think it will be much worse..

Hackers will find a way to unlock the kernel, but im sure by that time, those companies would be so powerful, they would have a legislation for that, so those kind of actions could be punished with fines or even prison.

I know im exagerating in this last scenario, but it is all possible, and with time it get more and more likely to happen.

Part of the point of the OP, as i understand it, is that theres also a cultural war going on, where if corporations end to get their way, by controlling/locking developers and users on their platforms, people will see this as normal.

This happened before with radio and TV signals. A great way to have peer to peer comunication, with local TV's and radios, ended up being regulated.. and in our culture, its normal to sit in front of a TV, and have a few monopolies to choose what we will watch.

And right now its unthinkable to revolt to those kinds of laws that forbid us to transmit content, as we accepted as normal (where's the cultural aspect of it, shaping our behaviour).

The same will happen to the next generations if we dont take a stand against this. Normal users wont understand the social, cultural and political implications of this. Companies like Apple defining what you can or cannot use, listen, see or install in your own device.

> To play the devil's advocate here...

You are not being the devil's advocate here.

Whatever MS, Google or Facebook do its the end of the world (as it should), but apparently for the HN crowd, Apple can do whatever they want.

This monopoly over our digital life will have severe consequences in the future. People here are so smart, but when its about Apple, their sentimental reasoning start triggering.

Actions like this one, as many others, are some of the reasons why i never use anything from Apple. Its like a car factory being able to decide where you cannot go with "their" car (Its yours). Or the clothing company choosing the places i can use "their" clothes.

The hacker spirit here ends when is anything related to Apple, when in doubt just read the top comments here in this thread. Its not a 'benevolent ditactor hacker' sort of social contract.. its a company which need to raise their profits so their shares keep being valuable to the stock market. If consumers and developers let them, they will own our digital life, and lock us with them.

We have no legal framework, and no State to intervene in our interests as it should be.. States and democracies are a dying species, and we are the ones to blame.. we, as in the general population, just want the next shiny gadget.

But i bet we will miss the things we have, but dont give much value now. Lets not forget the share of our lives that are constantly being transfered to the digital dimension, and how important they are now.

Reading the answers to your comment, can get pretty depressive. As people are just taking spionage for granted, trying to choose who we would want to let spy on us.

Please, can we try, or at least pretend we are trying to defend our rights to privacy of data that should be private?

I dont want to have to choose who should spy on me. We are entering into this dystopian reality, and somehow we are fine with it.. but there will be a time, we will understand it's too late, and theres no going back.

I hope we wake up sooner than that. Dont just accept it as it is, it will have severe consequences to our future, if we let them to have all of our data, because this means complete control of our lives and the end of the little free will we still have.

It feels to me like choosing which mob lord would be the less evil to me.. We need to understand we dont actually need to make this kind of choice. Resist. Dont let them have it.

C++

For ELF i would say because its easear to reuse a lot of tools that already deal with the format. Debuggers, linkers, compilers, etc..

My guess is also because its easear to have a bridge with Linux executables, so you can run the same ELF and emulate the linux syscalls somewhere like FreeBSD and now Windows .

I bet they were thinking about running Android stuff more easily, and i dont think there will be much more to gain in designing a whole new executable format, when you compare how much of free tools, code and compatibility with Linux you will have in the end.

As someone who was following Rust since its inception, i got pretty fond of the first Graydon Hoare's vision to it. It looked a lot like Swift is now, but with a different syntax and more FP dialects.

As a im a (mostly) C++ programmer, despite the fact that i liked the language, i feel that the balance between what the language was giving me, and the productivity, was not worth it when compared to C++.

I feel much more productive in C++, the language is still faster, with a low memory footprint in the majority of cases, and with modern C++, smart pointers, move, a correct understanding of the ownership model .. the bad sides of it, the ones Rust did a better job shelving us from, from my point of view are not worth paying for the lack of productivity i felt in Rust as compared to C++.

I know this is an unpopular opinion here in HN, but I decided to take a different approach .. instead of "one language to rule them all" i tend to use C++ for what's good at, and Swift for more application centered goals , because its nicer than C++ and Rust (in my opinion), release you from the burden of managing memory all around while being very fast at the same time.

Swift for me is "the better Java" we were looking for, Rust does not seem appealing in this arena (and the same goes for C++ here), while you pay for what you use in Rust in terms of productivity, even compared to C++.

The other thing that makes C++ a better option in my opinion, is the ammount of libraries and codebase you have access to, not only in C++, but in C. Very important codebases are either C or C++, even the newer ones like Tensorflow or V8, Chrome, LLVM, etc ...

I understand the importance of what Rust provides, I like its goal, but your comment sounded like the OP was either stupid or lazy / incompetent by using your anedoctical evidence. (While in the same anedoctical example you are the hidden figure who are sensitive about security while still using C++, as the 'lazy guy', enabling -Wall, using Valgrind, etc)

When I entered in the comments section here, I was just expecting the sort of comments in the spirit of "how could you even do that?"

PS: Im not the kind of guy who tends to disable -Wall -Werror to have more productivity and i would not favor C ++ in exchange for Rust, if i feel the balance were better among what i pay in terms of productivity were fair in exchange for more safety as compared to what I have now with C++.

Combine this with some sort of blockchain straight on your DNA, you could have a permission system to grant/deny access to things, that would work not only for your biological system, but with binding contracts on the real word. Like bad credit, or denying access to your bank account, to kill someone by making his system 'forget' how to process a given amino acid, or make them dependent of some drug to live so a government could just wait a "traitor" come to them so he/she can keep on living..

While you are right, i see a lot of enginners making bad decisions for the right tools to use for a giving problem, based on psychology and emotional reasoning.

Things might even work in the end, but you can end with a weak project that wont scale or will crumble when faced with the destructive nature of time.

I know its a controversial topic, but i think a little bit of zen-budhism training of the mind can make wonders in making those sort of decisions, where the unbalanced parts of our psychology will eventually show up and cripple what could be a great thing.

I am an IT enginner, but i practice a lot of self-mind vigilance to understand my decision making process, to avoid making the most confortable decisions and going for the write answer, no matter how painful and expensive it may sound.

To give an example of this, i remember for instance CouchDB vs. MongoDB, where the concepts were layout in CouchDB, but it was done in Erlang, so as soon someone did almost the same thing in a language that suits a database development well like C++, the tool sky rocket and reach all of its potential.

The language i see this happening the most for instance is Python. Where you have great concepts and great enginners but where a lot of them shouldn't be using Python for that particular goaç. Again here i can use Mercurial as an example of a great tool in a bad fitting language (for the given tool, as Python might be a great fit for other use cases).

One thing i like about using std::unique_ptr now that we have and use std::move() is to annotate in the API when you want to own the heap object being passed or to say that the api consumer should own the reference.

I get that if you just use it for usual the owning class, it doesnt provide that much, but it annotates lifetime, and its pretty cool when you get used to it.

if you see this:

    class X {
     Y* y;
    };

Does X owns Y? or is owned by Z and X is just using it?

    class X {
     std::unique_ptr<Y> y;
    };

Now you know for sure X owns y.

    class X {
      std::unique_ptr<Y> CreateY();
      Y* CreateY();
    };

Look how in the first example you know that X wont retain a copy of Y, and the caller will be considered the owner of the heap..

Now in the second example you are not sure if X retain and will handle the deletion of Y, and you should use Y, while in the first example its perfectly clear the api intention.

the same here:

    void AddY(std::unique_ptr<Y> y)
    void AddY(Y* y)

in the first you are aware you are passing the ownership of Y, in the second you wont be sure if you still need to handle the deletion yourself.

Before std::move() i get it, but after you can pass things by moving them, i dont get it why anyone would not like to use this.

For me this is basically the "lifetime annotation" feature, only that it is by convention, and not enforced by the compiler. Unlike others these are the reasons why i dont feel the urge to jump the Rust bandwagon, and prefer to use things like Swift when i need a more "chill" environment to work, as i didnt feel more productive in Rust than in C++, while with Swift it happened and it also has a pretty good story perfomance wise.

I prefer to mix C++/Swift as my perfect duo, than try to make it all fit in one language, as this always lead to frustation and a lot of headaches.

These are definitely a couple of good bets to be aiming for.

The blockchain trend reminds me that Rust could also try to find some cosy home in banking software, in expert systems and in embedded software.

The key now is to be humble and not to try to pick up a fight with C and C++ just yet.

Go only now is in a position to pick a fight against Java in the server and in the cloud, and Rust will probably need to get into the same point of adoption, if it wants to be seen as a serious contender to those languages in the eyes of the people they need to convince.

Unfortunatelly Rust missed a good new trend now, with multi-platform cores for mobile phones that ended up being written mostly in C++.

Rust wasnt even invented when people were trying to solve the problem of multi-os phone apps.

And that is the current trend which is giving the system development trend a second chance. But is not that bad, because thats exactly what is making people to take a serious look at Rust.

Battery life, memory, storage. It all matters again thanks to the phone environments, and you cant afford the be wrapped in layers upon layers of software virtualization like it was common in the early PC era, where Java and C# were kings.