Google Cloud Platform and near-perfect documentation
-
GCP gives out 300$ free credits for 12 months. That's a lot of credits to do a lot of shit. I was looking at GCP to see if I could use this for my projects and at work.
Off the bat, the documentation throws random 404's.
Also, the tutorials are scattered af. There are pages where the search functionality won't work and sometimes the documentation is written like the end user is supposed to know everything already.
Okay, so
-
Google Cloud Documentation
Comprehensive documentation, guides, and resources for Google Cloud products and services.
-
Click on Browse Tutorials and Architectures.
-
Broken. Search won't work. searching for the term they ask you to try does not fucking work.
What the fuck is up with this shit? There are so many fuckups here and I need to get some sleep before I implode. Wasted 3 fuckin hours over this.
How come a company that is so huge cannot throw some money at a motherfucker to write good documentation. The docs are sooooooo bad. AWS and Azure docs seem like heaven after looking at this piece of shit.
-
-
@stillwater said in Google Cloud Platform and near-perfect documentation:
How come a company that is so huge cannot throw some money at a motherfucker to write good documentation. The docs are sooooooo bad. AWS and Azure docs seem like heaven after looking at this piece of shit.
Let's compare apples to apples, shall we?
-
@ben_lubar said in Google Cloud Platform and near-perfect documentation:
@stillwater said in Google Cloud Platform and near-perfect documentation:
How come a company that is so huge cannot throw some money at a motherfucker to write good documentation. The docs are sooooooo bad. AWS and Azure docs seem like heaven after looking at this piece of shit.
Let's compare apples to apples, shall we?
Literally unusable.
-
These hurt my brain.
-
@stillwater said in Google Cloud Platform and near-perfect documentation:
Click on Browse Tutorials and Architectures.
Broken. Search won't work. searching for the term they ask you to try does not fucking work.In all fairness, if that happened on a Microsoft site, it wouldn't even be worth a thread.
-
@anonymous234 said in Google Cloud Platform and near-perfect documentation:
@stillwater said in Google Cloud Platform and near-perfect documentation:
Click on Browse Tutorials and Architectures.
Broken. Search won't work. searching for the term they ask you to try does not fucking work.In all fairness, if that happened on a Microsoft site, it wouldn't even be worth a thread.
We're all used to it by now and I don't expect anything better from them. But this is literally on the very first page on the tutorial. The likelihood of someone visiting this page for the first time is 100%. What's the point in having that page if the tutorial examples page is broken? Also having a broken tutorial is akin to saying 'we don't give a fuck if you use us or not'.
Maybe I'm TRWTF here for expecting google to take documentation seriously? IIRC the android docs were pretty good for someone starting out.
-
@anonymous234 said in Google Cloud Platform and near-perfect documentation:
@stillwater said in Google Cloud Platform and near-perfect documentation:
Click on Browse Tutorials and Architectures.
Broken. Search won't work. searching for the term they ask you to try does not fucking work.In all fairness, if that happened on a Microsoft site, it wouldn't even be worth a thread.
You can't make a thread about something whose URL changes before you've finished posting.
-
So I've been reading about GCP on the interwebz and quite a lot of people seem to have problems with the docs and the platform itself. It just confuses me when the customers section on the GCP site say they've used GCP to do this do that yadda yadda success money revenue blah blah. How the fuck is that possible? The documentation and the platform is the same for everyone. Does something magical happen when you're an enterprise vs a startup or individual when it comes to dealing with a cloud vendor?
-
@stillwater said in Google Cloud Platform and near-perfect documentation:
Does something magical happen when you're an enterprise vs a startup or individual when it comes to dealing with a cloud vendor?
Support sees $$$ and pays attention to you if you're an enterprise.
-
@stillwater said in Google Cloud Platform and near-perfect documentation:
Does something magical happen when you're an enterprise vs a startup or individual when it comes to dealing with a cloud vendor?
Yes .
- The enterprise people have had experience with similar platforms before, they likely don't even need documentation to figure most of it out.
- The paid workers are told to use GCP first, then they are free to figure out how. It doesn't matter if the documentation is shit, they're not going to get management to change platform for such a detail.
- And of course, Google will help you all the way through if you're a big customer, and that includes fixing any minor bugs you find, like the documentation page being down.
In short, you're a secondary customer they don't care too much about.
-
@anonymous234 said in Google Cloud Platform and near-perfect documentation:
In short, you're a secondary customer they don't care too much about.
-
@stillwater said in Google Cloud Platform and near-perfect documentation:
Broken. Search won't work. searching for the term they ask you to try does not fucking work.
Ok, so one text field is broken on a page with no documentation on it. How does that say anything about the quality of the documentation?
Also, the text box is working today, so whatever problem was there isn't there anymore.
-
@Unperverted-Vixen said in Google Cloud Platform and near-perfect documentation:
@stillwater said in Google Cloud Platform and near-perfect documentation:
Does something magical happen when you're an enterprise vs a startup or individual when it comes to dealing with a cloud vendor?
Support sees $$$ and pays attention to you if you're an enterprise.
Pays attention yes but you still get Enterprise™ support so you're often not much better off.
-
@ben_lubar said in Google Cloud Platform and near-perfect documentation:
Ok, so one text field is broken on a page with no documentation on it.
The entire page is one textbox right in the middle of it. And yes, it is working now. Relieved.
@ben_lubar said in Google Cloud Platform and near-perfect documentation:
How does that say anything about the quality of the documentation?
It does not. Read the rest of my post.
-
@Tsaukpaetra said in Google Cloud Platform and near-perfect documentation:
Literally unusable.
Of course. It's Go.
-
@HardwareGeek said in Google Cloud Platform and near-perfect documentation:
@Tsaukpaetra said in Google Cloud Platform and near-perfect documentation:
Literally unusable.
Of course. It's Go.
Does Go suck that bad? I have no clue what happens in the Go world but startups here are looking for Go devs everywhere. You get a seven course meal and a handjob in your interview if you're a Go dev. It must either be the new shiny thing or must be extremely performant. That seems to be the only explanation.
-
@stillwater Seriously, I don't really know. We like to poke fun at it, mostly because @ben_lubar. In discussions a long time ago, it was said that it had some good ideas and some really bad ones. I don't remember what those ideas are and who said it. I didn't really pay attention, because there is approximately 0.00% chance I will ever need it for my job, and I don't need to learn any new languages (except maybe C#) for hobby projects.
-
@stillwater said in Google Cloud Platform and near-perfect documentation:
@HardwareGeek said in Google Cloud Platform and near-perfect documentation:
@Tsaukpaetra said in Google Cloud Platform and near-perfect documentation:
Literally unusable.
Of course. It's Go.
Does Go suck that bad? I have no clue what happens in the Go world but startups here are looking for Go devs everywhere. You get a seven course meal and a handjob in your interview if you're a Go dev. It must either be the new shiny thing or must be extremely performant. That seems to be the only explanation.
It's... interesting. Interfaces are implemented by having the right methods instead of by having an explicit
implementsstatement, so everything is ducktyped. And aside from arrays and dictionaries, there's no generics (they're trying to change that). I can't say I like the syntax, but that's just me. There's also this strange distinction between null and uninitialized. However it's also very optimized for web backends, because asynchronous programming is heavily integrated into the language and there's almost no overhead to it. There's also no overhead to error handling because Go uses tuples of the result and an error value instead of exceptions.
-
@HardwareGeek said in Google Cloud Platform and near-perfect documentation:
@stillwater Seriously, I don't really know. We like to poke fun at it, mostly because @ben_lubar. In discussions a long time ago, it was said that it had some good ideas and some really bad ones. I don't remember what those ideas are and who said it. I didn't really pay attention, because there is approximately 0.00% chance I will ever need it for my job, and I don't need to learn any new languages (except maybe C#) for hobby projects.
Go is very good, but the inside joke is to assume everything I like is as effective as MilwaukeePC, as simple as Dwarf Fortress, and as user-friendly as lojban.
-
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
There's also this strange distinction between null and uninitialized.
There are no uninitialized values in Go. Every type in Go's standard library and runtime has a zero-value that is a safe default (usually "empty"). Examples include nil channels working like a channel with nobody on the other end, nil collection types acting like empty collections, and the zero value of string being an empty string.
Another nice thing is you never have to worry about returning pointers to local variables. If the compiler can't prove a value won't be accessible after the function returns, the value gets allocated on the heap instead of the stack.
-
@ben_lubar said in Google Cloud Platform and near-perfect documentation:
Another nice thing is you never have to worry about returning pointers to local variables. If the compiler can't prove a value won't be accessible after the function returns, the value gets allocated on the heap instead of the stack.
Because that's, you know, performant.
-
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
@ben_lubar said in Google Cloud Platform and near-perfect documentation:
Another nice thing is you never have to worry about returning pointers to local variables. If the compiler can't prove a value won't be accessible after the function returns, the value gets allocated on the heap instead of the stack.
Because that's, you know, performant.
The converse is also true: Allocating objects that don't escape puts them on the stack.
-
@ben_lubar Does Go solve existing problems with async distributed backend mischief or is it just another language that happens to be made by google? Is it the Angular of server side?
-
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
so everything is ducktyped
I have extremely strong knee-jerk reactions to statements like these. :/
-
@stillwater said in Google Cloud Platform and near-perfect documentation:
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
so everything is ducktyped
I have extremely strong knee-jerk reactions to statements like these. :/
Everything is ducktyped assuming by "ducktyped" you mean "I called a function that takes
io.Readerwith an object of a concrete type that implementsio.Readerand it compiled".
-
@ben_lubar said in Google Cloud Platform and near-perfect documentation:
@stillwater said in Google Cloud Platform and near-perfect documentation:
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
so everything is ducktyped
I have extremely strong knee-jerk reactions to statements like these. :/
Everything is ducktyped assuming by "ducktyped" you mean "I called a function that takes
io.Readerwith an object of a concrete type that implementsio.Readerand it compiled".No. The duck-typing is when anything with the correct method counts as an instance of an interface containing that method.
-
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
@ben_lubar said in Google Cloud Platform and near-perfect documentation:
@stillwater said in Google Cloud Platform and near-perfect documentation:
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
so everything is ducktyped
I have extremely strong knee-jerk reactions to statements like these. :/
Everything is ducktyped assuming by "ducktyped" you mean "I called a function that takes
io.Readerwith an object of a concrete type that implementsio.Readerand it compiled".No. The duck-typing is when anything with the correct method counts as an instance of an interface containing that method.
How exactly do you think the object gets there? It's not like JavaScript where you can just pass whatever bullshit you want to any function.
-
@ben_lubar said in Google Cloud Platform and near-perfect documentation:
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
@ben_lubar said in Google Cloud Platform and near-perfect documentation:
Another nice thing is you never have to worry about returning pointers to local variables. If the compiler can't prove a value won't be accessible after the function returns, the value gets allocated on the heap instead of the stack.
Because that's, you know, performant.
The converse is also true: Allocating objects that don't escape puts them on the stack.
That's stupid. You should have control over that. Even if it's very simple (e.g.
box xto put x on the heap in Rust), it's important to be able to tell where you're allocating something. I want my code to do what I tell it to, when I tell it to.
-
@ben_lubar said in Google Cloud Platform and near-perfect documentation:
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
@ben_lubar said in Google Cloud Platform and near-perfect documentation:
@stillwater said in Google Cloud Platform and near-perfect documentation:
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
so everything is ducktyped
I have extremely strong knee-jerk reactions to statements like these. :/
Everything is ducktyped assuming by "ducktyped" you mean "I called a function that takes
io.Readerwith an object of a concrete type that implementsio.Readerand it compiled".No. The duck-typing is when anything with the correct method counts as an instance of an interface containing that method.
How exactly do you think the object gets there? It's not like JavaScript where you can just pass whatever bullshit you want to any function.
What do you mean how the object gets there? I'm talking about what type a struct can count as, just because it's got certain methods. Types should not simply be method signature constraints; they should have actual meaning.
-
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
it's important to be able to tell where you're allocating something
why? where exactly in memory an object is placed is the most "implementation detail" implementation detail I've ever encountered.
-
@ben_lubar Oh, where it's placed in memory has no effect. Doesn't matter whether it's in the first gigabyte or the sixth. But the stack and the heap are not simply locations; they have completely different allocation procedures and the latter is far slower. Compare C#
List<long>performance to JavaArrayList<Long>with giant insertion and removal quantities, and you'll see the difference from a mile away.
-
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
@ben_lubar Oh, where it's placed in memory has no effect. Doesn't matter whether it's in the first gigabyte or the sixth. But the stack and the heap are not simply locations; they have completely different allocation procedures and the latter is far slower. Compare C#
List<long>performance to JavaArrayList<Long>with giant insertion and removal quantities, and you'll see the difference from a mile away.You do realize Go is not an object-oriented language, right? There's nothing like
java.lang.Longin Go.
-
@ben_lubar You do realize that wasn't actually the point, right? I'm talking about speed of stack vs heap.
-
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
@ben_lubar You do realize that wasn't actually the point, right? I'm talking about speed of stack vs heap.
If you think that Go is going to allocate a billion tiny objects on the heap, perhaps you should rewrite your code to not leak a billion tiny objects.
-
@ben_lubar And you don't know that you should be doing that, because things are implicitly allocated on the heap instead of you having to explicitly specify otherwise, so you don't actually know that it's allocated on the heap without debugging tools. No other language does that. Take the Java route and do it via type coercion, take the Rust route and make a compile error, but do something. Not to mention that I highly doubt that Go's compiler has the sophistication of borrowck/NLL, meaning that false positives are probably frequent.
-
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
@ben_lubar And you don't know that you should be doing that, because things are implicitly allocated on the heap instead of you having to explicitly specify otherwise, so you don't actually know that it's allocated on the heap without debugging tools. No other language does that. Take the Java route and do it via type coercion, take the Rust route and make a compile error, but do something. Not to mention that I highly doubt that Go's compiler has the sophistication of borrowck/NLL, meaning that false positives are probably frequent.
Do you have any idea about what you're talking about or are you just spouting whatever nonsense reasons you can think of to not try Go?
-
@ben_lubar I fully admit there are good things about Go. I can also freely admit that C# and Rust are shit in a lot of ways. That's the difference here. You're spouting whatever reasons you can think of that Go isn't shit, without actually taking the time to check whether they're true. You can't actually accept that there's anything wrong with the language. For example, borrowck has a ton of false positives too - that's why NLL is a thing, and even with NLL complex lifetime math can be a pain in the ass. But when you dodge that with dynamic memory you know you're doing it because you explicitly say 'hey, I'm boxing/garbage collecting/reference counting/celling/etc this value' instead of the compiler doing the Clippy thing except without asking you first.
-
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
You're spouting whatever reasons you can think of that Go isn't shit
which one of us has actually used the Go compiler ever?
-
@ben_lubar Well, if I open PS and type
go, and the Go compiler help page comes up, then I must assume I've used it, because I wouldn't have installed it otherwise.
-
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
@ben_lubar Well, if I open PS and type
go, and the Go compiler help page comes up, then I must assume I've used it, because I wouldn't have installed it otherwise.What does
go versionprint? Let's try to figure out when you installed it.
-
@ben_lubar
go version go1.9 windows/amd64.
Now, can you get back to telling me why using an alternative, slower form of memory without telling the programmer is a good idea?
-
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
There's also no overhead to error handling
That's literally impossible (except with really silly definitions of “overhead”). That the error handling is explicit doesn't make it free; the point where a problem occurs and where its resolution is best done are often not coincident and there is always some sort of cost involved in linking the two together. One of the overheads that is forced upon you with Go's design choices in this area is that you have to write more explicit error handling code than you would in some other languages. It might be a reasonable trade-off, but it's definitely not free. (FWIW, languages that use exceptions can do clever things to optimise the error path that make their use not as expensive as you might think; the key trick is in understanding what is actually observed, not just what is potentially observable by some code that could be written but hasn't been in this case.)
-
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
But the stack and the heap are not simply locations; they have completely different allocation procedures and the latter is far slower.
Sounds like you've never written an actually intelligent stack allocation system. The trick is knowing where the costs actually are. (Usually it's because heaps have to support multithreaded access whereas stacks as per-thread, which forces the use of locking, and that's very much not free.)
-
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
I'm talking about what type a struct can count as, just because it's got certain methods.
That's called a Structural Type System (as opposed to Nominal). It's also used by TypeScript, many FP languages, and C++ templates. It's definitely got upsides and downsides, but you shouldn't dismiss it right away.
-
@DCoder said in Google Cloud Platform and near-perfect documentation:
That's called a Structural Type System (as opposed to Nominal). It's also used by TypeScript, many FP languages, and C++ templates. It's definitely got upsides and downsides, but you shouldn't dismiss it right away.
The main issue with such type schemes is that you don't know whether the concrete type is participating in the protocol encoded by the interface because it has been properly designed to be that way, or whether it's just because it got (un)lucky with the function names. It'd be OK, except that interfaces (for very good reasons) don't constrain the semantics of their functions, just their names and signature types.
-
@dkf said in Google Cloud Platform and near-perfect documentation:
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
But the stack and the heap are not simply locations; they have completely different allocation procedures and the latter is far slower.
Sounds like you've never written an actually intelligent stack allocation system. The trick is knowing where the costs actually are. (Usually it's because heaps have to support multithreaded access whereas stacks as per-thread, which forces the use of locking, and that's very much not free.)
Heaps are way more complicated even if single-threaded. Unless you're using something like an arena, heaps have to support things being freed in an arbitrary order.
-
@topspin said in Google Cloud Platform and near-perfect documentation:
Heaps are way more complicated even if single-threaded.
That depends also on the usage pattern. If everything can be done reasonably efficiently with allocations of a single size (and you've not got too many threading troubles) there's some techniques that work superbly well.
-
@dkf Yes, but that's far from the general case.
-
@topspin said in Google Cloud Platform and near-perfect documentation:
Yes, but that's far from the general case.
I was talking about common cases, not general cases. They're very different!
-
I wouldn't worry about garbage collection pause time.
