Merovius

19 ms·

151.
by Merovius 10y ago
It's not a Google product. So no. (not that I'd agree with it not adhering to those roots currently. Just that this project has nothing to do with company policy)
152.
by Merovius 10y ago
> It was unfortunately obvious that the writer had insufficient tech chops when use the phrase That's a direct quote from the linked page. Unless you are suggesting that the authors of fuchsia have "insufficient tech chops&quot
153.
by Merovius 10y ago
Have you looked at vimeos business model? It is the opposite of youtube. On the latter, you get paid for uploading videos, on the former you pay for uploading them. And you pay quite heftily and even their most expensive option, from what I
154.
by Merovius 10y ago
> the weak typing What do you mean? > nonsense around no-generics What nonsense? > error-prone switch statements What makes them error-prone? > lack of control-of-the-language What do you mean? > not large. Service-units in a
155.
by Merovius 10y ago
> But as working engineers, focusing on the practical problems is, well, the practical thing to do. Well, yeah, I'm an engineer too (just educated as a mathematician) :) FWIW, I tried to solve an engineering problem, namely "ho
156.
by Merovius 10y ago
> they seem to focus their decisions on small-ish scale projects at the expense of large / longer-term ones, and this is the natural consequence. This is - excuse me - a pretty ridiculous claim, given the explicit design goals of go
157.
by Merovius 10y ago
> Yes but only in Go. I don't believe this to be true. I'd say at least most languages/projects would have exactly the same kind of problems (some of them at runtime, some of them at compile time), it's just that in
158.
by Merovius 10y ago
> It's not a problem in languages that come with a package manager, or at least promote a specific one to handle dependencies. No. It is pretty much only a problem in languages with a package manager. Languages without the notion
159.
by Merovius 10y ago
You are interpreting me correctly :) Indeed, the article was written when I started writing that tool and quickly figured out that it was impossible to do satisfactory. I'm a mathematician, so the only satisfactory solution to me would
160.
by Merovius 10y ago
What I was trying to illustrate is, that the notion of versioning is broken in and off itself. By the lessons of the article, pretty much every API change is a breaking change, so you would constantly need to increment the major version, if
161.
by Merovius 10y ago
The issue is that even if you only consider keyed initializers, adding fields is a breaking change, strictly speaking. I tried making clear that I use the compatibility guarantee as a basis in the introduction and I mention this exception
162.
by Merovius 10y ago
The article was created because I was starting to write a tool to do this. After sitting down and thinking about it quickly, I came to the conclusion in the article: There is no non-breaking change (or rather: That determination can not b
163.
by Merovius 10y ago
> The practical backwards compatibility things that I have seen come up Yes, I'm not really talking about practical problems :) This article is mainly a response to various people claiming, "backwards compatibility is easy, it&
164.
by Merovius 10y ago
Author of the article here. Weird to be on HN ^^ If you have questions, shoot away.
165.
by Merovius 10y ago
Unlike f2f I do believe this should be possible without a lot of problems. NaCl isn't that special magical technology and everything that is special needs to be in an RC anyway. And even if you have any implementation bugs; the way N
166.
by Merovius 10y ago
> They both use docker for isolation Docker isn't really meant as a security mechanism. Among other things, you still expose the full kernel API as an attack surface. I can't imagine that they only use Docker, at the very lea
167.
by Merovius 10y ago
> Oh interesting, I didn't realize it was a very special build of Go itself. It's not. It uses NaCl (native client), but that's just a special GOOS/GOARCH pair with a supporting runtime. NaCl is what the chrome sandbo
168.
by Merovius 10y ago
…until, at some point, you run a go command from a different shell or something, where GOPATH isn't set for some reason ;)
169.
by Merovius 10y ago
I don't see any problems with .git. Most go packages use git anyway, it would be pretty amazing if go tooling would break if you have a .git directory anywhere. Re the other question: If you don't run a go command with a path name
170.
by Merovius 10y ago
> Another issue is when you try to use a fork of one of library. A fork of a library is either identical to the original, or a new library. And you could argue (or rather: I do), that it is a good thing that you need to explicitly spec
171.
by Merovius 10y ago
FWIW: I instead started organizing my workspace in the GOPATH layout (that is, I have GOPATH=~ and put a C project cloned from github.com/foo/bar at ~/src/github.com/foo/bar too). It also helps knowing where $r
172.
by Merovius 10y ago
a) I wasn't replying to the article, but to a particular comment about it. b) I disagree with that summary of the article. I believe it's first paragraph should be an adequate indication of what it's point is, that's how
173.
by Merovius 10y ago
There is a difference between "a future-proof GC" and "the future of GC".
174.
by Merovius 10y ago
I don't think this is an actual claim made by go developers. Their arguments for choosing the algorithm they did was (at least as far as I remember, feel free to point me to a source) a) go for implementation simplicity, readability an
175.
by Merovius 10y ago
> I don't agree with Go marketing their GC as if it magically provides no trade offs. I don't believe this to be true. They always point out painstakingly, that the advances made on pause times come with less throughput, for ex
176.
by Merovius 10y ago
Yeah, I thought about that and it definitely is an improvement, but IMHO it still suffers similar problems. In practice, you won't just have logging; you'll add grpc Metadata, user info and whatnot and each thing will slow down al
177.
by Merovius 10y ago
What worries me about this is performance. Contexts are linked lists and adding a new value to log will add a new node to this list, slowing down all future operations involving the context. I didn't look at the implementation, but I,
178.
by Merovius 10y ago
> try to make a contained solution for a contained problem because the general solution may carry with it a number of unforeseen issues Orthogonality is one of the key design goals of go. That means a) keep the intersections of use cases
179.
by Merovius 10y ago
> We've been continually told that our use cases for missing features are just opportunities to explore the existing tooling to solve our problems The proposal pretty clearly explains, why tooling isn't a solution. > And yet
180.
by Merovius 10y ago
Aliases weren't only proposed as a way to implement gradual repairs (and the proposal, also, is for "a way to implement gradual repair", not so much "aliases"). There are several non-transitionary use cases given

More ›