News for hackers. Stuff that matters.

tignaj

Re:Petition to Withdraw Canada's Bill C-22 on Thursday June 11, 2026 @10:50PM (#48499287)
Is ourcommons.ca an official House of Commons website? It says so but how do I verify before I submit the petition with my information?
Re:I/O is no longer the bottleneck? (2022) on Monday January 05, 2026 @10:40PM (#46508479)
If you are looking for a fast format with schema support see STEF: https://www.stefdata.net/

Disclosure: I am the author.

Re:Union types ('enum types') would be complicated in Go on Saturday December 07, 2024 @03:04AM (#42348095)
Here is a fairly efficient version of a simple union like that I did a while back https://github.com/tigrannajaryan/govariant
Re:Cap'n Proto 1.0 on Friday July 28, 2023 @05:10PM (#36913358)
This is also because Google's Protobuf implementations aren't doing a very good job with avoiding unnecessary allocations. Gogoproto is better and it is possible to do even better, here is an example prototype I have put together for Go (even if you do not use the laziness part it is still much faster than Google's implementation): https://github.com/splunk/exp-lazyproto
Re:Logging Practices I Follow on Monday January 09, 2023 @04:57PM (#34316784)
Otel logs aim to record the execution context in the logs.

In languages when the context is implicitly passed (e.g. via thread-local storage / MDC in Java) Otel automatically injects trace id and span id in the logs emitted using your regular logging library (e.g. log4j). Then in your log backend you can make queries like "show me all log records of all services in my distributed system that were part of this particular user request".

Disclosure: I am an Otel contributor, working on logs (work-in-progress, not for production use yet).

Re:Faster Protocol Buffers (2019) on Sunday August 14, 2022 @01:18PM (#32460996)
This. The statelessness of the OTLP is by design. I did consider stateful designs with e.g. shared state dictionary compression but eventually chose not to, so that the intermediaries can remain stateless.

An extension to OTLP that uses shared state (and columnar encoding) to achieve more compact representation and is suitable for the last network leg in the data delivery path has been proposed and may become a reality in the future: https://github.com/open-telemetry/oteps/pull/171

Re:Faster Protocol Buffers (2019) on Sunday August 14, 2022 @01:09PM (#32460924)
Here is a OneOf Go implementation I wrote that hopefully is less ugly and is significantly faster: https://github.com/splunk/exp-lazyproto#oneof-fields
Re:Faster Protocol Buffers (2019) on Sunday August 14, 2022 @01:02PM (#32460853)
Article author here, good to see it on HN, someone else has submitted it (thanks :-)).

If you are interested in the topic you may be also interested in a research library I wrote recently: https://github.com/splunk/exp-lazyproto, which among other things exploits the partial (de)serialization technique. This is just a prototype for now, one day I may actually do a production quality implementation.

Re:Why and how GitHub is adopting OpenTelemetry on Wednesday May 26, 2021 @07:24PM (#27297403)
Please submit a bug at https://github.com/open-telemetry/opentelemetry-go/issues We want to make the SDKs rock-solid.
Re:OpenTelemetry on Wednesday September 23, 2020 @08:54PM (#24574186)
Here is the draft plan for logs: https://github.com/open-telemetry/opentelemetry-specificatio...

Logs are not going to be part of OpenTelemetry 1.0 release (only traces and metrics will). Logs are coming later (no specific timeline yet).

Disclaimer: I work on OpenTelemetry spec and wrote most of the linked doc. Comments/issues/PRs welcome in the repo.

Re:OpenTelemetry on Wednesday September 23, 2020 @08:43PM (#24574099)
Disclaimer: I work on OpenTelemetry spec.

Many tracing solutions settled on 128bits/16 bytes trace ids. Here is Jaeger's rationale: https://github.com/jaegertracing/jaeger/issues/858

It is also recommended by W3C: https://www.w3.org/TR/trace-context/#trace-id

Re:OpenTelemetry on Wednesday September 23, 2020 @08:35PM (#24574029)
Disclaimer: I work on OpenTelemetry specification and Collector.

I don't contribute to Go implementation but I encourage you to submit the feedback to https://github.com/open-telemetry/opentelemetry-go or https://gitter.im/open-telemetry/opentelemetry-go

You can also attend Go SIG meetings and provide the feedback directly. SIG meetings are open for attendance: https://github.com/open-telemetry/community#special-interest...

I am sure the Maintainers of Go implementation will appreciate your feedback.

Re:OpenTelemetry on Wednesday September 23, 2020 @08:31PM (#24573997)
Disclaimer: I work on OpenTelemetry specification and Collector.

It is true that the spec and libraries have been changing. This is to be expected since we haven't yet made a stable release. We are aiming for 1.0 GA release this year. The current plan is to freeze trace spec this week, followed by metric spec freeze in 3 weeks, followed by the release of several language implementations in 4 weeks after the spec freeze.

Like everyone else I wish we could release earlier, but the reality is that making dozens of companies agree on a standard takes time. I am very excited that we are approaching the finish line.

Re:Opnieuw: A simple and intuitive retrying library for Python on Wednesday February 05, 2020 @07:56AM (#22246323)
If you are not familiar with how retrying is used and why exponential back off, jitter, etc are useful here is a shameless plug to a blog post I wrote recently https://blog.najaryan.net/posts/autonomous-robustness/ (the first half pretty much is about all these things).
Re:The interviewer skills ladder for high growth companies on Sunday August 18, 2019 @06:17PM (#20733306)
Thanks for the link, I haven't seen this before, going to read it.
Re:The interviewer skills ladder for high growth companies on Sunday August 18, 2019 @05:17PM (#20732940)
Engineer / engineering manager here.

Nicely articulated article. There is one observation that I respectfully disagree with - the one that says interviews are monotonous and boring.

I have done hundreds of interviews in my career and never found them to be boring. Perhaps one the reasons is I don't do scripted interviews. It is always an exploration for me. I will start with simple questions and if I get good answers I will go deeper and deeper into the subject matter or into the adjacent area. If I don't get good answers I will retract and probe another direction. This is sort of a depth-first traversal of candidate's skills with a heuristic to stop traversing a particular branch if I see it is not a promising direction.

My goal is to discover the area where the candidate is the strongest (obviously within the areas I am interested in for the particular role I am hiring for). It is very fun and almost never boring. The experience is always different because people are never the same. Yes, some candidates are just not good, but even bad ones are bad in different ways.

I know common wisdom for using scripts is to have repeatable and comparable evaluations so that you can choose the best candidate. I understand the desire but I prefer to find the best in each candidate and if it means I have to use a lot of gut feeling and intuition to make the final decision then so be it, I believe it still results in better overall results. The idea to choose the person I want to hire based on how many answers to my standard questionnaire they got right was never appealing to me.

I can totally see how if you do scripted interviews it can become boring, so don't. Interviews can be fun and it can be a creative process.

Another way interviews can be fun is if you find someone who has stronger skills than you do in a particular area. I love it when a candidate teaches me something new. Find where their strength is and let them shine.