xedin's comments

On: New Diagnostic Architecture Overview

[xedin]

There is a discussion about introducing "descriptive" diagnostics of the same style happening on the Swift Forums at the moment - https://forums.swift.org/t/pitch-extended-error-messages-dia....

I this it's a great idea and with new diagnostic architecture described in the blog post it would be relatively easy to archive.

[xedin → xedin]

This is the diagnostic produced for similar example using new diagnostic architecture:

error: binary operator '+' cannot be applied to operands of type 'String' and 'Int'

_ = "a" + 1

   ~~~ ^ ~

note: overloads for '+' exist with these partially matching parameter lists: (Int, Int), (String, String)

_ = "a" + 1

       ^

note: candidate expects value of type 'String' for parameter #2

    @inlinable public static func + (lhs: String, rhs: String) -> String
                                  ^

note: candidate expects value of type 'Int' for parameter #1

    public static func + (lhs: Int, rhs: Int) -> Int
                       ^

On: New Diagnostic Architecture Overview

[xedin]

Yes, SwiftUI diagnostics in particular are going to benefit from these changes.

On: Java 8 Library for Building High-Performance, Thre...

[xedin]

It uses Thread-Per-Core architecture where Netty/Reactor use thread-pools to process work and have dedicated threads for selecting from network.

[crudbug → xedin]

So CPU affinity provides further optimization ? I am thinking less context switches.

[1] http://conferences.sigcomm.org/imc/2010/papers/p218.pdf

[xedin → crudbug]

Yes, exactly since it allows for fewer context switches and cache locality not only for the network packets but for disk I/O as well.