Practical Go: Real-world advice for writing maintainable Go programs - <AUTHOR> https://dave.cheney.net/practical-go/presentations/qcon-china.html <comment><USER2> > Naming the _Config parameter config is redundant. We know its a_ Config, it > says so right there.

> In this case consider conf or maybe c will do if the lifetime of the > variable is short enough.

This seems petty. Is it really that problematic to type out a few extra characters?

<comment><USER3> Yeah, I used to go by this advice, and I found the maintainability of my code dramatically increased when I typed out full names. I don't even use "i" for loop variables anymore. If the length is a problem, invest in an editor with autocomplete.

Well-known abbreviations are fine, like "iter" and "prev", but single-letter variable names notoriously impede readability for me.

<comment><USER4> I feel like I have the opposite problem.

If the name is more than a few characters long, it starts to become non- instantaneous to recognize it. Things get much easier to follow with visually- instantly-recognizable symbols.

So in conditions where a variable is used over a short area in the code (or where it's used _constantly_ over a wide area), I prefer short variables.

<comment><USER5> Totally agree. If you have to scroll up to be reminded what some variable means, a longer name is good. But if its usage is a few lines away from its declaration then there's no reason to add visual noise to your code.

<comment><USER6> Its easier said than done though. We started following this few years back but then while it was "few lines away" originally, code evolved and now there are parts where its 20+ lines away. This means that short var names need to be continuously "enlarged". Well, then why not start with a "medium" name and avoid all that headache? ctx is a good enough compromise between c and context. (c can be client, config, context, certificate ... you get the point).

<comment><USER7> Rarely do you have a case where a variable outgrows its simple name (and value) and you keep it the same. Even when a function adopts new characteristics it's advisable to change it's name or make a new one. If you initially had variable `i`, created and destroyed in 5 lines of code but that has grown to 20+ lines, I'd recommend you (1) not add the 15+ if it could be put in a function (you get to name that section of the code), or (2) rename the variable. But a 5-line code that becomes 20+ lines is both strange and interesting.

</comment></comment></comment></comment></comment></comment><comment><USER8> Came from Java world, I find the Go comment and godoc are really limited. We can't link between functions, types. We don't have a standard way to declare input, output, don't have any distinction between a normal word and a Go identifier Refactoring using tool (e.g: Goland) usually lead to unexpected text replacements.

Take following functions, for example:

      // Auth check if user credential is existed in bla, bla...
      // ... (many more explanation)
      Auth(user User, authProvider AuthProvider) bool

      // AuthDefault check user against the default **AuthProvider**
      AuthDefault(user User) bool {
        return Auth(user, new(DefaultAuthProvider))
      }

If only the _AuthProvider_ in the second function's godoc be a link to the first one, we don't have to repeat the explanation for the second one. Dev will be able to discover the explanation easily via their IDE. This alone will be very helpful for the maintainability of any big projects.

<comment><USER9> I'd argue there's a failure of the code to some extent to need such extsenibility with documentation. I've often found when I need more info outside of Godocs that simply clicking through and diving into the source provided me with all the answers I needed to know.

<comment><USER10> This attitude, which I'll paraphrase as "needing any feature that I personally consider unnecessary is a code smell," is endemic to the Go community and a big reason why I still find myself frustrated by it on a daily basis even after a month of using it for a greenfield project. I don't like the language itself, since I'm generally in favor of a language offering more affordances rather than fewer, but it's fine to write in and I'm ultimately concerned with making the pragmatic choice. When I go to look for what the idiomatic way to do something is, though, wow! It's rarely just "this is the way to do it, since the language optimized for a particular use case by making the tradeoff of omitting the usual features for this": instead, it frequently goes on to assert that those features are unnecessary in _nearly every_ case and languages that provide them are wrong, or old-fashioned, or too Academic, or the people that use them don't care about Getting Things Done. Also, throw in a few cargo-culted potshots at Java for good measure! I've used a good number of languages professionally at this point, and the Go orthodoxy is easily the most off-putting I've ever encountered. I don't know why it's become so aggressively totalizing, but it's not a good thing.

<comment><USER11> I couldn't disagree more. I think it comes down to personal preferences, mostly.

I get so much more done in Go, have fewer maintenance issues, and more frequently collaborate with other folks/contribute to other projects.

> I've used a good number of languages professionally at this point, and the > Go orthodoxy is easily the most off-putting I've ever encountered.

I could -- and do -- say the same about the Java ecosystem.

<comment><USER10> For what it's worth, I don't particularly have a cross to bear with respect to Java. I cited it just because its invocations as a Bad Language bogeyman are common in the Go-focused writings I've found, and those are far out of proportion to its inherent flaws (of which I believe there are many!). I completely agree that it's a matter of preference, which I think is supported by the fact that I found Go to be the best choice of language in the context that I'm operating in whatever my reservations.

I'm confused about your assertion that the Java ecosystem has a similar problem, though, because my sense is both that it has a much less identifiable orthodoxy by virtue of being so widely used across so many domains, and that the new guard, such as it is, is very much in favor of creating libraries and utilities that favor simpler implementations and interfaces contra its "architecture astronaut" baggage.

<comment><USER11> You make a fair point; I'm not adequately exposed to the Java ecosystem, I mostly end up reading Apache projects.

I guess my remarks could be rearranged as: In general, I find Java, and the JVM friend Scala, to worship Abstraction over simplicity. Complexity is constantly confused for convenience, and that makes me sad. The number of files I need to read to understand _any_ piece of Go, I could likely count on one hand, if even. For the JVM-based approach: dozens, if not more.

Abstractions _in theory_ are great: they reduce the cognitive burden, they simplify behavior, make it easier to rationalize and cast judgement; But in practice, that just isn't true. You _always_ need to peel away the abstraction.

In Go, countless times, I've found myself reading the standard library implementation. Is this good? No, of course not. Ideally, as a consumer, I never need to look under the curtain. Things should just work. But that tends to never be true, and looking under the curtain is an important aspect of computing (c. 1970-1999) that permeates everything we do.

Go makes it really easy to look under the hood, see what's happening, and more-or-less instantly achieve clarity. The only other languages I've ever used that came close were C and C++, and history has demonstrated how well that's worked out.

<comment><USER12> To add to your point last week I cleaned up a part of project in Java sprawling in 30 or so files with 5 KLOC to 2 Java files and under 1 KLOC of Java code. Now main clean up was using library properly which was already present as dependency for years and removing innumerable level of indirections.

This code was written in really roundabout way in Java tradition where e.g. setName() would call getName() -> initName() -> initClassName() -> getDefaultClassName() -> initDefaultClassName() just to set one damn string value. And believe me this getName() function would get called grand total of one time in whole project.

And it was possible for me to do so because learning and writing Go made me confident that straightforward code is not a sign of junior/inexperienced developer. Because in Java it will be exactly that if you do not bury the actual logic in ten levels of abstract crap.

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> Would love to see better separation on the page between "Bad" and "Good" examples. While a good read, it's difficult to quickly distinguish between the two.

For example: [https://github.com/airbnb/javascript](https://github.com/airbnb/javascript)

<comment><USER14> true. Google will index it and I can see many people copy and paste bad code considering the best practice for doing something

</comment></comment><comment><USER15> I'm not a Go user myself, but I skimmed through the document. What I found was a lot of good programming advice that is generally applicable, rather than being limited to the Go language. (It seems most of the Go-specific stuff is in section 5.) It's always good to see robust coding practices being promoted, regardless of language.

</comment><comment><USER16> About half-way through and I think this is a great article, in particular the quotes and I also agree that the first 4 sections are generally applicable.

One thing I disagree with is the remark about having fewer, big packages. Though conceptually I agree that avoiding having too many public APIs that aren't widely used makes sense, _in practice_ \--at least on the types of projects I tend to work on--I find that directing people to split things into a few packages forces them to think about a decoupled design with good APIs between the components. This could certainly be done with discipline inside a single package, but unless everyone working on the codebase is very diligent about this it's easy for abstraction leaks to creep in.

Ultimately it's a judgment call, but I think an earlier paragraph (copied below) is far more important than optimizing on having fewer packages or fewer exported types and functions, especially (as is also pointed out in the doc) you can use `internal` subdirectories to make APIs project-private if you are writing a library that is consumed by other projects, as opposed a service.

> A good Go package should strive to have a low degree of source level > coupling such that, as the project grows, changes to one package do not > cascade across the code-base. These stop-the-world refactorings place a hard > limit on the rate of change in a code base and thus the productivity of the > members working in that code-base.

<comment><USER17> I agree with you. I like the way packages are isolated from each other, meaning that to understand a package it is usually by definition a good start to simply read what is there. Smaller packages mean more bite-sized chunks of the program. And I think the discipline of slicing up your program this way is very, very good for the design, and often makes the tests easier to write to by significantly shrinking the surface of what your tests have to "fake" in order to test your code. I think it's just a whole heapin' helpin' o' benefits.

However, I feel myself to be in the minority on this one. To which I basically shrug and write my code with lots of relatively small packages. It really only affects code you're working on, or that your team is working on. Things you pull in as libraries and have no direct interaction with don't matter too much on this front.

<comment><USER18> If packages are too small it can get hard to understand the code if your not familiar with the structure yet. Working from bottom to top level can work but might also be different because you are missing context for the low level packages to make sense.

In general I found larger packages tend to produce more direct / pragmatic code with less indirection which is usually easier to understand, even though it also feels wrong to me from a theoretical standpoint.

<comment><USER17> "If packages are too small it can get hard to understand the code if your not familiar with the structure yet."

I solve that with describing the context of the package in the opening prose section. I think this section is underused in every language community I've seen, even though all the automated doc systems support a top-level summary/contextualization/etc.

I think that an advantage of small packages is precisely that it is easier to understand if you're not familiar with the structure yet, by isolating how much structure you have to understand. Large packages, or languages with loose barriers, force you to eat huge swathes of the project at once to understand the code. Small packages are both bite-sized on their own, and also the packages that use the small packages often allow you to gloss over the used package while you're learning _that_ package.

I don't end up with much indirection caused by the package boundaries. (Where there are interfaces I would usually have them anyhow for testing purposes.)

This tends for me to be one of those places where I wonder if I'm just doing something really different than most people. Another example is all the many people over the years who have tried to convince me, with varying level of politeness, that testing code should only use the external interfaces, or dire consequences like having to rewrite all the testing code if I tweak the package will happen. All my testing code uses private interfaces unless there's a really good reason not to, and maybe once in ten years have I had a serious rewrite of the test code come up. The threatened problems don't seem to happen to me. (And I am pretty sure I'd notice them if they did, although I guess I can't completely discount the possibility that I'm just too oblivious somehow.)

Certainly, if they cause you trouble, either because your style is different, or your problem domain is different, or whatever reason, don't use small packages.

</comment></comment></comment></comment><comment><USER19> This has got to be one of the best and most useful post i've seen about go (and code design in general) in a long time.

</comment><comment><USER20> > A good Go package should strive to have a low degree of source level > coupling such that, as the project grows, changes to one package do not > cascade across the code-base.

I wonder though why there is so little emphasis on how important interfaces are in Go. I mean, section 4.5 talks about it a bit, but in my experience, this mistake is made far too often.

<comment><USER21> This is encapsulation, really, and simply makes the point that the principle applies to packages.

</comment></comment><comment><USER22> > 2.1. Choose identifiers for clarity, not brevity

This is a real problem in Go these days, people use one and two letter vars quite a bit which makes reading code you're not familiar with practically impossible. On one project we simply switched to semi-java length like names since our customers couldn't read the code.

<comment><USER21> Since when are variables names a language issue?

There is no such thing as "Java length like names", or whatever. There are good practices and bad practices and they are universal.

<comment><USER23> It's really more of a language community issue, but communities of a language are commonly referred to by the name of the language itself.

<comment><USER21> I'm sure there are many actual professionals using Go. Not just script kiddies.

I happen to be learning Go coming from a C background. I find "The Go Programming Language" by Donovan and Kernighan exemplary and the decades of experience that went into the language really show.

<comment><USER23> No need for insinuations, that's not a point of contention.

If you look past the book, and directly at the STL, you'll find a common example: the "fmt" library, shortened to save three letters. Or compare the verbosity of these two examples from language docs, and the length and descriptiveness of variable names in them: [https://docs.oracle.com/javase/tutorial/essential/io/cl.html](https://docs.oracle.com/javase/tutorial/essential/io/cl.html) to [https://golang.org/pkg/bufio/#example_Scanner_emptyFinalToke...](https://golang.org/pkg/bufio/#example_Scanner_emptyFinalToken)

I agree, it's a great language. These naming conventions are part of its developers and community.

<comment><USER21> Naming conventions are part of your own practices and processes.

There is no issue with having short names to describe well-known entities part of the language, or trivial code.

Your example from pkg.bufio is trivial and but still the variables names are meaningful. There is a difference between clearly and meaningful, and verbose.

Your example from Java is not very different.

I feel that the point is not being understood here.

</comment></comment></comment></comment></comment></comment><comment><USER24> > 2.3. Don't name your variables for their types

What's the best way to handle a situation where you use two different types for the same data? e.g.

      var usersMap map[string]*User
      var usersList []*User

<comment><USER25> How about describing the intended use of the collections? E.g.

        var usersByUsername map[string]*User
        var usersToEmail []*User

</comment></comment><comment><USER26> [https://dave.cheney.net/practical-go/presentations/qcon- chin...](https://dave.cheney.net/practical-go/presentations/qcon- china.html#_never_start_a_goroutine_without_when_it_will_stop)

> 8.3. Never start a goroutine without [knowing] when it will stop.

100% agreed with the concept, but even the final example is flawed. That'll unblock and continue _immediately_ after `close(stop)`, without being able to do two important things: it can't tell you when it's done shutting down, and it can't tell you if it encountered an error. Fixing this makes it even more complex.

Both of those are common and often necessary things to do - e.g. if you need to drain traffic, you need to wait until it's actually done before killing your process. Same goes for closing files (you might need to flush / sync first), OS resources that might survive your process, etc. This example will just kill your process as soon as everyone has been _informed_ that it should stop, not when they're _done_.

\---

Yeah it's a bit nitpicky, but it's even called out as "asking a http.Server to shut down is a little involved, so I've spun that logic out into a helper function". Except that the helper function can't ensure the involved server shutdown process _actually shut down the server_. That's a dangerous pattern to encourage, and it's an over-simplification that's absolutely rampant in go tutorials and code I encounter.

The workgroup lib he links doesn't (arguably?) have this flaw, but it has some strange / incomplete error handling details... E.g. if you Add 5 funcs, you'll only receive the error result of _the first func to complete_ , not the first err or anything more predictable. If the first succeeds but all the rest fail, you'll see no error. Go's errgroup does "first non-nil error" at least, but you can still only get one: [https://godoc.org/golang.org/x/sync/errgroup](https://godoc.org/golang.org/x/sync/errgroup)

<comment><USER27> > 100% agreed with the concept, but even the final example is flawed. That'll > unblock and continue immediately after `close(stop)`, without being able to > do two important things: it can't tell you when it's done shutting down, and > it can't tell you if it encountered an error. Fixing this makes it even more > complex.

The final example actually does both of these things already, but maybe you're confusing the purposes of some of the channels?

The loop at the end of main will wait until it receives one (possibly nil) error value from every task that was launched. Upon receiving the first error, it will close the done channel, which will then cause any remaining tasks to run their Shutdown function, which will attempt to gracefully shutdown the server. The error of each shutdown function is then returned and printed if non-nil.

There is no immediate termination, and all errors are communicated. It doesn't let the process die until every task has sent its error value.

Obviously, there are two semantics not enforced at compile time: each task must send exactly one error value, and each task is responsible for its own shutdown. If a task sends more than one error, there will be early termination. If a task doesn't shut itself down properly, that is its own fault.

<comment><USER26> Shutdown blocks until draining is complete, but ListenAndServe returns immediately when Shutdown is called: [https://golang.org/pkg/net/http/#Server.Shutdown](https://golang.org/pkg/net/http/#Server.Shutdown)

> _When Shutdown is called, Serve, ListenAndServe, and ListenAndServeTLS > immediately return ErrServerClosed. Make sure the program doesn 't exit and > waits instead for Shutdown to return._

So no, this writes to the "done" channel essentially immediately once `close(stop)` is called, and ends the process prematurely.

</comment></comment></comment><comment><USER28> This is so fortuitous as I started writing my first real Golang service and as a python dev I have no idea what I am doing.

But one refreshing thing is how opinionated the language and the frameworks are refreshing as there's only one acceptable way to do many things.

<comment><USER29> I agree so much with this. I recently attended a Golang meet up and since I was one of the few who had been using the language regularly for over 2 years now i was asked to let the newcomers know my favorite "feature". I replied with the same point you make above and was met with a look of refreshment on people's faces.

Go lets you write One True Code for the most part.

</comment></comment><comment><USER30> Good collection of best practices overall. I would not say they are Go-only, as I read about them 5 years ago in Clean Code by R. Martin and another part can be found in Code Complete by Steve McConnell.

Once again, good collection if you have no time to read the book. Anyway, it does not cover other parts like contracts/interfaces, the absence of comments (which can be a good sign) etc. Would recommend checking both CC books if you want to write better and maintainable code.

PS. Anyway, Dave, thank you for the popularization of best practices.

</comment><comment><USER31> I've always found Go's 'guiding principles' to be highly subjective, the annoying thing about it is that they are masqueraded as objectivity. Simplicity and readability for whom?

If you've been writing C and Java for years, all simple/readable means is 'familiar'. There are other definitions of simplicity

<comment><USER32> Go developers have a sectarian mind set. They obey the cult of The Three Creators, and some other minor advocates/evangelists like this australian dude.

</comment></comment><comment><USER33> > That's a lot of repetitive [error handling] work. But we can make it easier > on ourselves by introducing a small wrapper type, errWriter.

> errWriter fulfils the io.Writer contract so it can be used to wrap an > existing io.Writer. errWriter passes writes through to its underlying writer > until an error is detected. From that point on, it discards any writes and > returns the previous error.

this is a cute trick.

In some cases it might produce a great result. For example, floating point nan values work roughly like this: a special error values included in the type that can be computed upon without needing to write special control flow until you explicitly need to check the final computed result to see if you got an actual value or the nan value.

but I fear the applicability of this trick in go is limited as it relies on a heap of idiosyncracies belonging to this example:

The chain of potentially error-ing operations that are being performed all involve a value of the same type that can be wrapped. In a less contrived example there would be a variety of different types involved in the sequence of possibly error-ing operations.

The code that is processing the wrapped error-hiding type roughly must not perform side effects when processing an apparently non-erroring computation, since now the error wrapper type is stopping the code from aborting early. It's completely non obvious that this transformation will be correct (ie result in a program with equivalent behaviour to the original program) without reading exactly through the implementation of everything that touches the error wrapper. This isn't helped by go not having a way to tag functions as pure.

The new code now superficially looks like it is wrong as it isn't bothering to check error values of the functions it is calling in the usual way. This will probably cause a spray of linter warnings about failing to handle possible errors in your CI build.

In other languages a much more general way to address this kind of problem could be:

error monads ; or exception handling

Which can be used to short circuit the entire normal control flow.

<comment><USER34> > In other languages a much more general way to address this kind of problem > could be: error monads ; or exception handling

errWriter is quite literally "let's do monadic error handling, except not just without monads but without generics or reified errors". And thus it can only handle a single source or error type.

Also FWIW monadic error handling != error monads. For instance Rust does the former, but its type system can't express the latter (so there is no monad or functor abstraction on top of Result).

</comment></comment><comment><USER35> I don't understand something.

> 5.1. Consider fewer, larger packages

> 5.2. Keep package main small as small as possible

If you have one package, which is the main package, then how are you supposed to keep it small, and at the same time not creating more packages because somehow that is the work of the devil? He is telling me to try to fit everything into one package, but at the same time keep it really small. It is not going to work. Maybe I misunderstood?

<comment><USER36> In golang packages named "main" are special. They're not importable and they correspond to a single executable.

If you want to be able to reuse code in different packages in the future or have more than one compiled binary, you won't be able to put everything into a single "main" package

<comment><USER35> Right now I use many internal packages. It makes my code more organized. By many, I use 4-5 and the number probably is not going to change. I dunno if this is a good idea, but it seems like the best I have got that suits me.

</comment></comment></comment><comment><USER37> Love Mr. Cheney, hate stuff like this.

Someone who has put the hours in will probably stray from all of this advice, and still end up with something beautiful. Meanwhile, for all of the other schmoes who haven't put the hours in, this is just more fuel for screeching about how this name isn't right or that comment is too long.

Dijkstra said GOTO was bad, and now we have callback hell and 10-layer inheritance hierarchies instead.

<comment><USER38> If you're writing the kind of thing where you need callbacks, GOTO isn't going to make it _more_ clear what's going on...

<comment><USER37> Never said it would. I did imply that things haven't significantly improved.

Throw away goto and globals, replace them with anonymous functions and closures, and the new thing looks an awful damn lot like the old thing.

All I know is that we used to have retrained housewives writing physics programs. Now we expect 10,000 hours to write a halfway decent web form, and halfway decent doesn't happen nearly as often as it should.

</comment></comment></comment><comment><USER39> This book is a great read for writing maintainable code: [https://www.amazon.com/Clean-Code-Handbook-Software- Craftsma...](https://www.amazon.com/Clean-Code-Handbook-Software- Craftsmanship/dp/0132350882/ref=sr_1_2?s=books&ie=UTF8&qid=1550785898&sr=1-2&keywords=beautiful+code)

</comment><comment><USER40> My advice would be this: If you have a specific reusable component.. Make a package to contain it.

Use init() to compile any regular expressions and store them as variables within that package, so that you don't

Split out related code in a folder, remembering that the included code is done in alphabetical order - so shared functions within the same package you should alphabetically make it the first to be included.

You can register components of a larger system by using the init() function to call a function in the base package, and within the calling package (usually main) import the "plugin" using the underscore space prefix (sql database drivers use this method)

Use the new go modules system; its great. But sometimes it doesn't include the latest packages, just modify the go.mod file and anything after the package name remove it and just put master instead.

One last thing with error handling. Everybody does if err!=nil. I tend to go the opposite way, if err==nil and nest these, if err isn't nil i drop out and deal with the error. If it is ok, it will return ok.

<comment><USER41> > One last thing with error handling. Everybody does if err!=nil. I tend to go > the opposite way, if err==nil and nest these, if err isn't nil i drop out > and deal with the error. If it is ok, it will return ok.

Don't you get "staircase of doom"?

        err := unsafe1()
        if err == nil {
            err = unsafe2()
            if err == nil {
                err = unsafe3()
                if err == nil {
                    err = unsafe4()
                        if err == nil {
                        err = unsafe5()
                        if err == nil {
                            // ...
                        }
                    }
                }
            }
        }

</comment></comment><comment><USER42> Slightly offtopic: Does anyone know which template was used to generate this document? I'm assuming the source in markdown and I really like that the generated html has table of contents, support for footnotes and is responsive!

<comment><USER43> It's asciidoctor, and it's indeed really nice.

[https://asciidoctor.org/docs/user-manual/](https://asciidoctor.org/docs/user- manual/)

</comment></comment><comment><USER44> Nice write up, could use a little simple editing / spell check!

</comment><comment><USER32> One more advice - implement Generics in your programming language, it's 2019 already, not 1970s!

</comment><comment><USER45> Really glad to see more pragmatism and less dogma in the Golang community.

</comment><comment><USER46> Great article, as always, by Dave Cheney.

I took a lot of his advice when designing V [1].

It's very similar to Go, but it has

\- No global state

\- Only one declaration style (a := 0)

\- No null

\- No undefined values

\- No err != nil checks (replaced by option types)

\- Immutability by default

\- Much stricter vfmt

\- No runtime

\- Cheaper interfaces without dynamic dispatch

[1] [http://vlang.io](http://vlang.io)

<comment><USER47> Exciting!

How long was this language in development? In what language was the compiler originally written in?

<comment><USER46> It was written in Go, my favorite language at the time :)

About 2 months later I rewrote it in V. Bootstrapping is fun. Did it 4 times (V1 => V4).

</comment></comment></comment><comment><USER48> So I don't know how to fly a commercial airliner, but I could probably figure my way around a small single prop airplane. That's basically the difference between Go and a language like Rust or C++ or any language that requires a lot of up front investment, but then let's you work at power level 9000.

So yeah, Go will get you there. It will take you a lot longer to get there when you aren't going 600MPH, and you can carry a lot less people, but at least you aren't driving a car like the people using Python. Sure it's probably not going to be as rigorously inspected as the Boeing borrow checker, but Go is at least getting an inspection, whereas your Python code is just going to break down on the side of the road when the problems surface itself because you didn't check the oil light.

To me, Go is a better Python. It's easier to learn, faster, more scalable, and safer, and just as easy and quick to write. It's just not a language for big projects.

<comment><USER49> But Go will never be a data science language like python, because Go is too limited to express that domain.

Python may leave you in the lurch when it comes to maintainability, but for some domains python is infinitely better than Go.

<comment><USER50> Hmm. Weird. Almost my entire data science pipeline is in Go.

<comment><USER49> Data engineering is not data science</comment></comment></comment></comment>


Show HN: A spreadsheet for nomads who can't find someone to travel with - <AUTHOR> https://docs.google.com/spreadsheets/d/1Igizd-21b-Syl-kJOxGSFsm-opv94FwFDxuZ2WsBZK8/edit#gid=0 <comment><USER2> I'd suggest trying nomadlist.com

<comment><AUTHOR> the difference between what I'm doing and nomadlist.com is that nomadlist.com connects you with nomads around the world where the expectation is to help via forum and chat,

this is more physical, meaning you arrive at the airport and wait for your nomadpartner so you get out of the airport together,

maybe stay a day or two together as well, find your way through the city and move as a group until you get familiar to the place you're traveling to.

<comment><USER3> I don't want to rain on your parade but don't you think "wait at the airport" is to small of a window for a coordinated meeting? The likelihood that two people from different places land at the airport within 2 hours of each other is low.

I can understand those who have arrived within +1/-1 day of yourself.

The main problem is getting critical mass for it to be worth using. Also being X times better than current solutions (couchsurfing, etc)

That being said I do think their are products that can be built in this space.</comment></comment></comment>


Microsoft doesn't want you to use Internet Explorer anymore - <AUTHOR> https://www.theverge.com/2019/2/8/18216767/microsoft-internet-explorer-warning-compatibility-solution <comment><USER2> The funny? thing is that IE has become better than Chrome for a lot of stuff because Chrome keeps dropping support for things that it used to support. The frequency of updates means that your stuff could just stop working one day when it worked perfectly fine the previous day. It requires constant attention to make sure things won't break. The most recent one to get us was the File.lastModifiedDate

<comment><USER3> To be fair, File.lastModifiedDate was never a standard. In my experience, as long as you stick to the stuff that's actually an accepted standard your code will last a long time.

FWIW, removed on Firefox too:

[https://bugzilla.mozilla.org/show_bug.cgi?id=1458883](https://bugzilla.mozilla.org/show_bug.cgi?id=1458883)

and lastModified works in both (and IE):

[https://developer.mozilla.org/en- US/docs/Web/API/File/lastMo...](https://developer.mozilla.org/en- US/docs/Web/API/File/lastModified)

<comment><USER2> I agree but if the latest document is a draft? That is how lastModifiedDate ended up in those browsers in the first place. Obviously, going back would have noticed that it was removed from the spec and updated accordingly. The point is that IE has maintained backwards compatibility and Chrome has not.

<comment><USER3> That's why you don't implement anything that's a draft. Obviously easier said than done, but if you want your code to be around for a long time it's the only sensible path.

<comment><USER2> I agree in principal, but the standards can move very slow. Look at WebRTC. It is only a 'candidate recommendation'.

<comment><USER4> That's the tradeoff you have to accept if you want stable code.

</comment></comment></comment></comment></comment></comment><comment><USER5> If that's the case, then they should probably start by offering something better for all currently supported OSes and versions.

Windows 7 is still supported and only runs IE11, no Edge

Windows 10 LTSB is still supported and only runs IE11, no Edge

If you need to support any of those OSes, there's no way around supporting IE11.

<comment><USER6> Windows 7 currently has less than a year of support (January 14th, 2020 is D-Day), and given the free upgrade having been available, and the improved security and performance, there is no legitimate reason to be on Windows 7 today.

LTSB is not intended for computers which browse the web. It's very specifically only intended for things like embedded platforms like computers operating medical devices. Aka, things that require the Windows kernel to run, and insane platform stability, and literally like nothing else. Business users who need a desktop should be running Enterprise, which does allow you to disable all the things most Windows installs don't, but is far more capable than LTSB.

<comment><USER7> In one of my companies, of the windows machines, half are Win7, half are Win10...

Often we wish we could buy Win7 to delete the Win10 on the Win10 machines.

Win10 somehow, is less reliable, often doing weird things, updating without permission, sending strange data out, have security update that kill half of our online bank apps, our another update that make the keyboard stop working, or nag about Cortana at same time Cortana is not available in our country, show ads, etc...

The only reason the Win10 machines are still Win10 is because Win10 was part of the deal when buying said machines...

<comment><USER6> If Windows is updating without permission in one of your companies, there's an issue with whoever manages IT for that company. Even _without_ an Enterprise license, it's trivial for a domain environment to control update behavior. Group policy handles the majority of these concerns easily.

Even if you could install Windows 7, you would be very mistaken in doing so, as it would put your company at significantly greater risk. Even while security updates are still available, the differences in the platform already lead to scenarios where large malware infections tend to be almost entirely on machines which weren't running Windows 10.

<comment><USER8> I agree. I always read these horror stories about windows, specifically win10, and I have just had a completely different experience. On personal machines, work machines, servers, large deployments, domain controlled and not ... I've just never had these problems.

<comment><USER6> To be clear: I've encountered _plenty_ of issues on Windows 10. But most have been addressed, the rest can be managed if you know what you're doing, and running out of date operating systems is not a safe or viable way to operate, especially as a business.

If someone really just _doesn 't like_ Windows 10, my advice is to switch to Linux. Continuing to run obsolete operating systems just isn't okay. :)

</comment></comment></comment></comment></comment></comment><comment><USER9> My first job doing intranet web development in 2000 was in a company with mandatory use of IE for all employees and all developed apps. We all grew to despise it very quickly especially as the alternatives increased in number and quality. Microsoft is only 19 years behind on this conclusion :)

<comment><USER10> Now all get to worry only about Chrome instead.

<comment><USER11> It's astounding how people like to paint MS as the bad guy and not monopolies. Every monopoly behaves like this. I'm not favoring MS- I'm asking people to stop letting monopolies become. No .. But google gives me free stuff

<comment><USER12> I can understand accepting a monopoly as a necessary evil but then often what I see in reality is that people are cheering for the monopoly and they even want the competitors to go out of business.

<comment><USER11> Exactly- everyone just wants to be seen as siding with the winner. I specially see it on "hacker" news actually.

</comment></comment></comment></comment></comment><comment><USER13> Finally. The only sad thing they didn't support Firefox. Having a fair competition to Chrome/Chromium would be the most obvious choice (and push Rustification project forward to a new heights).

<comment><USER14> It would have been interesting to hear what / if any discussion there was about picking Chromium.

<comment><USER15> Embedding Chromium is easy, embedding Gecko is....not. I'm guessing that's about where it started and ended, TBH.

<comment><USER16> It's sad; I remember that one of the things that was supposed to come out of Servo was a stable embedding interface. Of course, that's cancelled now…

I can't help but wonder from time to time what would be using Gecko now if they were reasonable to embed.

</comment></comment></comment></comment><comment><USER17> If that's the case then Microsoft needs to lean hard on all small and midsize business using a version of Sharepoint or Solomon or Great Plains to upgrade their internal apps to no longer require IE. Where I work our timesheets app on Solomon _requires_ Internet Explorer -- which is a bucket of fun for all of our MacBook Pro using sales team.

Microsoft may want us to move on from IE but they've created the apps that REQUIRE us to keep using IE.

<comment><USER18> Hell that's true of enterprise applications as well. What amazes me is large SASS companies like ADP whose eTime timesheet app required the JRE to function until they upgraded it a couple years ago to use Flash instead.

They still only officially support Internet Exploder, and when we switched to Chrome as our office standard they forced an addon that opens certain incompatible sites like ADP.com in IE if you try to visit them in Chrome.

<comment><USER17> A worse offender might be government apps. The radar loop on the National Weather Service _STILL_ requires Adobe Flash. Example: [https://radar.weather.gov/radar.php?product=NCR&rid=EAX&loop...](https://radar.weather.gov/radar.php?product=NCR&rid=EAX&loop=yes)

</comment></comment></comment><comment><USER19> Jokes on us. I have a building management system that uses IE thoroughly. These things are on 10-15 year lifecycles. And the only way to get major updates is to buy a new system. These things are in the $millions and we aren't anywhere near the next purchase cycle. The only thing I can do is harden it by lobbing it onto it's own VLAN.

</comment><comment><USER20> We're about to spend a number of dumptrucks full of money for a modern WCMS combined with a totally new design effort, and I guarantee you at some point someone will see a customer coming in from W7/IE11 and demand we design for 5 years ago.

So if you're that one guy, _can you not_, thanks!

</comment><comment><USER21> Internet Explorer is the only option for Windows Server.

<comment><USER22> The only browser on a server should be curl. Or wget.

Running a 'webbrowser' other than lynx/links/w3m implies a GUI, which makes no sense as you wouldn't have a GUI on a server.

<comment><USER23> Absolutist thinking is not good for you and I think that it often clashes with reality.

The only browser on your server should be the one you need to run there. How about a server to automate some Windows GUI thing or to run mobile OS emulators like BrowserStack does? You're gonna need a GUI there because going "headless" is not always an option depending on how interesting your work is.

I've also used server editions of Linux and Windows as my workstation throughout my career because they have features that I needed or just the convenience of having the same exact setup as production.

<comment><USER24> And Remote Desktop Services.

</comment></comment></comment></comment><comment><USER25> Migrating enterprise off IE will have a cascading effect on their cloud effort.

Most cloud revenue is from Windows only shops who use active directory, SharePoint...

When Microsoft harassed users off internet explorer, people didn't jump to Edge as they hoped. They ran to Chrome.

I predict the same happening for enterprise. If companies have to dev new software when leaving IE, it might cost less to just jump to Linux.

</comment><comment><USER26> Someone tell Microsoft "Mission accomplished!!!".

I knew they would ocme to their senses eventually so I stopped using IE about 10-12 years ago!!

<comment><USER27> This will only accelerate Chrome's rise to being a browser monopoly though. Google has been doing a ton of anti-competitive stuff to put the hurt on Firefox and IE. It's really a very bad thing for the internet.

</comment></comment><comment><USER28> You reap what you sow Microsoft...

</comment><comment><USER29> That makes two of us.

</comment><comment><USER30> "compatibility solution, not a browser"

It's more of a browser than any shell around chromium will ever be.

<comment><USER31> Is chromium not a browser? Surely a shell around it, which includes it, is also a browser.

<comment><USER30> > Surely a shell around it, which includes it, is also a browser.

An eggshell isn't an egg.

There's a browser _there_ , but it's copied wholesale. And it's the worst thing to copy if you care about the future of web standards.

<comment><USER32> Why not? Chromium is open source and uses webkit which has wide adoption. An eggshell wrapped around a yolk certainly is very egg-like.

<comment><USER30> An egg is made out of shell and white and yolk.

That does not make the shell itself an egg.

Microsoft is promising to make a shell, and to not make anything else.

<comment><USER32> The problem I have with this description is you could describe any software that has a renderer thats separate from the UI like this. Perhaps in Java if we had an egg, we could,

import egg.yolk; import egg.whites; import egg.shell;

Egg fakeEgg = new Egg(brown);

<comment><USER30> Which ones do you develop?

The whole thing is a browser. But Microsoft isn't developing a browser. The rendering engine, javascript engine, network handling, almost all the important input handling, all the things that make it a web browser, they're coming from someone else. And that source has a default shell too.

Remember that the baseline is questioning whether IE counts as a legitimate browser. If you're even slightly unsure about IE, then "shell around chromium" has to be far far on the no side of the line.

</comment></comment></comment></comment></comment></comment></comment><comment><USER33> Ha, I'm waiting this whole windows thing out.

I've never used windows ever, from ver 1 through the horrible 95 and NT, till v8 and onwards with it's spyware built in.

Glad to hear IE is also going away.

Enjoy your backslashes guys!

<comment><USER34> I actually have to hand it to you if that's true. You waited it out for like 25+ years, that's some impressive dedication. The "I told you so" attitude doesn't come off as pleasant though.

<comment><USER33> Well I can't even say "I told you so" yet.

This is just Microsoft discouraging the use of IE, Windows will still be around for a long time.

In many ways I've been lucky that I've been able to keep it to UNIX and Mac OS.</comment></comment></comment>


Myspace vs facebook: the facts - <AUTHOR> http://www.fastcompany.com/node/958577/print

<comment><USER2> Facebook is for connecting with your friends. MySpace for for hooking up with the opposite sex. Unless you're a musician, MySpace becomes useless once you're no longer single or married - that's when Facebook kicks in, IMHO.</comment>


AMD stock rises after best earnings in 7 years - <AUTHOR> https://www.marketwatch.com/story/amd-stock-rises-after-strong-revenue-fuels-earnings-beat-2018-07-25 <comment><USER2> And they're about to drop their new 24 & 32-core threadripper CPUs in a few weeks, for which Intel has no economically viable response. AMD is going is going to crush their earning reports for the next few quarters.

<comment><USER3> Well, Intel does want to put out the 28 core i9 eventually. Hopefully with a free industrial chiller.

<comment><USER4> This is what I don't understand. I thought all Intel has to do is to price its offerings cheaper to become competitive with AMD. They have the margins, don't they? Or is it not possible to lower prices?

From all I've read it feels like Intel dug itself into a hole with price segmentation but that means it can dig itself out by simply not being as greedy?

<comment><USER3> This is speculation to some extend, but I don't think it'll be that easy.

Intel does have margins on their products but at the same time, the products are still expensive. I fault their production method for that. I bet that even if they sold their CPUs at a loss, AMD could undercut them in the important market segments at minimum.

AMD has struck gold with being able to, in Intel's words, glue together a bunch of desktop CPUs.

Intel's biggest CPU, a 28 core, is a monolithic die. All in one go. Which means the yields are bad. AMD produces basically 1 die and glues together as needed. The yields here are much better due to the smaller die and being able to use basically any die that has functioning 2 cores.

Intel doesn't have a response to that since if their 28 core die has 26 defect cores, they don't have a housing for it to sell in. Their segmentation also means that they don't have compatible sockets in size to even conceivable put the 28 core to use at all.

IMO Intel will have to come up with a similarly modular response or reduce their production cost.

Of course, Intel has a while, they can idle a few years on marketshare and mindshare before they run a risk of loosing the CPU business (and they sell other silicon too where AMD doesn't compete). So likely, they will be able to do it.

Question then is how much marketshare AMD will have eaten by then.

(Personally, I hope AMD will release server cpus for the lower market segment, building an Intel-based Server that doesn't have the suck is rather expensive and low-cost baremetal would be a delight for hobbyists and SMB)

<comment><USER5> What difference does monolithic vs. modular really make? If Intel has a core on their 28 core die that is defective, they just disable it and sell a 27 core chip. Perhaps it's easier for AMD to find 4 8 core chips with no defects than for Intel to find a 28 core chip with no defects, but Intel can just make a 34 core die sold as a 32 core chip with better yields than AMD's 8 core dies.

<comment><USER3> There is a huge difference.

The number of defects is an average over an area. So if you double your die area then you get double as many defective chips.

Making a bigger chip means you throw away more dies. So Intel's 34 Core would be even more expensive to produce.

Imagine it like taking a low res photo of a paper with dots drawn on it. The bigger the pixel the bigger the black spots on the paper will be. The higher resolution your camera is, ie the smaller the pixel, the more pixels that aren't black, ie defective silicon.

AMD has the advantage here, their 4 core dies are very small so they can produce them with a high yield rate. The defect one with 1 or 2 defect cores but otherwise okay are recycled. Then everything is binned according to their performance (chips can have wildly different performance).

Another advantage Intel does not have. If one core on the 28 core chip does not manage to run stable on 2.8 GHz (example if they sold the chip at that) that means either bin it on the next lower frequency to run at or trash the die.

For AMD a low running chip means getting it into a lower bin. If they build a 32 core CPU with high core they just need to select from 4 core dies that run fast.

The difference here is very surprising, IIRC AMD stated their yield rate is 98%. For comparison, a chip like the 28 core Intel Xeon would be expected to have around 60% if not worse. And Intel can't rebin a bad Xeon for a low power desktop CPU in the lowest market segment since the die is too big for those sockets.

</comment></comment></comment></comment></comment></comment><comment><USER6> AMD has been my best investment so far. I've always loved them as they've been the rebellious underdog and have brought competitively powerful CPUs into the affordable range for historically low income computer nerds such as myself multiple times.

Bitcoin/crypto would have been my next best-- if only I hadn't had my bitcoins stolen from an early mining pool... oh well.

<comment> J0-nas Are you concerned about the state of AMD GPUs?

They couldn't compete in terms of high end performance for a long time. But nowadays they even lose the price-performance ratio of entry->mid level GPUs.

<comment><USER7> Not really. Entry->Mid level is RX 560, RX 570 and RX 580. RX 560 is a mixed bag, but both RX 570 and RX 580 are competitive and a bit superior to the Nvidia alternatives - as long as they are not overpriced, which they were till early this month. So the market just has to reach the regular prices AMD aimed for initially for those series to work fine.

But one can be concerned about the utter failure of high end Vega.

<comment><USER8> Luckily crypto saved the Vega. You can't really buy them for MSRP.

</comment></comment></comment></comment><comment><USER9> If the rumor [0] that Intel's first 10nm server chip will only release mid 2020 is true, then AMD's shares will probably skyrocket again if they truly can release their Zen 2 server CPU mid 2019 (on 7nm which is comparable to Intel's 10nm).

[0] [https://twitter.com/david_schor/status/1022142835989118977](https://twitter.com/david_schor/status/1022142835989118977)

<comment><USER10> And they just announced in their conference call, Zen 2 Rome will be Fabbed with TSMC 7nm.

</comment></comment><comment><USER11> "Epyc data-center graphics processing unit (GPU), which has been out for a year"

Uh, do they mean vega GPUs or EPYC CPUs?

That aside, the experience I've have had with the EPYC cpus has been awesome. They are truly amazing for the price tag.

</comment><comment><USER12> How is AMD doing in the GPU for deep learning business? Have they completely ceded that market to Nvidia?

<comment><USER13> They've made a CUDA competitor ([https://rocm.github.io/](https://rocm.github.io/)) and it works well enough to port Tensorflow to ([https://github.com/ROCmSoftwarePlatform/tensorflow](https://github.com/ROCmSoftwarePlatform/tensorflow)).

Not super impressive, but we'll see what happens I guess.

<comment><USER14> Is running TensorFlow on GPUs still relevant now that google has their TPUs? Other dedicated hardware is also coming.

<comment><USER9> I don't really follow the ML space, but when you have a good GPU in your PC (which I assume quite a few people here have) you can learn/use Tensorflow by running things locally instead of paying for Google Cloud etc. Why pay extra money if you already have a good GPU in your computer (unless you really need to decrease the time it takes to run the computation etc.)

</comment></comment></comment></comment><comment><USER15> I wanted a GPU to dabble in mining, machine learning, and games in my new Ryzen build. I went Nvidia becuase of CUDA. That is too bad. I'd have liked to buy the AMD gpu

<comment><USER16> I think you were right to stick with Nvidia. I have an AMD in my MacBook and it sucks that I can't use it for most deep learning stuff.

</comment></comment><comment> amiga-workbench Very pleased to see AMD doing well again, vigorous competition in this market is very much required.

</comment><comment><USER17> Oh hell yeah. So glad to see this new competition from AMD. Looking at getting a Ryzen laptop for my next personal workstation. The benchmarks looks fantastic.

</comment><comment><USER18> Arg, I sold out of my position in $AMD in January after growing impatient waiting for Ryzen profits to show up. That proved to be a mistake, should have held onto my guns and thesis.

Perfect buy was on April 25th, up 75% since then.

<comment><USER19> I bought AMD at $2.87 after someone on HN or Reddit (can't remember which) from AMD was discussing their new architecture and how it could be manufactured cheaper and was as performant.

Thank god someone spilled the beans; also incentives me read HN all the time -_-

<comment><USER18> lol, insider trading? :-) Do have the original comment thread?

<comment><USER20> Probably not insider trading lol. AMD was extensively shilled on /r/wallstreetbets and /r/amd_stock for 2 years now.

<comment><USER21> I'm not sure what else you expected from /r/amd_stock.

<comment><USER20> I didn't say I expected anything else. The point is it's not secret information that Jim Keller's Zen was going to change the landscape, people were shouting it from the rooftops. It was all just a matter of whether you believed them or not.

<comment><USER21> Right, but the point is that particular sub would be shouting it from the rooftops regardless of the underlying truth.

I think most would look at the situation and conclude that even broken clocks are right twice a day.

</comment></comment></comment></comment></comment></comment></comment><comment><USER22> Anyone increased their NW substantially betting on AMD?

<comment><USER23> Yep, I gained low 6 figures so far

<comment><USER22> Enjoying CGT? ;)

</comment></comment></comment><comment><USER24> AMD should thank Nvidia for failing to produce enough cards to meet demand.

<comment><USER25> Word is Nvidia overproduced and is sitting on a lot of current gen stock.

Miners bought AMD because AMD cards are usually better at mining for the money. They started buying more Nvidia when AMD didn't make enough cards.

In any case though, the success of Ryzen is the interesting thing, not the mining sales.

</comment></comment><comment><USER26> I mean I'm happy for AMD but "company makes money: stocks go up" is pretty much dog-bites-man non news.

<comment><USER27> There's a narrative that Intel will keep AMD down no matter what, so it's good to see the market working and refuting that.

<comment><USER28> Yep this is indicative of future IT trends and current. Plus we should all be applauding any competent competition for Intel. Imagine where we'd be if AMD had been a more credible threat sooner. I bet Intel wouldn't be able stagnate as much.</comment></comment></comment>


Invasion of the Body Hackers - <AUTHOR> http://www.modernluxury.com/san-francisco/story/invasion-of-the-body-hackers

<comment><USER2> Dave Asprey's claims of micro-toxins in coffee are false. Joe Rogan, formerly a Asprey fan, has since had his own tests done and Asprey's claims about micro-toxins are just wrong.

</comment><comment><USER3> Bulletproof coffee work?

I've had it a few times, seemed ok. Not sure it did anything for me.

Also, who thought of the concept first? My understanding is that the "bulletproof" brand just popularized it.

</comment><comment><USER4> _On a blindingly sunny September weekend in Southern California, 500 or so biohackers and brain tinkerers and people who would like to sell them things congregate at the Pasadena Convention Center for the Bulletproof Biohacking Conference, a three-day, $1,599 series of workshops..._

 _...40 Years of Zen (an Asprey-endorsed neurofeedback program that promises its users 12 more IQ points, more creativity, and less mental clutter in exchange for seven days of their lives and $15,000),..._

 _Because these supplements and systems promise vague improvements rather than make specific health claims, they're not subject to FDA approval—which means that they may be not only ineffective, but dangerous. (Not for nothing do Bulletproof conference attendees sign many-paged waivers before entering the convention hall.)_

Wow.</comment>


Some Elite Colleges Review an Application in 8 Minutes (or Less) - <AUTHOR> https://www.wsj.com/articles/some-elite-colleges-review-an-application-in-8-minutes-or-less-1517400001 <comment><USER2> Back in the days when I read slush I could reject manuscripts at a rate of about 20-25 an hour. It doesn't seem surprising to me at all that if you are looking at these papers all day long, it's not going to take very long to learn how to quickly weed out the obvious nonstarters.</comment>


Blame Your Product Manager - <AUTHOR> http://blog.aha.io/index.php/blame-your-product-manager/

<comment><USER2> this looks really interesting. should be a Show HN?

<comment><AUTHOR> Are you referring to Aha.io? If yes, various aspects of it have been, but we welcome your thoughts and anything that you would want to Show HN.</comment></comment>


Ask HN: I beleive I found a vulnerability in some software. What should I do? - non-entity Closed source, propriety stuff. Is it best to let be? It's not major, but it does leak credentials that wouldn't otherwise be accessible. <comment><AUTHOR> Email them especially since it is leaking credentials. Let the onus of blame be on them. Although they might be aware of it and busy patching it already. They might have contact information or a dedicated security email or security matters page as well. Perhaps, they might also have a bug bounty program. At least, you can have bragging rights later on identifying vulnerabilities and place that on your resume.

<comment><USER2> I had an experience with a major app that had a major 2FA fail. They wouldn't even look at it unless submitted through Hacker One (I was giving them a friendly heads-up and sought no compensation).

I spent hours documenting it, writing detailed descriptions, and making a video of the leak in a live session.

They closed the case with a vague (and unrelated) message within 30 minutes of its submission.

I deleted their app, never used it again, and don't work with people who do.</comment></comment>


Ask HN: When did you get good at computer science? - <AUTHOR>

I am currently an undergraduate senior majoring in computer science. My last few years, I have been learning computer science through a very breadth first approach, always working on different types of projects or reading about something different every couple of days. Although I have learned a lot, I feel like I am not amazing at any one area of computer science.
I thought by this time in my life I would have fallen so dearly in love with some topic that picking a specialization would have come naturally . However, I am interested in so many things right now, it is hard to limit myself. If I don't though, I am afraid I will be at the same place I am right now in ten years.
When did you decide that you wanted to specialize in some area, and what was the path like to the day when you woke up and realized "I am really good at X." ? <comment><USER2> You don't wake up on day and realize you're good at something. You become good at something after years of practice and study.</comment>


Show HN: Feedseer – A Mastodon instance to filter out posts based on content - <AUTHOR> https://feedseer.com/about/more <comment><USER2> This looks like it is presented as geared towards mastodon consumers who want to control what they see on their timeline. I think a mastodon client would be a better choice for an entity that supports these features than a mastodon instance. Why did you chose to design such an instance instead of a client with filtering capabilities? This instance looks like a great tool for moderators instead of mastodon consumers.

<comment><USER3> Not my project, but why bother writing a whole client and maintaining it when all you want to do is build some better filters?

Get filtering happening on the server, then it works for everyone on that server regardless of whether they're using the default web app or an app on their phone.

Some Mastodon admins share their patches for things outside the scope of what gets approved by the project lead so if they decide it's a good thing then maybe they'll add this feature to their own instance; the 'source code' link at the bottom leads to the git repo that is presumably their live code.

</comment></comment><comment><AUTHOR> I got some feedback that it's hard to understand the site without seeing it in action. So, I wrote this post. [https://medium.com/@sunilbandla/introduction- to-feedseer-578...](https://medium.com/@sunilbandla/introduction-to- feedseer-5787cff7254).

</comment><comment><USER4> Always cool to see another variant of the fediverse. I wouldn't entrust my feed to algorithms, but I'm sure there's a market for it.

</comment><comment><USER5> Mastodon already has pretty good regex filtering built in to the platform.

<comment><AUTHOR> Yes. Feedseer's qualifiers can do much more than regex filtering, like use AI to analyze the sentiment of a toot. The implementation details of a qualifier (regex, AI or other) are up to its creator and happen outside of Feedseer. Independently, a Feedseer user has the freedom to not use a qualifier (the default), or use it to take action (categorize/filter).

</comment></comment><comment><USER6> Are we really there? Outsourced, automatic, personal censorship?

Traditional usenet + personal killfile + (eventually) spamassassin are not enough anymore?

Try to think a moment: think how can be easily influenced by platform holders the content you get with all kind of "AI" solution respect of traditional "taxonomy" based solution (usenet hierarchy is essentially a taxonomy, so are feeds, bookmarks etc).

Automation is ALWAYS a must, but without loosing control.

<comment><USER7> I'm not sure how this comment applies to the site discussed here?

It allows the user to set filters. There is no "influence by platform holders". There is no "AI". There is full control over the automation you use.

</comment></comment><comment><USER8> I wouldn't want a tool like this deciding what I do or don't see. I thought that was part of the reason from moving away from centralizing platforms. What benefits does this provide over simply not following people?

<comment><USER9> What if you want to follow someone except for 10% of posts that forward a webcomic you find distasteful?

What if you want to find 100 people who occasionally post content in a narrow area interesting for you, but you have no interest in the rest?</comment></comment>


United and Continental will combine to form the world's largest carrier - <AUTHOR> http://www.google.com/hostednews/ap/article/ALeqM5g1nqrjLlyR8gd4N1ciZJryfh25LAD9FD1NHG0

<comment><USER2> Nice. Now I can feel like I am supporting the underdog when I fly American. Mindblowing.</comment>


The Last Bus Startup Standing: Chariot - <AUTHOR> http://techcrunch.com/2015/11/29/the-last-bus-startup-standing-chariot/ <comment><USER2> I used Chariot to get to work in SOMA from the Marina since they launched (now I live in NYC). The problem they're talking about is no joke. If they didn't exist, I'd have to walk 10 blocks to get to an earlier stop on my line. Alternatively, I'd walk 10min up a hill to get on a bus that took 45min to get to my office, which was less than 3miles away from my apartment. When not using Chariot, I ended up biking to work (about 30min) out of pure necessity.

There's unnecessary efficiency in the bus routes. Chariot's advantage for the Marina to SOMA route is that the majority of people riding that bus route are heading to SOMA, but the bus makes a lot of windy stops in China Town. There should really be two lines, one that exclusively serves China Town from the Marina, and one that exclusively serves SOMA. During rush hour, Chariot adjusts its route based on traffic sometimes saving 10-20min a roundtrip. It has the flexibility to do so since it bypasses China Town.

<comment><USER3> > I'd walk 10min up a hill to get on a bus that took 45min to get to my office

Why not just walk the 3 miles directly? It would take less than 55 mins for sure.

<comment><USER2> Google Maps indicates an hour walk. MapMyWalk show a 186 elevation gain, which I suppose is not too terrible considering it gradually increases until about the halfway point, and then gradually decreases. Add a laptop and hefty book into the mix, and you've got yourself an equation for one sweaty commuter.

I've also used Scoot which gets me to work a little faster than Chariot, but depends on there being scooters available and is more of a commitment than Chariot given Scoot's subscription (Scoot is awesome though!). Quite a few of my coworkers gave up on any sort of shared transit, and drive to work pretty regularly.

As a comparison, it took me a little over an hour to get to work using the CalTrain when I lived in Palo Alto and had a 35mile commute.

Another example would be going from Chelsea to the Lower East Side in NYC (about the same distance as Marina to SOMA). Takes between 25-30min using the subway on Google Maps.

[https://www.google.com/maps/dir/Chelsea,+New+York,+NY/Lower+...](https://www.google.com/maps/dir/Chelsea,+New+York,+NY/Lower+East+Side,+New+York,+email@example.com,-74.0109428,14z/data=!3m1!4b1!4m14!4m13!1m5!1m1!1s0x89c259b082b8c8a7:0x2e54eb9ab02636f0!2m2!1d-74.0013737!2d40.7465004!1m5!1m1!1s0x89c2598015ac8beb:0x59b849fea56b6a70!2m2!1d-73.9842724!2d40.715033!3e3)

The Marina to SOMA takes closer to 40min, but that's assuming you can get on the bus, which during rush hour is surprisingly difficult (like the article refers, you might wait 3-5 buses to find one with space).

[https://www.google.com/maps/dir/Marina+District,+San+Francis...](https://www.google.com/maps/dir/Marina+District,+San+Francisco,+CA/SoMa,+San+Francisco,+firstname.lastname@example.com,-122.4392007,14z/data=!3m2!4b1!5s0x89c2fa533fc767a3:0x663c92cc7cdbfe36!4m14!4m13!1m5!1m1!1s0x808580d79ae5a51b:0x3c50fe8f3930832!2m2!1d-122.4368151!2d37.8036667!1m5!1m1!1s0x80858083a662307b:0xfd99010c2dc1f950!2m2!1d-122.4056395!2d37.7785189!3e3)

<comment><USER4> Cheaper than paying for the gym.

</comment></comment></comment></comment><comment><USER5> OK, out of scope for what happens in San Francisco, but to put them on the map a little in China and certainly related to bus startups:

pandabus.cn are a small startup that provide real-time bus mapping (i.e., where is my next bus going to arrive - public busses) and private busses (either their own, or owned by someone else) for some cities in China. While privately shared busses are an old thing, they're consolidating everything together quite well and making it much more transparent.

I have no affiliation, other than being a user of their app, and while I've not met them, I understand they're a small team of around 20 people based in a technology building not far from me. Support your neighbours, etc.

</comment><comment><USER6> "Because Chariot is a consumer web and mobile startup with a direct relationship to its users through an app"

It is hilarious how these companies are called "web and mobile startups". People have been buying vans, buses and cars and running their own lines in emerging markets for over half a century in a profitable and sustainable way, and taking ride requests over SMS, WhatsApp and what not.

<comment><USER7> But those companies operating for half a century hadn't done it with a cell phone app. It's like pets.com and their unique angle of doing business on the web.

Ok, sarcasm aside, the article does point out a lot of quick-adaptation risk- reducing operations -- from not "cowboying it" with the law to getting card info from a critical mass before opening a route. It's an interesting read. Looks like there's a reason they've gone more amazon than pets.com (although it probably can't scale like amazon).

<comment><USER6> I agree with that point, but that's just a different form of market research, nothing new to see here. Instead of doing surveys over the phone or on the street, they're using an app.

</comment></comment></comment><comment><USER8> Let's hope not for long, found that trend of "busses without the poor people" a disgusting concept for a business.

<comment><USER9> I totally disagree with you, but I think this is an important point and you shouldn't be getting downvotes for it. I ride a city bus pretty routinely, although I don't live in SF. I would still ride the city bus if Chariot came to town, but I think "busses without the poor people" might be a good way to get the snobs you're sneering at onto transit and out of their private vehicles.</comment></comment>


Large Scale Deep neural net falling down the rabbit hole - <AUTHOR> http://www.twitch.tv/317070

<comment><USER2> Please don't tell it to look for cockroaches again.</comment>


Can 'Pods' Bring Quiet to the Noisy Open Office? - <AUTHOR> https://www.citylab.com/design/2019/07/open-plan-offices-architecture-acoustics-privacy-pods/586963/ <comment><USER2> The thing that a lot of these articles miss—probably because it doesn't matter at all to bean-counters—is personalization. The idea of spending all day tapping away at a laptop keyboard makes my wrists ache thinking about it, and the idea of being limited to a laptop display is pretty bad too. A real desk with a real keyboard (and no keyboard is one-size-fits-all!) and a real display is key to productivity, and wholly missing from all of these "just work from a couch/phone booth/privacy pod/hot desk" designs. People need individuality in their workspace equipment, to say nothing of the ability to personalize their environment to make it _human_ with things like pictures and plants. The inability to claim any part of the work environment as uniquely _yours_ is dehumanizing, and only serves to make people less attached. If companies want people to be attached to their employers (whether or not they actually should be), they might try harder to make the workplace less generic and depersonal.

</comment><comment><USER3> Is $3.5k per engineer really any cheaper than hiring a bunch of guys to throw up drywall and a prehung door? I suppose ventilation ductwork (even in a drop- ceiling) will probably put you over, but we are still working in the same order-of-magnitude of a high-end workstation.

A few years ago we converted a large area to offices and drywall was actually cheaper than 70"\+ height cubes (nobody wanted the "gopher" effect of the 4-5 foot cubes).

The final pricing of the drywall ended up slightly higher than the initial cube estimate, but only because network/phone/electricity was run into the walls for convenience.

</comment><comment> chris-hexx Open office is the future on average, just because it's the best you can do for dollar/worker/sqft. Offices with doors, we are told, are too expensive, because they're accounted for differently as part of the building, not part of depreciating furnishings and equipment.

Under that constraint, I don't understand why soundproofed full height cubicle walls with closing doors aren't the obvious compromise between what can be sold and what can be installed. Is it fire code? Do businesses who care about productivity spring for actual offices?

There appears to be a niche here, and I don't see why it's not filled.

<comment><USER4> The commercial real estate owners are also to blame. They used to have to build out the office space to a tenants wishes to attract tenants. It is much cheaper and easier for them to take out the walls/offices and tell the clients to furnish it how you want. While open offices are cool and there are more tenants than space, the owners refuse to do anything else.

</comment></comment><comment><USER5> So, cubicles? I'm game for that. I thought I hated cubicles, once upon a time. Then they took them away and gave us open office plans. Now, I miss those 5' tall cubicles I once loathed so much.

<comment><USER6> I dunno. The one pictured up at the top is maybe 6' x 6' and the one in the middle seems closer to a claustrophobic 4' x 4'. I suppose they're better than open plan but they seem more like cages than office space.

A pox on all the bean counters. I want to go back to the days when I had an 8' x 8' office with a door that I could lock.

</comment></comment><comment><USER7> Just stick cotton in your ears...

Only something like 7 dB of sound attenuation so if someone comes over to talk to you you can still hear them. That 7 dB (about a quarter) really takes the edge off the noise and makes for a less stressful day. Comfortable and breathable. You can jamb it in so it is hard to see, if for some reason that bothers you.

Works outside the office as well to take the edge off traffic noise and even airplane noise in a pinch.

I forgot and left the cotton in for a trip to the supermarket and even that was improved. The annoying muzak seemed far away.

<comment><USER8> Hearing protection is mandatory in the workshop where I work.

Somehow I managed to start wearing earplugs most of the time while I drive, and more recently have been leaving them in when I go to the supermarket and when I get home. I'll occasionally sleep with them in too.

It certainly does make a difference, in my experience.

</comment></comment><comment><USER9> You wish to make your glass hot desk prison even smaller and more confining?

Remind me why you would want to do that?

</comment><comment><USER10> Nope. But they can further marginalize people with mobility issues.</comment>


Training Differentiable Models by Constraining Their Explanations - <AUTHOR> https://arxiv.org/abs/1703.03717 <comment><USER2> someone want to do us all a favor and define what an explanation is in this context

<comment><USER3> Quick explanation here: [https://github.com/marcotcr/lime#what-are- explanations](https://github.com/marcotcr/lime#what-are-explanations)

<comment><USER4> That explains LIME, an older paper that's not the one being discussed here (but is referenced)

<comment><USER3> It also explains what an explanation is in this context (which is what was asked): a local linear approximation of the model. Additionally it has a diagram which is nice. Obviously it's not the one being discussed here though -- I'd hardly be adding useful information if I just linked to the submission again as a reply.

<comment><USER5> Yeah, so local linear approximations are what we and LIME are using as explanations, but it's not what an explanation is generally.

In the paper we do define an explanation as basically any artifact that "provides reliable information about the model's implicit decision rules for a given prediction." It's kind of a rough and over-general definition, but it gets to the idea that explanations can be partial. All we want to do is turn a completely black-box model into something slightly more transparent.

Ideally, we could have explanations that were at a higher level of abstraction, e.g. "this image is a picture of a husky and not a wolf because of the shape of the nose and the color of the coat," but a neural network has no idea what "nose" and "coat" means. Sometimes its intermediate layers will end up corresponding to meaningful abstract concepts like that, but not always.</comment></comment></comment></comment></comment>


Has anyone noticed the new "I'm feeling lucky" button? - <AUTHOR>

Mouse hover it <comment><USER2> Yes, that's due to google instant search - the I'm feeling lucky button no longer has a use (aside from visiting the doodles page)

<comment><USER3> I get nothing special on hover, but I get a 503 error when i click it

503\. That's an error.

The service you requested is not available at this time.

Service error -27. That's all we know.

[edit]- that was when signed in to google. If I open an incognito window, clicking the button brings up google doodles as expected.

<comment><AUTHOR> You are not getting links to <http://agoogleaday.com> and google maps with random pics. I find this awesome

</comment></comment></comment><comment><USER4> You still use google search? <https://duckduckgo.com/></comment>


Nano-hack 19yro runs kids code camps rather than making dotcom $. Needs donation - <AUTHOR>

tl;dr you should donate to him here:
http://comicmac.com/help-me-setup-dojos/
I met him (James Whelton) once when he detailed his Nano-hacks (at age 17) at Dublin Web Summit. Then again recently (at age 19) where he discussed his home-grown coder dojos that are teaching thousands of kids throughout Ireland and now the US how to program in unpaid after-school workshops. He's inspirational and the best of coder conscience. He's paid a trivial weekly stipend and paying for travel out of pocket. I've donated. Your turn:
http://comicmac.com/help-me-setup-dojos/ <comment><USER2> Why doesn't he just charge the kids' parents a small fee for the service he is providing?

<comment><USER3> I agree, parents should be asked to pay a small fee. The cost of a burger will not be bad. I am planning on starting something like that in my children's school if the head will agree. In order not to disadvantage the really needy families, I don't mind teaching such children for free, but that need must be proven in order to stop abuse.

<comment><USER4> Hey, so there is a couple of reasons we run it for free. Firstly theres no entry barrier, young people from all backgrounds come and kids that don't have laptops we try have spares to let them use. Money we found generally complicates things (where is it going, is there transparency, some locations start wanting rent money, etc). Some people find it hard to grasp also, but free youth activities in Ireland are extremely common.

Regarding abuse, people using it as a glorified babysitting service, etc. We have a rule that if a kid is 12 or under, they must have a parent or guardian there responsible for them. As we're extremely over booked (waiting list of 200 in Dublin), we reserve spots for extremely interested kids, who keep coming back and producing things and leave other slots open. If a kid is being disruptive and won't stop, we tell the parent to calm them down (Extremely useful when working with kids that have autism as some have behavior issues that parents can address there and then)or to take them home.

To date, running it for free has worked extremely well and in every Dojo, theres been little, if no issues. People are volunteering, giving up their time for free and volunteers are normally blunt with parents if its being abused.

We try to remove as much financial dependency from CoderDojo so its easier to set up anywhere and run, individual Dojos can arrange donations or sponsor if they want. In my case, I'm looking for some assistance if people want to give it, helping me setting them up.

@thepreacher thats awesome that you're starting something! If you want a hand please drop me an email: email@example.com, theres definitely some advice on things we've learned and resources we can give you!</comment></comment></comment>


Posting Rules in Online Discussions Prevents Problems and Increases Participation - <AUTHOR> http://civilservant.io/moderation_experiment_r_science_rule_posting.html <comment><USER2> I have a feeling this effect will soon be nil. The more subreddit sticky comment rules, the more people will adapt to filter them, like the way we ignore ads.

A lot of the subreddit I subscribe to have rules. I barely notice them anymore.

<comment> Ar-Curunir But if the rules are strictly enforced, then people generally stick to them.

<comment><USER3> The rules also tend to be largely similar.

\- Be polite

\- Be on topic

\- Use approved hosting

So it is relatively easy for most of us to stay within the lines

</comment></comment></comment><comment><USER4> I wouldn't be so sure of that. I've seen two separate communities completely fizzle out when rules were posted. These were smaller communities, with 20-50 people, though, and not reddit-size communities.

<comment><USER5> There is a regular pattern I've seen with a lot of subreddits where they initially start off being fairly lax in what they allow. Eventually the "old timers" get bored of seeing the same types of content being repeated and so they come up with rules for the sub. If the community is small enough this has the effect of putting off new users from posting and drastically cutting post volume.

If the subreddit is big enough on the other hand then this often improves the quality of discussion and effectively reduces the amount of what the old timers consider to be low quality content.

<comment><USER6> On a larger scale just look at Wikipedia and Stackoverflow and the discussions and blog posts about how bad they have become especially for newcomers the last few years.

Maybe a multi-layered approach could be tried, where people can choose to see content on different layers?

Long-time users fed up with mundane questions only get to see "advanced" posts, but beginners can still post a million "How do I (standard task)" questions without bothering anyone else. Instead of trying to split the people and direct them to different sites use layers. Same could be done with "funny" content (reddit especially, where every attempt of a serious discussion is swamped by 80% posts form people who don't really know anything about the subject, don't care, and just want to be entertained).

So instead of trying to achieve what now seems to be impossible I think we _might_ actually be able to find better ways to keep disparate users in the same forum. The problem with trying to separate beginners and advanced etc. is hat people _change_. What was a beginner becomes a an advanced user, but they don't see that _they_ should shift to a different site for "advanced users". After all, they've always been here! So sites like SO or Wikipedia seem to have a natural tendency to eventually become more and more beginner-unfriendly over time.

<comment><USER7> The problem is that everyone's post is "advanced", just like every bug is priority 0.

<comment><USER8> Then let others rate the complexity/novelty/nicheness? Of course asking users to rate on multiple dimensions is a problem on its own.

It may come off as elitist, but it may also help to find newcomers things they can contribute to. Similar to "good first bug" tagging on some bug trackers it could also help others to filter out things they can help with or that are too boring for them to bother with.

Efficient allocation of expertise is necessary.

<comment><USER9> Complex rating systems do not work. Even meta tagging on porn sites doesn't work properly for that and they have the most avid searchers.

It would be better as a baseline to use the forum's memory as a filter for each user instead of coming up with an objective standard for what is novel or complex to them.

I also believe we can extend this forum memory concept by some kind of generation of valid information (a sort of autotldr bot) to be inserted into newbie threads. This bot could then be rewarded by users if it gets a 'hit' because you're right at the point where somebody was helped out so you could suggest a small payment of $0.10 or something. That would be a nice way to scale the forum to large numbers of users and you could also reward the sources of the original information so those users get credit for their aid.

<comment><USER8> > Complex rating systems do not work.

Yeah, that is my main concern too. Maybe instead of tallying up/downvotes verbatim one could do clustering analysis on the voters. Votes by people who have similar voting-behavior might be of more interest to a user than votes by voters who have uncorrelated or even inversely correlated behavior.

> It would be better as a baseline to use the forum's memory as a filter for > each user

Not sure what you're suggesting.

<comment><USER9> > Yeah, that is my main concern too. Maybe instead of tallying up/downvotes > verbatim one could do clustering analysis on the voters. Votes by people who > have similar voting-behavior might be of more interest to a user than votes > by voters who have uncorrelated or even inversely correlated behavior.

That's the essential idea behind Amazon and Netflix recommendations so it is quite workable.

>> It would be better as a baseline to use the forum's memory as a filter for each user

> Not sure what you're suggesting.

I'm saying you have this massive haul of threads of which the majority are never referenced because they happened in the past. Normally users need to search this backlog but often don't know the right search keywords to begin searching. Thus they ask the same old questions of the old-timers who become crankier and crustier by the day because of this.

Since the same questions are asked multiple times you should be able to tally the answers together into a cogent form in a similar way to the method that autotldr bot uses on Reddit to summarize news stories.

Then you could present this information in a currently running thread that appears to ask the same questions.</comment></comment></comment></comment></comment></comment></comment></comment>