acln

perf and pprof.

> and the world would certainly be a better place if everybody coding C or Go switched to Rust

Perhaps. Let's engage in a thought experiment. Sorry for moving slightly off-topic, but the line I quoted made me think about this.

Someone fashions a magic wand, which you can wave over C, C++, and Go programs / libraries to instantly re-materialize them as idiomatic Rust, while preserving all of the "good" output they produce, and simultaneously removing the "bad": all memory safety and data race related bugs they exhibit.

You get to use this magic wand on any program you like, instantaneously. You do so, creating linux-rs, glibc-rs, chromium-rs, etc. in the process. You cargo build all of this new software and replace the old C / C++ versions with it, in-place.

In the brave new Rust-powered software world, does your day-to-day computing experience change? It is materially better?

Speaking for myself, the answer is "no", unfortunately. Perhaps this message is coming from a place of frustration with my own day-to-day computing experience. Most software I use is much more fundamentally broken, in a way in which doesn't seem to be dictated the programming language of choice. The brokenness has to do with poor design, way too many layers of absolutely incomprehensible complexity, incompatibility, and so forth. I don't remember the last time I saw a Linux kernel oops or data corruption on my machine, but I am waiting _seconds_ to type a character into Slack sometimes.

I like most of the ideas behind Rust (I don't like the language itself and some of the choices the authors made, but that is another discussion). However, I think there is only so much you can fix with the shiny and sharp new tools, because it seems to me that most issues have little to do with low level matters of programming language or technology, but with higher level matters of design, taste, tolerance for slowness / brokenness / incompatibility, etc.

It's up to the application author in that case, unfortunately. stat() enters the kernel and resolves in one shot, so it requires a whole thread. I haven't read into it very carefully, but on Linux, perhaps the new io_uring business is going to change this state of affairs. For now, however, you need a semaphore of your own.

The most important property of Go for me is that the language is not red/blue. [1]

This enables I/O interfaces to be truly universal, covering just about everything from files on disk, to pipes, to in-memory buffers, to sockets. This feature facilitates a style of, for lack of a better word, generic programming that is hard to come by in other systems.

I find basically any other language or platform except Go lacking and unpleasant in this regard, due to the viral nature of asynchronous functions, which never disappears entirely, no matter how much syntactic sugar is sprinkled on top of it.

Things like mismatch between event reactors or asynchronous frameworks do not exist in Go. Interfaces Just Work, and the entire ecosystem uses them.

[1] http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...

I've used OpenGrok for this in the past. These days, I like to run it in a container, so I don't have to deal with Java and Tomcat myself.

Sub-1ms STW pauses, even for very large heaps.

I like my HTTP package to actually speak as good an approximation of HTTP as it can, so fasthttp wouldn't be my first option.

Furthermore, the HTTP stack doesn't show up on most web servers' profiles. net/http is better understood by the community, interoperates with libraries better (e.g. golang.org/x/oauth2), and is better supported.

Use net/http.

It opens a ~190 MB JSON file[0] in about 2 seconds on my machine. Scrolling and jumping around the file feels very smooth. Editing is also crisp. Writing the file back to disk takes about as long as opening it.

[0]: https://github.com/zemirco/sf-city-lots-json

I use GOPATH=$HOME. All the code (Go and other languages) lives under $HOME/src.

Under certain conditions, it does not.

https://golang.org/pkg/net/#hdr-Name_Resolution

Balance (194)

  ^<.*>$|^<<.*>>$|^<<<.*>>>$