Re: [go-nuts] Package Stutter
In both Java and C++ (statically compiled languages), Google's style guides
prohibit "wildcard"-style imports of an entire library:
https://google.github.io/styleguide/javaguide.html#s3.3.1-wildcard-imports
https://google.github.io/styleguide/cppguide.html#Namespaces
I believe the restriction is there to allow library authors to add names to
their library over time without the risk of changing the meaning of calling
code (or making that code fail to compile).
I used to find working with Java imports fairly unpleasant as it requires
editing imports once for every type mentioned, rather than every package.
Luckily, there is goimports-inspired tooling for this (although it is much
slower, sadly).
In any case, I can maybe see why you'd want to use unqualified types, but
it seems valuable to know at the use-site which identifiers originate in
different packages, and which must originate in the same package. That
value seems worth prohibiting dot-imports. You occasionally have to deal
with things like "context.Context", but they are the exception not the rule
(there are more names in the io package alone than have been mentioned as
stutter here in this thread).
Sanjay
On Saturday, December 1, 2018 at 10:44:05 PM UTC-8, robert engels wrote:
>
> I think it is especially problematic for python because:
>
> import * + type inference + dynamic language = hell
>
> in my book.
>
> > On Dec 2, 2018, at 12:26 AM, Ian Denhardt > wrote:
> >
> > Quoting robert engels (2018-12-02 00:59:31)
> >
> >> Granted, their package structure seems poor in my opinion, but you
> >> can't talk bad about k8s.
> >
> > Of course you don't lose anything by getting rid of the package names if
> > the package structure doesn't make any sense in the first place.
> >
> >> And probably the most common method signature of them all:
> >>
> >> http.HandleFunc("/bar", func(w http.ResponseWriter, r *http.Request) {
> >>
> >> are you losing anything if this is:
> >> http.HandleFunc("/bar", func(w ResponseWriter, r *Request) {
> >
> > No, and I would go further (if Go permitted it):
> >
> >http.HandleFunc("/bar", func(w, r) {
> >...
> >})
> >
> > http.HandleFunc is so well known that having the types there at all is
> > just noise. But I know you don't like type inference.
> >
> >> All coding requires good development choices - there are many times
> it
> >> probably shouldn't be used - but I making a blanket statement its
> bad
> >> seems like overreach.
> >
> > It's bad enough that common Python linters will flag it, and a lot of
> > large python projects do ban it outright.
> >
> > Note that nobody in Python land complains about:
> >
> >from foo import bar, baz
> >
> > ..the equivalent of which is what I've seen in what Java code I have
> > looked at. Rather, the suspect construct is:
> >
> >from foo import *
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "golang-nuts" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to golang-nuts...@googlegroups.com .
> > For more options, visit https://groups.google.com/d/optout.
>
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: golang and http2
I suggest just using a self-signed cert for your LB<->appserver and disabling cert-checking in your LB. Should be relatively straightforward; you can even have your appserver generate a cert on startup, so there's less messing around with files required. It'll give you http2, and also cheaply protects you from passive eavesdropping. If you don't trust your network (e.g. your traffic is going over the internet), you can setup a private CA to also protect you from active eavesdroppers and/or tamperers; cfssl makes this relatively straightforward, you just need to create some JSON files. See https://blog.cloudflare.com/how-to-build-your-own-public-key-infrastructure/ for copy-pastable examples. My friend and I have used the exact same JSON from that blogpost in a very similar circumstance to the one you describe, and it was maybe 20 minutes of messing around before we had private/public keys for LB and appserver (plus a CA for each side, so that we could support multiple replicas of an instance without them sharing a cert) . On Wednesday, November 15, 2017 at 12:43:49 PM UTC-8, Albert Tedja wrote: > > Thank you for the links. > > I am still somewhat disappointed that the http/2 protocol would enforce a > certain configuration. I understand the necessity of secure connections, > but that's should be left as an option to the developers. > > If browsers want to strictly use TLS, that's fine because it's consumer > facing, but at least Go should enable http/2 over non-TLS. We are engineers > here, we should know the difference. > > > On Wednesday, November 15, 2017 at 12:05:41 PM UTC-8, Howard C. Shaw III > wrote: >> >> See >> https://github.com/golang/go/issues/14141 - for discussion of the issue; >> and >> https://github.com/hkwi/h2c for a way to use the in >> stdlib-but-not-linked-together support for h2c (http/2 over non-TLS). >> >> Howard >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Oracle
First, let me thank the person who has written the Oracle (oci8) package for Go (preferred over the other Oracle package). However, it seems difficult to install, on Windows at least. Google-ing for help did not give a solution. I am less than 7 hours old in Go, so perhaps after soldering on, I will eventually get to install it. If Go would like to entrench itself even more, perhaps appealing to corporate users would be a good idea. This means that installing linkages to databases used by corporates, such as Oracle, should be a breeze. Next, looking at the functions in oci8, they seem a bit kludgy. Coming from the Perl world, Go/oci8 does not look as easy as Perl/Oracle. Perhaps I have not internalised the "Go way" as yet. I am sending this hoping for help in oci8 installation. And for eventual revamp of the package for easier installation. Sanjay -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: RFC: Blog post: How to not use an HTTP router
I also think its a bit of a false dichotomy; I use a hybrid approach, where I have a server's public interface be a http.Handler, but its internal implementation of ServeHTTP uses a router to dispatch to several methods on the server. https://play.golang.org/p/-W4tHmiUve is a stripped down example from a real server I wrote at some point. I think this is nicely layered; you can have different components of your server use completely different routing logic if you want (say for portions of the server contributed by different people/teams; the pprof endpoints would be an example of this), and then its all just registered in main() generally using good old http.ServeMux for hostname-routing (perhaps getting the hostname itself from a flag). Sanjay On Tuesday, December 19, 2017 at 1:14:18 AM UTC-8, rog wrote: > > > You strip whatever prefix you chose before dispatching to pprof.Handler > and it does all the routing it needs for itself. > > It would be great if that was actually a viable approach in general, > but unfortunately it's not, because it's not uncommon to need to know > the absolute path that's being served, which is lost when using this > technique. One example is when you need to form a relative URL to > another part of the name space (you know absolute path of the > destination, but you can only create a relative URL path if you know > the absolute path being served too). > > > a) Having a Router doesn't actually save you code in a significant way, > because you are replacing a conditional with a function call > > It might not save *much* code, but it's generally just boilerplate, > and every conditional is another condition that can be wrong. > > > b) instead you are pulling a whole lot of unnecessary code into your > program, that implements a DSL to express the routing control-flow > > Sure, there's an argument to remove *any* external dependency - there > are costs and benefits here, and they need to be evaluated for every > project. > > Personally, I think there's room for a hybrid approach - routers, > particularly structured routers such as > github.com/julienschmidt/httprouter, can make the code more obvious, > maintainable (and probably faster too), but there's nothing stopping > you from combining that kind of routing with custom routing code for > some sub-paths. > > Using a router DSL can have other advantages. If you express things > that way, the routes become amenable to programmatic analysis. We're > using that to automatically generate API client code, for example. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal
3 of the most well-known new languages in the past decade (Swift, Rust, and Go, respectively) have all eschewed exceptions for control flow in favor of some sigil in the source code to propagate errors explicitly. Swift uses try-statements (along with a few other control flow constructs), Rust uses the "?" operator (previously the try! macro), and Go uses "if err != nil". C++, a language which does have exceptions, has significant fractions of its user base which disable exception support entirely (20% according to a survey) or partially (52%). Google, for instance, almost invariably compiles with -fno-exceptions and uses macros to propagate errors explicitly (see https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/stubs/status_macros.h#L49 to get a sense for how that works). Herb Sutter, one of the well-known members of the C++ standards committee from Microsoft, has proposals out to make propagating exceptions require a visible sigil in the source code (also a "try" expression, FWIW): https://youtu.be/os7cqJ5qlzo?t=2939 (an interesting talk overall, I've linked to the specific relevant time). His actual proposal paper is also an interesting read: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0709r3.pdf. In a table with the following introduction "This section lays out what I believe are ideal error handling characteristics. They are not unique to C++; I believe they apply to most modern languages", he lists "Unhandled error propagation is visible" as something not provided by C++ exceptions today. It's possible that a decade from now, this will all have been a minor blip, and you will eventually be proven right. But at the very least, this context that should inform your priors. Sanjay PS - checked exceptions don't really have a great leg to stand on either (e.g. consider their interaction with Java 8's streams: https://www.oreilly.com/ideas/handling-checked-exceptions-in-java-streams, or consider that both Scala and Kotlin don't implement support for them at all) On Sunday, June 30, 2019 at 7:34:54 PM UTC-7, robert engels wrote: > > I’ve developed systems that wrap checked exceptions in unchecked ones, but > in every case I can think of it was to “abort to the top” - returning > control (or exiting) - it is a specialized case of the re-throw, but I > would argue it is rarely used in anything other than framework type code, > with applications code typically wrapping the specific exception in an > “higher-level application checked exception”, that the upper layers handle > (possibly inspecting the “cause” exception. > > As to not answering the question about transferring across Go routines, I > apologize. It was not intentional - I read the statement a few times and > didn’t quite get the concern - and meant to get back to it and forgot - but > I read it again a few times and still don’t understand the problem. > > What is particular about Go that makes this difficult? It is pretty common > practice to pass exceptions across threads in Java and C++ - e.g. fork/join > and the worker thread throws an exception - the exception is passed to the > joining thread. Conceptually, it is as if the function was called serially > and the exception thrown at the fork point. In these cases the exception is > wrapped, but it has to be because of the strong type system. It is also > pretty trivial to declare a wrapper function that declares the checked > exceptions for clarity - this is done routinely in rpc using proxies. > > > On Jun 30, 2019, at 8:43 PM, Ian Lance Taylor > wrote: > > > > On Sun, Jun 30, 2019 at 5:23 PM robert engels > wrote: > >> > >> I am going to disagree here. I don’t think ‘checked exceptions’ exhibit > this behavior. Addressing the points from the Joeal article, > > > > Checked exceptions address some of the difficulties with exceptions. > > However, they introduce new difficulties, and I do not believe they > > work in large-scale programs. In practice, checked exceptions > > degenerate into unchecked exceptions. Changing the set of exceptions > > that a function throws forces all callers to adjust their set of > > exceptions. In practice this is so painful that programs catch > > exceptions and turn into them into unchecked exceptions. There are a > > number of discussions on the Interwebs about the problems with checked > > exceptions; here's one: https://www.artima.com/intv/handcuffs.html . > > > > I note that you didn't reply to my comment about passing errors across > > goroutines. > > > > Ian > > > > -- > > You received this message because you are subscribed to
Re: [go-nuts] Oracle
Hello Jan: Thanks for your prompt reply. Will try again. Will contact author after that if unsuccessful. Yes, it is https://github.com/mattn/go-oci8 - My inexpert guess is that there is some problem with how git is installed in my Windows pc. Sanjay On 2017-11-18 22:26, Jan Mercl wrote: On Sat, Nov 18, 2017 at 5:09 PM <mailto:san...@banerji.in>> wrote: > First, let me thank the person who has written the Oracle (oci8) package for Go (preferred over the other Oracle package). > However, it seems difficult to install, on Windows at least. Google-ing for help did not give a solution. I am less than 7 hours old in Go, so perhaps after soldering on, I will eventually get to install it. Please share you experience with the author of the package, he/she may not be aware of the problem because something might be different on your machine, for example. I can't try it as I don't use Windows nor Oracle. Also, please double check you're installing the package the intended way. Most packages are installed just via go get, but some others have documented alternative methods for various reasons. > If Go would like to entrench itself even more, perhaps appealing to corporate users would be a good idea. This means that installing linkages to databases used by corporates, such as Oracle, should be a breeze. The description of the problem doesn't sound like being really connected to Go per se. > Next, looking at the functions in oci8, they seem a bit kludgy. Coming from the Perl world, Go/oci8 does not look as easy as Perl/Oracle. Perhaps I have not internalised the "Go way" as yet. Please consult the author(s) of the package, it's unlikely the message gets through using this ML. > I am sending this hoping for help in oci8 installation. And for eventual revamp of the package for easier installation. From the post it's not even clear which package is discussed. Is it this one? https://github.com/mattn/go-oci8 -- -j -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Is net.Conn concurrency-safe?
In the documentation for https://golang.org/pkg/net/#Conn, it's stated that Multiple goroutines may invoke methods on a Conn simultaneously. My guess is this is not meant to imply that it is necessarily safe to do so. For instance, calls to Set*Deadline may create race conditions between goroutines. However, if this is true it also makes the quoted claim pointlessly self-evident. Am I missing something or is the documentation somewhat misleading here? You could argue (and it would be perfectly fair) that programmers should be aware of these sorts of obvious concurrency problems, but the misleading nature of the documentation has me questioning whether I can trust it at all. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
