The Design of Stanza's Optional Type System - <AUTHOR> http://lbstanza.org/optional_typing.html <comment><USER2> > Unlike current languages, Stanza is neither dynamically- nor statically- > typed, and has instead what we call an optional type system.

Why "optional typing"? It sounds like you are describing "gradual typing". [0] Using the more common term would make it easier for fans of Stanza to discover the slew of other languages that are pursuing similar type systems.

[0] [https://en.wikipedia.org/wiki/Gradual_typing](https://en.wikipedia.org/wiki/Gradual_typing)

<comment><AUTHOR> Optional typing is the general term for such type systems. "Gradual typing" was coined originally in a paper by Jeremy Siek and refers to a specific set of axioms that must be satisfied.

Thank you for the link though. I will see how the term is used colloquially nowadays.

<comment><USER2> The PL academic community here in New England seems to use the word in fairly broad sense. (Admittedly, type theory isn't my area, and they very well may use a different term when they actually write papers.)

There seems to be a lot of variance in what people mean by gradual/optional typing.

For example, Pyret (a language I work on) has both typed and untyped semantics. In both semantics, bindings can be optionally annotated with a type, and any Pyret program can be executed with dynamic type checking, or can be first statically type checked before executing (but doing so does not remove the dynamic checks). What should this be called? The practical effect is much the same: users can gradually add type annotations.

On the other hand, it's a far simpler approach than typed racket or reticulated python. We made the conscious decision only to include language features for which we had a static type-checking story for, wrote the compiler as if there was no static type checking, and then wrote a type inferencer/checker for the language which can be optionally enabled.

<comment><AUTHOR> Ah I have skimmed through the webpage for Pyret before. It's nice to meet you. I have some questions for you about that that I'll ask you later.

What you're describing is, I believe, one particular strategy among many with the goal of allowing users to gradually add type annotations. The goal itself is not new, and is often called optional-typing. The two words "gradual typing" specifically is also one particular strategy for optional typing but is under the ownership of Jeremy since he coined it. Informally, people do seem to use the term in a looser way.

</comment></comment></comment></comment><comment><USER3> The article could probably do with at least some discussion of [https://www.python.org/dev/peps/pep-0484/](https://www.python.org/dev/peps/pep-0484/).

Also:

> Our optional type system was designed from the perspective that a single > language can consistently contain the semantics of both a dynamically-typed > and a statically-typed language.

The obvious meaning of the word "consistently" here would preclude Turing- complete languages from this (recognition of the same language + undecidability), unless you adopt a fairly idiosyncratic definition of "type safe". I haven't read the whole thing, but it seems like there's a lot of dancing around this without actually coming out and saying it. For me, at least, headlining what you're not claiming would make this substantially more readable.

Edit: Okay, read some more and the "Parametric Types and Stanza's Captured Type System" and "Implications for Safety" sections "dance closer", but it feels like the implications need to be pulled out and moved _way_ up. The covariance assumption in particular...let's just say that I was expecting something substantially different by the time I got to that point.

Finally, if you want some nit-picky editing advice: The terms "Thus" and (to a lesser extent) "Hence" are used...frequently. Possibly just me, but I found it fairly jarring.

<comment><USER4> > preclude Turing-complete languages from this (recognition of the same > language + undecidability)

Can you explain what you mean here? What is the undecidability result you are referring to?

I kind of have the feeling you are trying to make a point about formal languages being "the same", whereas the article uses "the same language" to mean "a single programming language" that allows, but does not require, type declarations.

That such a language can exist should not be a point of contention. You yourself pointed to the PEP that defines such a language.

<comment><USER3> > What is the undecidability result you are referring to?

Just the correspondence between static type safety and the halting problem.

> I kind of have the feeling you are trying to make a point about formal > languages being "the same", whereas the article uses "the same language" to > mean "a single programming language" that allows, but does not require, type > declarations.

Yes this. To me, it felt like the article was making the "stronger" claim, at least until the end when it starts talking about co/contra-variance.

<comment><USER4> > Just the correspondence between static type safety and the halting problem.

I'm not sure if you are saying that there cannot be programming languages with decidable static type systems. Because there _are_ programming languages with decidable static type systems. Typically you cannot encode Turing machines in the type system, so you don't get the kind of problem you seem to be talking about. (But you haven't really explained what you are talking about.)

<comment><USER3>
      // ... Well typed things ...
      if (arbitrary_well_typed_function()) {
        v = 0xF00 + "bar"
      }
      // ... Well typed things ...

Let's say this program is well typed iff `arbitrary_well_typed_function()` is falsy. If a static type checker can not compute `arbitrary_well_typed_function`, it needs to make a trade-off which a dynamic type checker need not.

<comment><USER4> OK. Yes, static type systems need to make trade-offs. If this was your entire point, your original talk about undecidability was hiding it well.

<comment><USER3> You got my point in your first comment in this thread. Unless that comment was the result of hours of striving, it doesn't seem as if the point was hidden _well_. If you did spend hours working at it, then I apologize and commend you on your success.

</comment></comment></comment></comment></comment></comment></comment><comment><USER5> Haskell can, in fact, express the CardValue example using DataKinds. (I haven't written it out, though.)

<comment> nv-vn If I understand it correctly, it should work in OCaml too with polymorphic variants.

<comment><USER4> Yes:

        type card_value = [`Jack | `Queen | `King | `Ace | `Num of int]

        (* not really necessary, but nice to have *)
        type royal_card = [`Jack | `Queen | `King]

        let royal_value (card: royal_card): int =
            match card with `Jack | `Queen | `King -> 1

When trying to abuse this, you get a static type error at compile time:

        royal_value `Ace;;
        Error: This expression has type [> `Ace ]
        but an expression was expected of type royal_card
        The second variant type does not allow tag(s) `Ace

</comment></comment></comment><comment><USER6> Hmm...no mention of Objective-C? Optionally typing things since the early 90ies. The "?" type sound a lot like "id" in Objective-C. And the "feel" is very much what you describe. Quick prototyping, incremental hardening.

</comment><comment><USER7> Isn't "optional typing" the same as just assigning a "universal" type to symbols that have no declared type?

</comment><comment><USER8> How does this compare to Crystal?

Doesn't whether a language is compiled or interpreted have an effect on the type system?

<comment><USER4> > Doesn't whether a language is compiled or interpreted have an effect on the > type system?

The question is not well-posed. Would you call Haskell or OCaml "compiled" languages? They certainly _can_ be compiled to machine code, and often are, but both also have interpreted versions. Would you call Python an "interpreted" language? There are compilers from Python to machine code, which are more or less successful at optimizing away type checks. Being compiled or interpreted (or one of the many intermediate things) is not so much a language property as a property of the implementation.

That said, there are of course some correlations. Python code can heavily inspect and modify itself and its execution context. This kind of thing is easier to do in an interpreter, and it's much easier to do with a dynamic type system. Dynamically typed languages also tend to be interpreted because the dynamic typing incurs runtime costs anyway, so often you would not win a lot of performance by simple ahead-of-time compilation.

(Of course, if your goal is to have a compiled implementation without dynamic type checks, you will design a static type system.)</comment></comment>


Virtual Reality for Visualizing Internal Human Heart Anatomy - <AUTHOR> http://www.vhlab.umn.edu/atlas/vr/ <comment><USER2> Nothing displayed in Firefox.

<comment><AUTHOR> Thanks much! It should be working now.

</comment></comment><comment><USER3> Chrome works</comment>


I won't buy an iPad: ten years later - <AUTHOR> https://boingboing.net/2020/01/27/nascent-boulangism.html <comment><USER3> I won't buy another iPad, because my perfectly good iPad has essentially died from being cut off from most of the services it needs to run. Apps have been "updated" to versions that won't work, and the ability to download older versions is sketchy at best. Most recently, I discovered that my magazine access has stopped working, so not only did I stop getting new issues, I can't download older content that wasn't on my iPad when they killed it. Discontinuing system software updates was bad enough, but actively killing off the functions it needs to keep operating at the old level is too much for me.

<comment><USER4> I'm in the same boat with my launch day iPad. It still works great for e-mail, but pretty much every other app is useless now. So I just keep it by the couch in case I want to look at e-mail.

That said, it's a 10-year-old machine. I don't have any desktop or laptop computers left that are good for anything other than e-mail, either.

<comment><USER5> My main desktop isn't quite 10 years old (I got it in 2013), but it works quite well for rather more intensive uses such software development and playing games, despite not upgrading anything other than the hard drives. Admittedly, it was a high-end system when I bought it.

<comment> dan-robertson I think it's a little unfair to compare a 10 year old desktop today with a 10 year old ipad today because the rate of progress for desktops has been much lower (and many programs are designed to work on less powerful laptops).

Instead consider that a 10 year old laptop in 2010 would be basically useless and massively heavy, or a 10 year old desktop in eg 2007.

<comment><USER5> GP did say that "desktop or laptop computer" didn't last 10 years either. I agree that desktops are going to age better than any other segment of computers.

</comment></comment></comment></comment></comment><comment><USER6> I have met the writer and he is a nice fella but he is so preposterously missing any kind of substance in this article. A lot of great Apple technology has the ability to get out of your way and I often feel that people are being angry on principle. Making things maintainable or serviceable is a design requirement from the get-go, with all kinds of trade-offs and compromises that are endlessly speculated about on the web. But some people seem to think these trade-offs don't exist. Hypercard? Great at the time. How much did a Mac cost to run it though? Anyway, this article is poorly thought-out and badly-written on top, with absolutely nothing to offer that you didn't already know.

<comment><USER7> How is it lacking substance? He points out issues very sanely and very cleanly, like...

1\. How Apple has gone _out of their way_ to prevent allowing other people from touching their devices, including _influencing legislation._ (It wouldn't be nearly as much of a problem if they weren't trying to get guns pointed at anyone who wanted to fix their device themselves, but the act of lobbying to make the law bend to fit your desires is bad for just about everyone.)

2\. How the iPad has (nearly) succeeded at ruining the best parts of hobbies he likes, like comics.

3\. Apple design principles have moved from "Sane, intuitive," to making software targeting the stereotype of "My mother's a dumb old lady; she'd never understand this!"

4\. They've made a joke out of non-vendor-locked software distribution.

5\. People coming to their defense have disavowed basic market principles in doing so.

I don't even mind Apple's "walled garden," but Doctorow makes sound points, and I think the article is a fantastic read, especially when paired with the article it's referencing.

</comment></comment><comment><USER8> While I don't share the sentiment, I get the refusal to participate in the Apple App Store ecosystem. It's clear what the ideological issue there is.

But I do not _at all_ understand the enmity some nerds have for non- replaceable batteries. Over the last 10 years it seems like Apple has run an experiment on whether batteries work better when they're tightly integrated and not replaceable, and that the results are demonstrably in. The performance I get from non-replaceable batteries has been so much better that I would automatically be suspicious of any device that _had_ replaceable batteries. Meanwhile, if I really want to carry a spare battery with me, I still can; it just takes the form of a USB charger.

<comment><USER9> I think they're largely fine with carrying a USB charger, the complaint is that the built-in battery is known to degrade over time. If your device has a removable battery, you can get a new one and pop it in. But when everything is sealed together that becomes a much riskier job.

A lot of people replace their phones on a 2-3 year cycle. If you could get a new battery for $30 and install it yourself in 30 seconds, would people be throwing less phones out?

You'll note that Apple's warranty language (and probably everyone else's) specifically defines batteries as a "consumable part." Given that, it's a bit of a dick move to make them so difficult to replace.

<comment> j-c-hewitt The battery is the fastest-degrading component. It is also one of the most easily replaceable components, speaking in general and not specifically to the way Apple designs it to be non-removable. The desire to replace the fastest degrading component to extend the life of the device makes perfect sense from the consumer's perspective.

<comment><USER10> Additionally, most phones have a 2nd and 3rd owner (a child, or exported to another market). A 3 year old Pixel still has another 3 years of useful life at least.

Frankly it is ecological cancer to operate the way Apple does.

<comment><USER11> You can pay Apple to put a new battery in an old iPhone.

<comment><USER12> Only if you have a spare, or you use it so little that you can do without it—no mobile email, no GPS, no AAA, and no 2FA for up to a week.

<comment><USER13> Up to a week? They can do it in the store the same day if you make an appointment.

<comment><USER12> [https://support.apple.com/iphone/repair/service/battery- powe...](https://support.apple.com/iphone/repair/service/battery-power) warned that they'll try.

<comment><USER13> "In more complex cases, we might need to send it to an Apple Repair Center."

There are no "complex cases" of battery repair. They are referring to cases where there is other damage they have to fix first (which they stated).

<comment><USER9> Not everyone lives near an Apple Store either.

Thankfully Apple has recently made genuine iPhone batteries more available to repair shops, but that was just 4 months ago. They spent _13 years_ not doing that first.

[https://www.theverge.com/2019/8/29/20838307/apple-iphone- rep...](https://www.theverge.com/2019/8/29/20838307/apple-iphone-repairs- parts-independent-shops)

<comment><USER13> People have been able to go to a shop and get batteries replaced (whether they were genuine or not) for a decade. It's only been within the past two or three years where it made the slightest difference between whether it was genuine or not.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> The iPad is a great form factor. I prefer sitting back with it over a computer.

10 years later I only wish Google or Microsoft had a stronger competitor. Apple has dragged their feet in making it more useful.

Apple's Pencil is great but user input could be enhanced with something like Soli, for example:

[https://atap.google.com/soli/](https://atap.google.com/soli/)

Slide a wireless keyboard and mouse next to a tablet and it should become my desktop computer.

<comment><USER4> Since iPads support Bluetooth HID, it seems like it would be possible to create a Soli-type device that works with existing iPads.

 _Slide a wireless keyboard and mouse next to a tablet and it should become my desktop computer._

That's very close to what the iPad is now. I often sit in a coffee shop and read magazines on my iPad. Then when I'm ready to do some work, I just prop the iPad up on a table with its cover and turn on an old Bluetooth keyboard I keep in my bag.

E-mail on the left side of the screen. ssh on the right side with the Prompt app. Bang, it's 90% of what I use my desktop computer for.

I've heard that iPads support a Bluetooth mouse now, but I don't have any personal experience with it. I haven't heard anything about trackpads.

<comment><USER15> This is purely personal preference and probably not reflective of the overall market, but to me the big disadvantage of the iPad is that, as long as it's only running iOS, I still always feel like I need to own a "real" computer to do "real" work on.

The Microsoft offering is inferior as a tablet and inferior as a desktop OS (again subjective opinion), but it lets you have both a tablet and a laptop form factor without needing to own two units of hardware.

In a lot of ways it feels kind of like when I first switched from Windows to Mac back in the early 2000s. I knew that for 98% of stuff I do with a computer, OS9 (and then OSX) was perfectly fine. But the hassle of doing any of the other 2% kept me locked in. Making the jump from OSX to iOS feels the same way. The apps all seem to be 90% of what I need without issue, another 8% okay enough for now, and then 2% just unworkable. (And then there is the nightmare of trying to use many regular old websites on mobile these days with all the unresponsive scripts and ad cruft they carry.)

I'd love it if Apple could figure out some kind of bridge for iOS workloads to meet this, similar to how Parallels or BootCamp can let you get by with those 1 or 2 Windows things you still needed to do after switching. Maybe just let the iPad remote into my Mac at home if it has internet or have it run some kind of stripped down, emulated version of OSX.

<comment><USER4> _but to me the big disadvantage of the iPad is that, as long as it 's only running iOS, I still always feel like I need to own a "real" computer to do "real" work on._

To me that sounds perfectly normal and reasonable. A tablet is not a desktop. A desktop is not a tablet.

People complain that they cannot use their tablets to do desktop work, but somehow never complain that their tower doesn't travel well to the coffee shop.

</comment></comment></comment></comment><comment><USER16> My only observation is this: Not everything is about that one gadget you bought.

Yeah, I have an iPad. An iPhone. An Apple Watch. No, I can't mod these things, take them apart, etc. No, I don't care. I still have a self-built PC running Linux and a bunch of services. I still have a Macbook I can install whatever I want, even Windows or Linux if I chose to. I still have all my own networking hardware that's substantially more hackable.

Going wider, I have a car and I have a bike. One is more hackable than the other. One of them has a service light you need to go to the dealer to clear (unless you're in the know and have special tools). Some of that is in my wheelhouse, some isn't. Sometimes I pick a battle, sometimes I let a tool be a tool.

I think the world of computing is too wide to bother with puritanical about the devices I use. It's just not worth the energy when those things that are heretically 'infantilizing' etc. are just useful and pleasureful to use.

<comment><USER17> I think I agree with you for the most part. I've got a similar setup - <USER2> at home with an iPhone in my pocket. I've broken a linux installation enough times that I know well enough that I'd eventually do the same to my phone if I ran android and rooted it. It's a inevitability for me.

I don't need everything to be running hyper customized stuff. Sometimes simple and stable is all I need.

</comment></comment><comment><USER18> I get the ideological issues with the iOS software "walled garden", but the shitshow that is the only alternative (Android) leaves me wanting. It's malware and advertising infested and Android tablets are a joke and rarely supported for more than 2 years.

He complained about third party apps and then goes into a couple of nostalgia trips over the comic book store (I miss it and the music store, too) and taking apart much simpler electronics as a kid. Like, get your kid a regular PC case, then? What's there to even hack? The iPad, and almost every cell phone as well, is essentially a giant system on a chip with a screen and a battery. There's not much to hack. Also, most people keep thier iPads for more than two years unless it actually hard-fails. My last one was 5 years before I finally got a new one (though I also had the misfortune of buying the first one and the first retina one, which didn't hold up to the march of new models very well).

I don't need a hackable portable computer. I have a full time job and a toddler. I want to turn it on at the end of the day and look at stupid cat videos. Doctorow reminds me of the people that refused to get cell phones and then complained that their friends stopped contacting them.

Also, what the hell is a "CD-ROM programmer"? Does he just mean software that was distributed on CD-ROM?

Also, if he theoretically had "a lot" of AOL shares he'd have been "bailed out" by the merger with Time Warner and would have had "a lot" of shares in the successor companies (he wouldn't be laughing, but he'd have something), but the fact that he's still using AOL as a slur is showing just how much he hasn't moved on with the times, even in 2010.

The _only_ real criticism I have of the ipad is its annoyingly bad background support. I still IRC and the clients disconnect _very_ quickly if I switch apps. This makes SSH annoying as well.

<comment><USER19> > rarely supported for more than 2 years.

Moreso, during those first initial 2 "supported years", you would be extremely lucky to get OS and security updates without an insane delay (unless you run a Pixel device or, maybe, a couple of others I am not aware of).

Just ask any current or former Galaxy device owner in the US regarding how long they have to wait for an update after Pixel devices have already received it. In my case (Galaxy S8+ a couple of years ago, purchased only a few months after the release), I had to wait about half a year for the OS update after it has already arrived on Pixel devices.

</comment></comment><comment><USER11> Fundamentally I think the big difference between 2010 and now is not the continued rise of Apple's walled garden--which was the focus in 2010--but the steady decline of the state of the web.

Google, Facebook, Twitter, etc. today dominate the web and exercise at least the same level of gatekeeping over your visibility to customers as Apple does with their app store. Back in 2010 you could build a Facebook page for your business, and post messages that your fans would see. Can't do that anymore; buy some FB ads please. Google's search results quality continues to decline, and their ads continue to be harder and harder to distinguish. And if you anger them, you might just disappear from their service.

2010 was also before Snowden, before general awareness of the data collected by social apps, before Cambridge Analytica, before a thousand data breaches. Privacy is more important to people now, and one thing about walled gardens is that they are more private... that's why the original physical walled gardens were built.

It's not that walled gardens are ideal; it's that everything has a trade-off, and those trade-offs look different in 2020 than they did in 2010.

A lot of this is not specifically about the iPad, and in retrospect maybe the most obvious reaction to this piece is to laugh at the idea that the iPad was some important place to draw a line. Tablets are still great--and used by a lot of poeple--but they ended up being kind of a side story. The iPhone was the real turning point. Not just for Apple, but for many industries.

<comment><USER20> _> Google, Facebook, Twitter, etc. today dominate the web and exercise at least the same level of gatekeeping over your visibility to customers as Apple does with their app store._

That's clearly an exaggeration. Apple's control over the app store is absolute and in combination with the side-loading ban so is their control over the apps users can install on their devices. These restrictions go far beyond protecting users against security or privacy threats if you think of porn for instance.

Google/Facebook/Twitter's dominance over the Web is not absolute. You can still publish anything that is legal in your jurisiction. It may not be easy to get found, but that's still a _lot_ more freedom than asking a gatekeeper for permission to publish in the first place. Google/Facebook/Twitter is not the only way to find things on the Web either, and they are not one single company.

The Chinese regime cannot simply tell Google or anyone else to take Wikipedia off the Web for showing Taiwan on a map or something. But they can order Apple to take down all secure VPN apps that users could use to read Wikipedia or hand over the iCloud keys of Chinese users, and that's what Apple will do.

<comment><USER11> Google Search is not operating in China at all, and when they did, they censored search results at the request of the Chinese government.

And here in the U.S. the Google story today includes not just the services they provide for free, both also the personal data they collect and correlate.

My point here is not whether Google or Apple is better, my point is that since 2010, we have collectively learned that the web is not as open or resistant to surveillance and censorship as it once seemed it would be. Again: there are trade-offs, and some folks look at those trade-offs differently a decade later.

<comment><USER20> _> my point is that since 2010, we have collectively learned that the web is not as open or resistant to surveillance and censorship as it once seemed it would be._

That's undeniably true, but it doesn't mean that anyone exercises "at least the same level of gatekeeping" on the Web as Apple does on Apple devices.

And Google operating or not operating in China is beside the point. I'm talking about the structure of the Web, not about Google specifically. That's why I said "or anyone else". No private company owns the Web like Apple owns the only iOS distribution channel.

</comment></comment></comment></comment><comment><USER21> There's a lot to be said for making a computer my mother can/wants to use. And Doctorow's sneering condemnation of people describing their mother's as "not good with computers" is telling of what he thinks of those not firmly in the technorati circles he inhabits. Saying "not good with computers" != "a low opinion of that person". He's projecting.

My wife and mother are largely mystified by computers and have been brought to literal tears born of frustration when using them. One of these women is a PHD in English literature and has published over 20 books ranging from short stories for children to graduate-level textbooks. The other has a Doctorate of Dental Surgery and is clinical faculty at a respected School of Dentistry.

These women aren't dumb, but they don't give two flying fucks about a computer they lets them unscrew the casing or comes with the schematics of the circuitboards included! They're much more interested in exploring the human condition through language or practicing medicine. Between all of that they do need to check their email, shop, and keep up with their family on Facebook.

So Cory Doctorow won't buy an iPad. It's not for him/me/us/the nerds. We can buy raspberry pi's, Android devices, Linux desktops, etc... But there is a whole market of people who don't care about computers beyond what they can do for them in the most expeditious way possible. I'm not into toasters, but I use one almost every day and I don't care _at all_ how/why it works. I've got bigger fish to fry.

This article is framed as a victory lap, but comes off more like a gear-head complaining about how shitty the Ford Escape is. Except that Ford doesn't care, because he wasn't on their radar when they made it. The people buying Escapes don't care, because they're busy with all the parts of their lives have literally nothing to do with cars.

I'm sure Doctorow's echo chamber will congratulate on sticking it to Apple (again!) with this trailblazing though-piece. And in 10 years we'll get another article about how he's still not buying iPads. It's all very boring to me.

<comment><USER22> Yep. It has literally never been easier to be a home hacker. Raspberry Pi and Arduino mean you can hack to your hearts desire on a fifty dollar budget.

</comment></comment><comment><USER23> I'd love to buy a non-locked down tablet. There are a lot of things I kind of half-ass do on my iPad (which is my primary mobile device), but which due to iOS restrictions don't work very well. For instance, SSH'ing into a machine from it, and then having to check a website. The SSH connection gets closed in 30 seconds. Or, you know, running a JIT language right on the machine.

The problem is _nobody makes a tablet that works better than the iPad for the things I use the iPad for 90% of the time_ \- which is reading, surfing, checking email, and editing photos.

I tried transitioning to a Linux laptop last year. That experiment lasted 3 months. It just didn't fit into a corporate computing environment that is really only set up to support Windows machines. The iPad _does_ fit.

Back in the day, when asked about how Apple was going to deal with music piracy, Steve Jobs said they were going to out-compete it. And they did. And that's really the only way they could have succeeded. Jobs had it right. Similarly, if you want FOSS principles to rule in the mobile space, you have to come out with a product that works as well as or better than the non-open ones.

</comment><comment><USER24> My 1st gen ipad is still alive and ticking but completely worthless. Hardly a scratch in the case or screen and the battery is fine. I don't use it because no modern apps work on it.

I bought a 2018 model and what a piece of crap. Warped like a Pringle chip, screen shattered and cracked if you looked at it wrong.

<comment><USER25> same situation here, I wish there was a hack to update the OS completely, we are stuck in iOS 5 if I recall correctly.

</comment></comment><comment><USER26> I got six years of updates for my iPad Air, and it still works fine, albeit a little slowly and some apps are crashy now. It's hardly e-waste after 1-2 years.

There's a perfectly adequate online guide for replacing the battery yourself: [https://www.ifixit.com/Guide/iPad+Air+Wi- Fi+Battery+Replacem...](https://www.ifixit.com/Guide/iPad+Air+Wi- Fi+Battery+Replacement/25869) Or you can pay Apple or any competent repair shop to do it for you. I haven't yet needed to replace my battery, even after six years.

There's plenty of programming environments for the iPad, including a web browser to run all the awesome web software out there.

Did it come with a BASIC interpreter preinstalled? No, but I'm OK with that.

</comment><comment><USER27> > The iPad you buy today will be e-waste in a year or two (less, if you decide > not to pay to have the battery changed for you). The real issue isn't the > capabilities of the piece of plastic you unwrap today, but the technical and > social infrastructure that accompanies it.

The duration stated is nonsense for two reasons:

Hardware support: The battery in an iOS device should last at least four years. My father's is going on seven years under light usage conditions. If the battery fails within a single year, it's defective and the included warranty covers replacement.

Software support: Apple has historically provided software support for old iPads for 5.5 to 6 years. That's longer than the support duration for many Android devices, or even some cheap Windows laptops.

</comment><comment><USER28> i wont buy another one because i locked myself out of my icloud and despite my ipad working fine i reset it to give to my daughter. except now it wont work without the icloud account. i went to the apple store with the device itself, and as much proof as i could muster that the original icloud email i used no longer exists.. and they kindly offered to recycle my old one (old meaning less than a year, its 128gb) and sell me a new one.

never again.

</comment><comment><USER29> My biggest complaint with any of these mobile devices is that you can't write any software for them, using the device itself. This is regressive and I also think it impedes the growth of technology. Maybe this is what companies like Apple want. Not a much larger pie but the largest portion of a much smaller pie.

</comment><comment><USER30> Discussed at the time: [https://news.ycombinator.com/item?id=1236722](https://news.ycombinator.com/item?id=1236722)

</comment><comment><USER31> I've seen alot of discontent for his writing style but only a few posts that actually attempt to rebut the fair criticisms that you are being sold a device you don't control. It's an interesting hypocracy from a site that hangs on the every word of librem but condones apple in the same day...

</comment><comment><USER32> bold to go after apple, but also true. It's not just infantilization of hardware, but also software, culture and attention. frankly we should be fed up with the lack of any depth

It wasn't just the ipad, but the damage is already done by phones: entire generations have grown without knowning the real abilities of a computer. the internet has become a photo storage drive. people marvel at their babies knowing how to swipe, and are shocked when they are later baffled by the complexity of computer systems

</comment><comment><USER33> Doctorow histrionically copying the entire Gibson quote is a perfect example of why he is a poor writer. He has no sense of balance.

<comment><USER34> Not only that, the Gibson quote has not aged well. Consumers are not gripping a remote control in voiceless isolated rage; they now hold globally connected handheld computers that provide access to a dizzying choice of ways to interact with others. If there's something essential in this unattractive picture that hasn't changed, this choice of quote doesn't give me confidence that either Gibson or Doctorow understands it.

<comment><USER33> I think the quote was appropriate at the time, see parallel ideas espoused by Stephenson in Interface (1994). It predates the smartphone/social media era.

</comment></comment></comment><comment><USER35> It's weird to read this article when there are legitimately good programming environments available on the iPad, like Pythonista 3, which is an app that lets you run python on your device.

I think the thing that he's "standing by" is that he wants to continue making waves by sounding controversial when he has in fact become irrelevant. I like and appreciate the viewpoints of those shared by BoingBoing, but perhaps something less cringeworthy? I understand folks like to build electronics, and there are systems people can build on for 30 dollars. The iPad was always meant to be a computer for someone that didn't care to screw with all of the guts of hardware or software. But yes, if you really want to use your iPad to learn about hardware and software, you can certainly do so.

And every company has the right to enforce their rules in replacement of defective parts, based upon what prior abuse or misuse you put on it. The average person who "opens" their iPad to fix it deserves to have warranties and guarantees invalidated, even if Apple is a touch predatory in the rates they change for repairs.

</comment><comment><USER36> Some weird stuff for him to uncritically 'stand by':

 _If you want to live in the fair world where you get to keep (or give away) the stuff you buy, the iPad isn 't for you._

Seems like this is garbage.

 _If you want to write code for a platform where the only thing that determines whether you 're going to succeed with it is whether your audience loves it, the iPad isn't for you._

This is a weird and naively idealistic statement. On what platform has this now, or ever been true? It seems like iOS is at least as close to this ideal if not better than any other platform.

I wish we lived in the world he would like us to live in, but he seems to be out of touch with reality.

<comment><USER37> Cory Doctorow is one of the most consistently principled men you'll ever meet. File him with Bernie Sanders or Richard Stallman where regardless if you agree with the principles they uphold, there is still a certain admirable quality to the sheer genuine consistency as to who they are and what they represent.

Reading his piece, it is easy to see that Apple hasn't yet released an iPad Doctorow would like to buy, and I wouldn't blame him for being who he is. He's come to market looking for certain qualities in a tablet computer product, and found every iPad ever released to be lacking them. There's no reason to spend money on something you'll be unhappy with.

<comment><USER36> Principles are genuinely great - I strongly respect being principled.

Principles that are not re-evaluated in context with a changing human society, are just dogma. I respect that, but I call it what it is.

<comment><USER19> I like the way you phrased the last paragraph a lot. Thanks for pointing it out, as I have personally been struggling to articulate why some principles are not the same as others in this context, but your comment perfectly cleared it up in my head.</comment></comment></comment></comment>


Ask HN: How many working on passion projects solo? How come? - <AUTHOR> <comment><USER2> The productivity of N people is usually not N times that of 1 person but usually less.

There is another post on new right now that had me riled, it was "just another" non-technical person looking for a technical founder.

I was going to tear his head off but I choose you.

I am involved in one side project with other people who contribute something, listen to what I have to say, and help me do what I could not do myself.

I have worked with other people that pump in entropy faster than I could possibly pump it out. I find that terribly exhausting. I think there are many people who think they could get status if only they were involved in a successful project but they're allergic to the reality of matter and energy. If I have the fight those bozos then I lose my passion for the project and even to wake up in the morning.

I just nuked my LinkedIn account because it brought so many people like that who drag me down. The best news is I am close to paying off my home equity line after skipping work for a while to try to sell stuff with a salesman who couldn't sell.

<comment><AUTHOR> I feel that - I was working solo for a good bit. Then decided to start collaborating with other devs. It comes with its challenges. But I do think it can be worth it if the project is large enough and the devs you collab with know what they're doing and can self-guide.

> If I have the fight those bozos then I lose my passion for the project and > even to wake up in the morning.

Second this definitely.

What are you working on now?</comment></comment>


Can't We All be Reasonable and Speak English? - <AUTHOR> http://blog.stackoverflow.com/2014/02/cant-we-all-be-reasonable-and-speak-english/?

<comment><USER2> Why not Italian first? :(

(joking - I know italian is only spoken in Italy, New York and Toronto)

In Chrome, Google Translate did a pretty good job converting back to English. Maybe a plugin is in order to convert answers into Portuguese?</comment>


New surgical knife prototype can instantly detect cancer - <AUTHOR> http://hosted.ap.org/dynamic/stories/E/EU_MED_CANCER_KNIFE?SITE=AP&SECTION=HOME&TEMPLATE=DEFAULT&CTIME=2013-07-17-14-05-02

<comment><USER2> The standard way for a surgeon to detect if he has removed a tumor is a frozen section. This would appear to vastly improve upon the current tools available and perhaps allow for more successful surgeries. It is nice to see metabolomics being applied in a clinical setting.</comment>


Twirp: A new RPC framework for Go - <AUTHOR> https://blog.twitch.tv/twirp-a-sweet-new-rpc-framework-for-go-5f2febbf35f <comment><AUTHOR> Hey everyone! I'm the OP and primary author of Twirp. I'm happy to answer any questions and hear feedback.

You can also reach me directly, if you like, email is in my profile.

<comment><USER2> Thanks for posting! How did you work around issues with GRPC on AWS/ELB?

<comment><USER3> We had to stick to layer 4/TCP via an ELB (as opposed to an ALB).

<comment><USER4> gRPC connections are persistent, so a single client will always talk to a single backend in that configuration. It's fine if you have lots of clients but can easily lead to load imbalances.

That's why projects such as Envoy exist. I'd link it, but I'm on mobile.

Keep an eye on it.

<comment><USER5> You can use round robin load balancing in gRPC without Envoy.

<comment><USER6> And it's not difficult to swap it out for a consistent hash balancer or other solution.

</comment></comment></comment></comment></comment></comment><comment><USER7> I think the work the gRPC contributors are doing is great, including all the features. But I can't emphasize enough how important it is for projects like this that take great ideas to a new level by prioritizing simplicity. It's like one project brainstorms great ideas by not being too resistant to new ones (the "yes, and..." rule), while the other refines the ideas with a focus on simplicity to extract the greatest value for the cost.

Great work.

</comment><comment><USER8> Really excited about this. I didn't like how opaque and heavy gRPC is. Also I really wanted support for JSON. Mostly for these reasons, RCP hasn't been implemented in my architecture yet (Just using standard REST)

Twirp is everything I wanted in an RPC framework and I'm looking forward to implementing it ASAP. Thanks Twitch team :)

<comment><USER9> Can I ask why you want JSON with gRPC? The benefits to protobuf are tremendous, with little to no downsides

<comment><USER10> On the other hand, plain URLs with JSON are _much_ easier to work with without writing any code. You can do everything want with curl from the shell, and often an API allows doing almost anything from a browser (Elasticsearch comes to mind). The simplicity of it all comes in handy when you want to do something trivial — load a small piece of data into the server, do some diagnostics, run some ad-hoc queries, etc. — without really wanting to write a _program_.

Debugging with lower-level tools like strace and tcpdump is also something that's trivial with JSON-over-HTTP/1.1, but _virtually_ impossible with gRPC. (I mean, you could grab the payload and run it through gRPC deserialization, but _would_ you?)

I'm a big fan of gRPC, but it is pretty top-heavy — lots of code to accomplish relatively little. If you have a language that can build client bindings dynamically from .proto files without recompilation, that would ease things a lot, but if you're using Go, for example, the bar is pretty high going from zero to productive.

<comment><USER11> I think the only RPC mechanism I've been happy with, that required little work and didn't constantly get in the way was Stubby - the precursor to gRPC used inside Google.

For a few years inside Google I experienced zero discussions about almost every aspect of RPC. It took a trivial amount of time to implement stuff interfaces, clients and servers in multiple languages and it was trivial to understand the interface of, and implement a client for, other people's code.

I didn't necessarily like everything in Stubby, but I absolutely loved not needing to have pointless discussions about RPC mechanisms or protocol design.

Since I left Google, anything even remotely resembling RPC (including REST) has been an utter waste of time mostly spent bickering over this crap solution or that crap solution – mostly with people who don't care about the same things you care about.

REST is a crap solution in my eyes because it invites absolutely endless discussions on an endless list of subtopics. From the dogmatic/fundamentalist HATEOAS end of the spectrum to the RPC-using-HTTP-and-JSON-and-let's-call-it- REST camp. Not to mention that in addition you need to have an IDL and toolchain discussion. (Of course, none of the toolchains or ways to describe interfaces are very good. In fact, they all suck in part because the attention is being spread across so many efforts that don't get the job done).

I have yet to see an IDL that works better than a commented .proto file from a "get stuff done" point of view.

I completely understand where you are coming from when it comes to having human readable wire format. For 20 years I was a strong believer in the same, and for some systems I still believe in human readable formats.

But RPC and RPC-like mechanisms is no longer among them. RPC is for computers to talk to each other and not for humans trying to manually repair stuff.

(I'm a pragmatist, so I'm allowed to both change my mind and have seemingly inconsistent opinions :-))

For RPC you should encourage the creation of tools. If you need to look at the traffic manually: fine, make a Wireshark plugin or a proxy that can view calls in real time. That's annoying, but cheaper than going off and inventing yet another mechanism. And once it is done, it is done and there's one more thing that is sane.

We should really encourage people to build tools so we can automate things and have more precise and predictable control over what we are doing without having to reimplement parsing (which is what happens if people think they understand your protocol - which they often don't)

Also, make sure it works for a large enough set of implementation languages and understand how to work in mechanical sympathy with build systems. I don't care if Cap'n Proto is marginally better than Protobuf if it lacks decent support for languages I have to care about.

I have no idea how much time we wasted on trying to get Thrift to work in a Java project that needed to build on Windows, Linux and OSX back in the day, but I was ready to strangle the makers of Thrift for not paying attention to this.

At this point I'm beyond caring about the design of RPC systems. I just want something that works for software development and doesn't have to be a discussion. Hence, I get annoyed every time I see a new RPC mechanism instead of attempts to make some of the existing mechanisms work by just making just one aspect of them a bit more sane and exhibit a bit more empathy with programmers rather than the egos of protagonists of various libraries, frameworks and formats.

<comment><USER10> How does Stubby compare to gRPC?

I imagine part of the lack of friction around Stubby was that Google was the only consumer, and could maintain client and server bindings/tools for the strict subset of the languages that Google standardized on.

<comment><USER11> It was pretty similar, but gRPC is a bit simpler since Stubby had a lot of other stuff to deal with authorization etc.

I wouldn't say the lack of friction was mostly due to Google being the only consumer. It was mostly because there was a clear path from A to B when you wanted to give something an RPC interface and that this path was made efficient.

Or at least more efficient than trying to use REST-like stuff in a large organization with lots of different teams using different technologies.

It also helped that it wasn't a democracy. You had to use it. If you didn't like that you were free to leave. As a result people will focus more effort on making the tools better and make friction points go away.

In practical terms: we can spend weeks on getting a REST-like interface to work with other projects because everyone has an opinion on every bit of the design, and everyone uses different, and quirky libraries and tools. For Stubby in Google back then, it was mostly about defining the data structures, the RPC calls, discuss semantics and then the mechanics were taken care of. This is far, far, far from the actual case for many other technologies.

(And while I appreciate HATEOAS as a design philosophy, and I've tried to make use of it several times, it just is not worth the effort. It is just takes too much time to do right and to get everyone on the same page. Most proponents are more keen on telling everyone how they are using it wrong, than on writing good tools that actually help people use it right. There's very little empathy with the developer).

</comment></comment></comment></comment></comment></comment><comment><USER12> It is amazing to me that almost nobody here actually questioned the wisdom of throwing out the time tested benefits of robustness of REST in exchange for that which REST was created to eliminate; the fragility of RPC. And all because using RPC is easier in the moment (vs. over time.)

This reminds of of the old saw "Those who ignore history are doomed to repeat it."

If you are unaware of the benefits, here are a just few links that can explain it:

\- [https://www.quora.com/What-are-the-advantages-of-REST- over-a...](https://www.quora.com/What-are-the-advantages-of-REST-over-a-more- RPC-style)

\- [https://www.quora.com/What-is-the-difference-between-REST- an...](https://www.quora.com/What-is-the-difference-between-REST-and-RPC)

\- [http://duncan-cragg.org/blog/post/getting-data-rest- dialogue...](http://duncan-cragg.org/blog/post/getting-data-rest-dialogues/)

\- [https://apihandyman.io/do-you-really-know-why-you-prefer- res...](https://apihandyman.io/do-you-really-know-why-you-prefer-rest-over- rpc/)

\- [https://www.quora.com/What-are-the-pros-and-cons-of-REST- ver...](https://www.quora.com/What-are-the-pros-and-cons-of-REST-versus-RPC)

<comment><USER13> I did. It's pretty obvious they don't understand REST at all so they reinvented the wheel.

</comment></comment><comment><USER14> What could make this really take off is an in-browser JS client. The simplicity it has added seems to really help there. The gRPC team has had one in hiding for a long time only giving people access who explicitly ask: [https://github.com/grpc/grpc/issues/8682](https://github.com/grpc/grpc/issues/8682) (good thing GitHub has a feature that snips hundreds of comments or that link would take a while to load)

<comment><AUTHOR> Totally agree, and it's something I'd love to see. Consider this a call for contributors - I think a simple generated javascript client would be an excellent way to help with the project.

</comment></comment><comment><USER15> I am interested in finding out how Twirp helps with versioning? Is it possible to have services evolve independent of each other?

</comment><comment><USER16> This is a pretty awesome project. The one thing that's missing would be autogenerated javascript/typescript stubs like grpc-web does. Will definitely experiment with this when building small go applications.

<comment><USER17> Hopefully these will be implemented soon by the community. Open source rules :)

</comment></comment><comment><USER18> I'm trying to understand the problem this solves. Let's say you have an HTTP API which allows users to update their email address:

        POST /api/user/:username/update_email

But you change the application to require API clients to send the user_id instead of the username.

        POST /api/user/:user_id/update_email

Wouldn't you still need to mandate that all clients are updated regardless of whether you use this tool as an abstraction layer to your API?

<comment><USER8> Recommend reading on what an RPC is: [https://www.geeksforgeeks.org/operating- system-remote-proced...](https://www.geeksforgeeks.org/operating-system- remote-procedure-call-rpc/)

And protobufs: [https://developers.google.com/protocol- buffers/docs/proto3](https://developers.google.com/protocol- buffers/docs/proto3)

Example, one benefit is that you're defining your API by using language neutral protobufs which then generate code consistently (including types!) into many languages. Your entire communication procedure can be easily and succinctly described in a single small, human readable file.

</comment></comment><comment><USER19> Lots of comments here about lack of JSON support in gRPC - while that's true, it's relatively easily to bolt on using grpc-gateway ([https://github.com/grpc-ecosystem/grpc-gateway](https://github.com/grpc- ecosystem/grpc-gateway)).

Here's how we did it in CockroachDB: [https://github.com/cockroachdb/cockroach/blob/24ed8df04719a1...](https://github.com/cockroachdb/cockroach/blob/24ed8df04719a15e74c29d5747224ef6987e7756/pkg/server/server.go#L994-L1008)

The supporting code (protoutil) is [https://godoc.org/github.com/cockroachdb/cockroach/pkg/util/...](https://godoc.org/github.com/cockroachdb/cockroach/pkg/util/protoutil#JSONPb) and [https://godoc.org/github.com/cockroachdb/cockroach/pkg/util/...](https://godoc.org/github.com/cockroachdb/cockroach/pkg/util/protoutil#ProtoPb).

</comment><comment><USER20> I wrote a similar library to this called Hyperbuffs[0] in Elixir. The goal of the project is to document and build your endpoints using protobufs, but to allow the caller to choose either protobuf or JSON encoding for content and accept types.

[0] [https://github.com/hayesgm/hyperbuffs](https://github.com/hayesgm/hyperbuffs)

</comment><comment><USER21> Author of go-micro here. Good to finally start seeing some choices focused on RPC. I started go-micro in 2014, before gRPC came on the scene. Even still I think the tooling doesn't emphasize ease of development. That was my goal with go-micro.

[https://github.com/micro/go-micro](https://github.com/micro/go-micro)

</comment><comment><USER22> Looks nice. Can anyone comment on how auth works with Twirp? I was trying to get GRPC working to authenticate with unsigned ssl certs (much like using SSH) and was rather disappointed how awkward it was. Basically two completely different methods requiring hiding session ID in two unrelated places just to allow a SSL cert to control authentication.

Anyone done similar with Twirp?

<comment><AUTHOR> Yep, you can do this pretty easily because Twirp's generated objects plug in nicely to the normal `net/http` tools. The server is a `http.Handler`, and the client constructor takes a `http.Client`. So if you're familiar with how to use SSL certs for authentication with a vanilla Go HTTP client and server, Twirp would work in exactly the same way.

When you create a Twirp server, you get a `net/http.Handler`. You can mount it on a `http.Server` with its `TLSConfig` field set to the right policy.

The client constructor similarly takes a `*net/http.Client`. You could provide a Client that uses a `http.Transport` with its `TLSClientConfig` field set to something using the right value (like in [https://gist.github.com/michaljemala/d6f4e01c4834bf47a9c4](https://gist.github.com/michaljemala/d6f4e01c4834bf47a9c4), say).

</comment></comment><comment><USER23> this looks really sweet. i've never understood why gRPC limits itself to protobufs only when the protobufs have a canonical json representation. i'm glad that twirp is fixing that piece.

<comment><USER24> On GCP, Cloud Endpoints proxies will transparently translate back and forth between protobufs and the canonical JSON, allowing either representation to be used. So if you're on GCP and don't care about vendor lock-in, that's a solution.

<comment><USER25> There is also the grpc-gateway project for JSON transcoding [https://github.com/grpc-ecosystem/grpc-gateway](https://github.com/grpc- ecosystem/grpc-gateway)

<comment><USER5> To be fair, if you chose gRPC for performance, but then end up using JSON for most of your traffic, perhaps you picked the wrong tool.

<comment><USER24> I don't think generally people want to have JSON accepted to use in their production workloads. More for development, testing, that kind of thing. Being able to just curl your service makes a huge difference.

<comment><USER5> It always starts that way, then people demand JSON everywhere ("why not?"), then they complain when things get too slow or when the OOMs begin to appear. :-)

</comment></comment></comment></comment></comment></comment><comment><USER10> This looks promising! We use the go-grpc SDK in conjunction with gogoprotobuf, and it's been a rocky road.

While the article identifies some operational issues (e.g. the reliance on HTTP/2), there are several considerable deficiencies with gRPC today, at least when using it with Go:

1\. The JSON mapping (jsonpb.go) is clumsy at best, and by this I mean that it produces JSON that often doesn't look anything like how you'd hand-design your structures. "oneof" structs, for example, generate an additional level of indirection that you typically wouldn't have. Proto3's decision to forego Proto2's optional values (in Proto3 everything is optional) cause Go's zero value semantics to leak into gRPC [1]. (We had to fork jsonpb.go to fix some of these issues, but as far as I can tell, upstream is still very awkward.)

2\. The Go code generator usually produces highly unidiomatic Go. "oneof" is yet again an offender here. The gogoprotobuf [2] project tries to fix some of go-grpc's deficiencies, but it's still not sufficient. Ideally you should be able to use the Proto structs directly, but our biggest gRPC project we basically gave up here, and decided to limit Proto usage to the server layer, with a translation layer in between that translates all the Proto structs to/from native structs. That keeps things clean, but it's pretty exhausting work, which lots of type switches (which are hampered by Go's lack of switch exhaustiveness checking; we use BurntSushi's go-sumtype [3] a lot, but I don't think it can work for Proto structs, as it requires that a struct also implements an interface).

3\. Proto3 has very limited support for expressing "free-form" data. By this I mean if you need to express a Protobuf field that contains a structured set of data such as {"foo": {"bar": 42}}. For this, you have the extension google.protobuf.Value [4], which supports some basic primitives, but not all (no timestamps, for example) and cannot be used to serialize actual gRPC messages; you can't serialize {"foo": MyProtoMessage{...}}. Free-form structured data is important for systems that accept foreign data where the schema isn't known; for example, a system that indexes analytics data.

From what I can tell, though, Twirp doesn't "disrupt" gRPC as much as I'd like, since it appears to rely on the existing JSON mapping.

[1] [https://github.com/gogo/protobuf/issues/218](https://github.com/gogo/protobuf/issues/218)

[2] [https://github.com/gogo/protobuf](https://github.com/gogo/protobuf)

[3] [https://github.com/BurntSushi/go- sumtype](https://github.com/BurntSushi/go-sumtype)

[4] [https://developers.google.com/protocol- buffers/docs/referenc...](https://developers.google.com/protocol- buffers/docs/reference/google.protobuf#google.protobuf.Value)

<comment><AUTHOR> Yeah, I agree with pretty much everything you've written here.

> 1\. The JSON mapping (jsonpb.go) is clumsy at best

The best thing for optional fields in jsonpb is to use the protobuf wrapper types [1]. They have special support in jsonpb to serialize and deserialize as you would expect, without the indirection. But the Go structs you get on the other end are a little weird, so its a tradeoff.

> 2\. The Go code generator usually produces highly unidiomatic Go.

Yeah, using the generated structs as the main domain types in your code can be up-and-down. I agree that gogoprotobuf can help, but it's rough. We definitely use Getter methods on generated structs quite a bit for stuff like oneofs.

> 3\. Proto3 has very limited support for expressing "free-form" data.

There's always `repeated byte` :) It sounds like a joke, but we've used it in some spots where the input is totally schema-less.

The Any type is also designed for this sort of thing. Still clumsy, though.

[1] [https://github.com/google/protobuf/blob/master/src/google/pr...](https://github.com/google/protobuf/blob/master/src/google/protobuf/wrappers.proto)

<comment><USER26> _> > 2\. The Go code generator usually produces highly unidiomatic Go._

 _> using the generated structs as the main domain types in your code can be up-and-down_

At $DAYJOB we solve this by doing code generation outward from our domain types. The RPC layer is idiomatic Go because that's what we began with.

Some go/token and regexes take our structs and produce a server-side router implementation for net/http (endpoints from magic comments), some client-side libraries for Go / C++ (Qt) / PHP / JS, and documentation in markdown.

Our system is in a pretty reusable state, but nobody has the free cycles to open it. If Twirp had been available 24mo ago our project might have been different.

</comment></comment></comment><comment><USER27> Any performance numbers?

<comment><AUTHOR> It's really hard to write benchmarks of an RPC system that mean much, but the overhead is really just in serialization. We have services that handle tens of thousands of requests per second on Twirp in one process.

Serialization/deserialization of a typical protobuf struct takes a microsecond or two, but it generates some garbage, so GC ends up slowing you down if you try to go really crazy and push past 100k req/s in one process with non- trivial message structures.

<comment><USER27> Thanks, that's the exact info I was looking for.

I've unfortunately been bitten before by choosing json as a serialization format, specifically in go, due to JSON performance dominating processing.

No criticism though, JSON is the right choice for many types of APIs.

<comment><AUTHOR> You can and should use Twirp's protobuf serialization instead for almost all applications. The JSON serialization is really intended for developers and low-throughput cross-language clients.

Protobuf serialization isn't free, but it's definitely cheaper than JSON serialization.

</comment></comment></comment></comment><comment><USER28> awesome! a lot easier to integrate than gRPC. It will be way more useful after other languages are supported

</comment><comment><USER29> Is Thrift supported in Go?

<comment><USER9> Not fully

[https://thrift.apache.org/docs/Languages](https://thrift.apache.org/docs/Languages)

</comment></comment><comment><USER30> beautiful, i'm sick of juggling get/post/put/patch/delete and figuring out which one the api developer chose. just do X using Yparams.

</comment><comment><USER31> Can any explain to me what an RPC is?

<comment><USER32> Remote Procedure Call. [https://en.wikipedia.org/wiki/Remote_procedure_call](https://en.wikipedia.org/wiki/Remote_procedure_call)

</comment></comment><comment><USER33> Looks like the website got a HN hug of death and isn't really loading for me whatsoever.

<comment><USER34> Unlikely? It's hosted on medium - I'm pretty sure they can handle the load. However here is the cached version: [https://webcache.googleusercontent.com/search?q=cache:6vYOM9...](https://webcache.googleusercontent.com/search?q=cache:6vYOM9EjSsAJ:https://blog.twitch.tv/twirp- a-sweet-new-rpc-framework-for-go-5f2febbf35f+&cd=1&hl=en&ct=clnk&gl=us)

</comment></comment><comment> oh-kumudo It is nice but would say with limited value outside of Twitch

<comment><USER35> I definitely would prefer to use this instead of bizare-REST-like (it's how REST usually devolves into) in a next project , if I can't use graphql.

<comment><USER36> I was surprised to find that GraphQL was probably the easiest sell to my team ever.

</comment></comment></comment><comment><USER37> I've been saying for years and years that JSON RPC is the way to go. Glad to see at least someone agrees. [http://www.jsonrpc.org/](http://www.jsonrpc.org/)

</comment><comment><USER36> There seems to be somewhat of a pattern of Go being linked to outages (CloudFlare and now Twitch). Any regrets investing in Go?

<comment><USER38> Are you talking about problems with gRPC mentioned in the article? gRPC is not in any way specific to Go or even related to Go, and I can confirm that there have been some problems with the C++ version of gRPC.

The CloudFlare outage was related to leap second handling... while the particulars of the Go library contributed, this is also far, far from the only time that a leap second caused havoc online. Hell, in 2008, Zunes were crippled by a leap day bug.

RPC and time handling are notoriously tricky problems to get right.

</comment></comment><comment><USER39> Why use HTTP for transport instead of Messagepack or ZMQ? Seems a bit overkill if you are whipping binary data back and forth between services. Protobuf + ZMQ seems a lot more efficient to me.

<comment><USER40> A lot of this boils down to wanting to be able to use standard load balancers.

<comment><USER39> ZMQ uses ZMTP which is a TCP protocol, and for example, HAProxy supports TCP just as much as TCP/HTTP.</comment></comment></comment>


NASA's Lunar Space Station Is a Great/Terrible Idea - <AUTHOR> https://spectrum.ieee.org/aerospace/space-flight/nasas-lunar-space-station-is-a-greatterrible-idea <comment><USER3> The thing about the original moon landing programme was that it had a great clarity of outcome and timeline.

What: Land a man on the moon and return him safely

When: Before the decade is out

That meant NASA could really focus and throw out everything that wasn't directly on that path.

Reusability - take too long, we'll build each craft from scratch.

Permanent mission - Too complicated, keep the missions very short.

Multi-launch architecture - Nope, too complicated again. Launch it all together.

Crew size? Two on the moon so they could help each other, one in the CM to aid in docking. Want a larger crew? Sorry, no. Three is the minimum so that's what you get.

Complicated re-entry vehicles? Nope. We know we can make ablative work.

What is NASA's manned programme for now? Maybe the Moon. When, who knows? Maybe Mars. What architecture, when, how, for how long? Who knows. Moon orbit? For what, when? who knows.

It's impossible to run a clear programme if you don't know what it's for!

<comment><USER4> As far as I can tell, the primary purpose of manned space missions is to redirecting taxes to congressional districts and defense contractors. The secondary purpose might be to inspire interest in STEM, but it seems much less successful at achieving that objective.

<comment><USER5> The other cynical view is that the moon program was _really_ military.

As in, if the Soviets got to control the ultimate "higher ground", they could rule the world from it. Apollo made sure no one could control space, and we now have peace in space.

I kinda believe in this, though I don't know how historically verified it is. It's of course _not_ what you _ever_ say in your rousing speeches to the nation and the world!

<comment><USER6> There was fear that if the Russians got to the moon first they might set up a base, and having a base they could shoot down any other landing attempt (literally, with guns mounted in their moon base). Thus the moon could become Russian domain, which would not just grant them great research opportunities but also a virtually unreachable weapons platform. (Remember that the first crewed space station was 2 years after the moon landing, and also Soviet)

On that basis the military was advocating for a moon mission years before Kennedy's speech. It's hard to tell if this actually played a big role in the decision to go to the moon, but it was the cold war after all.

Also the Soviet Union was winning most of the relevant milestones in space (first satellite, first animal in orbit, first human, first woman, first space walk, etc), and this was a great source of national pride. Beating them had great propaganda value.

<comment><USER7> >Also the Soviet Union was winning most of the relevant milestones in space (first satellite, first animal in orbit, first human, first woman, first space walk, etc), and this was a great source of national pride. Beating them had great propaganda value.

I would rather say that the Soviet Union was winning the _irrelevant_ milestones, precisely for the propaganda value. First woman in space means nothing, really - you put a woman on your spaceship, wham, easy win. The moon landings forced the USA to tackle real engineering challenges - rendezvous and docking, piloted spacecraft and piloted orbit changes, functionally useful EVAs, keeping humans alive in space for long periods, etc.

<comment><USER8> Oh boy, you underestimate the power of feminism. First woman in space is a lot, especially if you go back to 60th of previous century.

<comment><USER7> That's the point - it's a propaganda win, not a technical achievement in any way. Not to belittle the symbolic importance of it, but cmon - first dog murdered by being launched in a rocket, first time running two manned missions at the same time, first nap in space - a large proportion of the Soviet "firsts" were just low-complexity stunts.

One of the last major "firsts" was "first organisms to circle the moon" \- they barely squeaked this one in a few months before Apollo 8, and they accomplished it by shoving some tortoises into a Soyuz (no food or water required!).

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> It's kind of ridiculous how often NASA has to reallocate their focus. Personally, I'd like to see a longer term 5 - 10 year plan that is voted on by congress and basically the funds are deposited in an escrow.

It's insane the waste that occurs from random political moves like this. I understand the need to be able to direct NASA, but that should be in addition to the described 5 - 10 year plans. This would give the flexibility needed, while at the same time ensuring skills and contractors are maintained and long term visions are still possible.

I kind of view the "gate" in its current state as NASA knowing it's the correct choice technically and trying to politically make it viable. Shouldn't we listen to the experts here?

<comment><USER10> Since Bush every incoming president has set up a "vision" that scraps all previous work and which then in turn gets scrapped by the next guy. I wonder how the people working there can keep motivated knowing that most of their work is just for show. Seems unmanned missions are fine but manned missions are just a mess.

<comment><USER11> From what I've heard, a lot of people have left NASA as a result of the month- long government shutdown this year. NASA is a political football, and it's not going to get any better: it just takes too long to see a big mission (i.e., manned ones) through, so they're never going to get done with the way our government is running these days. The probes are usually OK because those can get done a lot quicker.

<comment><USER12> > From what I've heard, a lot of people have left NASA as a result of the > month-long government shutdown this year.

I've got two friends there, a civil servant and a contractor, and I've heard no such thing. That doesn't mean it isn't true, but I'm curious whether there's any data to back this up. You'd have to be careful looking at that data, too: a lot of people are retiring from NASA simply because they're old.

Nothing that's happened to NASA lately is a new phenomenon.

<comment><USER13> Total conjecture, but seeing as how the private space industry has ramped up, it would make sense to leave during such a hostile administration

<comment><USER14> Where are people going to go if they want to do science? OK, the ESA, Japan, India. Maybe China. But is there anywhere else to go _in_ the USA?

<comment><USER15> SpaceX? Or if your science isn't specifically on materials for rockets/physics for rockets/etc... you could be funded by a university or research institute and simply pay for (part of) a launch on a SpaceX rocket.

NASA still does quite a bit of science work though, so I wouldn't count them out entirely. Administrations come and go. Sometimes you just gotta keep your head down and keep doing your job until someone better is voted in.

</comment></comment></comment></comment></comment></comment></comment><comment><USER16> For long time NASA announced a space program after space program only to be canceled at an unfortunate moment.

We have to understand that our problems with advancing manned spaceflight are mainly organizational. And because of that, it's beneficial to focus efforts not on a grand goal, which may not survive the next budgetary fight in Congress, but instead on capabilities which can mostly be used for whatever goal we'll have in mind at any particular moment.

We're well on the way along this idea already. Whatever payload can be used for on LEO, we already have means to get some 20 metric tons there reliably. This, as Heinlein put, is already half-way to anywhere in the Solar system. We also work on manned spacecrafts, which, while useful for getting to ISS and back, can also be used - mostly - for much more distant trips, to near-lunar space and more. We're growing a network of automatic stations, which can provide early reconnaissance for various sky bodies, navigational beacons and relays. A bunch of companies have growing experience with controlled landing and launching of one-stage rocket devices.

Gateway has a good property in that it's another component on the way to the Moon - and elsewhere - which has higher chances to survive another organizational shakeup because it's easier to build Gateway than to mount a sizable manned program to the Moon surface. Gateway is an ISS on steroids - <USER2> terms of getting to a much higher point - but not much more in terms of complexity, and we became pretty good with building and maintaining ISS. A smaller ISS in Moon vicinity can be less risky and less expensive than many other projects. As for usefulness - given that Gateway is in place, it's much easier to manage risks for more bold manned and unmanned projects on the Moon. Here I disagree with Griffin - he doesn't seem to recognize organizational challenges which Gateway allows to solve.

Gateway has benefits in easier construction (you don't need to land heavy modules on the Moon), better understanding of international cooperation (e.g., ESA will get experience launching modules towards the Moon), uses other than Moon (for later stages, when we might have some flow of materials from the Moo surface), easier return to Earth (so less risks), better coverage of Moon surface in terms of accessibility etc. IMO, not bad for something which actually has a better chance to get funded to completion than existing alternatives.

<comment><USER17> Finally, a sensical comment. You're exactly right.

Given the constraints of politics/funding, NASA can't pull off long-term & ambitious goals like they used to in the 60s-70s, and the administrator of NASA, Jim Bridenstine, knows that.

Using your term: ISS on steroids, the next stepping stone would be the Gateway on steroids: an orbiting station around Mars.

Here's a cool pdf from NASA that goes into details:

[https://arstechnica.com/wp- content/uploads/2019/05/2019-Why-...](https://arstechnica.com/wp- content/uploads/2019/05/2019-Why-Gateway-v5.pdf)

<comment><USER18> There are multiple launch systems that will have the payload capacity to go straight to the moon within the next few years. Why not just use those?

No one will care about a Lunar space station, it's not enough of a step forward to capture the public's attention. It's sad that NASA's 'futuristic' new proposal is to do half of what we were able to do 50 years ago. People will quickly vote to cut funding for it, and maybe they should.

<comment><USER16> > There are multiple launch systems that will have the payload capacity to go > straight to the moon within the next few years. Why not just use those?

Maybe SLS and BFR - but those are not nearly ready, and SLS may not be able to launch directly to the Moon what we may require to launch this time.

Remember that one of the problems of today is significantly lower risk tolerances. We'll want system to be much safer, and that will translate into more mass of the system for all kinds of backups. So Saturn-V or similar payload throwers won't cut it this time. BFR may - but this is much less visible on the horizon.

> No one will care about a Lunar space station... People will quickly vote to > cut funding...

I doubt. ISS may be seen as a giant step back from Apollo (even if it has a pile of its own benefits). Comparing to ISS Gateway is a significant step forward. Just imagine: deep space instead of "just" 400 km up, Moon vicinity, flights measured in days and not because one need to synchronize orbits; platform for telescopes which are much more stationary and aren't obscured with Earth every hour...

And launching expedition to the Moon from Gateway can be that much more convenient.

</comment></comment></comment></comment><comment><USER19> It's terrible because they effectively canceled the asteroid retrieval mission (ARM) when they chose to fund the proposals that did not include any de-spin mechanisms. This leaves them with literally 3 possible asteroids to try to bring in. Useless.

The point of the lunar gateway was to have a close (in time) place for resources and the like. But without any ability to capture and bring in asteroids it's just a waste of space.

<comment><USER20> It could be that they're fighting for tangible progress that would let them repropose something like ARM that now has a cheaper marginal cost.

</comment></comment><comment><USER21> > Aware of such criticisms, NASA is defending the Gateway. In May, the agency > quietly distributed a white paper titled "Why Gateway?" [PDF] that makes the > case for the space station.

Casey Handmer's take on that document, the best I know and strongly critical, is here:

[https://caseyhandmer.wordpress.com/2019/05/05/the-lunar- gate...](https://caseyhandmer.wordpress.com/2019/05/05/the-lunar-gateway- nasas-version/)

<comment><USER22> > The SLS is derived from the shuttle core propulsion system, but despite > adding a stage and 30% more fuel somehow lost 40% of its lift capacity. If > you know how this happened, please let me know.

That is a massively sick burn right there.

</comment></comment><comment><USER23> All this "get back to the moon" stuff makes me wonder what the purpose of going to the moon actually is. It's definitely different for different people.

If the whole point of the endeavor is just _another_ space race exercise to demonstrate American prowess like the we did in the 1960's-- perhaps that's a waste of effort? Do we really need that symbolic achievement at such an enormous cost? Not to mention the opportunity cost of having to drop more scientifically productive robotic missions?

The fact that the dithering idiocy of our current "administration" is even uttering anything about a moon mission sort of makes me think they see this as just a baloney "show-the-world" stunt.

What if, instead, there was a focus on true science, unmanned missions, and perhaps steps towards actual space applications: mining, asteroid protection, and staging for _permanent_ space installations ?

<comment><USER24> JFK didn't have any particular love for the scientific discovery of a moon mission. It was the same kind of thing that you're describing today: demonstrate American "greatness" in a world that seemed increasingly hostile - just substitute Islamicists/Terrorism for USSR/Cold War.

I think that tells us two things:

1) We can still accomplish great things even from lowly motivations, and

2) We shouldn't necessarily take those lowly motivations as proof of a craven administration.

<comment><USER23> I agree that people who get involved with space programs will be glad to "take what we can get" in terms of funding whether that means deep-space robotic missions or another manned moon landing.

Good things will happen with both. But why not choose the _best_ _way_ _forward_ when it comes to space exploration?

Why not free ourselves from the strictures of yet another "space race" with low-brow nationalistic goals where we again end up citing uninspiring spin- offs as the reward for "winning" the race?

</comment></comment></comment><comment><USER25> This might be a radical idea, but after reading that article, my thought was, "At this point, the most merciful thing to do might be to put NASA out of its misery." Specifically, this would entail:

\- The US government getting out of the business of _designing_ launchers: We'd acquire launchers the same way the Air Force gets airplanes: define requirements and solicit bids. This isn't perfect (see: F-35), but it's a darn sight better than the current SLS process. After all, in World War 2, it's not as if the US Army Air Corps (and later, the US Army Air Force) designed every plane that it acquired. It put out requirements and solicited designs from aircraft manufacturers like Boeing, Curtiss, Vought, Douglas, etc. Now that rocketry is no longer an unproven and speculative endeavor, we should do the same, and seek to build up multiple competing rocket manufacturers

\- Giving near-Earth science to NOAA: Right now, Earth-focused satellites are split between NASA and NOAA. Giving a single agency responsibility for Earth- focused scientific satellites will ensure that they have a single clear voice advocating on their behalf

\- Sending the astronaut program back to the Air Force (or maybe create the much ballyhooed "Space Force")

\- Creating a new, smaller, more focused organization for exploration of deep space (i.e. space beyond Earth's gravity well). While this organization _could_ wear NASA's logos, I think it would be better if there were a clean break with the past and the organization got a new name and new branding

<comment><USER17> This is a terrible idea. NASA is still the best agency in the world for moving humanity forward, even with bureaucratic inefficiencies. No other agency will have the funds to do what NASA does for non-military reasons.

For every tax dollar spent, the U.S. still gets about 7 times the return.

<comment><USER26> What do you mean by "7 times the return"? In productivity increases via. technology? In just the fiscal multiplier effect? In keeping decrepit, middle- of-nowhere NASA departments up and running?

</comment></comment></comment><comment><USER27> Polls show that ordinary people don't care about the Moon and Mars.

There is actually more support for planetary protection from asteroids, space- based observation of both Earth and Sky (people love the Hubble), resource utilization in space, etc... That is, the real Gerard K. O'Neil stuff.

If it were me I would set a goal of building a sunscreen at the Earth-Sun L1 point (e.g. planetary protection) using lunar or asteroid materials -- something like the lunar gateway would be an ideal crossing point for that. Space-solar power could be a byproduct of these efforts. This should have the urgency of Space Battleship Yamato (aka Star Blazers.)

The lunar gateway is also essential to long-term deep space exploration. One place where Obama was totally wrong was going to Mars without going to the Moon first. Since a Mars mission is going to be isolated from Earth for so long, we need to know that all of the technology is completely reliable and the best way to do that is get it to the point where going to the Moon is like riding the bus.

Radiation exposure in deep space is a known problem with the known solution of using space resources to build a radiation shield. This could be lunar or asteroidal rock and ought to be an early goal.

I am also very curious about Lunar geology and also the possibility that the moon has hidden sources of volatiles. People talk about the water, but you also need Carbon and Nitrogen as well as Phosphorous and Potassium to grow plants and run an economy. (Also you can't breath pure oxygen unless you want to end up like the Apollo 1 astronauts)

</comment><comment><USER28> One of the things the anti-station crowd misses is that giant rockets like Apollo are pretty expensive and wasteful. Apollo was great for getting us to the Moon first, but not necessarily for continuing to go there.

An ideal would be at the very least a place for the lander to dock and refuel during the return trip. Then you don't have to haul a lander on every single mission, and thus can use a smaller/cheaper rocket with just the (reusable!) crew module.

</comment><comment><USER29> I think one of the great potentials of commercial space exploration (and exploitation) is better long term focus (and stable leadership). Changing the mission every 4 or 8 years is not conducive with this stage of space exploration.

</comment><comment><USER30> The earth-orbiting ISS is only marginally useful. Who needs another money drain around around Luna?

Moon Direct probably makes the most sense. It needs only the Falcon Heavy (about $150 million per launch) as a booster. That's a real rocket that's flown. No need for NASA's vaporware Space Lanch System ($14 billion spent so far over 8 years, still unfinished, zero launches.)

Apollo did it with one giant launch, but now that assembling systems in orbit has been done many times, there's no real reason to build something the size of the Saturn V again.

</comment><comment><USER31> The whole idea of the Senate Launch System (SLS) is flawed from the start. When NASA has been at its finest, it has been on the edge of innovation. Think Apollo, Shuttle, ISS, all the Mars Landers, the Voyagers, Cassini, New Horizons, etc.

So why is NASA wasting billions to make a rocket, something we've known how to do reliability for more than 50 years? The reason is simple - politics. NASA is a political agency. They suffer from the same short-sighted, narrow focus thinking that a lot of other areas in policy live with. This is what hamstrings NASA the most, the constant change in directive, especially with regards to human spaceflight.

There are commercial alternatives that can already provide heavy lift capability, or at the very least are well positioned to take $1-3B and get one with even heavier capabilities flying. NASA is far too risk adverse these days to be building a rocket or a crew vehicle. They figured this out for commercial crew, why can't they figure it out for other architectures? Imagine NASA being able to cut the $2.5B/year line item that SLS has ballooned to and redirect that to other human spaceflight goals. Leaving commercial companies to build does not mean NASA is entirely removed from the process, for example ULA/SpaceX have been heavily reliant on knowledge transfer and oversight from NASA on their path towards commercial crew.

Honestly, having just graduated from a top aerospace/electrical engineering school and having experience in the industry myself, this is why you see the top talent going to places like SpaceX, Blue Origin, and a whole host of other commercial companies. These companies have a clear vision that NASA lacks. The NASA centers recent graduates gravitate towards are Caltech/JPL and APL/Goddard because they operate (almost) entirely independently from the rest of bureaucratic monster with serious research and a get-it-done attitude. A lot of the work at other facilities is farmed out to commercial companies, leaving a lot of NASA people in oversight/paperwork heavy jobs. This is not a blanket statement, but there is certainly a lot of "one technician doing the work and 5 engineers watching him" going on.

So if you follow the idea that NASA belongs at the forefront of research, what type of work do they do? Well, they are research heavy and build only the most advanced tech as a result. They research Mars and build rovers/architecture to further that research and get humans there. They conduct research on the ISS to further medicine for people back on Earth and learn about long term "0g" exposure. They research deepspace travel and build lunar gateways and architecture to support that. They build drones to go to Titan, build probes to fly by outer planets, etc. And then, they pay a commercial company to fly it for them (just because NASA did the bulk of the research that enables current rockets to be so successful does NOT mean they have to continue being the one making the rocket. Yes SLS has Boeing as a primary contractor, but the point is it's branded as a NASA rocket).

</comment><comment><USER32> Sounds like it could be good if you want to go there repeatedly, bad if you just want to get there as fast as possible again.

</comment><comment><USER33> on one hand I agree that a lunar base would be a cheaper option for a wealth of reasons including not having to refuel orbit keeping rockets, however, landing supply is far more risky than docking supply, which compound with the mission's distance and scope: failing a shipment is always an eventuality, but losing it at launch is far worse than losing it on arrival, in the first case you know immediately, in the other you know 2-3 weeks later, and that influences how large your stockpile needs to be.

what I'd say would be useful is if this station was the stepping stone for a lunar space elevator. then it would be a great investment and a true stepping stone for a permanent lunar presence, but a stationary orbit around the moon is impossible (too far, you'd fall on earth), so the tether would actually have to anchor the station.

</comment><comment><USER34> Given the exponential nature of Tsiolkovsky's rocket equation, I don't understand why its not common to perform multiple launches from the ground to LEO, and then rendezvous in orbit and go to the moon, or mars, or whereever.

If I'm understanding the mechanics properly (informed mostly by kerbal space program!) the biggest "expense" in traveling most places is getting into LEO. And every doubling of payload requires more than doubling of fuel. All of which requires significantly larger and more complex rockets.

Either I'm misunderstanding the true costs of launches (I know the fuel itself is relatively cheap) or I'm underestimating the complexity of linking two spacecraft in a robust and rigid connection while in orbit.

<comment><USER35> TNSTAAFL. I think you're misunderstanding that equation?

You're trying to get to orbit, so hold _v_ and delta- _v_ constant. Then you have the ratio of "wet" to "dry" masses constant. So the more you're launching, the more fuel it takes, and that is linear. I don't see how physics would work otherwise?

<comment><USER36> The ratio of wet and dry masses for a launch vehicle also depends on ISP, thrust, and aerodynamics. You can have an extremely high ISP and thus a lot of theoretical delta-v but you waste it all because your thrust ratio is below 1 and the vehicle can't leave the ground.

Over a certain size you can't build up anymore and have to make the vehicle flat. This is because a certain surface area of exhaust nozzle can only provide so much thrust. So you get to about 100m and then your rocket can't leave the ground because the mass of propellant is higher than the available thrust.

Then there's thrust to weight, meaning that to get off the ground and about two minutes into your launch it is far more important to have a lot of thrust than to have high efficiency. The rule of thumb for KSP players is 1.2 thrust to weight on the ground. You will fight gravity losses and end up with about 0.2g acceleration off the pad. This increases gradually as the mass of the vessel is burnt off.

Later in flight the major force to overcome is atmospheric drag. The faster you go, the worse it gets. Fat rockets will have a harder time. So you can't go too wide, you can't go too tall, and there are many trade offs to be made along the way.

But the short version is no, you don't hold v and delta-v constant. There are many more variables to consider when launching a rocket from a standing start where gravity and an atmosphere are involved.

Rockets do not scale linearly.

<comment><USER35> Yes of course rocketry is complicated. ITT we're discussing the specific question that parent raised: are a bunch of small-payload rockets more efficient than on big-payload rocket? We assume that actual engineers have done the work of designing rockets that actually reach orbit, whether small or large; that's why we assume equal velocities. Any particular orbit is characterized by a specific orbital energy. Tsiolkovsky certainly considers the effects of gravity; that's the point.

</comment></comment></comment></comment><comment><USER37> The genius of LOP-G is that it can be converted back to an asteroid intercept platform (its original purpose) should the next president decide to change NASA's mission yet again.

</comment><comment><USER38> Would building a lunar space station get us closer to being able to deflect mass extinction sized asteroids?

<comment><USER39> Of course it would.

But the important question is "how much closer". That would be much harder to answer.

<comment><USER38> Is there anyone from NASA or SpaceX here that could offer some opinions on how much closer we could get to deflecting / mining mass extinction asteroids?

</comment></comment></comment><comment><USER40> Out of curiosity, why isn't the gateway being planned for the Earth/Moon L1 point?

</comment><comment><USER41> Going back to the moon is just busy work to distract from the fact they don't have the funding or the ambition to get to Mars.

<comment><USER42> Going back the moon is the logical next step in going to Mars. You don't send off materials and bodies in the hope that years later it will work out.

[https://en.wikipedia.org/wiki/List_of_missions_to_the_Moon](https://en.wikipedia.org/wiki/List_of_missions_to_the_Moon)

It took many attempts to get a successful moon mission where we landed. How many more before we could dig into the rock for a habitat? Now multiply the time by the round trip to Mars. The fantasy of being on Mars in X years is fraught with dangers that include our own imperfection in execution. Don't expect a man on Mars in your lifetime, at least not one who comes back.

<comment><USER43> Indeed, the Moon is the best location to develop and perfect technologies to settle on another planet and to live there autonomously.

Because it's very near it's obviously much faster and cheaper to ship things there, and it allows near-instant communication back and forth.

Once the technologies are mature it will just be a question of longer shipping to mars or anywhere else.

<comment><USER41> No, earth is the best place to develop technologies to settle on another world. Planning a moon base when we can't even build and run a sealed biosphere on earth is like looking for sponsors for your F-1 team before learning how to drive a car.

<comment><USER44> Why would you need a fully sealed biosphere? It's not like we're going on a solitary one way trip. We've kept the ISS running for enough years to prove that, in terms of biosphere anyway, we have the technology to build a base on the moon or Mars.

<comment><USER41> >Indeed, the Moon is the best location to develop and perfect technologies to settle on another planet and to live there autonomously.

So which is it? Do we need to build a base on the moon to develop technologies to let us settle Mars or do we not need to go to the moon at all because we already have the technology to build a Mars base?

<comment><USER44> I responded to something you said. You're quoting something that I never said at me while completely ignoring the substance of my comment. That's no way to have a rational conversation.</comment></comment></comment></comment></comment></comment></comment>


Why Comp Sci Grads Can't Hack (and why you need them anyway) - <AUTHOR> http://lispy.wordpress.com/2007/11/30/why-compsci-grads-cant-hack-and-why-you-need-them-anyway/ <comment><USER2> I call em DayCoders and thats all they are. Fair enough they do the work and make a living but I still find companies hiring them over people without a degree just because of that piece of paper. I think the HR departments need to get past the college education and look at the details. I will only employ people that I feel have a passion regardless of any degree.

</comment><comment><USER3> This month I just finished my BS in CS. I set out to complete it over 11 years ago, in 1996. In 1997 I started working full time and have accrued over 10 years experience in qa, operations and sysadmin, software development, software engineering, management, and more. The CS classes I'd taken along the way each contributed to my abilities, but out of context I can certainly see how if I had waited to finish my degree to enter the work force, I'd have been at a serious disadvantage. Along the way, I never encountered a significant roadblock finding a job because I didn't have my degree - most employers never asked because I had enough experience after 2 years or so full time.

</comment><comment><USER4> Sturgeon's law strikes again.</comment>