NateDad

That has never happened in my experience, and I've been through a lot of layoffs. It's usually the exact opposite. They lay off all the peons and keep the few high level experts. They're a lot harder to replace.

I've worked remote for about 5 years (and about 18 years total). When I lost my last job, I resolved to only look for remote work. Commuting is a giant waste of time, which is the most precious resource we all have. I could live near Boston and have a tiny house with no yard and mediocre schools, or I could live an hour outside Boston and have a huge yard and amazing schools. The choice is clear. But it means that if I were to work in the tech hub, I'd never see my kids during the week.

When done right, remote is awesome. There's no reason every programming company couldn't be remote-friendly these days.

There are two things that companies often do that screw up remote workers:

1.) Having meetings in meeting rooms. This does not work for remote people. Remote people cannot participate in a conversation from a speakerphone when the majority of people are in the same room. You just can't break into conversations between people in the room.

2.) Having an open office. This prevents the fix to #1 - which is to have meetings via hangouts or other video chat, with everyone (even people in the office) participating via headset & personal video camera. The open office makes cross talk between mics too painful (with judicious muting you can sorta fix it, but it's a hassle).

These are fixable problems, but the company has to be committed to good remote culture to do so.

tl;dr: because it was designed for a weirdly shaped parcel of land, but then it wasn't put there, but they stuck with previous designs anyway, because the president thought it was a neat design .

How many people maintain their own email servers vs. use gmail?

Slack doesn't prevent you from accessing your data, in fact they explicitly built exporting features.

We're talking about open source, so reading your stuff shouldn't be a problem. For proprietary, maybe, but even then, reading someone's private slack info would be highly damaging to their brand, and to what benefit?

To have all the features you get for free out of slack, you have to do a lot of work and maintenance to get out of IRC and mailing lists.

Mailing lists by themselves are terrible, because there's no history. You can't scroll up to find context for the conversation. You can get public archives, but then where you actually use the mailing list and where you go to look at history are completely separate, which is a terrible UX. Google groups mostly fixes this because they're really just a forum that supports emails.

IRC is terrible because everyone has their own client, so you never actually know what someone will see when you post something. Post a link, - will it get auto-expanded? How will it look? Will it get auto-linked? If you @ someone, will they get notified? if so, how visibly?

IRC also has the multi-login problem - it gets confused if I log in from my phone and my laptop. To get a persistent history of IRC requires running an external service which is way beyond most users.

Slack has mindshare, which leads to having a ton of integrations with other platforms, which just multiplies its effectiveness.

I 100% agree that I wish they offered a publicly visible option, so anyone can view without logging in. I also wish they natively supported self-registration.

I have to echo another commenter on here. If you want the best of all worlds, a forum is what you're looking for. Publicly visible, easily linkable, long form, asychronous communication. Whether that's google groups or something else is up to you.

"log in to slack" vs. "deploy 3 services in the cloud by yourself and force everyone to use a specific irc client (good luck)"

There's a reason people like slack so much. It does a ton of stuff out of the box with no headaches. Nobody wants to maintain all that stuff.

TIL I learned about godeps -N.... a month too late :) Cool, though, that definitely would help with that problem.

I really want to learn Rust. It's been on my next-to-learn list for a while now. I have limited time because of young kids and getting embroiled in politics (actual politics). Someday :)

I agree, I wish + wasn't string concatenation either.

<_< >_>

No.

Go was a good choice. The project benefited from it, both from a hiring perspective and from a technical perspective. If I were in charge, I would make the exact same choice again.

Juju lives exactly in Go's sweet spot. A networked server worked on by more people than you can fit around your dining room table. Not every project would benefit from Go, but this one certainly did, IMO.

To be fair, you'll never see me compare Go to Haskell :)

This is about what the Windows API reports when you ask it what the path is of a file. Sure, inputs work with slash. Comparing outputs, which was the example I gave, does not.

That works for input, not output.

If you ask what the path of a file is on Windows, it'll give you the backslash version.

one of the things that go eschews is operator overloading.

    a := b + c

What's the runtime complexity of this statement? How much memory will it cause to be allocated? In go there's only two possibilities for what this code is doing... either this is string concatenation, or it's adding two numbers. Both of which are immediately comprehensible for impact on run time and memory.

In C#, you can overload operators, so the + could in theory do anything. And what's bad about that is that it is deceptive. It's easy to miss the fact that this line might actually be doing something complex.

It also means that if someone is looking at your code, they can't make any assumptions about what any particular line of code is doing, without complete understanding of a vast amount of code.

This is one of the pieces of magic that I'm glad go doesn't have.

To actually answer the question - yes it holds true, yes it scales (in my experience). There are a lot of abstractions that we built for Juju. And we absolutely tried to ensure there was only a single source of truth for everything. It would have been totally unworkable if we couldn't reuse logic etc. We may not always have chosen the best abstraction, but that's a problem in any language.

Yes, sorry, wasn't saying that either Go or Rust were an exception, just trying to forestall the inevitable "but what about X thing that was used by everyone and is still 0.9" :)

For Go vs. Rust, I think a comparison of 1.0 releases is perfect.

I worked in C++, C#, and Java for 15 years before my work in Go. I've used generics. I will freely admit to not having a lot of experience in functional or ML style programming languages a la Rust. I'd love to spend some time getting up to speed on Rust, it seems like an interesting language, and at the very least, a great learning experience.

functions and methods are the original abstraction. Interfaces allow you to abstract implementations of sets of methods.

I fail to see how that is saying that abstraction and usability are overrated. They're not. They're important.

Comparing 1.0's is a much better comparison, except in cases where there was huge adoption before 1.0.

That's not exactly true, Rog. If two people have changed the file, which causes a conflict, then you have resolve the conflict manually. Recreating the file with godeps would populate it with whatever commit happens to be in your gopath right now, which has no relevance to what is conflicted in the file and could be a completely different hash.

42 seconds.

Just tried it with go 1.8 and a clean gopath (after downloading). That's on a 3 year old quad core i7 laptop w/ SSD. That's `go install github.com/juju/juju/...` which actually builds two binaries - the client and the server.

Does kubernetes take 2 minutes to build? That seems super long. I csn compile juju (1mil LOC) in like 15 seconds.

Tests always rely on implementation details. The implementation details are what you're testing, after all. The problem is relying on the wrong ones.

You can hide all the details you want in the language, unless it's a pure function, there's side effects that can be relied on improperly. Often times this is because of hiding implementation details. A GenerateCert function might read from a config file. It hides the detail that the config file exists, but then to test it you need to create the file in the right spot.

Yes, testing Add(int, int) is easy in any language. No one's struggling with those tests.

This is one of the things I love about go. Basically any random tool written in go I can have installed and runnable in 3 seconds from the time I know the github url. All but the largest of applications is made to be compatible with 'go get' and so most of the time it just works.

Well, sort of, yes. https://play.golang.org/p/qyfqZA5pww

  func main() {
    go fmt.Println("Hi!")
  }

This is a valid go program (eliding import etc), and it'll almost never print anything.

This is actually a classic mistake when starting with goroutines - not adding synchronization to make sure your main goroutine doesn't exit before any spawned goroutines.

C, C++, C#, F#, R, Java, Julia, Rust, Python, Logo, Pascal, assembly, Haskell, lisp...

Unless you're writing in Perl or javascript, almost every programming that exists is either a short English word, a person's name, or just a letter with maybe some punctuation.

FYI, delve is integrated into a lot of editors, and basically works exactly like visual studio when used in VS Code (I used visual studio for C++ & C# for 13 years before moving to Go).

And this is why I'm intending to add a -c flag (and maybe a global config of some sort) to tell gorram to use a compiled version instead.

By fast enough, I mean this:

The tradeoff between go build and go run is that go build makes subsequent runs faster, but it creates a somewhat large binary that takes up disk space.

So, when I say go run is fast enough, I mean that the speedup of using go build is not big enough to justify the extra disk space required to store those binaries, compared to the speed hit we get from using go run each time (IMO of course).

Sorry. What I meant was that I considered generating the binary and leaving it around, but instead I generate just the code and rely on go run to create and then delete the binary.