17 ms·

Is it safe to use __secret_internals_do_not_use_or_you_will_be_fired?

350 points by shawabawa3 5y ago

BitwiseFool 5y ago
Seems like a dumb question, but I find that even BLATANTLY_OBVIOUS_WARNINGS are so much more effective if there is a 'why' that explains the danger.
- quietbritishjim 5y ago
  Here it seems "INTERNALS" is the "why". If it's not a public API then of course it could change or disappear without warning between releases (including minor releases).
  - verdverm 5y ago
    Go handles this by not allowing 3rd party to import a package path with internal/ in it. Only the current module can
    - MaulingMonkey 5y ago
      Ancient vanilla JS can accomplish similar by using wrapper functions. var React = (function(){ var React = {}; var __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED = {}; ...code extending/using React etc... return React; })(); // accessible: React.whatever // inaccessible: __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED However, there's always caveats where language level access controls don't let you quite express the access restriction you want. Perhaps you want to expose something to other official modules from the same constillation of libraries, for example (meaning you wouldn't be able to use Go's "internal"), without comitting to supporting the semver contract for any other arbitrary user of your API (meaning you might resort to similarly scary names.)
      - ______-_-______ 5y ago
        iirc, react-dom (a separate package) needs to access that property as well, which is why it's exposed in the first place
      - udbhavs 5y ago
        Private properties in JS classes are syntactic sugar that compile to variable definitions like this in the object's scope
    - mdoms 5y ago
      Most sane languages have visibility modifiers. This link refers to Javascript so...
      - verdverm 5y ago
        Go did that with casing, so you can tell visibility without lookup or needing to think. The internal/ is a package level restriction, so somewhat orthogonal in that they are for different levels
    - drdaeman 5y ago
      Which is awful, because I've seen a number of FLOSS projects that have perfectly good reusable code in their internal/ subdirectories. And I mean code by no means unique or specific to those projects. And whoever says something about instability or APIs being subject to change without notice - they're wrong because those are Go git repos and one can always pin to an old tag or even a commit SHA. If something is unusable (too specific, too fragile, too flaky), no one would use that anyway. A warning is fine and even welcomed, but a block is a slap in the face.
- deleted 5y ago
  [deleted]
- marcosdumay 5y ago
  It's certainly not dumb. If you look at every large library, there are some forbidden internal symbols that are used in a lot of 3rd part projects. Many times those are more stable than the API, and often enough they get published as part of the API once a lot of people decide to depend on them.
  - wk_end 5y ago
    It's maybe not dumb to use the forbidden internal symbols, but it's certainly dumb to go ask the folks who through naming and documentation have communicated almost comically loudly and explicitly that they don't want you using the symbols if it's cool if you use the symbols.
    - marcosdumay 5y ago
      You would be surprised about how many times I've seen the internalVariableDoNotUse symbol to be exposed on the formal API of a library because everybody uses it already, it would be too much work to change it.
- dmd 5y ago
  One of my favorites is the warning you get if you enter the shell of an Oracle ZFS storage appliance: +-----------------------------------------------------------------------------+ | You are entering the operating system shell. By confirming this action in | | the appliance shell you have agreed that THIS ACTION MAY VOID ANY SUPPORT | | AGREEMENT. If you do not agree to this -- or do not otherwise understand | | what you are doing -- you should type "exit" at the shell prompt. EVERY | | COMMAND THAT YOU EXECUTE HERE IS AUDITED, and support personnel may use | | this audit trail to substantiate invalidating your support contract. The | | operating system shell is NOT a supported mechanism for managing this | | appliance, and COMMANDS EXECUTED HERE MAY DO IRREPARABLE HARM. | | | | NOTHING SHOULD BE ATTEMPTED HERE BY UNTRAINED SUPPORT PERSONNEL UNDER ANY | | CIRCUMSTANCES. This appliance is a non-traditional operating system | | environment, and expertise in a traditional operating system environment | | in NO WAY constitutes training for supporting this appliance. THOSE WITH | | EXPERTISE IN OTHER SYSTEMS -- HOWEVER SUPERFICIALLY SIMILAR -- ARE MORE | | LIKELY TO MISTAKENLY EXECUTE OPERATIONS HERE THAT WILL DO IRREPARABLE | | HARM. Unless you have been explicitly trained on supporting this | | appliance via the operating system shell, you should immediately return | | to the appliance shell. | | | | Type "exit" now to return to the appliance shell. | +-----------------------------------------------------------------------------+ I like how it explicitly says "no, seriously, Mister Unix Wizard, we mean YOU."
  - duxup 5y ago
    >"no, seriously, Mister Unix Wizard, we mean YOU." That makes sense as they're the folks who will get in trouble. Rando person probably turns back at this point "nope this isn't what I wanted". Guy who thinks he knows better is the one who keeps going and freaks out when it hits the fan.
  - Gaelan 5y ago
    +-----------------------------------------------------------------------------+ | You are entering the operating system shell. By confirming this action in | | the appliance shell you have agreed that THIS ACTION MAY VOID ANY SUPPORT | | AGREEMENT. If you do not agree to this -- or do not otherwise understand | | what you are doing -- you should type "exit" at the shell prompt. EVERY | | COMMAND THAT YOU EXECUTE HERE IS AUDITED, and support personnel may use | | this audit trail to substantiate invalidating your support contract. The | | operating system shell is NOT a supported mechanism for managing this | | appliance, and COMMANDS EXECUTED HERE MAY DO IRREPARABLE HARM. | | | | NOTHING SHOULD BE ATTEMPTED HERE BY UNTRAINED SUPPORT PERSONNEL UNDER ANY | | CIRCUMSTANCES. This appliance is a non-traditional operating system | | environment, and expertise in a traditional operating system environment | | in NO WAY constitutes training for supporting this appliance. THOSE WITH | | EXPERTISE IN OTHER SYSTEMS -- HOWEVER SUPERFICIALLY SIMILAR -- ARE MORE | | LIKELY TO MISTAKENLY EXECUTE OPERATIONS HERE THAT WILL DO IRREPARABLE | | HARM. Unless you have been explicitly trained on supporting this | | appliance via the operating system shell, you should immediately return | | to the appliance shell. | | | | Type "exit" now to return to the appliance shell. | +-----------------------------------------------------------------------------+ Cleaned up formatting
- dahfizz 5y ago
  It depends. If you give a reason why, it opens up the door for people to argue about whether the "why" is a valid justification. It also can make people feel like the "why" does not apply to them.
  - MaulingMonkey 5y ago
    "why" can be pretty nebulous too. For a larger, widely used project, the question isn't "why" make something internal, but "why not". The safe default is to not semi-permanently commit every half baked bit of code to the public stable semvered API boundary to support for who knows how many years, but to only do so after careful consideration and justification. To add this disclaimer to every single bit of internal code is to drown your codebase in a sea of redundant comments - none of which are specific to the code, or even the codebase, but are instead rehashing "why encapsulation?" 101. This will only train readers of your code to ignore the low-value low-signal comments, and they will then end up asking the same question anyways, and "read the comment that's right there!!!111oneoneone" will be a fustrating experience for everyone, although they might not be able to articulate why. The real question I'm curious about here isn't "why are internal things internal" - but why this internal thing must technically be public. Does this predate ES6 symbols? Is there a plan to switch to those at some point in the future? Is there a tracking issue? Or does this need to be accessed from elsewhere in a manner that makes Symbols awkward to use? Where?
- deleted 5y ago
  [deleted]
- Imnimo 5y ago
  The "why" is that you will be fired, clearly :P
  - Grollicus 5y ago
    I suspect they'll soon have an issue where someone wanted to get fired but it didn't work...
    - MaxBarraclough 5y ago
      Interesting point. In naming it this way, the maintainers have committed to firing anyone who uses it, as an implicit guarantee of the public-facing API. Fortunately they're free to rename it in their next release. Perhaps something snappy like __secret_internals_do_not_use_or_version_specific_retribution_will_follow_possibly_including_firing
- cbhl 5y ago
  I wouldn't be surprised if there is a FB-internal comment (or commit message) that was stripped in the open source repos
deleted 5y ago
[deleted]
ellieh 5y ago
@gaearon has provided some context to this here: https://twitter.com/dan_abramov/status/1489278948517289991?s=20&t=183aL0bOJfiNle2Mh8sRPA https://twitter.com/dan_abramov/status/1489278948517289991?s...
- PragmaticPulp 5y ago
  From the thread: > at one point one of my teammates who is usually very calm and composed deleted some of the internals to “send a message”, which was reverted the next day because it broke a bunch of things for different teams. we didn’t do this again but this started a conversation Oof. I worked with some people who would declare things deprecated, not discuss the deprecation with anyone, and then remove the deprecated code a short while later even if it was still working just fine. Same logic: They wanted to "send a message". And it sucked for everyone. Many meetings were had and we usually had to get management to force them to put the (still working) code back and coordinate with other teams on a deprecation schedule. Please don't force-deprecate things within a company to "send a message" like this. (Note: It wasn't Dan Abramov who did this)
  - aidenn0 5y ago
    Without a bit more context it's unclear that it was this bad. It sounds like the removed it for one day and then put it back in. This may have been the only way to effectively notify people still relying on it. We had a deprecated server that we wanted to decommission. We announced this to the entire company. We pointed everyone to the new server, and asked for feedback if it couldn't fulfill any needs that the previous one did not &c. &c. We announced the date the server was going down. We inspected logs and guessed who might still be using it from IP addresses (one of the many reasons for wanting to deprecate the server was there was a single shared login for everyone using it :/) Finally, on the announced date, we just unplugged the Ethernet cable and got contacted by several different people freaking out, wanting to know what happened to the server. We (as planned) plugged the cable back in and then asked them the same questions that had gone out globally. A month later the server was finally offline for good. One way of interpreting this is that we unplugged the cable to "send a message" but we obviously did discuss the deprecation with lots of people ahead of time.
deltarholamda 5y ago
> I'd like to put my hand in the disposal and turn it on so I can catch the lemon seed that's stuck down there and pull it out. I wouldn't do that, there isn't enough space in there for your hand, a lemon seed is really small, and you will probably lose one or more of your fingers. > Okay, but I have pretty small hands, and I take ninjitsu classes at the Y, I'm pretty sure I can do it. Do you like the nickname "Lefty"?
- efficax 5y ago
  when the power is off it's perfectly safe to put your hand in the disposal
  - ubermonkey 5y ago
    This is a peak HN reply right here.
    - efficax 5y ago
      but I'm right!
      - NateEag 5y ago
        > I'd like to put my hand in the disposal and turn it on You are not right (see the detailed sibling comment to your claim to rightness), and either you didn't understand what the original poster actually wrote or you decided to reply to them but say something that's at best tangentially related to their comment and at worst is a pedantic assault on a strawman. Hence, peak HN. ... actually, "but I'm right!" with no evidence supplied for the assertion might be peak HN.
        deleted 5y ago
        [deleted]
        buescher 5y ago
        The good news is that most people have the good sense not to stick their hands in disposals when they're running.
specialp 5y ago
Wide usage of internal only APIs is why much of the world is still stuck using Java 8 and can't migrate.
- jdkjs 5y ago
  You mean “public APIs not being comprehensive enough”
- deleted 5y ago
  [deleted]
- RedShift1 5y ago
  I use java about 40% of the time at my work and I've never had to use "internal only" APIs. Do you have some examples of these internal APIs?
  - teraflop 5y ago
    There are JDK Enhancement Proposals that discuss the encapsulation of these internal APIs, including some examples and alternatives: https://openjdk.java.net/jeps/260 https://openjdk.java.net/jeps/260 https://openjdk.java.net/jeps/403 https://openjdk.java.net/jeps/403
  - thenickdude 5y ago
    The sun.* package hierarchy for example: https://www.oracle.com/java/technologies/faq-sun-packages.html https://www.oracle.com/java/technologies/faq-sun-packages.ht...
