Go reliability and durability at Dropbox(about.sourcegraph.com)
about.sourcegraph.com
Go reliability and durability at Dropbox
https://about.sourcegraph.com/go/go-reliability-and-durability-at-dropbox-tammy-butow
107 comments
That's a claim of the durability of the data, or the odds that a chunk of data will be lost in a year.
They calculate this through the odds that a single node fails, and then multiplying that odd out through all replicas. This covers the most easily quantifiable failure mode.
Obviously the real odds are somewhat higher when you consider that a rogue admin, malicious actor, or buggy code could delete multiple instances of replicated data at once. There's no way to estimate these odds though, and really they don't matter - they're big enough events that they could spell the end of Dropbox if they happened.
They calculate this through the odds that a single node fails, and then multiplying that odd out through all replicas. This covers the most easily quantifiable failure mode.
Obviously the real odds are somewhat higher when you consider that a rogue admin, malicious actor, or buggy code could delete multiple instances of replicated data at once. There's no way to estimate these odds though, and really they don't matter - they're big enough events that they could spell the end of Dropbox if they happened.
Another major class of data loss in this kind of system is operator error when dealing with rare, unrehearsed events requiring operator intervention. Often combined with confusing messages or behaviour from the software.
The video linked by kylequest below [1] speaks about durability, not reliability:
"Create a system that provides annual data DURABILITY of 99.9999999999. Create a system with availability of over 99.99%"
[1] https://youtu.be/5doOcaMXx08?t=220
[1] https://youtu.be/5doOcaMXx08?t=220
>For comparison, public telephony systems aimed for five 9s. That was usually expressed as "20 minutes downtime over 40 years, combined hardware and software budget, for outages affecting more than 32 users." One software crash requiring human intervention would count for more than 20 minutes, so you were allowed <1 of these in 40 years system lifetime.
And all of that is total bogus (the "aim", not your information), as no public telephony system (and surely not in my country) ever had anything close to that.
A few hours of downtime a few times a year is much more like it, although it has been getting better over time.
And all of that is total bogus (the "aim", not your information), as no public telephony system (and surely not in my country) ever had anything close to that.
A few hours of downtime a few times a year is much more like it, although it has been getting better over time.
Not really. The German phone and power networks get quite close to this reliability. I've had less than 30 minutes combined downtime in my life.
How would you know? Or at least, how would I know? If, back in the POTS day, the exchange went down half the night, I wouldn't have noticed.
Nowadays, you can look into your router logs. And Telekom had serious issues with their VoIP stuff.
Likewise, even the apparently planned outages at my previous location exceeded the 30 minutes. (It's still good, but not that good.)
Nowadays, you can look into your router logs. And Telekom had serious issues with their VoIP stuff.
Likewise, even the apparently planned outages at my previous location exceeded the 30 minutes. (It's still good, but not that good.)
> Likewise, even the apparently planned outages at my previous location exceeded the 30 minutes. (It's still good, but not that good.)
Yeah, they're starting to do maintenance here now, too (for introducing the 500/200mbps VDSL2), but I've never been with Telekom, and my existing ISPs never had real issues.
Yeah, they're starting to do maintenance here now, too (for introducing the 500/200mbps VDSL2), but I've never been with Telekom, and my existing ISPs never had real issues.
To properly measure that you'd have to be constantly trying to use the phone (and power network) that entire time though no? I.e. Your random sample is not representative of when the service was actually available?
I'd just have to be constantly using the network, yes.
As I have a computer constantly connected to a server via SSH, and have to manually reconnect whenever it fails, I'd think I'd notice.
As I have a computer constantly connected to a server via SSH, and have to manually reconnect whenever it fails, I'd think I'd notice.
[deleted]
The PSTN and similar systems do target five-9s, but fortunately that only requires keeping it to ~20 minutes downtime over 4 years. ~20 minutes over 40 years would be six-9s.
(* 1e-5 365.2425 24 60 4) => 21.038
(* 1e-6 365.2425 24 60 40) => 21.038Data durability - the probably that your data is not lost.
FWIW Amazon make a similar claim of 11 9s for data durability on S3: https://aws.amazon.com/s3/faqs/
FWIW Amazon make a similar claim of 11 9s for data durability on S3: https://aws.amazon.com/s3/faqs/
reliability != durability. The article separately mentioned reliability/durability -
"Go reliability and durability at Dropbox" "Dropbox hires engineers who care about reliability and durability"
for S3, in your link, there is very clear definition of the claimed durability, there is no similar definition in that dropbox article -
"(S3) designed to provide 99.999999999% durability of objects over a given year. This durability level corresponds to an average annual expected loss of 0.000000001% of objects."
"Go reliability and durability at Dropbox" "Dropbox hires engineers who care about reliability and durability"
for S3, in your link, there is very clear definition of the claimed durability, there is no similar definition in that dropbox article -
"(S3) designed to provide 99.999999999% durability of objects over a given year. This durability level corresponds to an average annual expected loss of 0.000000001% of objects."
Sure, that is a web page describing their product, the Dropbox one is a blog post primarily discussing a somewhat different topic.
The next bullet point is availability, so presumably they mean reliability in the sense that you won't permanently lose data?
I feel like they mean resiliency, not reliability. I could see 12x 9's resiliency with them factoring it based on x amount of data stored for y days. There's 0 chance they could claim that level of reliability for the reasons you mentioned among others.
> What does "Reliability of 99.9999999999% (twelve 9s)" even mean?
Sort of worst case: what it could mean is that every hour, the system reboots and this process takes 10^-12 of an hour, which doesn't seem like much, but you'd have to restart your client as well, which may take longer and is annoying, and you could lose data. So basically, the system would be useless :)
Sort of worst case: what it could mean is that every hour, the system reboots and this process takes 10^-12 of an hour, which doesn't seem like much, but you'd have to restart your client as well, which may take longer and is annoying, and you could lose data. So basically, the system would be useless :)
Here's the actual video: https://youtu.be/5doOcaMXx08
> It’s easy to be productive in Go.
Hum, I'm not sure what this means. Is it saying go is a productice language, or just that you'll master go quickly and reach peek go productivity quickly?
Hum, I'm not sure what this means. Is it saying go is a productice language, or just that you'll master go quickly and reach peek go productivity quickly?
Both, really. Go's so small you can be quite proficient with in months. While it's not as productive as, say, Python (wrt how quickly you can get your code up and running) it's much quicker than other languages (and nicer to use in the long run).
> While it's not as productive as, say, Python (wrt how quickly you can get your code up and running) it's much quicker than other languages (and nicer to use in the long run).
I can see that an experienced Go developer would be more productive than an experienced C developer. But, based on my experience of writing Go, i can't see how they could be more productive an experienced developer in any other current mainstream(ish) language - by which i suppose i mean Python, Ruby, Java, Scala, Kotlin, and (modern) C++. Go's great strength is how fast it is to get up to speed with, not how productive it is once you are.
I can see that an experienced Go developer would be more productive than an experienced C developer. But, based on my experience of writing Go, i can't see how they could be more productive an experienced developer in any other current mainstream(ish) language - by which i suppose i mean Python, Ruby, Java, Scala, Kotlin, and (modern) C++. Go's great strength is how fast it is to get up to speed with, not how productive it is once you are.
I would argue that it has the potential to be more product than some dynamic languages. Not trying to start a pissing contest, to be clear.
Some languages have a lot of mental overhead (JavaScript being an easy example), which I don't think matters how seasoned you are - I think it's pretty much a constant in that language. So even if you're a seasoned developer, I think it's very possible that there are other languages which are objectively more productive for seasoned developers.
So, which languages Go is more productive than is not something I can say - but I think it's a quantifiable thing. There is a nice middle ground between rigid safety of something like Rust, and careless abandon of some extremely dynamic languages. Go has a nice middle ground, but whether it's the "perfect" spot I'm not sure. Hell, I'm not even willing to say it's objectively more productive than X languages.
I will say that for me, personally, it's far more productive than JavaScript (Node) or Python. I can whack out more code in Python, faster, but any moderately sized project starts to run into maintenance overhead, and then suddenly I wish I was in a more rigid language. Middleground is good here, I think.
Though, I will say that if a language like Python gets some nice typing tools like they're working on - especially behavior based typing like Go's interfaces, Rust's Traits, etc - I think that language could really shine for larger projects. Prototyping speed and maintainability is a big boon.
Some languages have a lot of mental overhead (JavaScript being an easy example), which I don't think matters how seasoned you are - I think it's pretty much a constant in that language. So even if you're a seasoned developer, I think it's very possible that there are other languages which are objectively more productive for seasoned developers.
So, which languages Go is more productive than is not something I can say - but I think it's a quantifiable thing. There is a nice middle ground between rigid safety of something like Rust, and careless abandon of some extremely dynamic languages. Go has a nice middle ground, but whether it's the "perfect" spot I'm not sure. Hell, I'm not even willing to say it's objectively more productive than X languages.
I will say that for me, personally, it's far more productive than JavaScript (Node) or Python. I can whack out more code in Python, faster, but any moderately sized project starts to run into maintenance overhead, and then suddenly I wish I was in a more rigid language. Middleground is good here, I think.
Though, I will say that if a language like Python gets some nice typing tools like they're working on - especially behavior based typing like Go's interfaces, Rust's Traits, etc - I think that language could really shine for larger projects. Prototyping speed and maintainability is a big boon.
There's more to productivity than how many 1-line koans can I type per minute. I know I'm caricaturing other languages here a lot (and perhaps unfairly), but one of the more productive things about Go is the low amount of magic the next guy/gal after you will need to comprehend to do the next thing.
Style and maintainability still falls on the programmer, but Go code never "feels right" unless it's done neatly with as little magic as possible. I think that property is super beneficial in keeping a large and growing team/codebase effective and malleable enough.
Style and maintainability still falls on the programmer, but Go code never "feels right" unless it's done neatly with as little magic as possible. I think that property is super beneficial in keeping a large and growing team/codebase effective and malleable enough.
> i can't see how they could be more productive an experienced developer in any other current mainstream(ish) language
Others mentioned overhead which is a big issue. Because Go is so simple the mental overhead of remembering how to do stuff, edge cases, etc. is much smaller than other languages. Sure, a Go dev and a Java dev can be just as productive in their respective languages. But as somebody who has to switch back and forth between Go, JS/TS, PHP, and Java Go is by far the easiest language to switch back to.
Others mentioned overhead which is a big issue. Because Go is so simple the mental overhead of remembering how to do stuff, edge cases, etc. is much smaller than other languages. Sure, a Go dev and a Java dev can be just as productive in their respective languages. But as somebody who has to switch back and forth between Go, JS/TS, PHP, and Java Go is by far the easiest language to switch back to.
I disagree slightly. The problem with Python is that it may be quick and easy to cobble together something that does what you want, but it is a pain in the ass for someone else to install and use.
There is no shortcut where you can produce and distribute a binary so every damn user of your program will have to deal with Python versioning, installing dependencies etc.
So for the user, Python is not productive. It is time-consuming and bothersome.
There is no shortcut where you can produce and distribute a binary so every damn user of your program will have to deal with Python versioning, installing dependencies etc.
So for the user, Python is not productive. It is time-consuming and bothersome.
> wrt how quickly you can get your code up and running
Why is this such a huge benefit for code that typically works at the system level? Wouldn't you value reliability, consistency, etc when adapting system level functions over speed to deployment?
Why is this such a huge benefit for code that typically works at the system level? Wouldn't you value reliability, consistency, etc when adapting system level functions over speed to deployment?
When I wrote my comment I was thinking more about prototyping: after I sketch a design on paper or with UML diagrams I want to write a quick prototype. Go allows me to be able to quickly and easily sketch out a design with the added benefit that it's the language the actual application will be written in.
> months
? Go is tiny. The tutorial takes an afternoon. A C programmer will be profecient within days.
? Go is tiny. The tutorial takes an afternoon. A C programmer will be profecient within days.
They may learn the language in days but not the standard library. That's always what takes the most time.
I agree. And may I add the ecosystem: which third party modules you should or shouldn't be looking at, and if you should rely on them or roll your own.
Then months for best practices, idioms, and understanding the pitfalls around concurrency and channels, which are nowhere near as "batteries-included" as people would lead you to believe.
This "hype" around go letting you be productive sooner is honestly just bullshit. I've been programming for 20 years, with C, C++, Ruby, Perl, Scheme, Haskell, Rust, Go, Java, and others I've surely forgot. Sure, I was able to start writing go within a day. But it was terrible go, and months later I was still dealing with the consequences of early bad decisions.
This isn't unique to go by any means. But if you go in thinking you're going to write a project that does some sort of non-trivial task and be able to rely on that later, you're going to have a bad time.
This "hype" around go letting you be productive sooner is honestly just bullshit. I've been programming for 20 years, with C, C++, Ruby, Perl, Scheme, Haskell, Rust, Go, Java, and others I've surely forgot. Sure, I was able to start writing go within a day. But it was terrible go, and months later I was still dealing with the consequences of early bad decisions.
This isn't unique to go by any means. But if you go in thinking you're going to write a project that does some sort of non-trivial task and be able to rely on that later, you're going to have a bad time.
Hi! Thanks for replying with this useful information! (I'm just excited to have it - I don't work on Go or anything.)
You refer to:
>best practices, idioms, and understanding the pitfalls around concurrency and channels, which are nowhere near as "batteries-included" as people would lead you to believe.
Could you summarize these?
You wrote:
>Sure, I was able to start writing go within a day
If you could send back in time a brief note to yourself to prevent
>months later I was still dealing with the consequences of early bad decisions.
then what would you write? You can include links that the "day 1" version of you should have followed, or simply warnings.
I would be highly interested in more information on the above, from you or anyone else here.
Thanks so much!
You refer to:
>best practices, idioms, and understanding the pitfalls around concurrency and channels, which are nowhere near as "batteries-included" as people would lead you to believe.
Could you summarize these?
You wrote:
>Sure, I was able to start writing go within a day
If you could send back in time a brief note to yourself to prevent
>months later I was still dealing with the consequences of early bad decisions.
then what would you write? You can include links that the "day 1" version of you should have followed, or simply warnings.
I would be highly interested in more information on the above, from you or anyone else here.
Thanks so much!
But that's true with all those languages too. If you're an experienced Java programmer moving to Rust, you'll write Java in Rust.
So it's 1 day of learning Go + 1 month of learning style vs 2 weeks of learning Rust + 1 month of learning style. [1]
[1] Note, I think that Rust has the best community when it comes to getting beginners up to par, whether in #rust-beginners or on /r/rust. It just is a hard and not forgiving language.
So it's 1 day of learning Go + 1 month of learning style vs 2 weeks of learning Rust + 1 month of learning style. [1]
[1] Note, I think that Rust has the best community when it comes to getting beginners up to par, whether in #rust-beginners or on /r/rust. It just is a hard and not forgiving language.
> But that's true with all those languages too.
That is exactly my point, and I said as much in my post.
> So it's 1 day of learning Go + 1 month of learning style vs 2 weeks of learning Rust + 1 month of learning style.
More like 1 day vs. 1 week, with six months of ramp-up before you're writing anything approximating production-quality code. At which point, does it really matter that you were able to write garbage in one day rather than seven?
That is exactly my point, and I said as much in my post.
> So it's 1 day of learning Go + 1 month of learning style vs 2 weeks of learning Rust + 1 month of learning style.
More like 1 day vs. 1 week, with six months of ramp-up before you're writing anything approximating production-quality code. At which point, does it really matter that you were able to write garbage in one day rather than seven?
Hi. Could you (or anyone else here!) kindly answer this question:
https://news.ycombinator.com/item?id=14934690
One way to get your correct answer is for me to propose a wrong or partial answer. How is this as a message to the past (i.e. I am guessing your answer to the above request):
WRONG/FAKE ANSWER:
"Note to past self: although you can write code that compiles on day 1 and day 2, before considering your code idiomatic and ready to build on top of (or even deploy to production), DO/LEARN THE FOLLOWING:
1) read and work through all of The Go Programming Language book. This teaches all idioms.
2) Practice and use Go's testing tools (built-in). Always use its reformat tool applied on every save from your IDE.
3) Begin using a better error and logging library than the built-in error passing idiom. Google this.
4) Use a debugger. Google this.
5) Security and versioning with go get is broken: Google this and learn vendoring with versions. Otherwise your code cannot go on production.
6) You control garbage collection frequency. Learn to set this. In emergencies disable it entirely to trade memory for latency to gain one or two milliseconds (approach hard realtime), for example when you are dropping requests. Then reenable when you can take the (very small) hit. Garbage collection is very efficient and low-latency.
7) Channels and concurrency (goroutines) do not work as described. Specifically:
- This link will solve your problems with channels: https://stackoverflow.com/questions/41200505/whats-the-best-...
Adopt it. Then they work as described.
For goroutines:
Follow this document - https://gist.github.com/pzurek/6642797
After incorporating the above specific changes, you are ready to commit to production and build on top of what you want to build.
"
is the above message completely wrong and bullshit? Then please correct it.
Your insight and experience are appreciated and I would love to read what you would write as a message to yourself in the past, to save those lost months. Thank you.
https://news.ycombinator.com/item?id=14934690
One way to get your correct answer is for me to propose a wrong or partial answer. How is this as a message to the past (i.e. I am guessing your answer to the above request):
WRONG/FAKE ANSWER:
"Note to past self: although you can write code that compiles on day 1 and day 2, before considering your code idiomatic and ready to build on top of (or even deploy to production), DO/LEARN THE FOLLOWING:
1) read and work through all of The Go Programming Language book. This teaches all idioms.
2) Practice and use Go's testing tools (built-in). Always use its reformat tool applied on every save from your IDE.
3) Begin using a better error and logging library than the built-in error passing idiom. Google this.
4) Use a debugger. Google this.
5) Security and versioning with go get is broken: Google this and learn vendoring with versions. Otherwise your code cannot go on production.
6) You control garbage collection frequency. Learn to set this. In emergencies disable it entirely to trade memory for latency to gain one or two milliseconds (approach hard realtime), for example when you are dropping requests. Then reenable when you can take the (very small) hit. Garbage collection is very efficient and low-latency.
7) Channels and concurrency (goroutines) do not work as described. Specifically:
- This link will solve your problems with channels: https://stackoverflow.com/questions/41200505/whats-the-best-...
Adopt it. Then they work as described.
For goroutines:
Follow this document - https://gist.github.com/pzurek/6642797
After incorporating the above specific changes, you are ready to commit to production and build on top of what you want to build.
"
is the above message completely wrong and bullshit? Then please correct it.
Your insight and experience are appreciated and I would love to read what you would write as a message to yourself in the past, to save those lost months. Thank you.
Those months weren't "lost". There's no shortcut to learning idioms, best practices, and — more importantly — understanding the most natural way to model a solution in whatever language you're working with.
Sure, read books and blog posts. Test things. Learn debugging tools. But nothing really substitutes for actually working with a language. Having an experienced mentor helps, but only if they're advising you on why they chose a certain approach, or why a critiqued approach you chose was bad.
Sure, read books and blog posts. Test things. Learn debugging tools. But nothing really substitutes for actually working with a language. Having an experienced mentor helps, but only if they're advising you on why they chose a certain approach, or why a critiqued approach you chose was bad.
Essentially I am asking you to be that mentor (to your past self) and share the email you could write, specific to YOUR particular coding that you were doing. Think a mentor should include "why"? Then include why.
Remember: I didn't ask for a shortcut, I asked for specific sentences that you could have sent back in time to prevent this:
>months later I was still dealing with the consequences of early bad decisions.
Your sentences can be literally anything, specific to your specific situation, that could have prevented those bad decisions.
So, let's be clear. Your message to the past you reads:
"Hi - I am you from the future. I was asked to send back a message in time listing specific things you can do right now, having just learned Go, based on my having to deal with your code, that can prevent your bad decisions which you will be dealing with months later. It is impossible to put this into English words. So, I have no advice for you of any kind. Fuck you, past-me. And also fuck me - I'll just have to deal with your lack of understanding. I hope you have found this mentoring by me to be as helpful as I have. I don't believe in mentoring."
So, that's the new version of your message, based on your review of your own code and memory of your decisions and learning process at the time.
Well, okay. I guess I accept your viewpoint. (Note: if there's some other reason you don't want to answer publicly, such as not talking about your codebase, you can email me at the email in my profile.)
I am looking for specific architectural advice, using your experience as a case study.
Remember: I didn't ask for a shortcut, I asked for specific sentences that you could have sent back in time to prevent this:
>months later I was still dealing with the consequences of early bad decisions.
Your sentences can be literally anything, specific to your specific situation, that could have prevented those bad decisions.
So, let's be clear. Your message to the past you reads:
"Hi - I am you from the future. I was asked to send back a message in time listing specific things you can do right now, having just learned Go, based on my having to deal with your code, that can prevent your bad decisions which you will be dealing with months later. It is impossible to put this into English words. So, I have no advice for you of any kind. Fuck you, past-me. And also fuck me - I'll just have to deal with your lack of understanding. I hope you have found this mentoring by me to be as helpful as I have. I don't believe in mentoring."
So, that's the new version of your message, based on your review of your own code and memory of your decisions and learning process at the time.
Well, okay. I guess I accept your viewpoint. (Note: if there's some other reason you don't want to answer publicly, such as not talking about your codebase, you can email me at the email in my profile.)
I am looking for specific architectural advice, using your experience as a case study.
It will take a week at most, to figure out what libraries you will need, if you have programmed before in any language.
Yes, however, the concepts that are used to construct Go libraries are very simple. So it is still pretty quick and easy to learn Go.
I agree "months" seems too long, but "days" seems too short to me.
Learning the keywords and basic Go syntax is simple, so in that sense days fits, but a C (or C++) programmer is probably also going to be writing unidiomatic Go code, falling back to unsafe too much, trying to recreate OOP with some kind of wonky self-rolled inheritance system, etc, for a few weeks before they really "get it".
Learning the keywords and basic Go syntax is simple, so in that sense days fits, but a C (or C++) programmer is probably also going to be writing unidiomatic Go code, falling back to unsafe too much, trying to recreate OOP with some kind of wonky self-rolled inheritance system, etc, for a few weeks before they really "get it".
That doesn’t mean you’ll know idiomatic to (which isn’t the same as C), know the tooling, ecosystem, etc. It does take months to be proficient.
What do you base this on? Got some data to share?
> What do you base this on?
Experience?
One does not get 'proficient' in a week in any given language. One can build up a program in a new language in a week, but that does not mean proficiency. It takes between many months and a few year to become proficient in a language: it is the outcome of a process of exploration, trials, mistakes, discoveries of better or more adapted ways, finding out the shortcomings an learning to work around them, picking a right balance between ease to write and ease to read, ease to write and performance...
Experience?
One does not get 'proficient' in a week in any given language. One can build up a program in a new language in a week, but that does not mean proficiency. It takes between many months and a few year to become proficient in a language: it is the outcome of a process of exploration, trials, mistakes, discoveries of better or more adapted ways, finding out the shortcomings an learning to work around them, picking a right balance between ease to write and ease to read, ease to write and performance...
So, in other words, anecdotal evidence.
So let's quantify what "proficient" means. How would you measure of someone is proficient in a programming language?
So let's quantify what "proficient" means. How would you measure of someone is proficient in a programming language?
Proficient doesn't mean expert. It takes about 6 weeks to get proficient.
>The tutorial takes an afternoon. A C programmer will be proficient within days.
Hi! (I got a downvote but this is serious - I believe you!)
Thanks for this useful information. Could I ask you (or anyone else) to write maybe a checklist of links/resources or steps a programmer could go through?
Thank you again!
Hi! (I got a downvote but this is serious - I believe you!)
Thanks for this useful information. Could I ask you (or anyone else) to write maybe a checklist of links/resources or steps a programmer could go through?
Thank you again!
Try out in order
* tour.golang.org
* gobyexample.com
* The Go programming language book. (If you're a C programmer, one of the authors might be familiar to you)
Personally I got hooked when I saw a talk by Andrew Gerrand where he created a working chat server in about 30 lines of code. I'd recommend this after gobyexample just to get a taste of what's possible - https://talks.golang.org/2012/chat.slide
I hope you enjoy it :)
* tour.golang.org
* gobyexample.com
* The Go programming language book. (If you're a C programmer, one of the authors might be familiar to you)
Personally I got hooked when I saw a talk by Andrew Gerrand where he created a working chat server in about 30 lines of code. I'd recommend this after gobyexample just to get a taste of what's possible - https://talks.golang.org/2012/chat.slide
I hope you enjoy it :)
Thank you. This is exactly what I was hoping for - thanks so much for your reply!
I think it's only slightly ambiguous. It doesn't seem to be making a claim about mastering go or peak go productivity. It just says it's easy to be productive (not maximally productive, just "productive"). Which seems to be borne out by the huge amount of new code written in go just in the past few years.
Go is a very productive language in several senses in my eyes. It is a language you can master quickly, and it is a very productive language in day to day work. There it is important to consider the overall productivity. There are certainly languages, which allow you to implement something a little bit quicker, but you have to consider also the effort of maintaining and further extending a program. For long-term maintenance, Go especially shines. It is easy to come back to some software and pick up modifying it again, and also when there are properly set up packages, Go software tends to be maintainable and extendable.
I find it also interesting that they only have 1.3M loc of Go given the 15+ teams and hundreds of engineers. I would expect this number to be at least 10x larger. They either still use a lot of Python or other languages or are very efficient at reusing code.
Oh, I thought Dropbox was using Rust instead of Go for a lot of things, but maybe they ended up using both. I can see why they'd have wanted to be just moving to either Rust or Go since from what I understand they used to be mostly Python for everything.
Cool that they use Go a lot.
Cool that they use Go a lot.
Last I checked, server-side Rust usage at Dropbox is reserved for the very bottom of the stack, for the bits that are performance-sensitive enough that the alternative would have demanded they be written in C++. Apparently there's a significant amount of Rust in Dropbox's Windows client as well, though I don't know the story there...
We're making a pretty big bet on Rust in the client (if you'd call it a bet, I don't see a scenario where we walk this back). The majority of new Sync code in the client (read: not UI) is being written in Rust and it's been a blast so far, not to mention much easier to reason about correctness which is really what we care about.
(something something we're hiring)
(something something we're hiring)
So does this means that the talks at CppCon are now invalidated and future uses of Djini will see Rust support?
Here is a talk by Jamie Turner of Dropbox about where Rust is used: https://air.mozilla.org/rust-meetup-may-2017/
(I work at Dropbox)
(I work at Dropbox)
Easier to go from python to go than to rust.
How so? You can extend Python with Rust but you can't with Go. Go requires a complete rewrite or independent service.
You can write go with the same loose nature of Python. Conceptually you can write programs the same and get some speed boost + type checking while you're at it.
It's like a more intense form of adding annotations in theory.
So while it requires a rewrite, a cost which you should not write off either, it can feel similar to Python but more verbose. Where Rust feels like Haskell and C++ had a child together and can be more jarring to switch to (in my experience as primarily Python/Django who uses Go in many side projects and tried Rust up-to and around 1.0).
It's like a more intense form of adding annotations in theory.
So while it requires a rewrite, a cost which you should not write off either, it can feel similar to Python but more verbose. Where Rust feels like Haskell and C++ had a child together and can be more jarring to switch to (in my experience as primarily Python/Django who uses Go in many side projects and tried Rust up-to and around 1.0).
Thanks for commenting. I think I took the statement too literally. If I understand you correctly, the transition from Python to Go is easier because learning/using Go requires less cognitive overhead than what is required of Python to Rust.
Go and Rust are not competing for same space. They are different language for different purposes.
Sure they can be. Rust just isn't able to compete in some areas where Go is objectively easier and better, but they're areas which can be fixed with improved documentation, training, and libraries.
YMMV, but I think people just want something fast, productive, and safe by default. Normally you had to pick just two, but Go gives you 2.5 (Not as safe as it "could be") and Rust only gives you 2 right now (Not as productive, libraries too immature), but it is on it's way to giving all 3 as soon as libraries gain maturity.
YMMV, but I think people just want something fast, productive, and safe by default. Normally you had to pick just two, but Go gives you 2.5 (Not as safe as it "could be") and Rust only gives you 2 right now (Not as productive, libraries too immature), but it is on it's way to giving all 3 as soon as libraries gain maturity.
Rust is multi-purpose, and with improved tooling and a little more maturity (Rust 2.0) I can see it getting all the (network/server) systems and command line stuff Go does.
(But not vice versa: Go wont be able to handle the no-GC close-to-the-metal use cases).
(But not vice versa: Go wont be able to handle the no-GC close-to-the-metal use cases).
Rust is great, but to be honest, Rust's learning curve is way steeper than GO's. And this may slow down the Rust's domination.
I think the things Rust has had to sacrifice on the altar of zero-cost abstraction (mostly, garbage collection) mean that it will always be harder to use than Go.
The orthogonal fact that it's a much richer language also means that it will always be harder to learn, so Go has advantage in the niche of beginners' language, or second language, particularly for people who mainly work in an untyped language, and so don't already have type system instincts to lean on.
The orthogonal fact that it's a much richer language also means that it will always be harder to learn, so Go has advantage in the niche of beginners' language, or second language, particularly for people who mainly work in an untyped language, and so don't already have type system instincts to lean on.
I have an off-topic question: This is the second company (after GitLab) I see with an “about” subdomain. Is this a new trend of using “about.x.com” for the marketing website and “x.com” for the web app? Is there a blog post or discussion about this?
At GitLab we first used www dot the marketing site and the apex for the app but many people assumed they would have the same content. That is why we introduced about. Cool to see we might have started a trend.
Wow, never noticed that. When did you change? It would have confused me so much.
Browsers are thankfully highlighting the https-verified part of the URL (hostname) relative to the rest, so that a "paypal.com.fake.com" phishing attack is easier to spot. It was just a matter of time before UX people would put that highlighting to creative use. I like it.
On the technological side, I guess separate hostnames might make some ops things a little easier. But that alone can hardly be the reason. Easier and good looks can. Also: In a large scale outage, an about.x.com that is not running on your main cloud provider could be valuable for status updates, because far more people would know about about.x.com than about some status.x.com you might have if your "about" content was on the main hostname.
On the technological side, I guess separate hostnames might make some ops things a little easier. But that alone can hardly be the reason. Easier and good looks can. Also: In a large scale outage, an about.x.com that is not running on your main cloud provider could be valuable for status updates, because far more people would know about about.x.com than about some status.x.com you might have if your "about" content was on the main hostname.
I don't see this highlighting in the latest Chrome (60.0.3something, I just updated it).
Is there a specific flag to enable ?
Is there a specific flag to enable ?
Firefox and Safari also have it on Desktop: https://i.imgur.com/6lDFgIp.png
Ah! I see it. I expected something much more obvious.
And I expected something which includes the subdomain part in the highlighting. Doing a little "TN-display dance" I see that Chrome highlights news.ycombinator.com, whereas Firefox only highlights ycombinator.com which kind of undermines my point (and seems slightly wrong to me, as this seems to be a certificate for the exact third level domain, not a wildcard under the second level).
I think it might be a mobile-only thing.
In addition to it hurting SEO
Anyone know where in the talk it has the mention of "Debugging tools (mostly!) work well"?
I'm skipping back and forwards through it, but the talk isn't in the same order as this article which is making it very difficult without watching the whole talk from start -> end.
Asking because debugging is a pain point I've been having with Go for a few months, so am surprised to see it described as mostly working well. I'd like to get my debugging experiences to at least that level of "(mostly) working well". :D
I'm skipping back and forwards through it, but the talk isn't in the same order as this article which is making it very difficult without watching the whole talk from start -> end.
Asking because debugging is a pain point I've been having with Go for a few months, so am surprised to see it described as mostly working well. I'd like to get my debugging experiences to at least that level of "(mostly) working well". :D
What are you having trouble debug? Or what do you think isn't working well for you?
The two main problems are:
a) Pretty much any platform other Linux doesn't seem to work (for debugging). ;)
b) Breakpoints occasionally not firing even when running Linux (Fedora 25 in this case)
This is with CGO enabled code, which isn't optional as it's from the libraries we use (no choice).
Using Delve for debugging (though Gogland atm), as we're not yet in production.
Fairly worried about how things will er... go ;) in prod though when we get to rolling things out.
With Delve, it's apparently the state of the art with Go debugging. If something else actually works reliably though, I'm happy to try it. :)
a) Pretty much any platform other Linux doesn't seem to work (for debugging). ;)
b) Breakpoints occasionally not firing even when running Linux (Fedora 25 in this case)
This is with CGO enabled code, which isn't optional as it's from the libraries we use (no choice).
Using Delve for debugging (though Gogland atm), as we're not yet in production.
Fairly worried about how things will er... go ;) in prod though when we get to rolling things out.
With Delve, it's apparently the state of the art with Go debugging. If something else actually works reliably though, I'm happy to try it. :)
> The biggest pain with Go that Tammy identified was in dealing with race conditions.
> Data races are the hardest type of bug to debug, spot, fix, etc.
Exactly what Rust aims at preventing. Sad to see that the industry is not learning.
> Data races are the hardest type of bug to debug, spot, fix, etc.
Exactly what Rust aims at preventing. Sad to see that the industry is not learning.
> Sad to see that the industry is not learning.
Sad that Rust advocates are not learning. This sort of comment is what drives people away from Rust. Stop ramming your stuff down other people's throats. Go build that exclusively Rust based Dropbox clone that outperforms Dropbox and show how well Rust performs in that situation.
Rust has trade-offs just like Go has trade-offs. Being honest about the deficiencies of ones chosen platform is a good thing, it helps to keep you sharp and to avoid problems associated with those deficiencies.
Besides having an over-zealous community that posts off-topic comments all over threads that have nothing to do with Rust, Rust has deficiencies too.
Note also that Dropbox is already using Rust in some places.
Sad that Rust advocates are not learning. This sort of comment is what drives people away from Rust. Stop ramming your stuff down other people's throats. Go build that exclusively Rust based Dropbox clone that outperforms Dropbox and show how well Rust performs in that situation.
Rust has trade-offs just like Go has trade-offs. Being honest about the deficiencies of ones chosen platform is a good thing, it helps to keep you sharp and to avoid problems associated with those deficiencies.
Besides having an over-zealous community that posts off-topic comments all over threads that have nothing to do with Rust, Rust has deficiencies too.
Note also that Dropbox is already using Rust in some places.
Not to condone the grandparent's zealotry, but the article does mention Rust by name, Dropbox is using Rust, and preventing data races is one of Rust's two raisons d'être. It's not off-topic in the least. There's no need to stoop to zealotry yourself in order to fight zealotry.
I think I covered that.
Is it off-topic though? Go has warts and is plagued by poor design decisions, just like most software. I think it is worth mentioning those, and offering recommendations that don't have those issues, so people can make the best technical decisions when choosing a stack for their projects. It also may help Go maintainers in fixing legitimate complaints in Go, thus making it better. I've never used Rust, but I have used Go, and found certain things about it unappealing, so I'm interested in this information, and I'm also interested in Go improving.
> Stop ramming your stuff down other people's throats.
Pointing out your preferred language addresses one of the hardest problems in another language qualifies as "ramming your stuff down other people's throats"?
I find that hard to believe.
Pointing out your preferred language addresses one of the hardest problems in another language qualifies as "ramming your stuff down other people's throats"?
I find that hard to believe.
Repeatedly, incessantly, whereever there is the slightest link yes, that qualifies as ramming down your stuff down other people's throats.
I really don't think I'm the only person noticing Rust fans being a little - to put it mildly - overzealous when it comes to this. I do not see the proponents of any other language doing the same thing.
I really don't think I'm the only person noticing Rust fans being a little - to put it mildly - overzealous when it comes to this. I do not see the proponents of any other language doing the same thing.
Does rust gurantee data race free code?
This explains pretty well: https://doc.rust-lang.org/beta/nomicon/races.html
Yes, if you stick to safe Rust.
Yeah, Go has the worst possible model for concurrency there is - shared memory multithreading. Hopefully more and more companies will realize how bad this model really is and start looking into languages with decent concurrency models, like Erlang and Elixir or at least stick to event loops.
I give you Python and Ruby as worse - shared memory and an interpreter lock to limit concurrent operations.
That said, Go is the best of the C-style concurrency breed; having typed message passing and green threads built into the language.
That said, Go is the best of the C-style concurrency breed; having typed message passing and green threads built into the language.
The worst possible model? Oh my dear fellow, not even close:
http://catb.org/esr/intercal/ick.htm#Multithreading-using-CO...
http://catb.org/esr/intercal/ick.htm#Multithreading-using-CO...
My favorite is still the multithreaded apartment model...
https://blogs.msdn.microsoft.com/larryosterman/2004/04/28/wh...
https://blogs.msdn.microsoft.com/larryosterman/2004/04/28/wh...
That is exactly why I use Erlang and Elixir, and not Go. Also, Go processes are 10 times the size of those in Elixir.
What are you measuring? Memory use?
What a terrible article.
I think that is, in part, because it's a summary of a talk. So it's written a bit awkwardly and probably misses maybe some more interesting in-depth details from the actual talk. It does seem on the surface though like potentially a good text summary, having not watched the actual talk.
On the flip side, I have been frustrated particularly at linux.conf.au last year at how "not deep" many of the talks were. Having done quite a few talks over many years at similar conferences, it's actually quite hard to nail something technical and be entertaining for a presentation at the same time. Someone who nails that quite consistently is Aaron Paterson (from the Ruby/Rails world). Watch some of his talks on Youtube.. I aspire to produce more content on a level similar to his. To combine good entertaining presentation with actually educating an audience about the technical non-obvious details of something they probably didn't know -- and something that was relevant in a practical project he took on. Working on it, not there yet...
On the flip side, I have been frustrated particularly at linux.conf.au last year at how "not deep" many of the talks were. Having done quite a few talks over many years at similar conferences, it's actually quite hard to nail something technical and be entertaining for a presentation at the same time. Someone who nails that quite consistently is Aaron Paterson (from the Ruby/Rails world). Watch some of his talks on Youtube.. I aspire to produce more content on a level similar to his. To combine good entertaining presentation with actually educating an audience about the technical non-obvious details of something they probably didn't know -- and something that was relevant in a practical project he took on. Working on it, not there yet...
>This post was best-effort live-blogged at the conference
Cut them some slack.
Cut them some slack.
To promote their own service. While the actual talk will probably be actually posted online in multiple forms.
> She talked at GopherCon 2017 about
Ya'll too young to remember OG Gopher https://en.wikipedia.org/wiki/Gopher_(protocol)
Ya'll too young to remember OG Gopher https://en.wikipedia.org/wiki/Gopher_(protocol)
For comparison, public telephony systems aimed for five 9s. That was usually expressed as "20 minutes downtime over 40 years, combined hardware and software budget, for outages affecting more than 32 users." One software crash requiring human intervention would count for more than 20 minutes, so you were allowed <1 of these in 40 years system lifetime.