Data is always stored in the smart contract. So, technically, you won't be sending a message to another address, but you would be sending said message to the contract, and then the recipient would be able to access it.
Here's an extremely simplified example:
contract Messenger {
mapping (address => string) message;
function sendMessage(address _recipient, string _message){
message[_recipient] = _message;
}
function readMessage() returns (string) {
return message[msg.sender];
}
}
As I mentioned, this is an extremely simplified example to illustrate what I'm saying and it won't do as a "chat app", having said that...
In this example you have a mapping which stores a given message for a user. Basically, anyone could call the sendMessage function, providing an address (the recipient of the message) and the message itself.
Then, the receiver simply calls readMessage() which will lookup the message mapped to his address.
So, as you can see, address A is not sending a message to address B directly, as a matter of fact, you can't "communicate" from an External Account (a human) to another External Account directly, except for sending ether. There has to be a smart contract in between which will receive a command and do whatever it was programmed for. In this case, it receives a message and recipient and stores that data so the recipient can later access it.
Most probably the bytecode bloat comes from the new statements in your code. They're often the trouble maker because they include the code of the contract to be instantiated. You can create contract factories which you can deploy in front. This way you can reduce the bytecode size of your main contract.
E.g.
contract X {}
contract XFactory {
function createX() returns (X) {
return new X();
}
}
contract Main {
XFactory xFactory;
...
Main(XFactory _xFactory) {
xFactory = _xFactory;
}
...
function someMethod() {
X x = xFactory.create();
}
...
}
Best Answer
The ("official") Solidity compiler and associated utilities are written in C++.
But Solidity is its own language with its own grammar.
No. You could write a Solidity compiler in any language you like as long as the output of compilation is valid EVM bytecode. Knowing the language that the compiler is written in doesn't make the target of that compilation any easier to understand or work with, unless by coincidence there are inherent similarities in those two languages.
(Is Solidity similar to C++? Not similar enough that knowing C++ would give you an advantage, other than the fact that knowing C++ means you're familiar with programming in general. In my opinion.)
Difficult to answer objectively.
Back to the original question:
Smart contracts can be written in languages other than Solidity1. Vyper is another popular one, and one which I would argue has greater similarity to Python that Solidity does to C++.
(1 You could write smart contracts in complete gibberish, as long as you wrote a compiler - in any language you like - that could compile that gibberish to valid EVM bytecode.)