bena 5y ago
It sounds like they're trying to avoid the Windows issue. Where they have incorrect/inefficient/weird behavior carried over from Windows 1.0 because someone somewhere did something they shouldn't have done and now it's expected behavior.
- RedShift1 5y ago
  I know this is like common knowledge but how true is this? Are there examples of those intentionally left in bugs?
  - ______-_-______ 5y ago
    On the Old New Thing blog there are hundreds (maybe thousands) of examples. Here's the first one google decided to show me: https://devblogs.microsoft.com/oldnewthing/20031103-00/?p=41973 https://devblogs.microsoft.com/oldnewthing/20031103-00/?p=41...
  - duffyjp 5y ago
    I don't know if you'd call it a bug exactly, but the fact you still can't name a file "con.txt" or "aux.bat" etc is pretty silly.
  - mdoms 5y ago
    This PDF from Raymond Chen (I don't know the source material) is a great example of the lengths the Windows team had to go to to maintain backwards compatibility between Windows versions. They spent an inordinate amount of time either working directly with application developers or, when that wasn't an option, changing Windows internals specifically to keep problematic Windows apps working. http://ptgmedia.pearsoncmg.com/images/9780321440303/samplechapter/Chen_bonus_ch01.pdf http://ptgmedia.pearsoncmg.com/images/9780321440303/samplech...
  - bena 5y ago
    Sim City for Windows 3.x would read memory it recently freed. This never crashed the program because Windows 3.x was more like a graphical shell on top of DOS. It wasn't a true multi-user or multi-tasking operating system. If you released memory, there wasn't anything else waiting to grab it from you. So the fact that you shouldn't read memory that's been freed, it went unnoticed. Until they tried to run it on Windows 95. Then it would crash. A lot. The game was unplayable. Because Windows 95 was a multi-tasking operating system and it would reallocate freed memory to other programs that may ask for it. So they put a specific check in Windows 95 to see if Sim City is running. And if it was, they essentially sandboxed its memory so nothing else could grab any memory it used. While in this case, this isn't an example of a bug that was intentionally left in, it is an example of code written into an operating system to handle the bug of a single program. But that's how they'd handle it. If PROGRAM X required certain behavior, they'd check to see if that program was running and alter behavior so the program would run. If feels like that's like half of what the registry is for.
koala_man 5y ago
"DO_NOT_USE_OR_YOU_WILL_BE_FIRED" is a running joke at Facebook, used when soft-deprecating a field or method where you can't immediately get rid of all users. Sometimes it migrates into open source products. It's iconic enough that Facebook HQ has a conference room by that name.
- addandsubtract 5y ago
  Do people use the conference room more than once?
  - daveevad 5y ago
    There was a conference room at Yahoo named Sorry! that was used during many rounds of layoffs. The entire floor's conference rooms were all named thematically after popular board games.
    - KineticLensman 5y ago
      > The entire floor's conference rooms were all named thematically after popular board games. Getting OT, but I worked somewhere where the conference rooms were named after birds of prey (Eagle, kestrel, etc etc). The smokers' room was informally known as 'Puffin'
      - daveevad 5y ago
        I'm shocked there was an interior room that allowed smoking. It must not have been in California this millennium. I decided to stop smoking the day Jerry Yang held the door open for me and my band of misfits on our way to the outside smoking area. David Filo once asked me if he could share the panini station I was presently occupying in the cafeteria, URL's. I answered affirmatively but subsequently wished I had uttered "it would be an honor."
        shubb 5y ago
        Still a thing in much of Asia, certainly Japan, Thailand - instead of "smoke anywhere so long as it is outside" it is more "smoke only in the designated place, inside or outside, not in the street". Being able to smoke at an inside restaurant table but not outside the front door out of respect for non-smoker diners very odd. Do you remember the brief period around 2010 where people were vaping at their desks all day in normal office buildings?
cosmic_quanta 5y ago
Reminds me of the `accursedUnutterablePerformIO` function, although this is technically part of the public API: https://hackage.haskell.org/package/bytestring-0.11.2.0/docs/Data-ByteString-Internal.html#v:accursedUnutterablePerformIO https://hackage.haskell.org/package/bytestring-0.11.2.0/docs...
- sterlind 5y ago
  I think this is the first time I've seen an API describe itself as a "malevolent agent of chaos." > The carcass of many a seasoned Haskell programmer lie strewn at its feet. the docs are genuinely entertaining.
  - _0ffh 5y ago
    What's also quite cool that it discourages and additionally impedes usage of the function, because it really is called by a different name. I think it's true name is, ermmm, "nlnPrfrmNT". (I've ultimately decided to stay on the safe side too and not commit into writing the fullness of the dread name.)
mfringel 5y ago
As far as I know, there is still a configuration I wrote at a previous employer where I left the remark: ----- -- STOP. YES, YOU. -- -- THIS CODE IS A PROOF OF CONCEPT THAT DOES HORRIBLE THINGS TO THE PLATFORM. -- THE FACT THAT IT WORKS AT ALL IS VERY VERY BAD. -- -- DO NOT RUN THIS IN PRODUCTION. IF YOU DO, I WILL KNOW, AND I WILL FIND YOU. -----
- haolez 5y ago
  The fact that the comment syntax seems to be from SQL, this gets even more terrifying :)
  - cryptonector 5y ago
    Could be ASN.1.
  - danadam 5y ago
    Could also be Lua.
    - ljm 5y ago
      Or Haskell
  - rthomas6 5y ago
    It could be Ada or VHDL, which is even more terrifying still.
  - scelerat 5y ago
    Could be AppleScript
  - anyfoo 5y ago
    Could be a rug under someone's fireplace
- csours 5y ago
  We had a script that would re-sequence all the jobs in the system, which you rarely want to do, as you have to put eyes on a bunch of physical locations. The password for the script was "BADIDEA"
bradleybuda 5y ago
Story time! Back around 2008 when we were developing the first version of AWS CloudWatch (which was then code-named "Granite") we had two problems to solve: 1. What should the API for PutMetricData look like? 2. Where should we store that data? (you know, minor issues) At the time, we decided that #1 was more critical than #2 (and of course #2 depends deeply on the answer to #1), and that the best way to solve it would be to do some learning-by-prototyping - stand up an internal version of CloudWatch to dogfood with some other Amazon services and be able to go to prospective internal customers with a "working" service that they could kick the tires on, not just some API docs and paper prototypes. So I quickly hacked up an implementation of "GraniteDataStore" called "InMemoryDataStore", which would store every PutMetricData request in a HashMap and nowhere else. When I sent the code out for peer review, my reviewer was aghast at the idea that we would stand up a service that would knowingly store different copies of the data on every server, and lose it all on process restart. I responded by renaming InMemoryDataStore to FakeInMemoryDataStore, but that wasn't enough. Finally, we settled on a name of (if memory serves) FakeFakeFakeDataStoreThatLosesAllYourData and that was enough to get my merge approved.
- Hokusai 5y ago
  > FakeFakeFakeDataStoreThatLosesAllYourData So it is fake, so that means that it does Not lose all your data. Did I got that right? I will just use it as a temporal solution and remember to change it later.
  - evra 5y ago
    Nah the amount of "fake" is just right (FakeDataStoreThatLosesAllYourData) = A datastore that loses everything [Fake(FakeDataStoreThatLosesAllYourData)] = A fake (FakeDataStoreThatLosesAllYourData) that does not lose all your data Fake[Fake(FakeDataStoreThatLosesAllYourData)] = A fake [Fake(FakeDataStoreThatLosesAllYourData)] that loses all data.
- csours 5y ago
  > DataStoreThatLosesAllYourData Perfect name!
- 5y ago
erwincoumans 5y ago
This resonates: while replacing the obsolete 2d physics in a game to 3d, we renamed the old directories into a long 'dont_include_this', so it was easier to detect in the larger project.
Stampo00 5y ago
I really don't like Dan Ambramov's style of communication. It's terse, impersonal and authoritative in a way that implies an attitude of "I'm right, you're wrong, stop wasting my time and go away". In my decade plus of experience in the software industry this has been a reliable indicator of the type of people I don't enjoy collaborating with.
- ______-_-______ 5y ago
  He was asked the question, "can I use this field named DO_NOT_USE", so I'll forgive him for being blunt in this case.
- tantalor 5y ago
  I had the opposite reaction. I'd be happy to collaborate with such a person.
- tptacek 5y ago
  He's right, they're wrong, and the conversation was on track to be a waste of time. I'm impressed by how this was handled.
- bognition 5y ago
  I didn't read it as "I'm right, your wrong" but "I own this API and provide no guarantees things will not break, take it or leave it."
- deleted 5y ago
  [deleted]
- AndriyKunitsyn 5y ago
  Is it about his answers in the thread, or in general? How should he have sugarcoated it? I'm not sure it's wrong in this case specifically, because an answer to a question like "can I stick my fingers into a power socket" shouldn't be "I'm not sure it's a good idea and we don't support it, but you be you", it should be more like "hey, don't do it, you'll die".
- MikeBVaughn 5y ago
darkstar999 5y ago
> I need access to this queue to decide whether or not the current render was the last for a very custom React component. (YES maybe I can avoid it but currently, this is my requirement) the access must be from inside of this component. I would love to know what problem they are solving. Whenever you start fighting the framework, you should back up and look for a different approach.
- nexuist 5y ago
  How is React even supposed to know if this is the last render for a component? If the user changes the state, isn't React obviously going to re-render the component?
- deleted 5y ago
  [deleted]
deleted 5y ago
[deleted]
roywiggins 5y ago
int __THIS_IS_NOT_A_PLACE_OF_HONOR() # no highly esteemed deed is commemorated here. # nothing valued is here. # What is here was dangerous and repulsive to us. # This message is a warning about danger. # The danger is still present, in your time, as it was in ours.
- loa_in_ 5y ago
  When your cat's fur changes colour it's not our fault, but it's time to pack and leave.[1] (1) http://www.theraycatsolution.com/#10000 http://www.theraycatsolution.com/#10000
  - shepherdjerred 5y ago
    https://www.youtube.com/watch?v=amn3kn0XPLQ https://www.youtube.com/watch?v=amn3kn0XPLQ
  - yongjik 5y ago
    Ah I see the Missionaria Protectiva doing its noble work ...
    - loa_in_ 5y ago
      As I said, it's not our fault.
- dudus 5y ago
  Isn't this something they write on nuclear waste sites?
  - Bytewave81 5y ago
    It's an example message proposed in a 1993 report from Sadina National Laboratories[1]. I doubt it's actually been legitimately written or used anywhere, but it's one of many such long-term messages intended to communicate danger thousands of years into the future, when the dangers of radioactive waste or even the prevailing language of the time may not be known. [1]: https://en.wikipedia.org/wiki/Long-time_nuclear_waste_warning_messages#Message https://en.wikipedia.org/wiki/Long-time_nuclear_waste_warnin...
itsthecourier 5y ago
you can use it if you're a self-employed developer
js2 5y ago
An old Apple support document: > As if it were a swarm of bees, you should stay away from the SyncServices folder. Removing or modifying anything in the SyncServices folder - or in any subfolders within it - may cause unexpected issues. https://web.archive.org/web/20140228032449/http://support.apple.com/kb/HT1865 https://web.archive.org/web/20140228032449/http://support.ap...
frays 5y ago
The comments in this thread are giving me a good laugh.
zxcvbn4038 5y ago
My experience has been that such comments don't stop anyone. There is always one guy that ignores it for new projects. https://genius.com/Weird-al-yankovic-dare-to-be-stupid-lyrics https://genius.com/Weird-al-yankovic-dare-to-be-stupid-lyric...
mFixman 5y ago
Can anyone explain like I'm a C programmer what's this thing with owners and collects in React?

350 points by shawabawa3 5y ago

Seems like a dumb question, but I find that even BLATANTLY_OBVIOUS_WARNINGS are so much more effective if there is a 'why' that explains the danger.

quietbritishjim 5y ago
Here it seems "INTERNALS" is the "why". If it's not a public API then of course it could change or disappear without warning between releases (including minor releases).
- verdverm 5y ago
  Go handles this by not allowing 3rd party to import a package path with internal/ in it. Only the current module can
  - MaulingMonkey 5y ago
    Ancient vanilla JS can accomplish similar by using wrapper functions. var React = (function(){ var React = {}; var __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED = {}; ...code extending/using React etc... return React; })(); // accessible: React.whatever // inaccessible: __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED However, there's always caveats where language level access controls don't let you quite express the access restriction you want. Perhaps you want to expose something to other official modules from the same constillation of libraries, for example (meaning you wouldn't be able to use Go's "internal"), without comitting to supporting the semver contract for any other arbitrary user of your API (meaning you might resort to similarly scary names.)
    - ______-_-______ 5y ago
      iirc, react-dom (a separate package) needs to access that property as well, which is why it's exposed in the first place
    - udbhavs 5y ago
      Private properties in JS classes are syntactic sugar that compile to variable definitions like this in the object's scope
  - mdoms 5y ago
    Most sane languages have visibility modifiers. This link refers to Javascript so...
    - verdverm 5y ago
      Go did that with casing, so you can tell visibility without lookup or needing to think. The internal/ is a package level restriction, so somewhat orthogonal in that they are for different levels
  - drdaeman 5y ago
    Which is awful, because I've seen a number of FLOSS projects that have perfectly good reusable code in their internal/ subdirectories. And I mean code by no means unique or specific to those projects. And whoever says something about instability or APIs being subject to change without notice - they're wrong because those are Go git repos and one can always pin to an old tag or even a commit SHA. If something is unusable (too specific, too fragile, too flaky), no one would use that anyway. A warning is fine and even welcomed, but a block is a slap in the face.
deleted 5y ago
[deleted]
marcosdumay 5y ago
It's certainly not dumb. If you look at every large library, there are some forbidden internal symbols that are used in a lot of 3rd part projects. Many times those are more stable than the API, and often enough they get published as part of the API once a lot of people decide to depend on them.
- wk_end 5y ago
  It's maybe not dumb to use the forbidden internal symbols, but it's certainly dumb to go ask the folks who through naming and documentation have communicated almost comically loudly and explicitly that they don't want you using the symbols if it's cool if you use the symbols.
  - marcosdumay 5y ago
    You would be surprised about how many times I've seen the internalVariableDoNotUse symbol to be exposed on the formal API of a library because everybody uses it already, it would be too much work to change it.
dmd 5y ago
One of my favorites is the warning you get if you enter the shell of an Oracle ZFS storage appliance: +-----------------------------------------------------------------------------+ | You are entering the operating system shell. By confirming this action in | | the appliance shell you have agreed that THIS ACTION MAY VOID ANY SUPPORT | | AGREEMENT. If you do not agree to this -- or do not otherwise understand | | what you are doing -- you should type "exit" at the shell prompt. EVERY | | COMMAND THAT YOU EXECUTE HERE IS AUDITED, and support personnel may use | | this audit trail to substantiate invalidating your support contract. The | | operating system shell is NOT a supported mechanism for managing this | | appliance, and COMMANDS EXECUTED HERE MAY DO IRREPARABLE HARM. | | | | NOTHING SHOULD BE ATTEMPTED HERE BY UNTRAINED SUPPORT PERSONNEL UNDER ANY | | CIRCUMSTANCES. This appliance is a non-traditional operating system | | environment, and expertise in a traditional operating system environment | | in NO WAY constitutes training for supporting this appliance. THOSE WITH | | EXPERTISE IN OTHER SYSTEMS -- HOWEVER SUPERFICIALLY SIMILAR -- ARE MORE | | LIKELY TO MISTAKENLY EXECUTE OPERATIONS HERE THAT WILL DO IRREPARABLE | | HARM. Unless you have been explicitly trained on supporting this | | appliance via the operating system shell, you should immediately return | | to the appliance shell. | | | | Type "exit" now to return to the appliance shell. | +-----------------------------------------------------------------------------+ I like how it explicitly says "no, seriously, Mister Unix Wizard, we mean YOU."
- duxup 5y ago
  >"no, seriously, Mister Unix Wizard, we mean YOU." That makes sense as they're the folks who will get in trouble. Rando person probably turns back at this point "nope this isn't what I wanted". Guy who thinks he knows better is the one who keeps going and freaks out when it hits the fan.
- Gaelan 5y ago
  +-----------------------------------------------------------------------------+ | You are entering the operating system shell. By confirming this action in | | the appliance shell you have agreed that THIS ACTION MAY VOID ANY SUPPORT | | AGREEMENT. If you do not agree to this -- or do not otherwise understand | | what you are doing -- you should type "exit" at the shell prompt. EVERY | | COMMAND THAT YOU EXECUTE HERE IS AUDITED, and support personnel may use | | this audit trail to substantiate invalidating your support contract. The | | operating system shell is NOT a supported mechanism for managing this | | appliance, and COMMANDS EXECUTED HERE MAY DO IRREPARABLE HARM. | | | | NOTHING SHOULD BE ATTEMPTED HERE BY UNTRAINED SUPPORT PERSONNEL UNDER ANY | | CIRCUMSTANCES. This appliance is a non-traditional operating system | | environment, and expertise in a traditional operating system environment | | in NO WAY constitutes training for supporting this appliance. THOSE WITH | | EXPERTISE IN OTHER SYSTEMS -- HOWEVER SUPERFICIALLY SIMILAR -- ARE MORE | | LIKELY TO MISTAKENLY EXECUTE OPERATIONS HERE THAT WILL DO IRREPARABLE | | HARM. Unless you have been explicitly trained on supporting this | | appliance via the operating system shell, you should immediately return | | to the appliance shell. | | | | Type "exit" now to return to the appliance shell. | +-----------------------------------------------------------------------------+ Cleaned up formatting
dahfizz 5y ago
It depends. If you give a reason why, it opens up the door for people to argue about whether the "why" is a valid justification. It also can make people feel like the "why" does not apply to them.
- MaulingMonkey 5y ago
  "why" can be pretty nebulous too. For a larger, widely used project, the question isn't "why" make something internal, but "why not". The safe default is to not semi-permanently commit every half baked bit of code to the public stable semvered API boundary to support for who knows how many years, but to only do so after careful consideration and justification. To add this disclaimer to every single bit of internal code is to drown your codebase in a sea of redundant comments - none of which are specific to the code, or even the codebase, but are instead rehashing "why encapsulation?" 101. This will only train readers of your code to ignore the low-value low-signal comments, and they will then end up asking the same question anyways, and "read the comment that's right there!!!111oneoneone" will be a fustrating experience for everyone, although they might not be able to articulate why. The real question I'm curious about here isn't "why are internal things internal" - but why this internal thing must technically be public. Does this predate ES6 symbols? Is there a plan to switch to those at some point in the future? Is there a tracking issue? Or does this need to be accessed from elsewhere in a manner that makes Symbols awkward to use? Where?
deleted 5y ago
[deleted]
Imnimo 5y ago
The "why" is that you will be fired, clearly :P
- Grollicus 5y ago
  I suspect they'll soon have an issue where someone wanted to get fired but it didn't work...
  - MaxBarraclough 5y ago
    Interesting point. In naming it this way, the maintainers have committed to firing anyone who uses it, as an implicit guarantee of the public-facing API. Fortunately they're free to rename it in their next release. Perhaps something snappy like __secret_internals_do_not_use_or_version_specific_retribution_will_follow_possibly_including_firing
cbhl 5y ago
I wouldn't be surprised if there is a FB-internal comment (or commit message) that was stripped in the open source repos

deleted 5y ago

[deleted]

ellieh 5y ago

@gaearon has provided some context to this here: https://twitter.com/dan_abramov/status/1489278948517289991?s=20&t=183aL0bOJfiNle2Mh8sRPA https://twitter.com/dan_abramov/status/1489278948517289991?s...

PragmaticPulp 5y ago
From the thread: > at one point one of my teammates who is usually very calm and composed deleted some of the internals to “send a message”, which was reverted the next day because it broke a bunch of things for different teams. we didn’t do this again but this started a conversation Oof. I worked with some people who would declare things deprecated, not discuss the deprecation with anyone, and then remove the deprecated code a short while later even if it was still working just fine. Same logic: They wanted to "send a message". And it sucked for everyone. Many meetings were had and we usually had to get management to force them to put the (still working) code back and coordinate with other teams on a deprecation schedule. Please don't force-deprecate things within a company to "send a message" like this. (Note: It wasn't Dan Abramov who did this)
- aidenn0 5y ago
  Without a bit more context it's unclear that it was this bad. It sounds like the removed it for one day and then put it back in. This may have been the only way to effectively notify people still relying on it. We had a deprecated server that we wanted to decommission. We announced this to the entire company. We pointed everyone to the new server, and asked for feedback if it couldn't fulfill any needs that the previous one did not &c. &c. We announced the date the server was going down. We inspected logs and guessed who might still be using it from IP addresses (one of the many reasons for wanting to deprecate the server was there was a single shared login for everyone using it :/) Finally, on the announced date, we just unplugged the Ethernet cable and got contacted by several different people freaking out, wanting to know what happened to the server. We (as planned) plugged the cable back in and then asked them the same questions that had gone out globally. A month later the server was finally offline for good. One way of interpreting this is that we unplugged the cable to "send a message" but we obviously did discuss the deprecation with lots of people ahead of time.

