Hacker News new | past | comments | ask | show | jobs | submit | reactordev's comments login

struct tags greatly reduce the boilerplate code required to map fields to fields. It’s really quite novel once you understand it.

> struct tags greatly reduce the boilerplate code required to map fields to fields.

Are you somehow under the impression that Go is unique in having a terse way to map fields to fields?

> It’s really quite novel once you understand it.

It's the opposite of novel, putting ad-hoc annotations in unstructured contexts is what people used to do before java 5.


No, not at all, but considering C has no such thing, I’ll take it.

It's not very novel. There's far better ways of solving this than allowing a random string to be embedded as aux information to a struct field. Examples: F# type providers, or OCamls PPX system for extending the language in a well defined way. Macro rewriting systems also allow for better safety in this area.

This allows you to derive a safe parser from the structural data, and you can make said parser be really strict. See e.g., Wuffs or Langsec for examples of approaches here.


I’m not disagreeing that there are better ways to solve this given how other languages have implemented theirs but considering the constraints they had at the time the Go team designed this, it allowed them to implement marshaling fairly easily and leaves it open for extensions by the community.

> considering the constraints they had at the time the Go team designed this

What constraints? Ignoring decades of programming language developments since C89?


Exactly. DRM isn’t going anywhere so long as copyrights exist.

Not even that. Companies are already lobbying massively for selective enforcement of copyright as to not harm the AI boom (immediate jail terms for individuals torrenting a movie, "it's a complex issue" for AI companies scraping the entire internet)

But even the DRM that is already there often only uses copyright laws as suggestions. E.g. YouTube's takedown guidelines are defined through their TOS, not through the DMCA.


In game dev they definitely do.

I think this is indeed the advantage of this paper taking C++ as the language to compile to SPIR-V.

Game engines and other large codebases with graphics logic are commonly written in C++, and only having to learn and write a single language is great.

Right now, shaders -- if not working with an off-the-shelf graphics abstraction -- are kind of annoying to work with. Cross-compiling to GLSL, HLSL and Metal Shading Language is cumbersome. Almost all game engines create their own shading language and code generate / compile that to the respective shading languages for specific platforms.

This situation could be improved if GPUs were more standardized and didn't have proprietary instruction sets. Similar to how CPUs mainly have x86_64 and ARM64 as the dominant instruction sets.


This is the future. Hardware has already standardized more towards USB HID than in previous decades, Linus interview included. When AI can develop these device drivers based on just probing the HID info, we’ll be on Cloud9. Because maybe then, we’ll get the year of the Linux desktop.

Such standard interfaces are rarely the problem, though there is often a headache of dealing with the pile of 'quirky' hardware that just so happens to work well enough with exactly what windows happens to do. The pain point is all the things that aren't that. Nonstandard, niche hardware which maybe has a few thousand users, or big and complex interfaces like graphics cards which are basically whole OSs on their own.

Pretty sure if your device actually just uses USB HID, it already works on Linux without a custom driver.

What requires a custom driver is when your device adds its own non standard features.


USB it's a nightmare.

Sarcasm is too for some

They will fuzz your uniqueness into a profile no matter how many times it changes. There’s enough there to identify you based on your fingerprint and behavior.

right, but it is most powerful if they can combine unique fingerprint with identity fingerprint via login over time, so as to build up a long term behavioral profile. Identity is not good enough because you will sometimes not be logged in, fingerprint via uniqueness may not be enough because your behavior may change in different environments.

I assure you it’s enough even without a login

One can be uniquely identified but the info gathered can be made pretty useless (at least for commercial purposes). The State spying on one is another matter altogether, one has to assume one is then petty transparent.

For example, my default mode is no JS. If JS must be used then cache, cookies, history, etc. are erased by default (usually they are anyway). I use multiple machines and they have multiple browsers (there's five on this phone alone), and if I think it's important I'll change browsers between sessions for a given site—that also means an IP address change (router reboots, etc.). On Android, remove all Google apps, have no Google account, use a firewall and only allow apps from F-Droid to have internet access.

Can't say I've clicked on an add in 20 years unless accidentally, and anyway I see them very rarely sans JS. If I do I never linger over them to give the impression I'm reading them.

Browsers have block lists some very extensive (e.g. Privacy Browser), so do OSes' hosts files, location is off, etc. There's other stuff too but you get the gist.

Why bother you ask. Before the internet I could look at adds in magazines, buy something without giving name, rank and serial number, and or my address, or phone number and so on and be pretty certain manufacturers and advertising agencies weren't tracking me.

In short, I had some autonomy I could call my own.

So why is it now a prerequisite to give all that personal stuff away just because I've joined the internet? That wasn't the plan when the internet was devised.

I see what I do as basic self protection.

A final point: what the internet desperately needs is a JavaScript engine that users can tailor to their individual needs. Randomize, machine details, cookie info, and so on. A well designed engine could feed copious junk info back to websites and spoof itself as a 'genuine' engine to the extent that websites wouldn't know what's genuine and what's not.

Widespread use of such a JS engine could do considerable damage to these snooping bastards. The big question is why the hacking community hasn't yet come up with one.


Obviously it would be statistically enough, but logically I find the assurance not convincing enough for all users and cases.

More please

This happens in real life too when a dev builds something using too much copy pasta and encounters a build error. Stackoverflow was founded on this.

I have had to correct AI enough to know it’s the equivalent of a cocky junior dev that read a paper once.

I’ll stick to human emotional support.


Been doing this at Faro Inc since 2023 - I helped build it. The real magic is simply the lookup rasterization on device. Since mobile device GPU’s are fast now it fits inside the geometry shader.

Any word if Faro is working on anything like Leica's Powerlock for laser trackers?

Faro does scanning, not tracking. It shoots lasers in all directions while simultaneously taking 360deg imagery, resulting in high density colored point clouds and gaussian splat pre-imagery. I no longer work there as they up rooted their executive team.

It’s not that we should design for iffy internet, it’s we should design sites and apps that don’t make 1,000 xhr calls and load 50mb of javascript to load ads that also load javascript that refresh the page on purpose to trigger new ad bids to inflate viewership. (rant)

The only thing that works is to roll up your sleeve and take ownership of your deliverables on a level that management wants to see. Provide the manager with all the reports and communication ammunition they require. Once they feel comfortable that you understand their needs, they will leave you alone. Until higher ups decide to go a different direction again.

This is the only way if you want to stay.

Most people won’t tolerate it and will leave. Watch for turnover.


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: