Hacker Newsnew | past | comments | ask | show | jobs | submit | sa46's commentslogin

> US veterans have to seek permission

Retired military personnel, not all veterans.


This is a very off topic tangent, but that makes me quite curious.

What is the difference between "veterans" and "retired military personnel"?


“Retired military personnel” have completed their 20+ years of service and retired with full pension. “Veteran” refers to anyone who has served in the armed forces.

So if you only did 10 years and have military skills this regulation does not apply?

Ahhh, right. I guess that'a a distinction that makes sense. Thanks.

I'm not sure that it is a distinction with a difference in this specific case, because to my reading, the only folks who might not be covered publicly were those who were not officially, formally, regularly, or directly employed by military agencies, while doing the work alongside those who were so employed. Contractors, for example, may not be bound by the clause if they were not previously a reservist, a civilian DoD employee, an enlisted solider, or an officer in the armed forces. I am narrowly reading this to steelman their position, and it seems there might be some narrow wiggle room there, but I'm not sure if that's what they meant of if they're quibbling simply to have something to say. They might be technically right though, you be the judge:

https://dodsoco.ogc.osd.mil/Portals/102/emoluments_clause_ap... | https://web.archive.org/web/20250422185437/https://dodsoco.o...

> WHITE PAPER

> APPLICATION OF THE EMOLUMENTS CLAUSE TO DoD CIVILIAN EMPLOYEES AND MILITARY PERSONNEL