deltarholamda 5y ago

> I'd like to put my hand in the disposal and turn it on so I can catch the lemon seed that's stuck down there and pull it out. I wouldn't do that, there isn't enough space in there for your hand, a lemon seed is really small, and you will probably lose one or more of your fingers. > Okay, but I have pretty small hands, and I take ninjitsu classes at the Y, I'm pretty sure I can do it. Do you like the nickname "Lefty"?

efficax 5y ago
when the power is off it's perfectly safe to put your hand in the disposal
- ubermonkey 5y ago
  This is a peak HN reply right here.
  - efficax 5y ago
    but I'm right!
    - NateEag 5y ago
      > I'd like to put my hand in the disposal and turn it on You are not right (see the detailed sibling comment to your claim to rightness), and either you didn't understand what the original poster actually wrote or you decided to reply to them but say something that's at best tangentially related to their comment and at worst is a pedantic assault on a strawman. Hence, peak HN. ... actually, "but I'm right!" with no evidence supplied for the assertion might be peak HN.
      - deleted 5y ago
        [deleted]
      - buescher 5y ago
        The good news is that most people have the good sense not to stick their hands in disposals when they're running.

specialp 5y ago

Wide usage of internal only APIs is why much of the world is still stuck using Java 8 and can't migrate.

jdkjs 5y ago
You mean “public APIs not being comprehensive enough”
deleted 5y ago
[deleted]
RedShift1 5y ago
I use java about 40% of the time at my work and I've never had to use "internal only" APIs. Do you have some examples of these internal APIs?
- teraflop 5y ago
  There are JDK Enhancement Proposals that discuss the encapsulation of these internal APIs, including some examples and alternatives: https://openjdk.java.net/jeps/260 https://openjdk.java.net/jeps/260 https://openjdk.java.net/jeps/403 https://openjdk.java.net/jeps/403
