No its because 99% of the time people use enums to give names to magic constants... That is it. Go went for simplicity and const+iota achieves it just fine. People act like enums make or break software itself or something.
That seems unlikely to me to be the actual explanation. It could very well be what you prefer or how you would do it, but I can definitely assure you that the Go/other infrastructure teams think about these problems and hear plenty of complaints about lack of union type support.
Yea but with a tiny bit more effort they could have ensured that an invalid value is never assigned to an enum, iterate over the values, ensure switch statements handle every case, etc.
What is with people and their need for enums? Functionally using go const with iota gives you the same damn thing and people use enums that way 99% of the time. I find Rusts reliance on enums annoying as hell. At this point I consider Rust a bandwagon language. The syntax is abysmal and we have had memory safe languages far before Rust. That I wont get into because as a Vulnerability Researcher I find the Rust push super misguided and it sets me off.
To be more clear, I want sum types with exhaustive matching - which Go does not support.
I get by without it Go enums are an inferior representation of the same logical concepts. Sure, I can have (kind, value) and cast things for a hacky sum type for some kind enum. But Go lacks closed enums/exhaustive matching.
You can at least validate the match arms with things like type switches and marker interfaces, but they're still not exhaustive and they're terribly verbose.
And, again, I can get by without them! But I miss them because Rust-style enum representation comes up _so often_, even if you don't like the rest of Rust.
I mean, you have atomic and compound data types. Atomic ones represent single values, like "a string" or "an integer", and compound ones represent multiple atomic types combined in some way, like a struct or an enum. Enums are useful for the same reason structs are useful, they do the same core thing, just model it in a different way. It's the difference between "and" and "or", which are both useful tools.
They don't seem to understand Go much at all. Comparisons to Rust are somewhat misplaced but that's a different topic... Back to errors. Errors are interface values. They are simple yet powerful. You can create sentinel errors that can be wrapped or just passed to be checked then discarded. Go has all the functionality it needs to provide what ever it is Rust cult members believe makes Rust error handling so great. You can use the primitive constructs Go provides to do nearly the same damn things Rust can do and it won't look like a pile of hieroglyphs your local crackhead would draw. Best of all... Its simple and the syntax of Go (veering off topic) doesn't make me want to jump off a bridge. Stop gaslighting yourselves into thinking Rust syntax is reasonable and that its some perfectly proven language with all edge cases put to rest..
I hold a R&D Position at an MIT lab. I also hold gov clearances for DoD work. They are pretty accepting of the fact that a lot of folks in the field are neurodivergent. No one cares because if you deliver results you deliver results. No one cares about shit under the Trump administration because its an absolute joke that has thus far only stood to get in the way of the way we carry out research. The party of "minimal government" sure as hell loves to tell public established institutions how to carry out their own damn business.
The amount of pressure young kids are under... I am surprised the numbers aren't much higher. I grew up with debilitating OCD/Tourettes. I am glad kids growing up today have more resources than I did. Society itself is sick and broken. If that many kids are having issues.. Maybe the system is the problem here?
Ok.. Let’s ask a different question. Assuming development of super-intelligence is possible.. How do you measure it? What criteria satisfies the “this is super intelligence”? You honestly sound like most pseudo-intellectuals I hear discussing this very topic..: Ironic how you think you’re the brilliant one and it’s others who are stupid… Actually not really ironic a fool doesn’t know he is a fool.
I literally gave you the criterion. You can measure, "I have this model that is supposed to compress data. I have this data. Does it compress the data into fewer bits than other models? Than humans?"
Or, "I have this game and this model. Does the model win the game more often than other models or humans?"
Or, "I have this model that takes in states in an environment and outputs actions. I have this environment. Does the actions it outputs have a higher discounted future entropy than other models or humans?"
Your employees won’t rat you out… Just don’t say “sucky” to those above you. If I have a cool ass manager who looks out for me and is real (I’m lucky enough to be at a MIT lab where everyone is cool as hell), I will always have their back…
If you're a manager, consider not saying that up the org chart is "sucky". Almost certainly no one on your team will go tattle, but it can leak out accidentally, such as when someone is flustered over a problem.
More likely, it will leak out indirectly, in a way, if your team starts thinking of itself a little too much as a group that has to stick together against hostile outsiders within the company, either up the chain or sideways. People outside the team will pick up on that's the tone you're promoting to the team.
But it's not just about not wanting impolitic words to come back to you...
For one thing, it's part of your job to help the team work with the company and people outside the team. Not promote a sense of hostile environment. (If there's an intractably hostile environment, then either that's getting fixed promptly, or your people should be escaping.)
A good manager should have the team's back, especially in a hostile corporate environment, but also insulate the team from a lot of noise including some of what they're being shielded from, as a team and individually. Just like personal life, if you care, you don't have to tell people all the things you do for them.
(I was fortunate to have some awesome managers, who knew when to shield and help me, who knew when to (on rare occasions) lower their voice and tell me something that a drone wouldn't, and who always came across as honest and caring. Some of it rubbed off of me despite my strong-minded personality, and I can always just ask myself what would Bill/Kathy/Nancy/Tom do, to name some of the earliest and most formative ones. All highly skilled engineers first, and later managers/mentors.)
Maturity can be many things, but complaining about internet brownie points is not one of them, at least as far as I'm concerned. People disagree with all kinds of things and that's fine, that comes with the territory of having an opinion.
I think this is true 90% of the time, but that 10% of the time is really risky. The high stakes of the bad case make it wise (imo) to avoid saying your company's policy "sucks"
Even in situations where this is true, there's almost certainly a better phrasing than "this new policy sucks," which only communicates an emotion. It is imprecise. Listeners will jump to their own conclusions about why you think it sucks.
You can acknowledge the problems more directly: "I get it, we don't have enough chairs so Wednesday is likely to be a challenge." or "I know mandatory 9-5 is going to disrupt your commute."
A bonus of the more precise approach is you can follow up with "do you have other issues with the new policy that I may not know?"
Oh, MIT LL (from your HN bio) seems to be all about top serious engineering and science R&D.
Would you say it's probably a pretty different cultural environment than the established company and tech startup environments that most of HN works in?
Professional Security Researcher here.. I haven't really seen any models reliably find and exploit a 0day. Folks are are at least TRYING to develop such models internally at the MIT lab where I work, but not sure how far along they are coming yet.. If a model is developed that can find a 0day or two (like Big Sleep which I think maybe found some) I won't be surprised but keep in mind fuzzers find thousands of real 0days with far less compute... These capabilities are of course something worth looking into, but too many people are promising 0day oracles already and that simply just isn't where we are right now (or ever? ). Sorry for bad grammar typing quickly from phone here.
reply