Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: spec: Formal Seal Model & Support for Go Features and Libraries including from the Go Community #39377

Open
EugeneSindambiwe opened this issue Jun 3, 2020 · 10 comments
Labels
Projects
Milestone

Comments

@EugeneSindambiwe
Copy link

@EugeneSindambiwe EugeneSindambiwe commented Jun 3, 2020

Go has been praised for its simplicity, and I would add its productivity. Only 2 to 6 features seem superfluous or have a questionable place in the Core language. On individual level I don't use and that's it.

A bigger deal seem to me

  • The impossibility for companies to use GO even simpler by disallowing language features and have all GO tools, no matter from which vendor, enforces this policy.
  • The absence of a "seal" (label/ category) below "core language" and "standard" which could be given to community packages, e.g. if the initial author transfers them wholly, including in legal sense, to the GO community at large and the latter commit to maintain them at least for a well-defined period and consolidate licence terms. The same mechanism could be used for language features,
  • The combination of the two to e.g. define which language features are permitted to de-activate ("soft deprecation"). Some may not, e.g. because the language would no longer be complete.

The answer may not bee much or everything, just some infrastructure at the right level, preferably language level. At the very least, it could be just fixing the semantic (e.g. GOLD; SILVER; BRONZE) and the protocol tools should have to implement.
Thanks for considering,
Eugene

@davecheney
Copy link
Contributor

@davecheney davecheney commented Jun 3, 2020

What current, real world, problem does this proposal address?

@EugeneSindambiwe
Copy link
Author

@EugeneSindambiwe EugeneSindambiwe commented Jun 4, 2020

Hi Dave,
thanks for the prompt response. Sorry, for the late response.
Take e.g. Javascript: Douglas Grockford spent time identifying the “good parts of JavaScript”—for PayPal. He should not have needed to write a whole tool (JSLint) that checks code for “bad parts”.

Go not being JavaScript, let me take Mat Ryer’s “Things in Go I never Use” (speech at GothamGo 2018). Companies may decide which “not good for us parts”. They lack tool enforcement for non-usage of bad parts. Tools like JSLint cannot restore the lost productivity.

“Bad libraries” are an even greater challenge “Bad” may mean because they contain other “bad parts” or non-technical properties It may be because of attached risks with regard to maintenance assurance, licensing issues etc. Tool support is needed for libraries as well.

I hope this added some clarity.
Thanks for considering
Eugene

@davecheney
Copy link
Contributor

@davecheney davecheney commented Jun 4, 2020

Thank you for your reply. This still feels rather subjective. Can you give some examples of specific features, packages, or api calls which should be disallowed? Personally I’d like to see runtime.SetFinalizer banished.

@EugeneSindambiwe
Copy link
Author

@EugeneSindambiwe EugeneSindambiwe commented Jun 5, 2020

Right. Even objectively people come to different conclusions due to e.g. differences in expertise degree and background, operational context, tasks to solve, … I accept that and want to deal with it. Esp. given that GO does not throw the maximum features to the world trying to make everybody happy. Providing some room and mechanisms for additional and differentiated minimization to those who know best about the concrete GO usage deserves at least a consideration. The proposal is such it is thereby not needed to know, care or agree on what is reduced in each instance.

As a prominent example occurring in each company take the dichotomy between needs of infrastructure vs. application builders --each company practically does both. Let take a few features:
• Labels, fallthrough, goto …: Most likely no one would have missed them
• Panic, error and reflect packages: Infrastructure builders need them. In applications with human interaction just using the error package would be a violation of I18N and L12N standards. As BIZ application vendor you want them enforced. Panic in end user messages would be banned as well as too rude to end users. Application developers would need and be required to use libraries of higher abstraction level and greater convenience under the impossibility to use reflect.
• Generally speaking, as a company you don’t necessarily want features and libraries always banned., but specifically per environment assigned a clear usage.

I know there is some advice, e.g. on how to do better with errors than just the error package (Dave Cheny, Steve Francia,…,) or why not unnecessarily toying with e.g. the reflect package (Rob Pike ...). Some technical built-in assistance, not built-around the JSLint style, should at least be considered.

@davecheney
Copy link
Contributor

@davecheney davecheney commented Jun 5, 2020

What’s wrong with the reflection package? It’s going to be pretty hard to do json decoding or print a formatted string without it?

@davecheney
Copy link
Contributor

@davecheney davecheney commented Jun 5, 2020

Re: panic. If you remove panic from the language what should happen if a slice out of bounds condition occurs? Can that still panic)

@EugeneSindambiwe
Copy link
Author

@EugeneSindambiwe EugeneSindambiwe commented Jun 5, 2020

  • application developer would use panic only indirectly, i.e. through a library that itself uses reflect.
  • I don't want panic to be removed. The runtime should panic. Not application developers. They should always recover and terminate the application more nicely and meaningful info the end user can act upon
@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Jun 5, 2020

To me this sounds like a proposal that is better implemented by a third party rather than the core Go team.

@EugeneSindambiwe
Copy link
Author

@EugeneSindambiwe EugeneSindambiwe commented Jun 7, 2020

fair enough

@rsc rsc added this to Incoming in Proposals Jun 10, 2020
@andybons andybons changed the title Proposal/ Spec: Formal Seal Model & Support for Go Features and Libraries including from the Go Community Proposal: spec: Formal Seal Model & Support for Go Features and Libraries including from the Go Community Jun 15, 2020
@gopherbot gopherbot added this to the Proposal milestone Jun 15, 2020
@gopherbot gopherbot added the Proposal label Jun 15, 2020
@andybons andybons changed the title Proposal: spec: Formal Seal Model & Support for Go Features and Libraries including from the Go Community proposal: spec: Formal Seal Model & Support for Go Features and Libraries including from the Go Community Jun 15, 2020
@EugeneSindambiwe
Copy link
Author

@EugeneSindambiwe EugeneSindambiwe commented Jun 27, 2020

Update (esp. to Ian): Meanwhile I took a try. I was surprised how awesome go.token, go/types, go/ast, go/parser, go/printer et al. are: Putting the standardization aspect aside, I realized that GO already does an excellent job at enabling implementation of GO code introspection and transformation tool even beyond the requirements raised above. And that despite having written my first go code only a year ago. I am not new at programming though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Proposals
Incoming
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.