notanaverageman

Not that I regret it, but I found out that creating a community around an open source project is not like what you expect. I've been working on a tool for a very popular project for more than two years, adding features, refining it etc. since I had my time. Reading many comments on HN and Reddit on how people don't like current dominant tool or its alternatives, what features they expect etc. I thought I've got one that people would like to use.

I have open sourced it and shared it on a few places and got zero traction. Ok, I thought, I can talk about it here and there, so it would get more visibility. People don't like it much since I'm promoting my own tool. I posted a blog post about some technique on tool's website and people seemed to like it on Reddit. A few people wrote comments like "interesting" or "amazing" and I was happy for the first time. Then someone wrote that you should not make your friends/alt-accounts comment on your posts, it's cringe and that happiness went away.

I've been a lurker on social media nearly whole my life. Putting myself out there feels like an unpleasant experience. I'm still deciding whether to continue or just go back to lurking and keep my tool to myself.

I'm finishing the work of adding apply, list, delete mechanism to my Kubernetes package manager.

The tool is written in Go and exposes a JavaScript interface (like k6) to generate manifests using both template-based and object oriented approaches. It is similar to cdk8s, but is more flexible, doesn't require a dev environment, and allows sharing packages. The apply mechanism will be like kapp, but using kubectl's apply sets.

It already has the features to generate manifests to be used in GitOps. With this addition and the next one, which will be waiting for generated resources, it will become a fully featured package manager.

https://github.com/ohayocorp/anemos

I suggest checking out Anemos (https://github.com/ohayocorp/anemos), the new boy in the town. It is an open source single-binary tool written in Go and allows you to use JavaScript/TypeScript to define your manifests using templates, object oriented approach, and YAML node manipulation.

You can read a comparison with Helm here: https://www.ohayocorp.com/anemos/docs/comparison/helm

P.S. I am the author of the tool.

Meanwhile I'm trying to adapt ESM only packages to CJS since Goja (JS runtime library for Go) doesn't have ESM support. [1]

And yes I know that Grafana has a fork called Sobek that has ESM support, but it is tailored for k6 and they don't have plans for making it easier to use. [2]

[1] https://github.com/dop251/goja/issues/348

[2] https://github.com/grafana/sobek/issues/49

The hardest thing for me when I started using Go after a decade of writing C# is to accept that Go and C# are very different and Go is a much simpler language. It is actually more similar to C than C#.

For a time I tried to write Go like it is C# and got frustrated a lot. After accepting that they are fundamentally different languages it became much easier.

For a large group of people, lifespan of a phone is the same as the lifespan of the battery. They complain that the phone gets slower day by day, but they don’t know what causes it. Most of them come up with deleting WhatsApp messages so that the storage will be freed and phone will get faster.

Showing a persistent notification that “the battery has degraded and should be replaced” can increase the average lifespan of a smart phone significantly. These people don’t really care about shiny new apps or security patches. They just call people and send messages on WhatsApp. And maybe do some browsing on Facebook.

On iPhones, if the battery is degraded at least it drains up quickly and this hints that there is a problem with the battery. However, on most Android phones even 4-5 years old batteries last at least a day and they do so by reducing the CPU clock speed significantly. I know that Apple got fined for doing this in the past, but I haven’t heard any Android brand got fined for the same thing.

As anecdata, I have replaced the battery of my iPhone 6S at least three times and I will probably replace it again in a few months. And the phone is still very much usable.

There is already an analyzer for it: https://github.com/microsoft/RoslynClrHeapAllocationAnalyzer

More than 50000 people died there in one of the fiercest fights of WWI and many of those people was buried there without a grave. So those lands are treated as graveyards of martyrs, and therefore have historical and cultural importance.

Turkish people would not accept building the bridge and the roads there even if it was cheaper.

You still have to use stackalloc to allocate on stack. With Span<T> you don’t have to use the unsafe keyword and you can pass the allocated array to other functions easily.

Any method does an extra null check and a cast to ICollection<T> which incur unnecessary performance degradation. Of course this is in micro optimization scale. If you do not call Any() on a hot path it does not matter which one you use.

I use it for structured logging, which makes filtering and searching very convenient. E.g. I can filter by an object’s id and a property to see which tasks change the property of that specific object and in what order. Serilog[0] and Seq[1] are the best tools for this in my opinion.

[0] https://github.com/serilog/serilog

[1] https://datalust.co/seq

Thanks, I removed unnecessary parts. It should be better now.

Note that most of the performance improvements come from PGO, which is enabled with following environment variables. PGO is not enabled in .NET 6 by default, but will be in .NET 7 IIRC.

  set DOTNET_ReadyToRun=0 
  set DOTNET_TieredPGO=1 
  set DOTNET_TC_QuickJitForLoops=1

Here are my own benchmarks from a CPU intensive application without any IO and already optimized for allocations. Application runs a task graph either serially or in parallel.

  .NET 5
  --------------------------
  |      Method |     Mean |
  |------------ |---------:|
  | RunParallel | 473.4 us |
  |         Run | 513.5 us |

  .NET 6
  --------------------------
  |      Method |     Mean |
  |------------ |---------:|
  | RunParallel | 452.5 us |
  |         Run | 499.8 us |

  .NET 6 PGO
  --------------------------
  |      Method |     Mean |
  |------------ |---------:|
  | RunParallel | 381.8 us |
  |         Run | 412.2 us |

  .NET 5 - .NET 6     -> ~5%
  .NET 5 - .NET 6 PGO -> ~20%

Here is what I learned from micro-optimizing a .NET application:

- Use BenchmarkDotNet[0] for general measurements and Visual Studio profiler tools for detailed inspection. They help a lot.

- Memory allocations matter. Using capturing lambdas, LINQ, even foreach on interfaces introduce allocations and slows down the application. You can use ClrHeapAllocationAnalyzer[1] to find these hidden allocations.

- Using abstractions with interfaces and casting back to concrete types cause some overhead, though PGO will probably eliminate most of these.

- Use LINQ cautiously as its variants are mostly slower than explicit coding. E.g. .Any() vs .Count == 0

- Checking Logger.IsEnabled() before calling Logger.Debug() etc. helps a lot. You can even automate this with Fody [2], but it breaks Edit&Continue and possibly .NET Hot Reload too, so it may hinder your productivity.

[0] https://github.com/dotnet/BenchmarkDotNet

[1] https://github.com/microsoft/RoslynClrHeapAllocationAnalyzer

[2] https://github.com/jorisdebock/LoggerIsEnabled.Fody

WPF is still Windows only. It will not work on a Linux machine.

Each generation has its own problems. Today's problems may seem scary to us, but world has seen worse days.

From Billy Joel:

  We didn't start the fire
  It was always burning
  Since the world's been turning
  We didn't start the fire
  But when we are gone
  It will still burn on and on and on and on