[The following paragraph is from the conclusion, and I think this might be Justice Department interpretations, as I don't think these issues have been tested before the Supreme Court. I am not a lawyer, nor do I speak for the military or Justice Department.]

> The Emoluments Clause to the Constitution applies to all Federal personnel. The Clause prohibits receipt of foreign gifts unless Congress consents such as in the Foreign Gifts and Decorations Act, 5 U.S.C. § 7342. For retired military personnel, the Emoluments Clause continues to apply to them because they are subject to recall. The Justice Department opinions referred to in this paper construe the Emoluments Clause broadly. Specifically, the Justice Department construes the Clause to include not only gifts of travel and food, but also payments such as proportionate profit-sharing. To avoid an Emoluments Clause problem resulting in suspension of retired pay, retired military personnel should seek advance consent through their respective Service consistent with 37 U.S.C. § 908. It is prudent for retired military personnel to obtain advance approval even when there is uncertainty about the Clause’s applicability.

Perhaps there's some nuanced reading of "veterans" that includes folks who aren't armed services, although I think they would likely still fall under the purview of this clause, though I am curious about the factors at play here.

Edit: I think that if you are retired and fail to comply to the Gov's liking, all foreign payments are able to be counted against any military pension you may receive. I am less certain about how non-officers who have no pension are treated, or if they are still beholden to the clause after leaving the armed forces.

Here is additional material from the Commissioned Corps Personnel Manual:

https://dcp.psc.gov/ccmis/ccis/documents/CCPM26_9_1.pdf | https://web.archive.org/web/20250529163709/https://dcp.psc.g...

Found this slideshow that has this test:

https://www.oge.gov/web/OGE.nsf/0/A7C0E4D79F3F6D07852585B600... | https://web.archive.org/web/20250505113229/https://www.oge.g...

> 4-Part test to Determine if the Emoluments Clause Does Not Apply:

> 1. U.S. cannot be a member of a foreign state

> 2. Organization must carry out U.S. foreign policy

> 3. U.S. participates in governance of organization

> 4. Congress approved participation, no concern about divided loyalty


So you think that if you are a pilot that left after 19 years you can go and train Chinese pilots without permission?

Veterans is just another word for retired military personnel. If you were in the military and are not dishonorably discharged you are a veteran. Whether you do 2,3 or 20 years.

I am pretty sure the rule though applies to all regardless of discharge status.


> Veterans is just another word for retired military personnel.

A sergeant who leaves after a three-year enlistment is a veteran, but not a retiree.

The distinction matters because military retirees retain some privileges from their service, most importantly, a pension. Those privileges mean retirees fall under the emoluments clause.

However, a veteran not receiving retired pay is not subject to the emoluments clause as they have no relationship with the federal government. The Congressional Research Service states:

> Former servicemembers with no military status and not entitled to military retired pay can perform [foreign military service] on the same basis as a U.S. national who never served in the armed services. [1]

Interestingly, this implies a retiree could forfeit their retired pay to avoid being subject to the emoluments clause.

[1]: https://www.congress.gov/crs-product/IF12068


> This uses global state under the hood.

Looks safe to me. It uses `crypto/rand.Read` which is declared as safe for concurrent use. The cache is accessed via sync.Pool which is thread safe. As a check, I ran the tests with `-race` and it passed.


Funny timing—I tried optimizing the Otel Go SDK a few weeks ago (https://github.com/open-telemetry/opentelemetry-go/issues/67...).

I suspect you could make the tracing SDK 2x faster with some cleverness. The main tricks are:

- Use a faster time.Now(). Go does a fair bit of work to convert to the Go epoch.

- Use atomics instead of a mutex. I sent a PR, but the reviewer caught correctness issues. Atomics are subtle and tricky.

- Directly marshal protos instead of reflection with a hand-rolled library or with https://github.com/VictoriaMetrics/easyproto.

The gold standard is how TiDB implemented tracing (https://www.pingcap.com/blog/how-we-trace-a-kv-database-with...). Since Go purposefully (and reasonably) doesn't currently provide a comparable abstraction for thread-local storage, we can't implement similar tricks like special-casing when a trace is modified on a single thread.


Would the sync.Pool trick mentionned here: https://hypermode.com/blog/introducing-ristretto-high-perf-g... help ? It’s lossy but might be a good compromise.


It might be. I've seen the trick pop up a few times:

1. https://puzpuzpuz.dev/thread-local-state-in-go-huh

2. https://victoriametrics.com/blog/go-sync-pool/

It's probably too complex for the Otel SDK, but I might give it a spin in my experimental tracing repo.


There is an effort to use arrow format for metrics too - https://github.com/open-telemetry/otel-arrow - but no client that exports directly to it yet.


Other fun fact, Army Rangers trace their lineage to Rogers’ Rangers. Rogers fought for the crown in the Revolutionary War.

https://en.m.wikipedia.org/wiki/Rogers'_Rangers


> The convenience of writing `?` means nobody will bother wrapping errors anymore.

A thread from two days ago bemoans this point:

https://news.ycombinator.com/item?id=44149809


“Simply declaring” is inaccurate description of the Go team’s decision. The team built several proposals, reviewed dozens more, and refined the process by gathering user feedback in multiple channels.

The Go team thoroughly explored the design space for seven years and did not find community consensus.


There are two possibilities.

1) There isn't consensus that improved syntax for error handling is needed in the first place. If that is the case, they should just say so, instead of obfuscating by focusing on the number of proposals and the length of the process.

2) There is consensus about a need for improved error handling syntax, but after seven years of proposals they haven't been able to find community consensus about the best way to add said syntax. That would mean that improved syntax for error handling is necessary, but the Go team is understandably hesitant to push forward and lock in a potentially inferior solution. If that is the case, then would be reason to continue working on improved syntax for error handling, so as to find the best solution even if it takes a while.


I helped with the initial assessment for a migration from Postgres with Citus to SingleStore.

https://www.singlestore.com/made-on/heap/


It's quite a leap from "certain observable behaviors of the runtime" cannot change to Go is a dead-end.

Go regularly makes runtime changes and language changes, see https://go.dev/blog/. Some highlights:

- Iterators, i.e., range-over-function

- Generics

- For loops: fixed variable capture

- Optimized execution tracing

- Changing the ABI from stack-based to register-based.


Maybe not. The macFUSE issue suggests that networked file systems can be supported but some plumbing is missing.

https://github.com/macfuse/macfuse/issues/1025#issuecomment-...


What layers of hardware can comic rays impact? Memory with ECC is largely safe, right? What about the L1 cache and friends?


Anything can fail, at any time. The best we can do is mitigate it and estimate bounds for how likely it is to mess up. Sometimes those bounds are acceptable.


Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: