joncalhoun

People have a mental cap on what text should cost. If someone creates instructional content that provides thousands of dollars in value, they can sell videos for $200+, but a book version is hard to sell over $50, even if both provide the same value. Even for free content it is easier to monetize YouTube than it is to monetize a blog.

If we want people to create more text-based material, it needs to have similar financial incentives.

In my head I was thinking of a definition like the one below when I wrote that:

"Spam is irrelevant or inappropriate messages sent on the Internet to a large number of recipients." - https://ieeexplore.ieee.org/document/7048231

When people sign up for Gophercises, the first two emails I send them are about the course asking how the course is going, if they had issues with the player, etc.

After that they get Go related emails. Eg https://ckarchive.com/b/0vuwh9hvx32q Again, not really irrelevant given the interest in learning Go, and 99% of the people I talk to love those emails.

Maybe 3-4x per year I'll have a sale on my other paid courses. During those times people who have been on my mailing list for a set period of time (I think it is at least 10 days and have received at least 2 previous emails from me without unsubscribing, but I'd need to double check) will get a notice about the sale. I try to avoid being super annoying with those, so they will often contain useful lessons about coding with Go even if you aren't interested in the sale.

I make my living selling Go courses. I was only able to create and offer Gophercises as a free course because of this, so yes, I require an email address and I use Gophercises as a marketing tool. I try to make it a decent experience, but no matter what I do someone will always complain. I find my time is better spent helping the people who enjoy and appreciate what I am doing.

Many employment contracts prohibit doing additional contract dev work. I agree the spirit of contract to hire is great, but worth noting it won't work for everyone.

I'd double check that you don't have multiple orgs. You used to share a cess to your account with people, then they made some org change a while back that essentially moved that shared access setup to an org and gave you a new personal account iirc. Easy to not realize you have both.

Go to the bank and say, "I would like to withdraw money from my account." Do they hand you your balance in cash, or ask you how much?

Obviously one can withdraw all of something, but I'm skeptical of it meaning "all" by default.

Does steam take any cut of in-game purchases for free to play games? I don't think they do, so that is a difference to consider.

The most frustrating experience is when I'm already paying for an app and intercom constantly nags me and gets in the way of me using the actual app.

Was this a timed take home project or something with a flexible timeline? That is, was it "You have to respond within 3 hours of receiving this email with your solution" or something more flexible?

I mostly understand why some companies do the x hours routine, and when I've done interviews this way I've historically performed well, but it just felt like it added unnecessary stress. For instance, anyone on the job doesn't have to worry about issues like, "What if I couldn't get the app up and running because I had the wrong version of X installed?" longer than maybe their first day on the job. And if you plan on hiring an engineer for a few years, one day is irrelevant. At best this felt like it favored contractors who were more experienced at jumping into new projects frequently.

I don't think plausible deniability works on one-of-a-kind artwork. Even if you assume your dealer is legit, any cursory research will tell you it was stolen. It would be like buying the secret formula for Coca-Cola and claiming you didn't know it was stolen because it went through multiple middlemen.

Now imagine being the dev who keeps making proposals and working diligently at the problem only to have countless ideas and proposals shot down for one reason or another. Ian Lance Taylor is persistent if nothing else and I'm hoping his hard work pays off with this proposal.

My guess is you are incorrect and this has more to do with the Ardan Labs partnership[1][2]. This release also came shortly after Bill (founder of Ardan Labs) went to visit Matt and discuss Caddy[3], which helps support that claim.

Prior to the partnership I believe the real issue was that Matt & co didn't have a sustainable way to maintain the project and they were trying to figure that out. I don't know the details of the partnership with Ardan Labs, but my guess is it is structured in a way that allows Caddy to focus solely on building out a great product without worrying about monetizing it so they dropped all the proprietary licensing.

[1] - https://www.ardanlabs.com/news/2019/05/ardan-labs-partners-w... [2] - https://twitter.com/mholt6/status/1179957356005707776 [3] - https://twitter.com/goinggodotnet/status/1178949305421438976

Most people - traveled or not - would be okay with this if they knew the service person was making a fair wage. The problem is that service workers are not fairly compensated in the current system so our options are (a) hurt the service worker by not tipping to make a point, or (b) tip so the service worker is fairly compensated.

The only real way this changes is if we first make sure service workers are fairly compensated, but for most people this isn't a big enough issue to prioritize it - we only discuss it in forums like this when an article this appalling gets posted - but it is a big issue for the millions of restaurants in the US who would have to increase wages so they will all lobby against it.

The page is a little rushed, but the worst thing you should see is an ugly error message.

This is a TRIAL RUN, but if things go well I want to make this a regular thing with new designs by a variety of artists, and I'd love to donate proceeds to orgs that are doing good things in the Go space. Eg Women who Go or Golang Bridge (suggestions for orgs are welcome). I think there are a lot of great places that could do way more with more funds.

If you experience any issues or have questions just let me know - jon@calhoun.io - the FAQ tries to answer most, but I'm sure I missed something.

I'd like to expand the course a bit and cover more testing topics, so if anyone has suggestions I'm all ears.

Ideally I'd love to hear about situations that were particularly hard to test and (if possible) solutions you used to address the problems.

Eg testing subprocesses is a tricky thing to do, but there are a few ways to write test cases that can be used as a mock subprocess and this has become a relatively useful technique for companies like Hashicorp.

I'm guessing other similar testing ideas exist, but aren't covered in the course and I'd love to research them more and add them.

If you don't show with "good" reason (finances, health issue, etc) they usually do nothing.

If you don't show with a "bad" reason then what they do varies, but I've never heard of someone being sued. Instead it seems to be things like, "we will tell your high school and it may be mentioned if you try to apply to another university."

Huh... I was thinking I touched on the Secure field of the http.Cookie when I wrote this article, but I guess I did not. I'll try to find time to update the article with both the Secure field and more info on HSTS.

I both founded a YC backed startup and I worked at another YC backed startup and had a great experience there. Having said that, I can't say I would ever recommend a new graduate taking an offer at a startup (at least an early stage one) over an offer at a BigCo of some sort.

A BigCo will help them get hired for the rest of their career. Anecdotally, I learned and accomplished far more at startups than at Google, but anytime someone sees my resume "Google" is what they notice first and are impressed by. This sucks because early employees at a startup have so many opportunities to learn and accomplish way more than a typical BigCo employee, but recruiters can't easily filter on this like they can "Oh this engineer worked at Google - they must be good!" As a result, working at a BigCo will likely help their career more than working at a startup.

Pay and filtering out good vs bad offers is another concern. Most engineers are unfamiliar with startups, equity, preferences, cap tables, and everything else. We on HN are probably more knowledgeable, but I founded a startup and still don't fully understand it all so I can't imagine how someone completely unfamiliar with startups could possibly evaluate an offer. This is made worse by the fact that it feels like startups for the past decade have taken advantage of this ignorance and screwed over many early employees with poor offers and a fake promise of wealth when the company is a mega-success. Many others have made this point in this thread already so I won't get into the details, but the TL;DR is that employees need to be treated as vital investors in the business and as people you want to help succeed.

A third concern is development and training. At a startup you are expected to already have a pretty solid knowledge base when joining; you typically need to know how web apps work, some of the stack the company uses, etc. That isn't to say you won't learn a lot at a startup, but this is typically done in a "sink or swim" manner where you have to have some foundational knowledge to avoid drowning. At a BigCo this isn't always the case, and many new grads will be hired with less domain specific knowledge and are given an opportunity to learn and grow over the first year. Now I realize not all startups (especially early stage ones) can afford to hire employees who won't be contributing in the immediate future, so I'm not sure how you fix this (maybe a company like Triple Byte could find promising employees who lack some specific knowledge and give a crash course before sending them off to startups to interview?), but if you can get hired at a BigCo you can basically get paid to learn these skills which is a much more enticing offer.

A fourth concern I've heard from people less familiar with startups is concern that the startup will just die at any minute leaving them jobless and in a tight situation. This mostly stems from founders not sharing important information like cash reserves, burn rate, runway, etc, so I think the general fix is to encourage founders to provide more clarity around these things. The problem is this is hard because no founder wants to admit they are failing or that the company may not be alive in 3 months. They might raise money or turn things around and they don't want their best employees to leave, but by not saying anything they risk getting into a situation where employees need to be suddenly let go and a single story like this can scare away many potential candidates. This just isn't as much of a risk (or it is perceived to be less of a risk) at BigCos, even though they do occasionally close down branches.

I fear things like this would never work in the US because at this point $14k/yr is nowhere near enough to cover the insane rate at which university prices are rising.

Ignoring all the reasons why the rates are going up, the simple truth is that many degrees are not worth their increased cost (in terms of ability to repay the loan with a career derived from said degree) and as a result the program wouldn't work for every major which could lead to the exact situation we are in - private parties offering crazy loans for majors that are deemed not cost effective by others.

We almost have this now in some ways. I've heard of hospitals paying for people to get nursing degrees if they work at said hospital for N years after graduating, so that apparently is a major where it is cost effective. I suspect you could also come up with something comparable for other majors that have a relatively high salary and high job prospects, but it would be much harder for fields where getting a job paying more than $15/hr after college is hard and often requires a PHD.

> That makes it bloody hard to mock during unit testing.

Can you share why? Not trying to say you are wrong, but I am guessing that part of this stems from some limitations in the way interfaces work in Go, and this could make a good user experience report.