- thenickdude 5y ago
  The sun.* package hierarchy for example: https://www.oracle.com/java/technologies/faq-sun-packages.html https://www.oracle.com/java/technologies/faq-sun-packages.ht...

bena 5y ago

It sounds like they're trying to avoid the Windows issue. Where they have incorrect/inefficient/weird behavior carried over from Windows 1.0 because someone somewhere did something they shouldn't have done and now it's expected behavior.

RedShift1 5y ago
I know this is like common knowledge but how true is this? Are there examples of those intentionally left in bugs?
- ______-_-______ 5y ago
  On the Old New Thing blog there are hundreds (maybe thousands) of examples. Here's the first one google decided to show me: https://devblogs.microsoft.com/oldnewthing/20031103-00/?p=41973 https://devblogs.microsoft.com/oldnewthing/20031103-00/?p=41...
- duffyjp 5y ago
  I don't know if you'd call it a bug exactly, but the fact you still can't name a file "con.txt" or "aux.bat" etc is pretty silly.
- mdoms 5y ago
  This PDF from Raymond Chen (I don't know the source material) is a great example of the lengths the Windows team had to go to to maintain backwards compatibility between Windows versions. They spent an inordinate amount of time either working directly with application developers or, when that wasn't an option, changing Windows internals specifically to keep problematic Windows apps working. http://ptgmedia.pearsoncmg.com/images/9780321440303/samplechapter/Chen_bonus_ch01.pdf http://ptgmedia.pearsoncmg.com/images/9780321440303/samplech...
- bena 5y ago
  Sim City for Windows 3.x would read memory it recently freed. This never crashed the program because Windows 3.x was more like a graphical shell on top of DOS. It wasn't a true multi-user or multi-tasking operating system. If you released memory, there wasn't anything else waiting to grab it from you. So the fact that you shouldn't read memory that's been freed, it went unnoticed. Until they tried to run it on Windows 95. Then it would crash. A lot. The game was unplayable. Because Windows 95 was a multi-tasking operating system and it would reallocate freed memory to other programs that may ask for it. So they put a specific check in Windows 95 to see if Sim City is running. And if it was, they essentially sandboxed its memory so nothing else could grab any memory it used. While in this case, this isn't an example of a bug that was intentionally left in, it is an example of code written into an operating system to handle the bug of a single program. But that's how they'd handle it. If PROGRAM X required certain behavior, they'd check to see if that program was running and alter behavior so the program would run. If feels like that's like half of what the registry is for.

koala_man 5y ago

"DO_NOT_USE_OR_YOU_WILL_BE_FIRED" is a running joke at Facebook, used when soft-deprecating a field or method where you can't immediately get rid of all users. Sometimes it migrates into open source products. It's iconic enough that Facebook HQ has a conference room by that name.

addandsubtract 5y ago
Do people use the conference room more than once?
- daveevad 5y ago
  There was a conference room at Yahoo named Sorry! that was used during many rounds of layoffs. The entire floor's conference rooms were all named thematically after popular board games.
  - KineticLensman 5y ago
    > The entire floor's conference rooms were all named thematically after popular board games. Getting OT, but I worked somewhere where the conference rooms were named after birds of prey (Eagle, kestrel, etc etc). The smokers' room was informally known as 'Puffin'
    - daveevad 5y ago
      I'm shocked there was an interior room that allowed smoking. It must not have been in California this millennium. I decided to stop smoking the day Jerry Yang held the door open for me and my band of misfits on our way to the outside smoking area. David Filo once asked me if he could share the panini station I was presently occupying in the cafeteria, URL's. I answered affirmatively but subsequently wished I had uttered "it would be an honor."
      - shubb 5y ago
        Still a thing in much of Asia, certainly Japan, Thailand - instead of "smoke anywhere so long as it is outside" it is more "smoke only in the designated place, inside or outside, not in the street". Being able to smoke at an inside restaurant table but not outside the front door out of respect for non-smoker diners very odd. Do you remember the brief period around 2010 where people were vaping at their desks all day in normal office buildings?

cosmic_quanta 5y ago

Reminds me of the `accursedUnutterablePerformIO` function, although this is technically part of the public API: https://hackage.haskell.org/package/bytestring-0.11.2.0/docs/Data-ByteString-Internal.html#v:accursedUnutterablePerformIO https://hackage.haskell.org/package/bytestring-0.11.2.0/docs...

sterlind 5y ago
I think this is the first time I've seen an API describe itself as a "malevolent agent of chaos." > The carcass of many a seasoned Haskell programmer lie strewn at its feet. the docs are genuinely entertaining.
- _0ffh 5y ago
  What's also quite cool that it discourages and additionally impedes usage of the function, because it really is called by a different name. I think it's true name is, ermmm, "nlnPrfrmNT". (I've ultimately decided to stay on the safe side too and not commit into writing the fullness of the dread name.)

mfringel 5y ago

As far as I know, there is still a configuration I wrote at a previous employer where I left the remark: ----- -- STOP. YES, YOU. -- -- THIS CODE IS A PROOF OF CONCEPT THAT DOES HORRIBLE THINGS TO THE PLATFORM. -- THE FACT THAT IT WORKS AT ALL IS VERY VERY BAD. -- -- DO NOT RUN THIS IN PRODUCTION. IF YOU DO, I WILL KNOW, AND I WILL FIND YOU. -----

haolez 5y ago
The fact that the comment syntax seems to be from SQL, this gets even more terrifying :)
- cryptonector 5y ago
  Could be ASN.1.
- danadam 5y ago
  Could also be Lua.
  - ljm 5y ago
    Or Haskell
- rthomas6 5y ago
  It could be Ada or VHDL, which is even more terrifying still.
- scelerat 5y ago
  Could be AppleScript
- anyfoo 5y ago
  Could be a rug under someone's fireplace
csours 5y ago
We had a script that would re-sequence all the jobs in the system, which you rarely want to do, as you have to put eyes on a bunch of physical locations. The password for the script was "BADIDEA"

bradleybuda 5y ago

Story time! Back around 2008 when we were developing the first version of AWS CloudWatch (which was then code-named "Granite") we had two problems to solve: 1. What should the API for PutMetricData look like? 2. Where should we store that data? (you know, minor issues) At the time, we decided that #1 was more critical than #2 (and of course #2 depends deeply on the answer to #1), and that the best way to solve it would be to do some learning-by-prototyping - stand up an internal version of CloudWatch to dogfood with some other Amazon services and be able to go to prospective internal customers with a "working" service that they could kick the tires on, not just some API docs and paper prototypes. So I quickly hacked up an implementation of "GraniteDataStore" called "InMemoryDataStore", which would store every PutMetricData request in a HashMap and nowhere else. When I sent the code out for peer review, my reviewer was aghast at the idea that we would stand up a service that would knowingly store different copies of the data on every server, and lose it all on process restart. I responded by renaming InMemoryDataStore to FakeInMemoryDataStore, but that wasn't enough. Finally, we settled on a name of (if memory serves) FakeFakeFakeDataStoreThatLosesAllYourData and that was enough to get my merge approved.

Hokusai 5y ago
> FakeFakeFakeDataStoreThatLosesAllYourData So it is fake, so that means that it does Not lose all your data. Did I got that right? I will just use it as a temporal solution and remember to change it later.
- evra 5y ago
  Nah the amount of "fake" is just right (FakeDataStoreThatLosesAllYourData) = A datastore that loses everything [Fake(FakeDataStoreThatLosesAllYourData)] = A fake (FakeDataStoreThatLosesAllYourData) that does not lose all your data Fake[Fake(FakeDataStoreThatLosesAllYourData)] = A fake [Fake(FakeDataStoreThatLosesAllYourData)] that loses all data.
csours 5y ago
> DataStoreThatLosesAllYourData Perfect name!
5y ago

erwincoumans 5y ago

This resonates: while replacing the obsolete 2d physics in a game to 3d, we renamed the old directories into a long 'dont_include_this', so it was easier to detect in the larger project.

Stampo00 5y ago

I really don't like Dan Ambramov's style of communication. It's terse, impersonal and authoritative in a way that implies an attitude of "I'm right, you're wrong, stop wasting my time and go away". In my decade plus of experience in the software industry this has been a reliable indicator of the type of people I don't enjoy collaborating with.

______-_-______ 5y ago
He was asked the question, "can I use this field named DO_NOT_USE", so I'll forgive him for being blunt in this case.
tantalor 5y ago
I had the opposite reaction. I'd be happy to collaborate with such a person.
tptacek 5y ago
He's right, they're wrong, and the conversation was on track to be a waste of time. I'm impressed by how this was handled.
bognition 5y ago
I didn't read it as "I'm right, your wrong" but "I own this API and provide no guarantees things will not break, take it or leave it."
deleted 5y ago
[deleted]
AndriyKunitsyn 5y ago
Is it about his answers in the thread, or in general? How should he have sugarcoated it? I'm not sure it's wrong in this case specifically, because an answer to a question like "can I stick my fingers into a power socket" shouldn't be "I'm not sure it's a good idea and we don't support it, but you be you", it should be more like "hey, don't do it, you'll die".
MikeBVaughn 5y ago

darkstar999 5y ago

> I need access to this queue to decide whether or not the current render was the last for a very custom React component. (YES maybe I can avoid it but currently, this is my requirement) the access must be from inside of this component. I would love to know what problem they are solving. Whenever you start fighting the framework, you should back up and look for a different approach.

nexuist 5y ago
How is React even supposed to know if this is the last render for a component? If the user changes the state, isn't React obviously going to re-render the component?
deleted 5y ago
[deleted]

deleted 5y ago

[deleted]

roywiggins 5y ago

int __THIS_IS_NOT_A_PLACE_OF_HONOR() # no highly esteemed deed is commemorated here. # nothing valued is here. # What is here was dangerous and repulsive to us. # This message is a warning about danger. # The danger is still present, in your time, as it was in ours.

loa_in_ 5y ago
When your cat's fur changes colour it's not our fault, but it's time to pack and leave.[1] (1) http://www.theraycatsolution.com/#10000 http://www.theraycatsolution.com/#10000
- shepherdjerred 5y ago
  https://www.youtube.com/watch?v=amn3kn0XPLQ https://www.youtube.com/watch?v=amn3kn0XPLQ
- yongjik 5y ago
  Ah I see the Missionaria Protectiva doing its noble work ...
  - loa_in_ 5y ago
    As I said, it's not our fault.
dudus 5y ago
Isn't this something they write on nuclear waste sites?
- Bytewave81 5y ago
  It's an example message proposed in a 1993 report from Sadina National Laboratories[1]. I doubt it's actually been legitimately written or used anywhere, but it's one of many such long-term messages intended to communicate danger thousands of years into the future, when the dangers of radioactive waste or even the prevailing language of the time may not be known. [1]: https://en.wikipedia.org/wiki/Long-time_nuclear_waste_warning_messages#Message https://en.wikipedia.org/wiki/Long-time_nuclear_waste_warnin...

itsthecourier 5y ago

you can use it if you're a self-employed developer

js2 5y ago

An old Apple support document: > As if it were a swarm of bees, you should stay away from the SyncServices folder. Removing or modifying anything in the SyncServices folder - or in any subfolders within it - may cause unexpected issues. https://web.archive.org/web/20140228032449/http://support.apple.com/kb/HT1865 https://web.archive.org/web/20140228032449/http://support.ap...

frays 5y ago

The comments in this thread are giving me a good laugh.

zxcvbn4038 5y ago

My experience has been that such comments don't stop anyone. There is always one guy that ignores it for new projects. https://genius.com/Weird-al-yankovic-dare-to-be-stupid-lyrics https://genius.com/Weird-al-yankovic-dare-to-be-stupid-lyric...

mFixman 5y ago

Can anyone explain like I'm a C programmer what's this thing with owners and collects in React?