Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

65535 interfaces ought to be enough for anybody

aakinshin.net

Post reply on HN
Print view View original

71–80 of 82 posts

Re: 65535 interfaces ought to be enough for anybody

#71

Post by BoorishBears »

Benjammer wrote: post #69
orbitur wrote: post #58

Earlier quoted context omitted.

When you deploy release-like builds to your QA team (as you should), a tripled-build time is a bit problematic if you're trying to iterate quickly.

Who needs to "iterate" so quickly that several minutes added to your build time becomes a huge issue?

Me? I work on embedded android installations that have over a thousand years combined of running with 0 software crashes. Once I get to a certain point in developing an app for our installations I start profiling for the slightest memory leaks by watching changes in memory usage profiles for different user flows.

And I can only do that with release builds if I want useful numbers. I've had us split up apps over build times because of Multidex (for example, most of our AWS centric code lives in a separate app that exposes specific functions via an AIDL interface because the SDK was bringing in too many methods)

Re: 65535 interfaces ought to be enough for anybody

#72

Post by Retra »

revelation wrote: post #55
overgard wrote: post #37

Earlier quoted context omitted.

Packet size is important. If your ports are strings, every packet gets that much bigger. Nobody wants slow internet for programming convenience.

It's not even convenient. Strings are one of the biggest scourges of any programming language out there. Giant mess in basically every language until Java got it somewhat right, and even then don't forget your equals... C# (.NET) could be the forerunner if only they had not gone with UTF16, but then it's only with hindsight that we can point out UTF8.

Strings are only a problem because they are being treated as text. In this case, they would simply be treated as binary identifiers, so there is no problem. The raw bytes would do just as well for this kind of thing.

Re: 65535 interfaces ought to be enough for anybody

#73

Post by jmiserez »

Retra wrote: post #72
revelation wrote: post #55

Earlier quoted context omitted.

It's not even convenient. Strings are one of the biggest scourges of any programming language out there. Giant mess in basically every language until Java got it somewhat right, and even then don't forget your equals... C# (.NET) could be the forerunner if only they had not gone with UTF16, but then it's only with hindsight that we can point out UTF8.

Strings are only a problem because they are being treated as text. In this case, they would simply be treated as binary identifiers, so there is no problem. The raw bytes would do just as well for this kind of thing.

Only if they are fixed length. If you used variable length strings in packet headers things would get complicated.

But if you're fine with fixed-length strings, you could just as well use all those bits to represent a number instead.

Re: 65535 interfaces ought to be enough for anybody

#74

Post by paulddraper »

duskwuff wrote: post #33
paulddraper wrote: post #24

Earlier quoted context omitted.

Well, for counts 32 bits is enough, unless you count something really small, like every individual byte in something. And for counts 64 bits should be enough, since it's 20 billion billion.

For counts of things you have in memory, 32 bits is usually enough -- even if each thing is just 8 bytes, 2^32 of those objects would require 32 GB.

You mean 4GB.

And yes, 32-bit programs can't use more then 4GB.

Re: 65535 interfaces ought to be enough for anybody

#75

Post by duskwuff »

paulddraper wrote: post #74
duskwuff wrote: post #33

Earlier quoted context omitted.

For counts of things you have in memory, 32 bits is usually enough -- even if each thing is just 8 bytes, 2^32 of those objects would require 32 GB.

You mean 4GB. And yes, 32-bit programs can't use more then 4GB.

No, I mean 32 GB -- 2^32 x 8 bytes. We're discussing 32-bit integers, not pointers.

Re: 65535 interfaces ought to be enough for anybody

#76

Post by detaro »

duskwuff wrote: post #68
jandrese wrote: post #48

Earlier quoted context omitted.

32GB isn't an exceptional amount of memory these days.

Sure -- but it is an exceptional amount of memory to use for tiny objects like those. If you're working with four billion objects at a time, they're probably more substantial than eight bytes.

Or you spent a lot of effort to get them to 8 bytes or even smaller, to fit as many of them as possible in memory. See use-cases like time-series/analytics databases, point-clouds, simulations with many elements...

Re: 65535 interfaces ought to be enough for anybody

#77

Post by kelnos »

Cyph0n wrote: post #17
kelnos wrote: post #16

Earlier quoted context omitted.

IIRC the Facebook app had many more than that at one point, and had to use multi-dexing. Not sure if that's still the case. I've also heard that scala apps on Android can sometimes hit the limit, because pulling in the scala stdlib greatly bloats the method count.

Wasn't that the initial reason behind splitting off Messenger into a separate app?

I don't know, but I would doubt it. Making such a huge product decision based on an engineering limitation (that has a workaround) seems like a poor idea.

Re: 65535 interfaces ought to be enough for anybody

#78

Post by josefx »

monocasa wrote: post #60
vkou wrote: post #56

Earlier quoted context omitted.

Java's crippled generics, lack of tuple support, and lack of default parameters encourage interface bloat in utility libraries. Given how bloody good Java IDEs are (By which I mean to say - how good IntelliJ is), the cognitive cost of this interface bloat is very low... Until you start developing for Android.

Wouldn't Java's crippled generics actually help reduce the method count since due to type erasure they're all the same method at the VM level anyway?

On the one hand yes, on the other hand Java also generates Bridge methods when you implement a generic interface. A MyType implementing Comparable will contain a compareTo( MyType ) method and a generated compareTo( Comparable ) bridge method.

It is more likely that generated classes, countless getters and setters and a tendency to small methods has a higher impact.

Re: 65535 interfaces ought to be enough for anybody

#79

Post by brokenmachine »

tangent128 wrote: post #31
sixothree wrote: post #25

Earlier quoted context omitted.

I find it extremely awkward that we actually use numbers for ports. Port 80 is typically used for HTTP, but there's nothing preventing another application from using port 80. Why not call the port "HTTP" instead. Better yet why not give it an integer range of ports to go along with the naming - Eg MyApp[1], MyApp[2]. If you want to hide a port from being probed then give it a GUID as a name. No more port scans.

At the time TCP/UDP were invented, keeping packet size small was very important. A string or GUID as addressing information would have been out of the question. (If there wasn't a need to distinguish multiple clients on the same machine, we might have only had 255 ports!) A standard port for HTTP servers is needed, as most HTTP clients don't support DNS SRV records. That said, in the IPv6 world there's no technical r…

> in the IPv6 world there's no technical reason you can't just let every service bind a different IP address.

I'm not a networking expert, but is that true that you can create multiple ip's for a single device using ipv6? Sounds like it would end up very messy.

Re: 65535 interfaces ought to be enough for anybody

#80

Post by karmelapple »

Benjammer wrote: post #70
karmelapple wrote: post #54

Earlier quoted context omitted.

Our app's build time ballooned by 2-3X or more when we went to multidex. We've had some luck reducing it, but we'd still like to axe multidex. I definitely consider a 3X build time increase (not 30 seconds to 90 seconds, but 1 or 2 min to 5-8) to be a significant problem, bordering on nightmare... especially since we just included a few more libraries that put us past the 65k mark. Is that what other people have seen…

How is your dev pipeline set up such that an 8 minute release build becomes such a problem?

I guess I'm thinking of builds on my machine taking that long, not even release builds.
Post reply on HN