Blogging is basically just content marketing, which has been proven to work when done well. It is also one of the cheapest ways to market if you have a little time each week to invest into it. I know of at least 10 companies and/or individuals who have used this strategy to build an audience and start selling one product or another with great success and a very limited initial budget.

You are right that one (or ten) success example(s) doesn't prove that this strategy works, but similarly neither does one (or many) failure(s). It depends on the quality of the articles, the audience, and many of other factors, just like paid advertising depends on various factors like where the ad is, what audience you target, cost, etc.

What I can say with certainty is that there are definitely markets where you can get to the front page of Google within a year by just writing a few quality articles every month. You don't have to pay money, use spammy backlink tactics, or anything like that. Whether OP's audience is one of those is unclear, but it seems that he knows his audience reasonably well if he is making $$ from them, so chances are he could get a positive ROI on a blog if he gave it the proper attention.

> When a security issue is found in a package, it's common to see point releases get released for older major/minor versions. So if foo has 1.1.0 and 1.2.0 out today and a security bug that affects both is found, the maintainers will likely release 1.1.1 and 1.2.1. This means 1.1.1 is released later than 1.2.0.

I should have addressed this in the original reply and its too late to edit now, but this isn't an issue. I downloaded vgo and verified that you CAN release a 1.1.1 AFTER 1.2.0 and it is treated correctly as far as I can tell.

See github.com/joncalhoun/vgo_main:

    $ vgo list -m -u
    MODULE                          VERSION                    LATEST
    github.com/joncalhoun/vgo_main  -                          -
    github.com/joncalhoun/vgo_demo  v1.0.1 (2018-02-20 18:26)  v1.1.0 (2018-02-20 18:25)

v1.0.1 is newer than v1.1.0, but isn't treated as the latest version. I suspect that RSC didn't mean "older" in the literal datetime sense, but rather in the context of semantic versioning where "older" means you don't release v1.3.4 AFTER you have released v1.3.5

You CAN ship v1.2.1 after v1.3.0 is live. I have tested this with the vgo prototype and it works fine (see github.com/joncalhoun/vgo_main):

    $ vgo list -m -u
    MODULE                          VERSION                    LATEST
    github.com/joncalhoun/vgo_main  -                          -
    github.com/joncalhoun/vgo_demo  v1.0.1 (2018-02-20 18:26)  v1.1.0 (2018-02-20 18:25)

Notice that v1.0.1 was released AFTER v1.1.0

What the minimum version is doing is giving our code a way to automatically resolve upgrades if they are necessary. Eg if module X requires module Z w/ a version >= 1.0.1, while module Y requires Z with a version >= 1.1.0 we clearly CANNOt use v1.0.1, as it won't satisfy the requirements of Y, but we CAN use v1.1.0 because it satisfies both.

The "minimum" stuff basically means that even if a version 1.3.2 of Z is available, our code will still use v1.1.0 because this is the minimal version to satisfy our needs. You can still upgrade Z with vgo, or if you upgrade a module X and it now needs a newer version of Z vgo will automatically upgrade in that case (but to the minimal version that X needs), but random upgrades to new versions don't just occur between builds.

Let's say I create a program that is using foo and end up with the following dependencies:

main:

    requires "foo" v1.0.0

foo (v1.0.0):

    requires "bar" v1.0.0

Right now if I check my dependencies, I'll have something like this:

    MODULE    VERSION
    main      -
    bar       v1.0.0
    foo       v1.0.0

Now lets say some time passes, and both foo and bar release new versions:

foo:

    v1.0.0
    v1.1.0

bar:

    v1.0.0
    v1.0.1
    v1.1.0
    v1.1.1
    v1.1.2

And the deps for foo v1.1.0 are:

foo (v1.1.0):

    require "bar" v1.0.1

Realizing that foo has an update, I decide I want to upgrade. I'd do vgo get foo. My updated dependencies (shown with "vgo list -m") are:

    MODULE    VERSION
    main      -
    bar       v1.0.1
    foo       v1.1.0

bar gets its version increased as well, using the version specified by the foo package's module. This makes sense to me - the foo package maintainer has stated that he only needs v1.0.1 to be stable, so we default to what he specified.

Now imagine I want to add another package, say it is the wham package and it has the following dependencies:

wham (v1.0.0):

    require "bar" v1.1.1

If I add this to my code my versions will now be:

    MODULE    VERSION
    main      -
    wham      v1.0.0
    bar       v1.1.1
    foo       v1.1.0

bar now uses v1.1.1 because it is the minimal version that satisfies all of my modules. vgo DOES upgrade bar for us, but not beyond the lower version number required to satisfy all of our modules. That said, we can still upgrade it manually with "vgo get bar", after which it will be using v1.1.2 because our main dependencies would become:

main:

    requires "foo" v1.1.0
    requires "wham" v1.0.0
    requires "bar" v1.1.2

