Possibly? I'm less familiar with building iOS applications, but Depot is providing a native Linux amd64 builder VM, so if you're able to build an iOS app in that environment, it should just work.
This is practical implementation when working with websocket. When server got an error or timeout waiting for client pong, it closes the connection, at the same time client send “health check” message without receive reponse (whatever message value of your choise) it closes the connection and reconnect.
Great point, the research should also investigate more about this case, since its get published it will create more negative effect to people who dont believe in vaccine but believe in themselves they will never die because of Covid
> Come to think of it, I searched and didn't find a "distributed disk cache with optional replication" that can be used in front of S3 or whatever dataset. You can use nginx/varnish as a reverse-proxy but it doesn't have "distributed". There is Alluxio, but it's single-master.
If you think more about this, it will be like distributed key value store with support both disk and memory access. You can write one using some opensource Raft libraries, or a possible candidate is Tikv from PingCap
> If you think more about this, it will be like distributed key value store with support both disk and memory access. You can write one using some opensource Raft libraries, or a possible candidate is Tikv from PingCap
Languages have many competing goals. It shouldn't take long to get used to u64 over, e.g., unsigned_int64, and brevity is valuable in its own right. Too many wasted characters can obscure the flow of a program and make it slower to read and understand.
Is it the right choice? I could be persuaded either way. I know it's one I've personally made before, choosing rebindings like i256 and cmpeq8 when doing a lot of bit-twiddly vector code.
I realize I'm stating the obvious, but 'i' is shorter while 'int' is slightly clearer. So I think there's a valid argument for both, but personally I think clarity is more important.
Having said that, less typing and clutter are also beneficial, so it's really a net natural debate.
Clarity is important but I don't see how it suffers from that
except for people reading code in that language for the first
time. To my knowledge the languages shortening this to one
letter are also the kind where the programmer can be expected to
already know the fundamental data types, otherwise this syntax
won't be the biggest problem.
Personally I prefer it, mostly for subjective reasons but I
think it makes sense - in the case of Rust it was the easiest
syntactic novelty to get used to, things like lifetime
annotations are a different beast.
That's a weird strawman. The long names are irrelevant here. It's not about C types overall, just stdint. Each of the languages mentioned uses intN in some form.
When people do something differently than most other popular implementation it's good to ask if that's worth it.
> It existed before. Golang, Haskell, C, D (both kind of - int32_t), caml, and many others. It's i32 that deserves a "why this one?" comment.
"i32" and "u32" are used because they are short (and used often). They are just typedef away in C and are used ~forever, did you look at Linux kernel for example?
But I'm with you on the general sentiment - beyond trivial, lexical things like type names (which almost any language allows you to redefine anyway), Zig appears to have strong NIH mentality in regard to the syntax. Trying to replace C, but go out of their way trying to invent syntax just to be different from it and most other things too.
And a lot of people appear to notice and pay attention to this, as the discussion here shows.
Syntax has a heavy influence on function, so if all languages had very similar syntax, they couldn't be ideologically diverse without jumping through ridiculous hoops.
> couldn't be ideologically diverse without jumping through ridiculous hoops.
Jumping thru hoops is what Zig seems to choose with its unorthodox, different-just-to-be-different syntax. I wonder, how many will want to jump with it?
> Jumping thru hoops is what Zig seems to choose with its unorthodox, different-just-to-be-different syntax.
Did zig run over your dog or something? You seem to be particularly hostile in your comments about it. As someone who has participated in discussions about zig syntax for years, I can assure you that a significant amount of thought and consideration goes into these choices. It is not "different-just-to-be-different". In fact, the very syntax being complained about is derived from other languages!
No, I'm adept of (anti)survivorship bias. In other words, I like to study mistakes. And Zig offers a great field of study in that regard, as many issues are seen with a naked eye (i.e. even to casual passers-by).
at first I guess it'd be great, finally eff found a solution that any companies can implement their own security layer that's compliant with new standard and EME, but it's not.
Even if W3C accepted this open letter and changed, there would be nothing changed at all.
Most people - who know C or any programming language do not ask for a book to read, just pick one, read it carefully, do something based on it, make mistakes, learn from them. Time went by, write a book!
