From a top-level, the biggest difference is the fact that Vyper is focused on security and doing its best to protect developers' code from being exploited. It has the advantage of having seen Solidity go through various stages of development and is being designed around Solidity's experiences. Vyper is built with security, language and compiler simplicity, and auditability in mind.
Additionally, Vyper's syntax is much easier to follow, as it is a Python-like syntax.
In present and future which one can more acceptable for making smart contracts and why ?
This is up to the developer. Functionally, they both do the same thing (interact with the EVM). If the contract is simple, I would say Vyper should be used, as there is less room for error. There are times, where Vyper may simply not work, such as if you need to write low-level assembly to manipulate the EVM.
From Vyper's Github page, a few of the items that Vyper has removed for simplicity:
Some examples of what Vyper does NOT have and why:
Modifiers - e.g. in Solidity you can do function foo() mod1 { ... }, where mod1 can be defined elsewhere in the code to include a check that is done before execution, a check that is done after execution, some state changes, or possibly other things. Vyper does not have this, because it makes it too easy to write misleading code. mod1 just looks too innocuous for something that could add arbitrary pre-conditions, post-conditions or state changes. Also, it encourages people to write code where the execution jumps around the file, harming auditability. The usual use case for a modifier is something that performs a single check before execution of a program; our recommendation is to simply inline these checks as asserts.
Class inheritance - requires people to jump between multiple files to understand what a program is doing, and requires people to understand the rules of precedence in case of conflicts (which class' function X is the one that's actually used?). Hence, it makes code too complicated to understand.
Inline assembly - adding inline assembly would make it no longer possible to Ctrl+F for a variable name to find all instances where that variable is read or modified.
Function overloading - This can cause lots of confusion on which function is called at any given time. Thus it's easier to write missleading code (foo("hello") logs "hello" but foo("hello", "world") steals your funds). Another problem with function overloading is that it makes the code much harder to search through as you have to keep track on which call refers to which function.
Operator overloading - waaay too easy to write misleading code (what do you mean "+" means "send all my money to the developer"? I didn't catch the part of the code that says that!).
Recursive calling - cannot set an upper bound on gas limits, opening the door for gas limit attacks.
Infinite-length loops - cannot set an upper bound on gas limits, opening the door for gas limit attacks.
Binary fixed point - decimal fixed point is better, because any decimal fixed point value written as a literal in code has an exact representation, whereas with binary fixed point approximations are often required (e.g. 0.2 -> 0.001100110011..., which needs to be truncated), leading to unintuitive results, e.g. in python 0.3 + 0.3 + 0.3 + 0.1 != 1.
Best Answer
I originally used Vyper for doing more complex math (specifically the curve integrals and inverse curve integrals for bonding curves), as it has a lot of securities built-in (such as over/underflow protection etc) but it can be quite a hassle. In my project, we ended up rewriting the math back into Solidity for continuity within our repo, and because the way that Vyper does square roots (the Babylonian method) was the same level of accuracy we got in Solidity anyway so there was no value add.
If you want to work with it just to try it out, go for it, but if you are looking for a specific reason to use it I wouldn't recommend unless you are going to be using some heavy math and want the Pythonic structure.