In short, upgrading foo WILL upgrade all of foo's dependencies in order to meet it's minimum version requirements, but no further. That said, you can still manually upgrade any of those dependencies.

To me this makes sense. The creator of foo may have avoided upgrading the dependency on bar for some performance reasons, so this upgrade only happens in your code if it is required by another package, you initiate it manually, or if the foo package releases a new version with updated dependencies in its go.mod file.

PS - I've tested this all using the prototype of vgo. You can see yourself by grabbing this code: github.com/joncalhoun/vgo_foo_main and then use vgo to list dependency versions and try upgrading foo which has a dep on demo.

You (and likely everyone else) should look at the tour as well before commenting, as I think many people are misunderstanding some of the subtler points.

> If I'm starting a brand new from scratch Ruby on Rails application today, in 2017, there is no reason it should default to having me use Rails 1.0 from 2005.

In the tour it states, "We've seen that when a new module must be added to a build to resolve a new import, vgo takes the latest one." which means that the newest Rails would be used and set in your `go.mod` file.

From that point onwards the "minimal version" will be used, which means vgo won't upgrade you to a version released tomorrow unless you (or a module you use) explicitly state that they need that newer version.

This is a much saner default than the one you describe (imo) as people still get recent versions for new projects, but once they are using a specific version they won't upgrade unless they need to or want to.

I think you misunderstood what was said. In this proposal, each of your modules specifies a minimum version, but when code is built it tries to use the minimal version that meets those requirements.

Eg I might have my module that says:

    "some/pkg" v1.4.1

Which means I need at least version 1.4.1.

When the code builds it will try to use 1.4.1 EVEN IF 1.4.2 EXISTS, unless it is forced to use 1.4.2 by another module you depend on. That is, say you are using module X and it says:

    "some/pkg" v1.4.2

At this point 1.4.1 cannot be used - module x, which you are using, won't work with 1.4.1 - so pinning doesn't help. Your code will not build unless you manually update your pinned version.

What the minimal version selection does is say "okay one module needs >=1.4.1, another needs >=1.4.2. What is the minimal version that satisfies these requirements?" And the answer to that is `1.4.2`, so even if 1.4.8 exists, 1.4.2 is used in that scenario.

I don't know how this will work long term. I think there are definitely some concerns to consider (eg many minor version bumps are for security fixes), but the scenario you are describing - the newer version causing issues - just isn't an issue as I understand it because your code won't opt to use a newer version unless you (or another module you use) explicitly tell it to.

I've been remote for a long time now, but I don't see it working for everyone; I don't even think it would work for a majority of people. Many just lack the communication skills and discipline to make it happen, and there are many roles that can't be done remotely (doctors, janitors, cooks, etc).

Now what would be plausible is if we could get 10-20% of the workforce remote, and thinking about what that looks like. It might mean that at a remote-friendly company, something like 50% of the staff is remote so we need tools to help remote and in-office employees work better together.

It could also mean that parts of traditional organizations get broken into independent services. x.ai and clara labs both are great examples of how part of a traditional assistant's job is handed off to tech, but the same approach could be used to hand work off to remote employees. This would enable companies to hire fewer people for the in-office tasks, but it requires a rethinking of what each role's responsibilities are and might include sharing an assistant amongst a few execs rather than each having their own. These changes could have a big impact, but don't come directly from new technology. Still, I think they are worth considering when we imagine a more remote workforce.

A lot of the syntax is a byproduct of the template packages shipped in Go.

I assume the ordering of or, if, etc is a byproduct of them being function calls, but I'd have to double check to verify. Regardless it's a little weird at first but you get used to it after a bit. I used a fair bit of customization on the www.calhoun.io theme and I didn't have to think twice about the order of terms after a short while.

One issue with these is that they don't always ask you to rate what you expect. For instance, my local Walmart has one with a small sign above asking you to "rate your experience with self checkout" yet everyone who checks out with a cashier uses the button assuming you are resting any checkout experience.

Inheritance tax also taxes wealth, but it does so rarely and again the rich tend to find ways to avoid this.

The problem with many "wealth" taxes is that they end up missing the top 1% and hurting the people who are building a business.

Eg inheritance tax does a fantastic job of just screwing over family businesses that on paper are worth say $7mm+ because on paper the kids who inherit the business now owe taxes on maybe $2mm (I think the first $5mm is tax free w/ inheritance), but selling any of the business to pay the taxes would often destroy the business.

And I'm not talking about massive businesses like Walmart - I mean businesses like a large-ish family farm where just the land, equipment, animals, etc are all worth $7mm+ on paper, even if the farm doesn't produce massive profits.

> cost of living crisis

I know this is a major issue in CA, NYC, and probably a few other cities, but I'm not really well versed on how much of an issue it is elsewhere. Where could I learn more about this? Preferably sources with data and not just journalistic fluff.