pegasuscollins

> In Rust, there is exactly one way to create an instance of a struct: you provide a value for each of its fields.

As a user of both rust and and C++, I certainly wouldn't consider the the lack of default constructors in rust to be a good thing. Especially for std types like Vec it is really annoying to have to initialize it explicitly.

> The [dcl.init] section of the spec is about 16 pages long and there are about another dozen about how constructors work in the special member functions section.

That is a bad argument if you're comparing to a language that doesnt have a spec. Maybe a complete, exhaustive rust spec would be much longer than the C++ standard?

Have you actually checked the link? This seems to be a reasonable advanced clone of photoshop in JS; all the basic stuff that you would expect to be there seems to work. Pretty impressive stuff considering its one guy.

Have you seen the relevant reference in RFC3629, page 2? It's explicitly listed there as a feature: "The byte-value lexicographic sorting order of UTF-8 strings is the same as if ordered by character numbers"

Agree that specifying the keys to be ordered >by unicode code points< instead of >lexicographically< would be less ambiguous though.

> Protobuffers can handle that with a lot less muss and fuss than JSON can.

Are you speaking from personal experience? FWIW it doesn't match mine.

What do you mean by ordering? This is easy to miss in the linked "spec" (I did too at first) but there is a sentence:

"Object members must be sorted by ascending lexicographic order of their keys."

You could either stipulate (as you suggested) to always use the smallest width that still fits a number and then prefix with a length byte but that would be wasteful. Ideally something like LEB128 would be used. At any rate, it's not an issue in terms of guaranteeing a bijective mapping.

> The only problem that I can see with this is that Son wants to ensure deterministic encoding, but in my example, 0 could be encoded as an integer of any size or signedness.

To be pedantic: Not really. Assuming your example uses twos complement (what else would it use) and you meant "int32" instead of "uint32", negative zero and positive zero would still be the same encoded value. Also since you said "[u]int32", there is only one size the integer can be: 32 bit. So, in your example, the literal value zero has one and only one unique binary representation, which is "0x00000000"

> Yeah right, because there is only one lexicographic order in the world.

The specification tells you all strings (keys) must be UTF8. There is only one lexicographic ordering of UTF8 strings (RFC3629, page 2). This should probably be explicitly mentioned in the linked specification though.

Pretty much every binary format will encode integers using a fixed width or varlen scheme in "base 2".

This generally is done for two major reasons: First of all, such an encoding is significantly easier and cheaper to parse than a base10+ascii (human-readable) encoding.

I encourage you to write a parser that reads a fixed, 32-bit binary number (1) and another parser that reads a JSON-formatted number string into an internal variable in a classic language like Java or C++. You will immediately see the big difference in complexity. Make sure your parser can also deal with a message that contains more than just one number, i.e. the parser should be able to tell at which byte index an encoded number begins and ends. Even if you're using a language or library where this is hidden from you (e.g. by using parseInt or std::stod) the same work still happens behind the scenes.

The other reason is that for most numbers and fixed/varint encoding schemes, the "binary" representation will be much more compact. Storing the number "1000000" in base10+ascii (human readable) takes at least eight bytes. Storing the same number in a fixed 32-bit integer encoding takes four bytes. Using a varint encoding scheme might allow you to get down to three bytes.

(1) Ignoring stuff like byte order and representation of negative numbers; this is usually fixed in the protocol/format specification.

When comparing the two, keep in mind that JSON is a self-descriptive format while protobuf is not.

Less taxes in the UK means higher take home from the 55k than you would have in germany. And you have to factor in that the 55 figure is probably from a time where GBP to EUR was still 1.4:1. Consider that 55k GBP might have been ~4.5k EUR/mo take home not too long ago vs ~2.5k EUR/mo take home from 50k EUR in germany. Still shitty, but not as shitty as it seems now.

EDIT: Also, using current exchange rates, the cost of living in one of the larger cities (Berlin, Munich, etc) in germany isnt that much lower compared to London anymore.

So what happens when Karpeles needs to sell all of those bitcoins to make the creditors whole in yen? And also: when will this happen?