Introduction to Go 1.1 - <AUTHOR> https://go.googlecode.com/hg/doc/go1.1.html <comment><USER4> Two most interesting news for me are:

> The garbage collector is also more precise, which costs a small amount of > CPU time but can reduce the size of the heap significantly, especially on > 32-bit architectures.

Previously, 32-bit version was almost unusable is some cases when garbage collector kept the allocations for which he falsely believed to be used even if they were not. I'd like to know if this means that the problem is finally solved.

> Previous Go implementations made int and uint 32 bits on all systems. Both > the gc and gccgo implementations now make int and uint 64 bits on 64-bit > platforms such as AMD64/x86-64.

This is a C-like can of worms, forcing you to test on more platforms just to be sure that you have portable code. I believed there's no reason to do such things with primitive data types in the new languages of 21st century (compare with [http://docs.oracle.com/javase/tutorial/java/nutsandbolts/dat...](http://docs.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html)). I'd like to see any discussion about such in my opinion quite strange decision.

<comment><USER5> On the go-nuts list people have been reporting large slowdowns with the new precise GC, and someone even backported the old GC to Go 1.1.

<comment><USER6> > with the new precise GC

The new GC is still not a precise GC, it's still conservative and non-tracing, just "more precise" (probably means they refined their heuristics) so you should probably not call it a precise GC.

<comment><USER7> I thought Go 1.1 featured precise GC on the heap and conservative on the stack. Is that incorrect?

</comment></comment></comment></comment><comment><USER8> Worth also knowing that the Go team has made significant improvements in crypto speed:

[https://code.google.com/p/go/source/detail?r=eb2c99e6ec17db2...](https://code.google.com/p/go/source/detail?r=eb2c99e6ec17db272ef3a20fa416f3fe86ba9f29)

[https://code.google.com/p/go/source/detail?r=e7304334527349c...](https://code.google.com/p/go/source/detail?r=e7304334527349c395f150e109296dfc0f81d271)

[https://code.google.com/p/go/source/detail?r=e5620fd3ba5fb1d...](https://code.google.com/p/go/source/detail?r=e5620fd3ba5fb1d5fb083dbba864ca66d84fa859)

Fast approaching OpenSSL speeds.

Also, the integration of the network poller into the main scheduler is likely to make a big difference to Go programs that make heavy use of the network.

<comment><USER9> Good work! While speedups of go of the order of 30% in general are a good thing, they do point at the relative immaturity of the language. You would not be able to get these kinds of seedups in gcc, where tings presumably already are close to optimal.

Another worry I have is the 'backwards compatibility'. It sounds good but in the long run creates its own problems. I think Java and even Python run into major problems with this.

<comment><USER10> Even though they are somewhat contrived benchmarks, I still like to refer to the "Language Shootout" to get some idea of the quality of code that the Go compiler is producing. I would expect the numbers should be better than Scala, for example.

[http://benchmarksgame.alioth.debian.org/u32q/benchmark.php?t...](http://benchmarksgame.alioth.debian.org/u32q/benchmark.php?test=all&lang=scala&lang2=go)

<comment><USER11> Yes I too find the Language Shootout a very interesting benchmark (while knowing full and well it's shortcomings) and it shows (imo) that Go has alot of work to do in the optimization department, something one can confirm by compiling cpu intensive go code using gccgo which will often yield great performance improvements.

Not surprising though, as GCC's optimization backend is very strong and has been developed for a long time, meanwhile Go's compiler toolchain is very young.

As for Scala vs Go, Scala compiles into Java bytecode and then makes use of Java's excellent and very mature JIT compiler so I'm not surprised Go loses out to it for the same reasons mentioned above.

Also note that the Go version used on the 'Language Shootout' is the 1.03 version, not the upcoming 1.1 version, it will be interesting to see what improvements in performance have been made.

AFAIK the 32-bit version of Go (which is what you compared with in your link) has not been given as much love in the optimization department as the 64-bit version, which I guess would do slightly better atleast.

<comment><USER12> Go's compiler toolchain is not "very young". Go's compiler toolchain is derived from the Plan 9 C compiler and is a decade older than modern gcc (4.x), which has substantially rewritten its optimization framework relatively recently with "GENERIC" and "GIMPLE". There are no equivalent changes in the go backend.

The reason the code quality (in optimization terms) of Go's compiler isn't that great is that the Plan 9 C compiler was always designed for fast compiles. This is a matter of design.

<comment><USER13> The Go compiler converts its AST to assembly directly. There's a peephole optimizer and certain AST patterns are specially handled, but overall the compiler is extremely simple.

By comparison, LLVM/GCC passes code through multiple internal representations and performs many complex optimizations on them before emitting assembly.

</comment></comment></comment></comment></comment></comment><comment><USER14> It's not released yet, this is just a preliminary document. There are still open issues for Go 1.1: <http://swtch.com/~rsc/go11.html> And I guess there will be a RC first.

<comment><USER15> Is there any ETA on the release or is it just a case of "when it's finished"?

I'm about to start a largish project in Go and I'm thinking I'd rather start in Go 1.1 rather than worry about upgrading and testing the project mid- development.

<comment><USER16> It's "when it's finished", but you can expect it in the near future.

Go 1.1 is strongly backward compatible. You can start working on a large project right now with Go 1.0.3 and it'll work just as correctly under Go 1.1.

<comment><USER15> It's the term "strongly" that concerns me as that's not really a guarantee. However I think I will take your advice and start development on it regardless (if I've written it correctly, then any breaking changes will be confined to their respective module so fixing them shouldn't be much of an ordeal).

Thanks for the feedback :)

<comment><USER17> It is a guarantee. I promise, you won't have to change any of your code when updating from 1.0 to 1.1.

<comment><USER18> True. Except if you used ListenUnixgram returned and couldn't use type inference for storing it's return value. Go1.0 returns UDPConn, which will be renamed as UnixConn.

This is a clear API bug, and it's the only exception to the backward compatibility rule.

</comment></comment></comment></comment></comment></comment><comment><USER19> For those of us who are wondering if 1.1 is stable enough to upgrade: Google is already using Go 1.1 in production.

And the company is betting big time on Go, more than 50% of their codebase will be (re)written in Go in a couple of years.

Source: core dev on the golang team.

<comment><USER20> >And the company is betting big time on Go, more than 50% of their codebase will be (re)written in Go in a couple of years.

!!! wow !!!

<comment><USER14> Don't believe anything without a credible source citation. Not everything someone writes on the internet is true.

</comment></comment></comment><comment><USER21> I grew up with Pascal and its derivatives, so I have a strong sense of the aesthetic of programming languages. I can't take Go seriously, or bring myself to use it, because it appears to have no aesthetic sense at all. It's ugly! Strings of keywords and punctuation, no rhythm to it, just a lot of mess. Like a cross between C and Prolog, perhaps, with a smattering of Python but only the ugly bits. I really don't like it.

Now, if you want to see a recent language with a bit of style to it -- and bear in mind I know nothing of how it is to use in practice, so I'm basing my opinions entirely on the look of it -- I think Rust is one of the best of the pack. So much smoother.

TL;DR (for any Redditors who may have stumbled in on their way to the Ron Paul fansite): languages have a flavour, and Go's flavour is "mess".

<comment><USER22> Sure, Go is ugly. I had the same reaction as you. But it's so damn _functional_. There are plenty of warts, syntax and design-wise, but once you get over them, it's actually a decent language.

Compared to Erlang, for example, it's positively beautiful. I like Erlang's execution model, but the unnecessarily gnarly syntax and the antique approaches to some things (no real strings, no Unicode, tuples that depend on positional values instead of named attributes, horrible stack traces, tail- call recursion as a looping construct, etc.) has made me stay away.

Go is a decent alternative to both C/C++ and Ruby for me these days. There are plenty of things I don't like about Go, but it's easy to forgive many of them when the language makes you so productive (at least for the things I need it for; it's pretty bad at web app development and completely useless for GUI development), so I do. Sometimes you just want something that works, with minimal amounts of pain. C++ works, but is always painful to me because it feels like the language is working against me, not with me.

I love the simple syntax in Go; the no-nonsense approach to object- orientation, the way the typing system allows adding methods to arbitrary types, which may have been inspired by Haskell's typeclasses. I love having native Unicode strings, first-class functions, a simple package system, built- in concurrency and decent networking in the standard libs. I love the built-in documentation generator (although it's too simplistic at this point; why not Markdown?).

Things I don't like:

* Capitalized names for visibility.

* nils in the language instead of Haskell-style Maybe.

* nil cannot be used in place of false.

* The "non-nil being nil" insanity (an interface value can be nil, but it can also be non-nil and contain a nil value).

* Functions return errors instead of Haskell-style Either monads, or Erlang-style matching. (I see the problem with exceptions, but Go's solution is worse and leads to very awkward code that has to branch a lot to catch errors.)

* The fact that "go" is a language keyword; compare with Rust's very elegant task spawning, which is part of the standard library rather than being built into the language, and yet relies on first-class language constructs to integrate perfectly.

* That "range" is not extensible (that I know; it only works on maps, arrays, slices and channels).

* The whole GOPATH thing, pretty much requiring that you maintain a local tree with symlinks.

* That "import" when used with Git cannot be pinned to a specific revision (so if you rely on a third-party package, it could break your app at any time if HEAD changes; it's ridiculous, and counter-productive, to have to fork third-party repos just because of this).

* That packages have only a single nesting level. I don't mean that I should be able to create a package "x.y.z", I mean that given a package "x", all the files _have to be in the same folder_. I can't organize the tree in multiple subfolders.

* That statements are not expressions.

* That semicolon elimination necessitates some insane syntax at places (like having to end a line with ",").

* The lack of structural tagging in the language (similar to Python and Java annotations), and the fact that they _did_ add tagging, but only for struct fields, and the tags can only be strings.

Right now, Go is, in my opinion, mostly an inelegant, weirdly-shaped thing that fits into the weird hole not filled by C and C++, a stepping stone to the next big language. I don't love the language, but I love how I can do the same things I was planning to use C++ or Ruby for; as a C++ replacement I gain productivity and simplicity; as a Ruby replacement I gain performance.

Go is, if anything, a very pragmatic compromise that favours simplicity over complexity at the expense of structural and syntactical elegance. It looks a lot like Java around 1.3-1.4, before the enterprise stuff derailed its focus. My concern is that Go has no particular philosophy as a foundation; it bakes in some current concerns (concurrency, networking, ease of use) and made itself a very useful hammer for hammering today's nails, but may not be as easy to extend to work with tomorrow's screws.

PS. I, too, come from Pascal — specifically, Borland's Object Pascal. While I have fond memories of that language, I'm not sure elegance was one of its main traits.

<comment> grey-area Nice list of frustrations with Go, though I wouldn't call it inelegant - <USER2> syntax may be homely, but the simplicity gives it a certain minimalist elegance.

Re nils, yes this still feels pretty ad-hoc, I wonder if they'd do anything differently there now if they could? Probably there is no easy way out now they're past 1.0.

It would be nice to see an extensible range and I've had this thought myself (as have others), there has been some discussion on the list, and they're not sure: [https://groups.google.com/forum/?fromgroups=#!topic/golang-n...](https://groups.google.com/forum/?fromgroups=#!topic/golang- nuts/n1izOhyaO8I)

but then you can also turn it around and iterate by passing in a function to the structure to iterate:

        func (self *DataStructure) Iterate(fun IteratorFunc)

Re GOPATH, what do you mean here?

Re packages having one level - I actually love this - if you want to nest things in folders, Go is trying to tell you to split it into sub-packages (in that opinionated manner it sometimes adopts). Of course this might feel restrictive, but if a package has lots of files I'd rather it was split up and organised into packages with clear boundaries between them rather than into an interconnected set of files/folders which only makes sense to the author of the code because it's all in one package with no boundaries. This restriction means we will see apps composed of packages by default rather than all in one namespace because it's easier.

Re the versioning, they originally resisted versioning the language, but eventually gave up on that idea and used versions, so I suspect for packages they'll eventually recognise the need for this when the ecosystem of packages grows sufficiently. Versions do introduce problems of their own (dependency hell), but IMHO being able to reliably import snapshots of a package (tag, branch or version) will be essential long term without having to fork a repo and rename it just to do so. If go becomes popular you can expect this to be addressed by third parties if the go team doesn't bother.

Re the tagging, in a way I'm pleased that they avoid adding lots of features like this, as this is the stort of thing I hate even in the limited version they have (on struct fields) - it's untidy and gets misused and overridden to try to extend the language (see sql libraries in Go tagging fields with all sorts of their own meta-data).

Re commas on lists, this bothers me less than having to put semicolon & LF on every line, I think it's a fair trade.

Re philosophy, I can't speak for the Go authors, but I've found radical simplicity to be its overriding principle, which explains some of the limitations which annoy you above and the ditching of a lot of OO baggage which languages nowadays are expected to carry whether they want it or not. I've found the simplicity worth the trade for some small frustrations.

<comment><USER22> > _Probably there is no easy way out now they're past 1.0._

Yeah, any attempt to change this would have to introduce something like a per- package pragma flag to disallow nils. I feel they have painted themselves into a corner there.

> Re GOPATH, what do you mean here?

I mean that the "go" suite of build tools (build, get, install) rely on a specific convention: Your GOPATH is supposed to point to folders each containing bin, pkg and src subfolders with all packages.

Let's say I am developing a package A that uses my own package B. Both on Github. You're supposed to then create: $GOPATH/src/A (which contains A's files as immediate children) and $GOPATH/src/B (ditto for B).

The manuals I believe suggest that you have something ~/projects/go, under which you create bin/src/pkg and put your work. But I don't organize my home folder like that and I find it presumptuous that the tools assume that I do, so I have ~/.go, which contains bin/src/pkg, and I symlink stuff into ~/.go/src. Acceptable if annoying.

> _Re packages having one level - I actually love this_

I want to use folders as an organizing unit, the way they are intended. It makes sense even for small packages.

Generic example (I have something very similar to this, but I don't want to go into details): I have a framework. There is a bunch of core interfaces, and then a bunch of implementations. Let's say that my interfaces are called Queue (with concrete implementations FooQueue, BarQueue, BazQueue etc.), Block (again, a bunch of concrete impls) and Stream (same). For my brain not go insane every time I look at my source tree, I want to have the core interfaces in the root, and then subfolders queues/, blocks/, streams/.

That's not much to ask. Putting these things in separate packages with dependencies on the original package makes no sense, in particular because the original package has internal dependencies. For example, the framework has a configuration builder that connects queues, blocks and streams, and it knows certain things about the implementations and how they interconnect. Putting _that_ into yet another package is just insanity.

It's _one_ package. And it needs subfolders. (Especially with how Go mandates that tests be in the same folder as the unit being tested!)

I have encountered lots of C projects that pile all the files into a single root folder, instead of having a src/ folder with appropiate subfolders by category. I think that's what the Go guys are mimicking. I hate it.

I mean, just the fact that a package needs the Go files to be in the root is pretty bad. I may have a docs/ there, a readme file, an examples/ folder, a locales/ folder -- why must the source files go in the root? They're not that special. I know you can import directly from a src, but the convention is 'import "github.com/foo/bar"', not "github.com/foo/bar/src"'.

As I said, I don't want Java-style nested package names. All I want is to be able to organize the _files_. After all, the location of the files doesn't matter to the compiler. (Java used to be like this at one point, too, unsure if it's still the case: What you put in the package decl didn't need to match up with the structure of your folders.)

> _Re the versioning, they originally resisted versioning the language_ ...

Hope this will be solved. I suggest something similar to Ruby's Bundler -- don't make it part of the language, but part of the development environment.

> ... _as this is the stort of thing I hate even in the limited version they > have_

Agree, I would rather see no tagging at all, rather than the flimsy stuff they have today.

<comment> grey-area Re package paths, I guess the tradeoff here is for go get/install etc to be able to include or fetch dependencies, it needs to know where to put them and install them, and this was the simplest system they could think of which worked. Nowadays I think it's ~/.go/src/github.com/user/pkg rather than just ~/.go/src/pkg It would be nice to be able to specify goinstall and golib paths or something though, and I guess your symlinked idea is a good workaround. I have just gone with the flow on this one, and don't mind as don't have gopath at the root of ~/.

Re folders versus sub-packages, yes I take your point - again there are some conventions here they've tried to impose to make it simpler for the package tools, but those could get in the way. I also hate projects that have all the files piled into one dir, so I prefer to break into sub-modules where possible and make the organisation clear. The other advantage of this is that people could use just your sub-module if they want.

I've developed a few packages which I wanted subfolders for, but those subfolders naturally became sub-packages without much wrangling - seeing too many files on one level forced me to organise them and create more packages. One case for example mirrors your usage - a top level pkg, with interfaces and concrete types for specific databases, which lived in their own folder 'adapters' this became a sub-package, which contained the interface and concrete implementations, and it being a package forced me to remove any knowledge of the enclosing package and any circular refs - the top level pkg knows about the adapters, but adapters don't know about the top level. I felt like this was making the code better, not worse, by removing internal dependencies, but YMMV, and I can see how it would be annoying. I'm willing to forgive conventions like this if the tradeoff feels worth it (in this case I really like the go gettable packages, and to have that am willing to live with restrictions like some code must be in root, folder=subpackage, etc.).

<comment><USER22> With the subpackage, did you actually put the stuff in subfolders of the original package, or did they have two different top-level folder names? In other words, was it

        import (
          "github.com/foo/x-core"
          "github.com/foo/x-adapters"
        )

or

        import (
          "github.com/foo/x"
          "github.com/foo/x/adapters"
        )

If the second, then do you need to do something special with regards to compilation or anything else?

One thing that bugs me with the second approach is that the package names then have to be different. If the original core package is called "x", and you have an "adapters" package, would the package name be something like "x_adapters"? Just "adapters" seems a bit presumptuous (it's very generic).

<comment> grey-area Because packages are namespaced by user, and it's easy to rename imports, I don't worry about choosing obvious names - that's only a problem if it is popular and used by more people than me anyway :)

So I'm using obvious names, with the pkg (say core) in one folder, and subpkg in the subfolder named adapters.

        "github.com/user/core"

this has a few .go files in it to split things up into different concerns, and a subpackage with adapters (again with a few files), imported with:

        "github.com/user/core/adapters"

and using adapters.XXX in the core code. You can also do this:

        import
        (
         mypkg "github.com/user/core/adapters"
        )

and use mypkg.XXX to refer to the subpackage, so you're not tied to the folder names for package import names, that's just the convention, and if someone needs to rewrite the name on import, they can do so.

<comment><USER22> True, although it gets annoying having to "rename" a package like this. If it's a package you use _everywhere_ in your project, it gets old fast; canonical, author-defined names are always the best option.

<comment> grey-area Yes, it could be a pain unless it was just imported in one or two files. In practice though I've not found collisions in package names to be an issue, simply because of the layering of packages - the top level package is really the only one which knows about these adapters and imports them - it then presents an interface to the world which is under its namespace, so the only worry for uniqueness is the top level pkg name really.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER23> I'm interested in tracking Go as a replacement for Erlang. Some things that should probably happen:

* GC works on 32 bit systems.

* Scheduler improvements so that things are a bit more robust ( <http://code.google.com/p/go/issues/detail?id=543> )

* A fairly solid library implementing supervision trees or something like it.

* Probably some other things, but those strike me as the big ones. The important thing is for the system to be able to run for months at a time.

I think they'll get there eventually. Maybe not 100%, but 'good enough' sooner or later.

<comment><USER24> Akka is also a viable Erlang alternative.

<comment><USER25> Looks like a nice library but I don't think it's a serious contender to replace Erlang because the JVM just isn't made for the level of concurrency that Erlang's VM is. Off the top of my head as an Erlang newbie:

      * You're still using Java threads, so the potential to access [shared memory][1] is there (i.e. "shared nothing" can't be guaranteed).
      * You're still subject to global GC pauses, whereas the Erlang VM has per-process GC.

[1]: <http://doc.akka.io/docs/akka/snapshot/general/jmm.html>

<comment><USER24> Recent benchmarks and related responses resulted in Akka out-performing Erlang (read the full post): [https://plus.google.com/112820434312193778084/posts/HdKFx4VQ...](https://plus.google.com/112820434312193778084/posts/HdKFx4VQtJj)

Shared memory when running on the same machine is actually more efficient since there is no need to copy immutable objects.

If the sophisticated low-latency GC options available on the JVM are not sufficient for you feel free to fire up more JVM instances on the same machine or on other machines.

<comment><USER25> I assume you mean the comment that links here, with Akka getting 2.1M messages/sec? [http://uberblo.gs/2011/12/scala-akka-and-erlang-actor- benchm...](http://uberblo.gs/2011/12/scala-akka-and-erlang-actor-benchmarks)

If you follow the comments there, someone improved the Erlang benchmark to 3M messages/sec, beating Akka once again: [http://musings-of-an-erlang- priest.blogspot.dk/2012/07/i-onl...](http://musings-of-an-erlang- priest.blogspot.dk/2012/07/i-only-trust-benchmarks-i-have-rigged.html)

> _Shared memory when running on the same machine is actually more efficient > since there is no need to copy immutable objects._

Many Erlang processes fit onto an OS-level thread or process, so passing messages is very fast ("copying" shouldn't be equated with context switching OS threads).

> _If the sophisticated low-latency GC options available on the JVM are not > sufficient for you feel free to fire up more JVM instances on the same > machine or on other machines._

Akka is a library and can't make guarantees about how the JVM will perform garbage collection of actors while Erlang has it built into its VM. No amount of creating new JVM instances will change that.

<comment><USER24> _> I assume you mean the comment that links here_

You assume incorrectly. I'm referring to the version where Scala was 44% faster than Akka: [https://plus.google.com/112820434312193778084/posts/HdKFx4VQ...](https://plus.google.com/112820434312193778084/posts/HdKFx4VQtJj)

In any event the application logic in Java will likely outperform erlang. See: [http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...](http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=hipe&lang2=java) where Java outperforms Erlang by 3-30x in most cases and uses significantly less memory in most cases.

> _Many Erlang processes fit onto an OS-level thread or process, so passing > messages is very fast ("copying" shouldn't be equated with context switching > OS threads)._

Many Akka actors fit into a single process and there are many actors per OS level thread, so this isn't really a useful point for comparison.

> _Akka is a library and can't make guarantees about how the JVM will perform > garbage collection of actors while Erlang has it built into its VM. No > amount of creating new JVM instances will change that._

The JVM does the GC, not the library. Is 100 microseconds not short enough for your application? [http://mechanical-sympathy.blogspot.com/2012/03/fun-with- my-...](http://mechanical-sympathy.blogspot.com/2012/03/fun-with-my-channels- nirvana-and-azul.html)

<comment><USER25> Your 44% link is after crippling the benchmark by de-parallelizing it on top of using a poorly written Erlang implementation. I suggest you read the actual blog post that your Google+ post links to, including its comment section and the links posted therein (which is how I arrived at my links): [http://www.krazykoding.com/2011/07/scala-actor-v-erlang- gens...](http://www.krazykoding.com/2011/07/scala-actor-v-erlang- genserver.html)

> _Is 100 microseconds not short enough for your application?_

GC time is not a useful benchmark by itself. The important thing with the JVM is that you can't predictably reason about when the global GC will happen (global GC pause). Your JVM actors aren't shielded from these global GC events so building a soft real-time system is less practical under the JVM than the Erlang VM IMHO.

<comment><USER24> The benchmark doesn't "cripple" by de-parallelizing. Execution is already in parallel, it just uses regular collections as the concurrent ones weren't worth the performance overhead and in the end Akka ran 44% faster than Erlang. In the comments you refer to having 50% Erlang is roughly the same as 44%, so I don't thing there is much performance difference even though Java/Scala is faster than Erlang in general.

Regarding soft realtime requirements Erlang may be a better choice, but I doubt there are too many use cases where it will make much difference.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER20> Whenever I look through golangs specs, I always get stuck on the same question.

Why are the methods we define restricted to the types we define? I'm SURE there is a good reason.

Others have said that it's because if you did allow that kind of thing to happen, you might get naming collisions in packages. I don't buy this argument, you could get naming collisions anyway from packages, Go resolves those issues by aliasing. Go also allows for polymorphic behavior by packaging the actual type of the method caller with its actual value, so resolving which method to use isn't any more complicated.

I don't get it, I'm sure there's a good reason! I just hope it's a good enough reason to throw out the kind of freedom that would allow you.

<comment><USER26> You can't add methods to a type in a different package as you might break that package. By locking the method set of types when a package is compiled you provide some guarantee of what it does, and it doesn't need to get recompiled again! This is central to Go's ideals of compiling fast.

Besides, embedding a type is very easy <http://golang.org/ref/spec#Struct_types>

<comment><USER20> Hmmm. I can see how adding methods to a type in a different package would require that package to be recompiled, but I don't see how I could break that package. Unless there's some reflection magic I'm not considering.

I'm reading through the embedded types now. I am new to golang so this one is lost on me. I thought if you wanted your own methods on a type from another package, you just aliased it with your own type def.

though it looks like there's some kinda prototyping behavior being described here?

        If S contains an anonymous field T, the method sets of S and *S both include
        promoted methods with receiver T. The method set of *S also includes promoted
        methods with receiver *T.

        If S contains an anonymous field *T, the method sets of S and *S both include
        promoted methods with receiver T or *T.

<comment><USER26> For example, if you do a runtime type assertion to see if a variable satisfies an interface:

        v, ok := x.(T)

<http://golang.org/ref/spec#Type_assertions>

If you "monkey-patch" x to satisfy T in another package, the value of ok may change.

<comment><USER20> Hmm I can kind of see what you mean, but I don't see it as a big of a problem.

If you make package A depend on package B, package B monkey-patches x with method Foo so now x is a Fooer

x now satisfies the Fooer interface in package A, well that seems ok. You imported B after all. In things that don't import B, x doesn't satisfy Fooer. Is this unexpected behavior? If B depends on C, C's x won't satisfy Fooer right?

</comment></comment></comment></comment></comment><comment><USER27> Still missing custom generic types and methods :(

<comment><USER28> Experience with Go in the last few years has shown that you don't really need them. If you think you do, then you're doing it wrong.

Also: <http://research.swtch.com/generic>

<comment><USER29> And as the various comments there show, .Net does it right, and better than any of the methods they list.

If I want to create a new wrapper class, the last thing I want to do is either make it hold an Object, or have to write a new version of it for every type it can hold.

<comment> grey-area _If I want to create a new wrapper class, the last thing I want to do is either make it hold an Object, or have to write a new version of it for every type it can hold._

Can't you solve this problem with an interface defining the behaviours your wrapper expects? The interface can then be passed in or held as a ptr without requiring a specific type, allowing a generic implementation. You can create a generic iterate or sort function for example which operates on slices of a given interface. Sorry if I've misunderstood, if so a code example might help clarify what you mean.

<comment><USER29> Let's say we have a Reply<T> which packages up the actual reply from a service, along with the status of the service call, and any additional warnings, etc.

In C# I can define this once, and then any service can just return a Reply<string>, Reply<int>, Reply<Address>, etc. The calling method can check the associated reply status, and then unwrap the data if the call was successful, displaying any associated messages as needed.

Or, for a different example: If I want to store a long list of Customers in a dictionary, keyed on String, then in C# I'd create a Dictionary<string,Customer>, and know that it would always contain the types I'd expect.

How would I do either of those in Go?

<comment> grey-area I'm no expert in Go, but I think it can cover most common uses of generics like those you mention, though you cannot of course replicate all C++ code in Go without changing paradigms a little. It won't work in exactly the same way, but it can usually solve the same problems elegantly.

1\. Generic reply (for a good example of this in use see the way errors are used in go; errors are extensible and can contain info like that in your example).

<http://blog.golang.org/2011/07/error-handling-and-go.html>

For your example, you could have a reply interface, defining the requirements, then concrete types which conform: <http://play.golang.org/p/e18n36Ub5u>

There are probably shorter ways to do this, this is just an off the cuff example, but it's quite possible to have generic reply types which respond to any methods you want, and can be created easily and extended if necessary. You can also cast back to the original type.

2\. Just use map[string]Customer - Customer could be an interface (duck typing) or a type.

Something like this: <http://play.golang.org/p/ZoftbY8mQX>

IMHO using an interface here is more interesting, as it lets you define your requirements, and forget all about the type system, while letting the compiler check that any uses will always work as they conform to the interface.

<comment><USER29> In your examples there, am I not having to create a new type per case? So a Reply<String> and a Reply<Customer> will require me to create two classes?

<comment><USER30> You'd just want to have your types implement the interface for Reply, and provide a method with the same signature that clients can use.

Here's what I think you want, written in (as far as I am able to) idiomatic Go:

<http://play.golang.org/p/KI79ynfRg2>

<comment><USER29> So every type that can be returned from a service call has to implement Reply? That's acres of template code being duplicated all over the place - and if I need to fix a defect in it I need to change it in every place!

That strikes me as terribly unmaintainable.

<comment> grey-area _So every type that can be returned from a service call has to implement Reply?_

Yes, if you want it to actually be a Reply, it has to implement Reply.

 _That's acres of template code being duplicated all over the place_

No, if you need to reuse code you can use other techniques like embedding (not shown in examples).

The features and restrictions differ from many other OO languages but I think the creators of Go deserve a little more credit than you are giving them - they do not produce unmaintainable code (see std lib for Go), worked on a large scale with C++ OOP previously, designed the forking Unix operating system, and are not unaware of the ramifications of the decisions taken.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER31> Here's the same document with a stylesheet: <http://tip.golang.org/doc/go1.1>

<comment><USER32> The post's URL should be replaced with this one ... most of the links in the posted page are broken.

</comment></comment><comment><USER33> Sweet performance improvements! Definitely looking forward to seeing Go 1.1 on the benchmark game.

<comment><USER24> Definitely looking forward to seeing if Go has made any progress in catching up to Java and Scala in algorithm execution times.

</comment></comment><comment><USER34> > In Go 1.1, an integer division by constant zero is not a legal program, so > it is a compile-time error

How often do be people accidentally divide by a constant 0? I personally use that to simulate runtime errors all the time in python. It's shorter than writing "raise Exception()".

<comment><USER35> I'm not familiar with Go, but I'd imagine something like this:

      const int SomeNumber = 0;
      // then much later in the program
      return 3 / SomeNumber;

An accidental and not immediately obvious divide by constant 0.

<comment><USER36>
      const weasels = 5
      const lawyers = 5
      const mustelids = weasels - <USER3>

      feedWeaselsEach(chickenPortions / mustelids)

<comment><USER37> would this count as a constant 0 and be caught by the compiler?

<comment><USER36> Yup. Constants are computed at compile time in Go.

</comment></comment></comment></comment></comment><comment><USER38> We have integer madness here and no one is commenting on it. Why making this int change and why now? I don't like Java, but well-defined integer types sizes is a good thing. Most of the world uses intXX_t typedefs in C and C++ too.

<comment><USER15> Nobody is commenting because there isn't any integer madness.

If the size of an integer is critical to the execution of your program, then you should be using _int16_ or one of the many other types that specify the number of (un)signed bits.

The _int_ type is designed to be platform specific to optimize on execution speed when the maximum size of the integer isn't an issue.

<http://golang.org/ref/spec#Numeric_types>

<comment><USER38> See my response to grey-area.

And regarding optimization. Language-defined integer type size is one thing and CPU register sizes used in calculations is different thing. It's not like having 32-bit int forces you (or compiler) to use 32-bit registers.

For every int we (i.e. programmers) should be aware of possible min and max values that can be stored in it. Thus we can easily use fixed-size ints everywhere, paying attention to signedness too of course. The problem is that there is high temptation of using _int_ most of the time, because it's easier to write (it's shorter). For the same reason many C programs use int instead of unsigned short or uint16_t for instance. Well-defined int size is part of self-documenting code, as it shows mindfully applied constraints.

<comment><USER15> There's arguments for and against both methods. Back when I first started programming, memory was a luxury (we're talking 80's personal computers here), so it made a great deal of difference. These days, however, choosing an integer type which most closely matches the values stored is largely an academic process which costs developer time (though obviously there are exceptions, times when it makes more sense to be mindful and times when it makes less sense).

My point is this: the problem when talking about "best practices" is there's some approaches that actually doesn't make a huge deal of practical difference, so it's more subject to specific circumstances (eg developer time constraints) or even just personal preferences (eg the arguments between ()\n{\n\t and (){\

Anyhow, in answer to your other post, the int _n_ and uint _n_ types have been available in Go since day one. So (and in answer to your original post as well), this _int_ issue you raise isn't an issue unless developers have written extremely bad code to begin with (ie written counters which they know will exceed a 32bit integer and not cared enough to write an error handler nor specifically use an _int64_ type). Go does do a lot more to protect the developer from shooting his own foot off (more so than C/C++), but if we're completely honest, if the developer is crap then no amount of hand-holding from language design will help.

<comment><USER39> "There's arguments for and against both methods. Back when I first started programming, memory was a luxury (we're talking 80's personal computers here), so it made a great deal of difference. These days, however, choosing an integer type which most closely matches the values stored is largely an academic process which costs developer time"

Actually, memory is even more of a luxury than ever, since your caches have limited size and main memory bandwidth is atrocious, compared to the speed of your execution units. Using 32 bit fields for stuff that safely fits into 16 bits can cost you for that reason alone.

<comment><USER15> Sorry, but that's not the same as a program crashing to run because you've exceeded 64KB of RAM. Plus your program will spend a great deal of time off the cache anyway (thanks to the OS overhead and any multitasking taking place).

I'm all for performance tuning and writing efficient code (like I said, I learn to program back in the 80s when every bit of data mattered and various tricks were used to work around the limited power of those systems), but let's be clear about one thing, memory these days is not " _more of a luxury than ever_ ". The exact opposite is true.

</comment></comment></comment></comment></comment></comment><comment><USER40> Can you please delete this article until go1.1 is officially released. Just in case the go developers make any last minute changes. Otherwise this article may lead to confusion for those who choose to skip out on reading it on golang.org when go1.1 is released because they read it here.

<comment><USER14> It's not an article. It's the HTML page in the Go source code repository that will be put online on golang.org once Go 1.1 is released.

<comment><USER15> He knows this and arguing the semantics of 'article' is completely missing the point he was raising.

Personally, I think it's silly to delete this thread, but I appreciated his warning that this [article / document / HTML page in a source code repository / whatever the hell you want to refer to this as] is only a draft document for a version of Go that's not yet been finalised.

</comment></comment></comment><comment><USER41> "We trust that many of our users' programs will also see improvements just by updating their Go installation and recompiling."

Does anyone know if it is possible to determine what version of Go a given binary was compiled with? Perhaps extracting some metadata from an ELF section?

<comment><USER42> There's no guaranteed way unfortunately. If you expect to need this in the future, you can add a flag in your program to print runtime.Version(). But for existing binaries that don't use that function the version will not be included in the binary.

<http://golang.org/pkg/runtime/#Version>

</comment></comment><comment><USER43> I'd more than welcome any instructions and pointers on how to install Golang 1.1 on my computer which has 1.03 installed already. Either to replace my current version or maybe to install it aside 1.03 for testing. Thanks a lot.

<comment><USER44> I would guess that right now you need to install from source.

<https://code.google.com/p/go/source/checkout>

<comment><USER43> I see, thanks a lot. And congratulations and thanks to the dozens of developers who made that release happen.

</comment></comment></comment><comment><USER45> I'm excited for this release.

I'm not sure if I understand what "method values" are though

<comment><USER46> Yes, I wondered about that. Is it just that the function

      func (w *Writer, int n) {
      }

is actually a method, like:

      func (w *Writer) Anon(int n) {
      }

<comment><USER14> No, it means that it is now possible to use methods as first-class values as well, just like functions: <http://tip.golang.org/ref/spec#Method_values>

<comment><USER46> I see. Seems like a nice addition.</comment></comment></comment></comment>


Announcing Git LFS Support in GitLab - <AUTHOR> https://about.gitlab.com/2015/11/23/announcing-git-lfs-support-in-gitlab/ <comment><USER2> To me, Git-LFS and Git-Annex when compared to the Mercurial LargeFiles extension, are perfect examples of what's wrong with Git.

Mercurial's LargeFiles extension allows you to do what I would imagine, 90%+ of Git-LFS users will want to do: store some binary assets with their regular source code.

In Mercurial, the files get stored on the shared server, inside the .hg directory of the repo you clone. They are cached between requests client side, and it generally just works. I had to add 2 lines server side, and 5 lines client side (both times in a hgrc file) to enable and test the functionality.

With Git it seems very much that Git-LFS (rather than Git-Annex) is more like what I need to achieve basically the same results/workflow.

Oh wait, but I need a separate Git-LFS server. So, Git-LFS was created by GitHub, and they of course support Git-LFS on their servers.. But I want to manage this repo on my own machines so what can I do..

Oh look GitHib has a reference implementation of a standalone Git-LFS server.. Oh wait. Second sentence of the Readme is a bit ominous:

> It is intended to be used for testing the Git LFS client and is not in a > production ready state.

I'm just using regular SSH access to use my Repos, can't I just access the Git-LFS file store that way? Oh. No. I have to expose a HTTP(S) server that accepts basic auth.. Oh and the Git client needs to be able to provide the Authorisation header automatically so I don't get prompted... Oh and the slightest thing can make the "automatic" mapping of URLS from repo to LFS- store not work, meaning I have to specify it manually...

That Git-LFS comes from GitHub and is relatively complex to setup for hosting, is likely not a coincidence. They make money offering 'easy' repo hosting. Why would they want to make it easier to setup your own repo.

This line from [http://git-lfs.github.com](http://git-lfs.github.com) really takes the cake though:

> Work like you always do on Git—no need for additional commands, secondary > storage systems

So you don't need a secondary storage system... you just need a HTTPS server and Username/Password authentication layer.. but that isn't a secondary system. Just like a Turducken isn't really three birds crammed into one.</comment>


Unity 4 is here - <AUTHOR> http://unity3d.com/promo/unity4/ <comment><USER2> disclaimer: I spent the last three years making Unity.

You can share code between projects by having seperate visualstudio projects that create a managed library. just put the managed library into your assetsfolder. it live reloads as smoothly as when you edit just one script.

While I'll be the first to admit that we have some things that you can consider basic that don't work as well as they could yet, the perspective from inside the development team is that we have an enormous focus on improving what we have, and do not do "jump on new feature, and quickly move on and forget about it".

@reitzensteinm, We would love to fix your crash! If it happens in Unity4 as well, it would be great if you could file a bug, or give us some way to reproduce the problem. While we think using our serialization system makes a lot of sense for most games, we will always support people wanting to do things in their own way, and serializing your data with json should not be a problem. obviously, you crash and there is a problem, so we'd love to get our hands on that and fix it!

Bye, Lucas Meijer

<comment><USER3> Is there a similar solution for mono develop / OSX? Common libraries remain one of our largest pain points. We tried git repos but it broke down constantly. Currently are using a series of scripts that copy files or create symlinks when needed.

</comment></comment><comment><USER4> Lots of impressive headline features. DirectX 11, detailed animation system, Linux support.

The trouble is, these come at the expense of the basics. Not so impressive is that the only supported method for sharing code between projects is _copy and paste_.

The engine is six years old. I'm not kidding.

Unfortunately, frustrations like that are common. I adopted Unity expecting to be there for the next few years at least; however my experience has been lukewarm.

It's a shame, because it could be a _fantastic_ engine if they'd concentrate on polishing what they've got. But I don't get the impression that's the roadmap.

[http://forum.unity3d.com/threads/148393-Unity-4-removes- supp...](http://forum.unity3d.com/threads/148393-Unity-4-removes-support-for- symlinks-on-Windows-listed-as-quot-improvement-quot)

<comment><USER5> On the other hand, Unity has implemented some basics, which are a real time sink in other engines, outstandingly well.

Lets compare the coding workflow in Unreal Engine 3 and Unity 3:

In UE3 you play the game, find something you want to change. So you shutdown the Game/Editor and go to the code. You code in some immature language called UnrealScript (I think there is a complicated way to use C++ too). Then you compile. Then you startup the Game/Editor again (this is slow).

In Unity you find something you want to change. Alt-Tab to your Code Editor. Change C#/Javascript code. Alt-Tab back to the game, recompiling the code and loading it into the currently running game is automatic and takes about 1-2 seconds.

Also the engine APIs are one of the best software designs I've seen in a long time.

<comment><USER4> On the other, other hand, if you don't use their serialization system (I prefer to stick with json), automatic reloading of the code causes a hard crash as your objects have been incorrectly reloaded.

And, naturally, there's no way to turn it off. Strictly speaking there is but it requires restart of _Unity_ , not just the game, to reload code. Which is basically the UE3 workflow you describe.

You're right though; there are quite a lot of good parts of Unity - which is why I'm sticking around for now.

But I stand by my assertion that their focus on headline features is troubling.

</comment></comment></comment><comment><USER6> I am an ex Web developer who got into game programming with Unity over the last 3 years. Its been amazing, i have learned a ton by using C# and actually needing to apply Math knowledge to a real world project. Unity is awesome but also has some issues, but as i havent really worked with the other big engines, i guess these have similar issues.

* Version control is a pain. We used Git (with Github) all the time but unitys meta files like to screw things up from time to time. Unity also uses alot of binary files (eg. prefabs) that could easily be replaced by some kind of JSON based format, making version control much easier

* its not cheap. If you want to use their killer multi platform features you will need licences for all platforms per seat, which adds up to quite a lot if you have several developers. When they release a new major version once a year, you will need to upgrade all your licenses (granted for a reduced price). Its a nice customer lock-in...

* its not very stable. At least under Windows it crashes alot on big projects

<comment><USER7> Project Settings/Editor/Asset Serialization/Force Text. I think this might be pro-only though.

</comment></comment><comment><USER8> Ever since unbuntu ruined their desktop with the same brand name, I flinch a little everytime I hear the word

<comment><USER9> By the time Unity for Ubuntu reaches version 4, it will include the following features:

-the ability to launch a command line will be gone, because the command line could allow accidental damage to your system

-it will not be possible to minimize or maximize windows (if you can still call what they have turned it into "windows"), those buttons will instead have been replaced by a shopping basket, and a helper assistant button, respectively

-because top left is not exotic enough, the window close button will now be in the bottom left

-launching more than one window of the same application will not work because this is confusing

-the menu of a program will be on the right side of the screen. You'll have to hover the mouse there first, then wait for a list of helpful suggestions to slide into view, scroll through it with an awesome fluent scrolling animation, and then finally at the end will be the menu options.

-the file system is abstracted away. Directories are confusing, so the concept of directories is hidden. Instead it presents the files as if they're in one large "basket". Extensions won't be shown because those, too, are not understood very well by most users.

-the scrollwheel, middle and right mouse button, and keyboard shortcuts, are ignored, to unify the desktop better with touch interfaces of mobile devices

</comment></comment><comment><USER10> Looks like fun. I've heard game development (for an employer) is quite the sweatshop though. What are the employment prospects and expected salary for someone proficient in this software?

Also, wondering if there any competitive open source game engines to aide in learning.

<comment><USER11> I can definitively say that where I work, at EA All Play's Sacramento studio, is not a sweatshop. We encourage eight hour days (plus lunch break, however long that ends up being), and every Friday afternoon there is free beer and fun presentations to end the week.

Right now, though, our only programming openings are for Java server engineers. Sorry.

I do recommend learning Unity though, if that's what you're interested in. As Unity improves, its easy cross-platform deployment becomes more and more attractive to larger companies.

</comment></comment><comment><USER12> Anyone know if Unity has any plans to support WebGL?

<comment><USER13> WebGL would be extremely tricky for them -- they'd first have to port their OpenGL render pipeline to JavaScript, which would be "doable I guess" especially since they could just port their GL ES (mobile) render paths, that's mostly identical to WebGL. But they'd also have to port their entire runtime library to JS, which would exceed a major rewrite in terms of effort I believe. And then they're calling .NET / Mono APIs everywhere in their own runtime/core code, I'm sure. And then there's the thousands of Unity projects out there calling said APIs. And then, and then, and then...

Next, asset loading but since you're on the web, ideally you'd have smarter on-demand streaming of compressed assets, rather than a 10-minute-long "Loading Game Assets" splash-screen page...

Next, user code. Uh-oh... I give up.

</comment></comment><comment><USER14> Does anyone know if they updated their default GUI elements (they were pretty rudimental in v3), so you don't need to use custom GUI elements?

<comment><USER15> They are planning the GUI update for the later 4.x releases. At-least that's what i could guess from the forums.

<comment><USER16> Here's a blog post on the upcoming GUI-system revamp, from earlier in the year: <http://blogs.unity3d.com/2012/06/29/the-new-gui/>

</comment></comment></comment><comment><USER17> I just ran a 32-bit build of "Angry Bots" for Linux on my Windows machine. It ran flawlessly on Linux machine (Ubuntu 12.04 LTS).

</comment><comment><USER18> I love the scroll effect on the header of this website, gives it a depth perspective. Very cool stuff...off topic I know, just wanted to mention it =P

<comment><USER19> It's called parallax scrolling, just as an fyi. :) (I learned the term myself not too long ago, so I get excited to use it when I can, haha.)

</comment></comment><comment><USER20> Anyone knows how much the upgrade costs? Can't find it without login which I don't posses at the moment.

<comment><USER21> $750 for pro license and $125 each for iOS / Android

<comment> matthew-wegner $125 is for upgrading "basic" iOS/Android. Pro upgrade is $750 for each. License comparison chart is here: <http://unity3d.com/unity/licenses>

Edit: Note that it _is_ possible to upgrade just your Unity 4 Pro license _without_ upgrading the individual platforms. For instance, I have Pro iPhone/Android licenses, but currently working on a PC/Mac game, so I upgraded my Unity 4 Pro license and left the platforms for a later upgrade.

</comment></comment></comment><comment><USER22> I would be curious to see how Ouya will fit in there, yes Android is supported, but at what point will Ouya be supported or not by Unity 4?

<comment><USER23> Presumably after they show some signs of actually shipping the thing.

Yes, yes, I'm a curmudgeony and perennial Kickstarter skeptic - but what other stance can you take when a team that has never shipped any consumer electronics before promise to ship a profoundly game-changing piece of hardware on an extraordinarily aggressive schedule, at a shockingly low price?

<comment><USER24> The price is realistic: [http://www.isuppli.com/Teardowns/News/pages/Low-End- Google-N...](http://www.isuppli.com/Teardowns/News/pages/Low-End-Google- Nexus-7-Carries-$157-BOM-Teardown-Reveals.aspx) gives a BOM cost for the Ouya sans controller at around $75. Add a year's worth of deflation, and it should be around $50. No, they're not making any profit at $99, but they hope to make that up on game sales and later sales to those who missed the Kickstarter. The point is that they're not losing money. A normal manufacturer would have to spend millions in advertising to get the exposure Ouya did.

The only thing that's hard about the schedule is that they're a new manufacturer and need to build relationships with all of their suppliers. NVidia would have given them a reference design that they could almost use unchanged.

</comment></comment></comment><comment><USER25> No OpenGL support at all? Isn't Unity used for mobile games, too?

<comment><USER26> On Windows Unity uses DirectX.

On iOS and Android OpenGL ES.

On Linux and Mac OpenGL.

</comment></comment><comment><USER27> ...and oh, how we wish it wasn't.

<comment><USER28> This has got to be the lightest gray comment I've ever seen.</comment></comment>


Ask HN: I am confused about ReactJS Native - <AUTHOR>

I understand that ReacJS works natively and that there is no DOM.  But isn't it just that. A web view builds views from the html file, but react js builds it with native function calls and its own renderer. After all the over head of javascript still exists.<p>>> ReactJS native just replaces the DOM rendering part of webview with something else of its own. <comment><USER2> React Native does not use a webview.

The overhead comes from a slow DOM and other browser cruft like over- complicated CSS. We've found that Javascript itself is actually quite fast.

We are no longer constrained by browser APIs. For example, we can access native device features, and we can also integrate other native components into React Native apps.

</comment><comment><AUTHOR> Basicaly its nothing but a new webview, offcourse with privilage api access.</comment>


When Cyber Fraud Hits Businesses, Banks May Not Offer Protection - <AUTHOR> http://www.npr.org/sections/alltechconsidered/2015/09/15/440252972/when-cyber-fraud-hits-businesses-banks-may-not-offer-protection <comment><USER2> I've said for years, using a debit card for purchases is foolish, yet another example of why. Banks have done a "good job" of hiding it from consumers, but to believe you universally have the same fraud protections using it as with a normal credit card is just crazy.

<comment><USER3> Since when do you have fraud protection with credit cards?</comment></comment>


ASK HN: Need help with determining equity split for seed funding - <AUTHOR>

So this is where I stand.  I have an idea for a mobile app in the property management industry.  I have it spec'd out and potential beta customers.  The only thing holding me back is getting it built.  A property management company has offered to invest (30k) to get the app built.
I am trying to determine what a fair equity split would be.  In my head I am thinking 80/20 but I believe he is leaning towards the 60/40 range.
What do you guys think? <comment><USER2> YCombinator deal is aproximatly 20K for 5% equity, perhaps you are giving too much.

Exact numbers from: <http://ycombinator.com/apply.html>

      We usually invest $11,000 + $3000n, where n is
      the number of participating founders, up to 3
      (i.e. 2 founders get $17,000, 3 or more get $20,000),
      in return for between 2% and 10% of the company.
      The average is 7%.

<comment><AUTHOR> so one thing i have to take into account is i cant get into a ycombinator program

</comment></comment><comment><USER3> How much do you expect it to make annually ? If it's millions then 30k doesn't mean much. If it's 5k then 30k means a lot.

</comment><comment><AUTHOR> I expect to price it 100 bucks a month and there 1000s of potential customers.</comment>


Dropbox is down - <AUTHOR> https://www.dropbox.com//

<comment><USER2> No it isn't. "<https://www.dropbox.com//> is not the same as "<https://www.dropbox.com/>

<comment><AUTHOR> It was when I posted this - You're right about the // business though. I was attempting to avoid the re-submission detection, but failed pitifully :)</comment></comment>


Given the State of the World, Is It Irresponsible to Have Kids? - <AUTHOR> https://www.nytimes.com/2019/09/25/t-magazine/should-have-kids.html <comment><USER3> Ah yes, the state of the world:

\- Lowest global poverty rate of all time (<3%)

\- Lowest global childhood mortality rate of all time (<4%)

\- Lowest incidence of child labor ever (<17%)

\- Most wealth per capita ever

\- Highest literacy rate of all time (86%)

\- Lowest CO2 emissions per $ of GDP since 1950

\- Highest % of people living in a democracy (70%)

A horrible world to raise kids in. Definitely.

All data from [https://ourworldindata.org/](https://ourworldindata.org/). Great resource.

<comment><USER4> Overall agreed on these, but to nitpick, the world has gotten less democratic over the past decade.

57% in 2005; just under 56% in 2015; probably a bit lower now. (not sure where you get 70% from).

from [https://ourworldindata.org/democracy](https://ourworldindata.org/democracy)

<comment><USER3> Ah, I was including anocracies in the number because they are _technically_ democracies and still an improvement over autocracies. Should have rephrased as "70% live in at least a partial democracy"

</comment></comment></comment><comment><USER5> Given the state of the world, it's irresponsible to _not_ have kids -- if you're a maker, giver, and lover of the neighbors, lands and wildlife surrounding you.

If you're a doughy-handed politician or jr. totalitarian central planner, be my guest; don't have children.

Let the adults and our awesome kids take care of the planet. You've tried to ruin it; we'll fix it. Your time is done.

<comment><USER6> How about adopting? Or fostering?

<comment><USER5> Awesome idea! Unfortunately, there is essentially no adoption in my country of Canada (single-digit infant adoptions annually in most provinces, nation wide).

It's inexplicable, given that thousands of families are waiting years without success for a child, and many more have simply given up.

The government agencies are either incompetent beyond human comprehension - <USER2> are architected to actively suppress adoption.

The options presented to a prospective young mother who cannot care for her child are: Abortion, or Abandonment (to a terrible institutional care system); Adoption is basically not an option.

</comment></comment></comment><comment><USER7> It's irresponsible for NYT editors to have kids.

This article is weird because it assumes we're in a finite, zero sum game. People are creative. More smart people is really good for the world as they create things, help others, etc.

Journalists like this need to get a basic economics background to realize that it's not just humans using stuff up and then we're gone. We reuse the same atoms over and over. Information doesn't even really need atoms in the same way.

<comment><USER8> But to expect continuous growth in a finite system is naif, even accounting for optimization and reuse. As an example, a mass of x humans will still need x*1500 calories a day at least; the bigger x, the bigger the strain on the planet.

<comment><USER7> Who's expecting continuous growth? Population tends to level out with urbanization and education.

Food can be grown much more efficiently. If we get to the point of needing 1500 calories then we'll be drinking soylent and having offworld farms long before we break the world.

It's such a phenomenally large population if you're just trying to grow x*1500 calories that we can hit it in hundreds of years. So should not factor into anyone decision to have kids.

</comment></comment></comment><comment><USER9> Simple answer: yes. The single biggest positive change you can make towards climate change is not to have children. This outweighs any other change you can make (going vegan, not flying, etc) by 5-10 times [[https://www.theguardian.com/environment/2017/jul/12/want- to-...](https://www.theguardian.com/environment/2017/jul/12/want-to-fight- climate-change-have-fewer-children)]

Complex answer: well, it's complicated. If everyone stopped having kids... well, that's not going to work either.

<comment><USER10> If that's the single biggest positive change then we're doomed.

1\. Given the lack of other constraints, humans tend to use the maximal resources available. If the world population dropped to 10 million, but those 10 million people used the bounty left behind by the 7 billion and used private jets to go everywhere, we'd still be screwed.

2\. The goal is net-zero by 2050. Without any other change, that means 0 humans by 2050? Stopping having babies isn't going to get anywhere near that. For population change to have any effect on the environment, it requires a drop in population into 9 figures in a decade or three. Nuclear war is the only way to achieve that, and that's not going to be too friendly to the environment...

3\. Net Zero is achievable without drastic solutions. There are lots of better options, but the backstop is carbon sequestration. At a cost of $100 - $300 per ton, that's tens of trillions for net zero. Incredibly expensive, but achievable for the modern economy. A lot easier than removing a few billion people from the planet in a few decades.

<comment><USER9> It's the single biggest change the average individual can have.

Climate change isn't going to be solved by lots of individual actions. The whole planet could go vegan overnight and we're still doomed.

If we're going to have any meaningful impact on climate change, we need to deal with it on a total war footing.

But that's not going to happen.

<comment><USER10> It's quite possible to go carbon-negative, assuming you're well off. A family of 4 being carbon-negative is going to do more for climate change than a carbon-positive family of 2.

</comment></comment></comment></comment><comment><USER11> I couldn't read the article because of the pay wall, but this stuff creeps me the fuck out. Genocide is wrong but convincing a certain demographic to not have children is somehow okay, even if it produces a similar result.

I bet this article doesn't include this map [https://en.wikipedia.org/wiki/Birth_rate#/media/File:Countri...](https://en.wikipedia.org/wiki/Birth_rate#/media/File:Countries_by_Birth_Rate_in_2017.svg)</comment>


This startup sucks. I want to work at another startup. - <AUTHOR> https://medium.com/p/6800367d3cc5

<comment><USER2> The interesting part: [http://www.poachbox.com/home.html](http://www.poachbox.com/home.html)</comment>


Show HN: SQL Generator for Segment/RudderStack Event Data - <AUTHOR> https://github.com/rudderlabs/query-generator <comment><USER2> Link is broken.

<comment><USER3> Thanks for pointing. Fixed it now (it was a private repo)</comment></comment>


The Myth of AI - <AUTHOR> http://edge.org/conversation/the-myth-of-ai <comment><USER2> "What we don't have to worry about is the AI algorithm running them, because that's speculative. There isn't an AI algorithm that's good enough to do that for the time being."

By the time a risk does hit, it will be far too late to invent the requisite mathematics necessary for machine safety. There are _many_ paths towards dangerous AI futures and _many_ powerful forces that could inadvertently tip the boat the same way we are escaping the implicit "goals" of our genes, so the union of the respective probabilities is very much not speculative and must be taken seriously.

"There's a whole other problem area that has to do with neuroscience, where if we pretend we understand things before we do, we do damage to science, not just because we raise expectations and then fail to meet them repeatedly, but because we confuse generations of young scientists. Just to be absolutely clear, we don't know how most kinds of thoughts are represented in the brain. We're starting to understand a little bit about some narrow things."

Appealing to scientific ignorance is always a bad idea: [http://lesswrong.com/lw/kj/no_one_knows_what_science_doesnt_...](http://lesswrong.com/lw/kj/no_one_knows_what_science_doesnt_know/)

<comment> hippee-lee Forgive my lack of knowledge on the topic but a question keeps popping into my head when I read comments about the danger to humanity where AI runs amok.

> There are many paths towards dangerous AI futures,

Are there not just as many paths towards protective, helpful <or insert one of many adjectives here> AI futures?

Is there a reason to believe that there will only be one AI in the future and that given a directive to do something, the elimination of humanity will be a logical endgame scenario for it?

Why not many AI entities with different and competing goals? Granted, this opens up a different can of dangerous worms. But still, if there is a probability of an AI evolving to 'think' that elimination of the human race is a logical path then isn't it equally likely that there will be another AI evolving logical paths to preserve the human race?

<comment><USER3> I have two competing responses:

1) Check out the AI of Iain M Bank's Culture series [0]. In it is a benevolent society of AI machines (the Minds) that generally want to make the universe a better place. Shenanigans ensue (really _awesome_ shenanigans).

2) In response to the competing AI directives, I'll reference another Less Wrong bit o' media, this time a short story called Friendship is Optimal [1]. Wherein we see what a Paperclip Maximizer [2] can do when it works for Hasboro. (It is both as bad, awesome, and interesting as you might expect it to be.)

Personally, I think the general idea is that once one strong AI comes about, there will also be a stupefying amount of spare idle CPU time available that will suddenly be subsumed by the AI and jumpstart the Singularity. Once that hockey stick takes off, there will be very little time for anything else to get in on being a dominant AI. It's... a bit silly written like that, but I get the impression it's assumed AI will be just like us: both competitive and jealous of resources, paranoid that it will be supplanted by others and will work to suppress fledgling AI.

I have no idea _why_ this is prevailing, aside from it's like us. Friendship is Optimal makes a strong point that the AI isn't benevolent, merely doing it's job.

> The AI does not hate you, nor does it love you, but you are made out of > atoms which it can use for something else. — Eliezer Yudkowsky

[0] [http://en.wikipedia.org/wiki/The_Culture](http://en.wikipedia.org/wiki/The_Culture)

[1] [http://lesswrong.com/lw/efi/friendship_is_optimal_a_my_littl...](http://lesswrong.com/lw/efi/friendship_is_optimal_a_my_little_pony_fanfic/)

[2] [http://wiki.lesswrong.com/wiki/Paperclip_maximizer](http://wiki.lesswrong.com/wiki/Paperclip_maximizer)

EDIT: I feel it may be appropriate for me to share my opinion: AI will likely be insanely helpful and not at all dangerous. But there will be AI that run amok and foul things up - life threatening things, even. But we already do that with all manner of non-AI equipment and software, so I'm not terribly worried (well, no more so than I usually am).

<comment><USER4> I think bostrom/Yudlowski's arguments are a bit flawed on thsi topic.

 _The AGI would improve its intelligence, not because it values more intelligence in its own right, but because more intelligence would help it achieve its goal of accumulating paperclips._

Why is the worthiness of this goal not subject to intelligent analysis, though? The whole scenario rests on the idea of an entity so intelligent as to wipe out all humanity, but simultaneously so limited as to be satisfied with maximizing paperclips (or any other limited goal for which this is a proxy).

 _An AGI is simply an optimization process—a goal-seeker, a utility-function- maximizer._

Then I submit that it's not an artificial _general_ intelligence because it apparently lacks the ability to evaluate or set its own goals. I'm reminded of the 6th sally from the _Cyberiad_ in which an inquisitive space pirate is undone by his excessive appetite for facts.

<comment><USER5> >it apparently lacks the ability to evaluate or set its own goals.

The AI would have to evaluate the goal by some standard, so 'maximize paperclips' is a proxy for whatever goals get a high evaluation from the standard. Getting the standard right presents essentially the same problem as setting the goal.

Putting in 'a need to be intellectually satisfied by the complexity of your end product' is complicated and still wouldn't save humanity.

</comment></comment></comment></comment></comment><comment><USER6> I'm okay with the Citizens United decision (first amendment should be protected above all else, I think we shouldn't cap political donations). I understand that it's a position that puts me at odds with a lot of techy liberals. So starting a video on AI by referencing his own thoughts on Citizens United is off-topic and isn't persuasive.

<comment><USER7> Say I program a drone to constantly fly in front of you.

Every time you open your mouth to speak, it blows an air horn away from you, noise-cancelled towards you. Your person has not been violated, but your ability to be heard has been obliterated.

Have I interfered with your first amendment rights?

That is what Citizens United means to me - asymmetrical free speech warfare.

Additionally, is the "money == speech" relationship a transitive property? Why not?

<comment><USER8> > Have I interfered with your first amendment rights?

Not unless you're from the government.

Otherwise you're probably just disturbing the peace or trespassing.

</comment></comment></comment><comment><USER9> Seems like he's not really talking about AI so much as the business model of the web. Elsewhere Lanier has talked about what he calls "Siren Servers" \-- the web business model of baiting people with free services, collecting their data, and then engaging in uncompensated monetization of that content. A lot of "big data," which drives a lot of today's "AI," is in the same category.

When you look at how much money Facebook and Google make from your content via indirect monetization, these services are _not_ free. They're actually fairly expensive.

<comment><USER10> It is very hard to actually sell the product (the content generated for Facebook or Google) for the people producing it. It has little to no value outside of the social network context that was provided. Thus, it seems to me more like the "sirens" are creating a market where no viable one existed before. There is no cost or value lost for the people using them. The value did not exist before the social network was created.

<comment><USER9> "There is no cost or value lost for the people using them."

That assumes the data isn't being used in a way that harms the interests of the user.

</comment></comment></comment><comment><USER11> I found this article badly written. The author seems to confuse the two different types of AI that different people in his article are talking about.

Stephen Hawking and Elon Musk are talking about a hypothetical evil or amoral AI with super human intelligence when they label ai an existential threat to us.

The author is not talking about such a hypothetical ai and seems do dismiss the possibility of such an ai ever existing without so much as a second thought.

He seems to skirt around the problem in the first few paragraphs, and as I understand it his argument finally comes down to this:

"People should stop worrying about mythic or religious ai, because it's bad for the economy and the AI field itself.".

The author never questions the fact that it might be possible that super human AI can exist and that it's therefore very good to be afraid and/or cautions when researching AI, and that it might be very beneficial for humans to quit AI certain research altogether.

<comment><USER12> I think he argues that it's the actuators that we need to be concerned about, because there are plenty of intelligent entities around who will do bad things with actuators that allow that. One more entity intent on doing a bad thing does not make a great deal of difference. Neither humans or AI's should be given the tools to do great harm to other humans or AI's.

He cites drones as an example, but of course nuclear weapons are the obvious gotchas for humanity. One trident sub is perfectly capable of killing a hundred million people, I doubt whether anyone so vaporized would give a toss whether these were launched by a googlebot or a mad captain.

</comment></comment><comment><USER13> Elon Musk is one of my idols, but his stance on AI is highly disappointing! It doesn't require much of a brain to conclude that without AI, which can vastly increase our intelligence, we're doomed. There's no bigger extinction risk that us being constrained by our selfish and intellectually-limited nature! We need a scalable intelligence without the burden of emotions, politics, restroom, lunch, and coffee breaks, that will work round the clock on solving problems we've been trying to solve for decades. Let's start with eradicating the flu, for example. I honestly can't respect our civilization until we handle basic issues like this one!

<comment><USER14> I think it's important to realize that AI doesn't have to have bad intent to do us harm.

Al it need for AI to have horrible consequences is for us to rely on it more and more and thus allow it to control more and more parts of our lives.

I don't fear the human level intelligent AI I fear the rat level intelligence that comes before.

<comment><USER15> Right; many moral dilemmas are easy to solve if you have no conscience. 10 people on the tracks? switch the engine to run over one child.

<comment><USER4> Moral dilemmas are easy to solve if you have perfect information. In the train-track problem you reference, the utility of saving 10 people at the expense of 1 life is obvious and I would do so without hesitation (though not without regret). But life rarely presents us with cases where the utilitarian calculus is so clear; our powers of foresight and analysis are so limited that we get better results by establishing and promulgating rules that cover the most common situations - imperfectly, but with tolerably low error levels.

<comment><USER16> > In the train-track problem you reference, the utility of saving 10 people at > the expense of 1 life is obvious and I would do so without hesitation > (though not without regret)

Even if it were your own child?

<comment><USER17> Even if the answer is no, how does that relate to anigbrowl's point? (or were you just curious?)

<comment><USER16> From a "purely utilitarian" perspective your relation to the people involved is not relevant. That's assuming the existence of some "universal" utility, not one specific to the person deciding.

</comment></comment></comment></comment></comment></comment></comment><comment><USER18> We can't predict what startup is going to succeed, why do we think we can predict what the future of AI will look like?

<comment><USER19> Because the foundations upon which AI shall be built aren't exotic. They're still programs. They still need an architecture to run on and they need electricity.

Even if new architectures that are specifically designed to leverage neural nets[1] or some other variety of processing are developed, the fundamental realities of computing, programs, physics and economics are not immune from being sufficiently underwhelming as far as AI is concerned.

Of course, this is precluding cloning technology where actual biological brains and therefore legitimate "life" and therefore intelligence can emerge.

[1] [http://www.nytimes.com/2014/08/08/science/new-computer- chip-...](http://www.nytimes.com/2014/08/08/science/new-computer-chip-is- designed-to-work-like-the-brain.html)

</comment></comment><comment><USER20> We should be worried about AI and we should have a plan: [http://en.wikipedia.org/wiki/Superintelligence:_Paths,_Dange...](http://en.wikipedia.org/wiki/Superintelligence:_Paths,_Dangers,_Strategies)

</comment><comment><USER21> Why is Elon Musk an expert in these discussions?

<comment><USER19> Bachelor's degrees in physics and economics. Experience in engineering, consultancy and management while working at Tesla and Space X (particularly their engine design). Has a history of literally thinking outside the box.

<comment><USER20> Figuratively.

</comment></comment></comment><comment><USER22> One bright side of an AI apocalypse is the robots will have better haircuts.

</comment><comment><USER23> Most likely you and your kids are gonna be wiped out by intellegent machines just in a few decades.

<comment><USER24> Hey, you've got a lot of mileage out of your burn account. You copy and paste this message a lot?

[https://news.ycombinator.com/item?id=8180222](https://news.ycombinator.com/item?id=8180222)

[https://news.ycombinator.com/item?id=8260954](https://news.ycombinator.com/item?id=8260954)

[https://news.ycombinator.com/item?id=8505964](https://news.ycombinator.com/item?id=8505964)

[https://news.ycombinator.com/item?id=8523499](https://news.ycombinator.com/item?id=8523499)

<comment><USER23> Whenever I'm finding it appropriate to do so.

I'm a computer science researcher, I have a right to that opinion and I sincerely expect this to be the most likely outcome.

I do not see anything wrong in stating it bluntly and clearly, as often as I like. I don't see anything wrong in copy-pasting my own quote.</comment></comment></comment>


Castles That Are Cheaper Than an Apartment in San Francisco - <AUTHOR> http://www.upout.com/blog/san-francisco-3/5-castles-that-are-cheaper-than-an-apartment-in-san-francisco <comment><USER2> None of those examples are castles. If it's got windows on the ground floor it's a palace, not a castle. It's a castle if a foot-soldier sees it coming over a rise after trudging for hours through the freezing muck and thinks to himself "Oh man, this is going to suck."

<comment><USER3> We don't really have an accurate translation of the word "chateau". It's a superset of what we'd call anything from "fort", "castle", "mansion", "palace", "manor house" and anything in between. That being said, the word "chateau" comes from the exact same etymological root as our word "castle", so it's not exactly unfair to use the word.

<comment><USER4> They're not apartments, either!

</comment></comment></comment><comment><USER5> As they say: Location, location, location.

You are paying for the land. While building might cost a little more in the city due to permits, and labour's cost of living, in general it is mostly land. All this article tells us is: If land is cheap, you can buy a lot of it and built large structures on it.

This is why, to me, it is surprising that so few companies offer "remote only" jobs. On the face of it there seems to be downsides (worse communication, VoIP costs, etc) and few upsides. But just because you could employ people from lower cost of living areas (who would accept lower pay), you'd save enough on salaries to make the venture worth considering.

For example, let's say you're based out of NYC. You have to pay people in that area in the $80K+ ballpark so they can even make rent. However if you remain in NYC and employ people from Mississippi, Tennessee, or Idaho you could pay people in the 60K range and they'd have the same or better living standard than the 80K people in NYC.

<comment><USER6> > This is why, to me, it is surprising that so few companies offer "remote > only" jobs.

Politics. Politics. Politics.

How do you prove, as a manager, that you are doing your job when nobody can see half of your employees?

As a side note, there are also good reasons to have your technical team co- located. It's sometimes really hard to drill into difficult technical problems without everybody standing in front of a whiteboard.

<comment><USER7> > How do you prove, as a manager, that you are doing your job when nobody can > see half of your employees?

I don't know if I buy it. How do you prove, as a manager, that you are doing your job when everyone can see all your employees? I fail to see how the visibility of you employees helps you prove that you're doing your job.

<comment><USER8> It's all perception. The manager talking with employees, having meetings with them etc gives the appearance of "work". This same thing causes interruptions to developers all day long. "Hands off" managers who hire people they trust to do their job are far more productive, but not the middle of the curve.

</comment></comment></comment></comment><comment><USER9> Reminds me of Crack Shack or Mansion, a game of sorts to show the ridiculousness of real estate in Vancouver. These listings are several years old - the situation is much worse now:

[http://www.crackshackormansion.com/](http://www.crackshackormansion.com/)

<comment><USER10> Yeah, I prefer this one. I mean, some of those SF apartments, while of course expensive, are pretty damn sweet. ALL of the houses in crackshackormansion are shitty, and I'm amazed the lot value of these places is still 1+ million.

<comment><USER9> Getting closer to $2,000,000 these days.

</comment></comment></comment><comment><USER11> What a click-baity title. Yes, apartments are indeed expensive in San Francisco, but 2 of the 5 listings aren't even apartments: one is a _mansion_ and the other is a 4,300+ sq ft home.

</comment><comment><USER12> Very clickbait-y title. Only one of the "castles" is cheaper than an actual apartment. The rest are houses.

Also does not factor in the cost of upkeep of a 200+ year-old castle. Yes, the housing market in SF is crazy but this is a pretty spurious article.

<comment><USER13> The lower cost castles tend to have a lot of delayed maintenance.

<comment><USER14> That and they often cannot be rebuilt with modern materials and techniques. And you may even go to jail if you try.

</comment></comment></comment><comment><USER15> Spoiler: Some apartments in SF are very expensive.

I'm sure I can find castles cheaper than other absurdly expensive apartments in other places too. I thought this article was going to be about castles cheaper than the cheapest apartment you can buy in SF.

</comment><comment><USER16> Since when is a "studio" actually 5 offices and 3 apartments?

<comment><USER17> Looking at the Zillow listing it has 5 offices with a dedicated kitchen and bath and 3 apartments and is 8k sq/ft total with lots of updates. It isn't "cheap", but for that amount of rentable space right in the middle of SF that would be a pretty good investment.

</comment></comment><comment><USER18> It doesn't matter how much you can buy it for. What matters is how much you'll pay for mortgage + property taxes + maintenance + insurance. A lesson that I admittedly learned the hard way when purchasing my home.

</comment><comment><USER19> > 3... Or this mansion in Alamo Square for $6,400,000.

Grew up in a 7+7 city house in Zimbabwe (5ha property). When we left it was sold for less than US$100000 (current day value). Given that perspective I'd have to venture a guess to the true meaning of the article: property values vary wildly depending on location to _extreme_ scales.

 _9+9 is a mansion by modern standards? Bloody hell._

</comment><comment><USER20> I'm the co-founder of UpOut and even I think this article is not super relevant for HN.

</comment><comment><USER21> Besides other flaws, premise of this article assumes that castles are better living quarters than apartments which I don't think is necessarily true.

</comment><comment><USER22> Yeah, but how's the internet connection at the castles compare to San Fran?

</comment><comment><USER23> "Win tix to unique SF events!"

How about no. <close tab>

</comment><comment><USER24> What is the earthquake insurance on these apartments?</comment>


Found this site, apply to New York City's startups in 60 seconds - <AUTHOR> http://underdog.io/

<comment><USER2> It would be nice to see a list of the startups that can see resumes (or opt out of some).

If I was at a startup and looking to move to a new one, I wouldn't want it to be public knowledge that I was looking until I at least talked with a couple companies.

<comment><USER3> Exactly. With no knowledge of who my information is going to I can't agree to submit an application. Privacy is one reason; not having your time wasted if the companies aren't something you're interested in is another.

<comment><USER4> It takes, like, 2 minutes to fill out the form so you wouldn't be wasting much time on that side.

That being said, I'm __assuming __you 'll be told what company is interested in you (if any) when/if they make contact rather than the usual recruiter nonsense ie. "A company in the financial services space" etc etc

<comment><USER3> It's the follow up communication that could waste time. I would prefer to do a little research on each company before applying to a dozen of them at once, or to see that the companies listed are known and trustworthy.

</comment></comment></comment></comment><comment><USER5> What sort of candidate volume are you seeing? I signed up from the startup side but for $350/month I want to have a pick of a lot of candidates. Maybe some way to preview candidates without getting their contact info so that I can feel better before handing over some money? Or free accounts for startups too while you guys build out your volume?

Also I think your tone is too informal for this kind of thing. Seeing "moar" made me cringe.

<comment><USER6> Hey Mason, we'll send you an email to discuss. We just went live (like one hour ago :D) but we're seeing a good deal of traffic.

</comment></comment><comment><USER7> The part about needing sponsorship - Don't you think your form should have a field to reflect this. So that the startups can easily see if the candidates are not in the US and need sponsorship? Without having to view each resume.

<comment><USER6> Also great feedback. We'll add this later today.

</comment></comment><comment><USER8> looks suspiciously like hired.com - but as a resume aggregator rather than talent marketplace. maybe you can convince companies to pay $350/mo for your book, maybe you can't. good side project though :)

</comment><comment><USER2> How do you prevent a bad actor from signing up as a fake startup and harvesting your users?

<comment><USER6> We do our due diligence on every startup before we partner with them.

<comment><USER2> Great -- and well done going into the thread and answering questions.

</comment></comment></comment><comment><USER9> I don't want to specifically say this site is good or bad, but I've had really bad experiences with sites of this sort.

Essentially, sites of this sort were all just recruiters trying to farm up candidate contacts, and all you are left with is just spam.

My advice to underdog.io: tell us who you actually are. What's your name? What experiences do you have? Your "About Us" says nothing about you, and makes me suspicious that you don't want to put yourself out there.

<comment><USER6> Hey, I'm one of the people working on this.

That's totally a legitimate concern. I can promise you we aren't recruiters. It's just a side project at the moment, so we didn't want to draw too much attention to ourselves.

<comment><USER10> I was interested in your service until I read the about us and the FAQ sections. They are respectively, not transparent enough and patronizing. If you want me to use your job-search service, treat me like a professional and don't address me as "silly" and "cute". I like that you're trying to make it easy, but as you say, a job search is not easy, and your website makes it seem suspicious too. I put all of my information and then what do you do with it exactly?

<comment><USER11> Pretty much this. I'm not sure why I'd use this service either, if they are a serious company they'd put effort into getting the word out about the jobs in the first place.</comment></comment></comment></comment>