Something to learn from: On Telemetry in the Rust compiler

2023-08-01 Thread Hécate via ghc-devs
We should all certainly learn something from reading this post on telemetry and user trust. I know I did: https://estebank.github.io/rustc-metrics.html Cheers, Hécate -- Hécate ✨ : @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD

Re: Telemetry (WAS: Attempt at a real world benchmark)

2016-12-10 Thread Manuel M T Chakravarty
l > >> On Dec 10, 2016, at 1:34 PM, Manuel M T Chakravarty <c...@justtesting.org> >> wrote: >> >>> Simon Peyton Jones via ghc-devs <ghc-devs@haskell.org>: >>> >>> Just to say: >>> >>> · Telemetry is a go

Re: Telemetry (WAS: Attempt at a real world benchmark)

2016-12-10 Thread Moritz Angermann
, or the more restrictive stackage set are non-representative? If we can agree that they are representative of the language and it’s uses, analyzing the publicly available code should provide almost the identical results that large scale compiler telemetry, no? I have no idea about

Re: Telemetry (WAS: Attempt at a real world benchmark)

2016-12-09 Thread Manuel M T Chakravarty
> Simon Peyton Jones via ghc-devs <ghc-devs@haskell.org>: > > Just to say: > > · Telemetry is a good topic > · It is clearly a delicate one as we’ve already seen from two widely > differing reactions. That’s why I have never seriously contempla

Re: Telemetry (WAS: Attempt at a real world benchmark)

2016-12-09 Thread Phyx
On Fri, Dec 9, 2016 at 3:53 PM, Ben Gamari <b...@smart-cactus.org> wrote: > Simon Peyton Jones via ghc-devs <ghc-devs@haskell.org> writes: > > > Just to say: > > > > > > · Telemetry is a good topic > > > > · It is clearly a delicate o

Re: Telemetry

2016-12-09 Thread Ryan Trinkle
I certainly see the value of telemetry in being able to produce a higher quality product through understanding user behavior. However, I am not sure it is realistic. My clients are very conscious of intellectual property and data privacy concerns, and for some of them, even discussing

Re: Telemetry

2016-12-09 Thread MarLinn via ghc-devs
Pretty random idea: What if ghc exposed measurement points for performance and telemetry, but a separate tool would handle the read-out, configuration, upload etc. That would keep the telemetry from being built-in, while still being a way to get *some* information. Such a support tool might

RE: Telemetry (WAS: Attempt at a real world benchmark)

2016-12-09 Thread Ben Gamari
Simon Peyton Jones via ghc-devs <ghc-devs@haskell.org> writes: > Just to say: > > > · Telemetry is a good topic > > · It is clearly a delicate one as we’ve already seen from two widely > differing reactions. That’s why I have never seriously contemplated > doing any

RE: Telemetry (WAS: Attempt at a real world benchmark)

2016-12-09 Thread Simon Peyton Jones via ghc-devs
Just to say: · Telemetry is a good topic · It is clearly a delicate one as we’ve already seen from two widely differing reactions. That’s why I have never seriously contemplated doing anything about it. · I’m love a consensus to emerge on this, but I don’t have

Re: Telemetry (WAS: Attempt at a real world benchmark)

2016-12-09 Thread MarLinn via ghc-devs
assume that their software is doing telemetry, so it feels more plausible. But someone would need to work out whether it had to be opt-in or opt-out, and how to actually make it work in practice. Privacy here is complete can of worms (keep in mind you are dealing with a lot of different law