WingNews logo WingNews GitHub [2]

giovannibajo1's comments

giovannibajo1 | 6 years ago | on: Qt Offering Changes 2020

My company has been a Qt partner for 10 years now. It’s embarrassing how many companies we met that were not complaining with the open source license — most of them did comply after they talked to us though. Our market (Italy) is specially allergic to runtime licenses (required for embedded products, which is 90% of what companies use Qt for, at least here) so they prefer to bend over for compliance rather than spending on a runtime license.

giovannibajo1 | 6 years ago | on: The dark side of GraphQL: performance

The last comment specifically shows that there is one big part of degradation that depends on the usage of promises. This is either a platform or library problem, but surely not a GraphQL problem at all.

giovannibajo1 | 6 years ago | on: Why are my Go executable files so large?

Because one of the mantra of Go is not telling users to have a "debug" build and a "release" build. The development build is the one that goes into production, with no difference in optimizations, symbols and whatnot. This has pros and cons, like all tradeoffs.

giovannibajo1 | 6 years ago | on: The Go runtime scheduler's way of dealing with system calls

There is a difference though: libSystem on Darwin is a very thin wrapper over the kernel syscalls; on the contrary, libc is a library that was designed for C, then standardized in POSIX, and has several layer of abstraction over kernel syscalls including many bad defaults that are universally recognized as wrong today (eg: libc’s created file descriptors will all inherit by default).

giovannibajo1 | 6 years ago | on: SQLite is easy to compile

Another good example is the Go compiler. Assuming you have any version of Go in your PATH, it's:

    git clone https://github.com/golang/go
    cd go/src
    ./make.bash     # or make.bat for Windows
And that's it. You can then use "bin/go" to compile your projects.

giovannibajo1 | 6 years ago | on: Linux kernel drivers in Rust might become an option in the future

But the point is that there is so much provably safe code that the borrow checker doesn’t understand. Let’s not get confused: Rust borrow checker forces you to write in a very narrow space that it can understand, which is a very small subset of safe programs. Sometimes it’s worth it to be so constrained, others simply don’t.

giovannibajo1 | 6 years ago | on: Deconstructing Google’s excuses on tracking protection

Depends on your point of view. Chrome is going to use the same architecture that Safari has had for a few years (on iOS and Mac): data-driven content blocking, where rules are declared by the extensions, and then read and implemented by the browser core with no JavaScript involved on each request.

Javascript-based content blocking is technically slower because you need to invoke V8 on all requests, and then it’s up to the extension to make sure that the JavaScript code is fast enough. It surely is more flexible (as you can do whatever you want in that javascript code) but it’s hard to beat a simpler, data-driven content blocking engine written in native code and integrated in the core.

Whether this difference in resources does have a concrete impact or not, remains to be seen. The fact that Apple Safari did it first makes me believe that there is some truth in the technical merit argument; surely Apple didn’t want to make sure their content blockers were ineffective, but was actually using the same approach as always: providing a possibly “weaker” but far more efficient implementation (compared to “de facto standards” on other platforms) to protect iOS resources usage.

giovannibajo1 | 6 years ago | on: Await in Rust

There have been comments in this HN thread that this implementation of continuations based on futures is supposedly more performant than a stack-pointer switching one (like green threads). Can you elaborate on how? It looks to me that it should instead be slower (and even much slower if the stack depth is deep).

giovannibajo1 | 6 years ago | on: Await in Rust

Can somebody explain the performance characteristics? For instance, let’s say I have a deep stack of 15 async calls. If the deepest call yields, what code is executed? Does it “jump back” to the top ala “longjmp” or it needs to return back up the stack frame by frame? And what happens when it resumes execution? IOW is the overhead linear with the stack depth or not?

giovannibajo1 | 6 years ago | on: A Map That Made Los Angeles Make Sense

Well, in that case, Google Maps would wake up and suggest an alternative route.

The point I'm trying to make is that Google Maps (actually, all navigators) is biased towards shutting the brain down and just focusing on next turn. It could do much better in describing the overall route, and even letting you drive by yourselves parts of the route you already know -- it can still tell you to do alternates routes if there's traffic though.

Obviously the workaround is to skim the overall route and decide by yourself what to do, whether to follow directions or not on certain parts. This is what I always do -- just because I want to make sure that I still know my way without a navigator and it's also a good way to learn new parts of the city (or new cities) that you don't know. At the same time, Google Maps isn't really helping on this.

page 5
newer more