HN user

dlock17

86 karma
Posts3
Comments40
View on HN
Linux is good now 7 months ago

I very much agree with this, it also scared me off Debian Testing initially as well.

I wonder how many potential users have been scared off by the name... Maybe Debian devs like it that way, less annoying desktop users to support.

Go's Sweet 16 8 months ago

Yep, and I personally feel like it's been the biggest stealth marketing of Go through the years.

They're suggesting the video game workers get a better job outside of the video game industry, as their talents would be better compensated elsewhere.

I agree as this is the main reason why I do not work in the video game industry.

I would love to work in it like many others but seeing friends get chewed up and spat out has dissuaded me over time.

I felt the same way, and made my own package for adding slog attributes to an error for easier logging. It's usually all I need for my own custom errors.

https://github.com/Danlock/pkg/blob/main/errors/attr_test.go

I can understand why it's not in the stdlib though, it seems easy enough to run into key overwriting issues if a dependency returned custom errors with attributes.

I appreciate the built in support slog has for slog.GroupValue and the slog.LogValuer interface that enables everyone to build a solution best for their needs.

"classic Gen Z"?

Generational wars are so stupid and so old that Ancient Sumerians complained about the youth on stone tablets...

I wonder what future generations will use to complain about their descendants...

Do you think Charlie Kirk was pushing society's morals forward?

I don't think dismissing chattel slavery or it's ramifications on the modern day will improve the morals of society either.

I may be thinking more about FedRAMP in general rather than just FIPS140-3, but mandating things like keeping user passwords out of logs is a security improvement.

And the average company needs to be dragged kicking and screaming to care about security at all.

Companies don't need any additional reasons to skimp out on security.

The money could probably be more wisely spent if not following FIPS but without FIPS the average company wouldn't direct that money towards security at all.

The automatic part was what I was referring to, yes. I didn't realize you wrote the article, thanks!

The article mentions using the function version to implement all others, but also that the method version would be optimized better.

Would the compiler be able to inline MethodTree's compare even though it's passed in as a function variable to node.insert?

I didn't realize how important order was to type inference.

Are there any real packages out there using these techniques?

This is also my feeling. And I wouldn't even have minded the ? syntax.

It seems that now that Ian's left the rest of the Go team is just being honest about what they are willing to spend their time on.

And I'm more than fine with that, because look at this comment section. You can't please everybody.

I like this, as it also maps well to using defer at the top of the function to wrap any returned errors with metadata.

I've implemented something similar in my errors library relying on log/slog.Attr.

Very cool, hope to see the non CGo FIPS support fully accepted by FedRAMP soon.

What other languages have built in FIPS supported in the stdlib?

To be clear, my problem isn't with requiring a single DSL, it's with writing so many DSL's at work that there's need for a DSL writing framework to crap them out even faster.

At what point do you sit back and ask, is there a way to reduce complexity here? Is it not until you're joining a team where the last guy made dozens of DSL's for all his tools?

That was the main reason I was expecting more than a few real world use cases rather than generalized examples and no examples from their workplace.

This seemed like nuclear overkill for most problems I can think of.

And where it should be used, I can't imagine you can't find a pre existing language (Cuelang maybe) instead.

I was expecting a section at the end where they demonstrate which services need a new language written just for it's configuration, but nope, just general examples.

Also, this should have a (2022) in the title.

Closing the channel is pointless. I don't understand why people get obsessive about closing channels.

It's not needed by the garbage collector, it's not good practice. It's explicitly called out in the official go guide as unnecessary most of the time. [0]

If you have a channel that is only used a single time and then discarded, closing it is literally just wasting CPU cycles. And definitely not "lazy/rude".

[0] https://go.dev/tour/concurrency/4

While I'm sure Goja is great for just JavaScript, using something like wazero allows your app to support more languages (anything that compiles to WASM) while keeping the benefits of CGO.

https://wazero.io/

I've used Wazero myself on C++ -> WASM code but I'm sure you could use Emscripten or something to compile JavaScript to WASM.