6 ms·

Am I the only one whose first reaction to this is "Oh, great, yet another manner in which my next application won't be cross-platform?" My second reaction bein

by Yoric 8y ago

Am I the only one whose first reaction to this is "Oh, great, yet another manner in which my next application won't be cross-platform?" My second reaction being: "Oh, well, I'll just make it a web app instead of a native app." edit Rephrased the last sentence.

trothamel 8y ago
And I'm now wondering how long it'll be until Apple deprecates Sockets.
deleted 8y ago
[deleted]
pjmlp 8y ago
Not everyone cares about cross-platform, some developers rather specialize in a given platform. You can keep using sockets if that is your thing.
- Yoric 8y ago
  > Not everyone cares about cross-platform, some developers rather specialize in a given platform. True. > You can keep using sockets if that is your thing. For the moment, yes. However, as you know, earlier this week, Apple has officially deprecated OpenGL and OpenCL, a few years after introducing a competing (and admittedly suprerior) API. It is my understanding that Apple has not attempted to get this replacement API standardized, nor to offer it on any other platform. While it's hard to deduce from such a small sample, this precedent does suggest that the days of sockets are numbered. This would make the life of some of my colleagues quite more complicated, and it would, in time, simply get rid of the macOS version of a number of existing cross-platform applications whose authors have neither the time nor the energy to rewrite the network layer.
  - pjmlp 8y ago
    Every effort to get rid of plain unsafe C APIs is a plus on my book. Apple has enough business with developers that care about macOS experience, not plain ports from other platforms. When I buy a computer with a specific OS, I want the experience provided by the OS APIs.
    - kitsunesoba 8y ago
      Yes precisely. I’m sure this varies from person to person but the applications that have the most staying power in my tool belt by far are those that are well executed first class citizens of my platform of choice. Cross platform apps written by developers who are more concerned with an easy one size fits all solution nearly always fall to the wayside. I chose the platform I use for a reason. Why should I be ok with apps that undermine that by taking the lowest common denominator approach to porting?
      - falcolas 8y ago
        Interesting. As a counterpoint, if I look at the toolkit I'm using right now on my MacBook, it's: Chrome Firefox Hipchat Vim Git So, not one single-platform tool in the bunch. I'd even go so far to say that, aside from my terminal emulator and app install tool, I don't use any single-platform tools in my day to day job. > Why should I be ok with apps that undermine that by taking the lowest common denominator approach to porting? Because they're, in many cases, as good if not better than the native-only alternatives?
        kitsunesoba 8y ago
        I guess it depends on what types of apps one tends to use and what work you do. While I make frequent use of the terminal, I live in UI apps all day, so bad ports tend to stick out more prominently. If I lived in vim or emacs I could see it not mattering as much.
        jose_zap 8y ago
        Do you use iTerm for opening vim?
        jexah 8y ago
        Clutching at straws.
    - geodel 8y ago
      I agree. I extend same to other software like databases etc. I have seen so many project over abstract and that turns out useless when migrating or supporting additional backend with same abstracted solution.
  - jrs95 8y ago
    OpenCL didn't seem to be succeeding, so that's not entirely surprising. It is disappointing that they've chosen to deprecate OpenGL and ignore Vulcan in favor of Metal, though. Although I don't know much about this particular area, and I couldn't tell you about the merits of Vulcan vs Metal. It's hard to tell whether there's any good technical reasons for their decisions or if it's purely just business in that they don't want to contribute their resources to something that will benefit Android.
    - doctorsher 8y ago
      Admittedly, I am also not well versed in this area. My guess is, because Metal is proprietary, they can include intimate details of their hardware platform to squeeze out the most performance. And they probably would not feel comfortable having that same level of detail in Vulcan.
      - MBCook 8y ago
        They also started making/using (and deploying?) Metal before Vulkan was announced/available. Doesn’t mean they couldn’t have changed course, but I’m sure it was a factor.
        ovao 8y ago
        And they may still yet change course. At this point it’s hard to say.
- vesinisa 8y ago
  > Not everyone cares about cross-platform, some developers rather specialize in a given platform. Yeah. This is exactly what people thought in the early 2000s of IE6. It was the de facto 'standard' web browser. Whole enterprises were built on the assumption that no other browser matters. But the world around changed. IE6 became obsolete. Then insecure. People kept running it to use the old apps that would not work on modern browsers. But eventually, IE6 had to be buried. Thousands of apps containing billions of lines of code had to be re-written at an astronomical cost. Just because, for a short while, we once thought specializing on one platform was a sustainable long-term strategy.
  - pjmlp 8y ago
    Which is why those devs now specialize in Chrome instead.
    - Yoric 8y ago
      Sad but largely true. On the other hand, it is easier to install Chrome on your machine, if you need a Chrome-locked webapp, than to install macOS on the same machine. In fact, the only platform on which you cannot install a Chromium-based Chrome is iOS, and that's a political choice by Apple. edit Rephrased entirely.
      - dwaite 8y ago
        Blocking all third party code (and most first party code) from creating executable pages is a pretty strong security decision, but yes it has political ramifications.
  - ksk 8y ago
    You are claiming a false dichotomy. Specialization doesn't mean future-deprecation. Every single cross-platform app is written to an abstraction. There is no implicit assumption that all abstractions are good. Whenever I hear cross-platform code I think slow bloated web-apps or slow bloated java apps with a funky UI. Websites written for IE6 can still be used today with minor changes. The problem is activex and other crappy plugin technologies. If people had just targeted Win32, those apps would still be working today - but probably still end up requiring a rewrite because of modern security requirements.
- api 8y ago
  You can also code in a language with good cross platform network APIs like Go or use a wrapper library like boost::asio or libuv. The latter are likely to add support for this eventually if there is a strong benefit to doing so on MacOS. I'm ambivalent about platform-specific solutions but I welcome any attempt to obsolete socket() and select()/poll() and friends. I absolutely loathe that API.
- xHopen 8y ago
  I couldn‘t care less about cross Platform honestly, and yeah the most of the mobile market use Andoird, well, the android user (average) don‘t download apps, do not spend money in apps, so... is out of my target.
  - jexah 8y ago
    Wot. Citation needed? I may not be an "android user (average)" but I download apps every day (paid and free) and have spent far more money than I'd like to admit on the Play Store.
s73v3r_ 8y ago
If you're writing it in Swift, you're probably doing native apps anyway. So there isn't much reason to not use the native things the platform provides.
- deleted 8y ago
  [deleted]
- coldcode 8y ago
  At our company (in one of the largest companies in the US) all of our employee related tools are iOS devices. So cross platform is unnecessary. It's not like we standardized on Palm or Windows Phone, Apple is not going anywhere and neither are we.
  - deleted 8y ago
    [deleted]
  - Yoric 8y ago
    Well, Apple has demonstrated more than once that they are willing to U-Turn and entirely drop core technologies. By opposition, Linuxen and Microsoft try very hard to avoid breaking applications. So, while Apple is not going anywhere, whichever technologies you're using to build your iOS apps might.
    - pram 8y ago
      Microsoft intentionally broke compatibility with every major release of Windows Phone though, and then ultimately killed the entire platform?
      - Yoric 8y ago
        Ah? I wasn't aware of that. Still, that doesn't mean that Apple won't :)
        saagarjha 8y ago
zamalek 8y ago
> yet another manner in which my next application won't be cross-platform I skimmed the video and it really looks like sockets++: once you have the connection the rest is up to you. It doesn't seem to break anything on the wire. Unless you're referring to compilation - but we can assume that Libuv will soon abstract this platform away (just like it does with Windows IOCP).
int0x80 8y ago
1st thing: The people here asking if they are going to deprecate BSD sockets. No way that is going to happen. We are talking about 30yo+ API deeply integrated in the kernel, unix and userspace. OpenGL/CL is a very very different case. It's always been a third party thing an doesnt have the same level of usage. Not even close. 2. Not everything is a webapp or http. You may absolutely need to use the raw network without any encapsulation. This posibility must simply not die. Its true that most people will not need to use this apis and will use a http webapp. On the API itself. I think it is a really good idea to make a new generic tcp/udp library. With everything we use today included, and as a first class citizen from the first minute of the design. The particular API they present looks good and it is very well thought out. Mostly integrates async tcp/upd/tls seemless and supports changing interfaces on the fly. This alone is a big improvement. Does this while still providing raw access to the out/input net queues. You can even access the lowlevel details and parameters if you want or need to. However this is not the first modern network API. QT (qt network) has a good network layer for one. There are simpler alternatives: libuv, libevent etc. This are more speciallized and dont handle all that Network.framework offers.
- Yoric 8y ago
  > 1st thing: The people here asking if they are going to deprecate BSD sockets. No way that is going to happen. We are talking about 30yo+ API deeply integrated in the kernel, unix and userspace. OpenGL/CL is a very very different case. It's always been a third party thing an doesnt have the same level of usage. Not even close. I agree that removing sockets would break large chunks of the ecosystem. On the other hand, after OpenGL's removal, it's not clear to me that Apple cares anymore about anything outside of Cocoa. > 2. Not everything is a webapp or http. You may absolutely need to use the raw network without any encapsulation. This posibility must simply not die. Its true that most people will not need to use this apis and will use a http webapp. Of course. Nearly 100% of my code is not webapp/http. Which is why I'm annoyed when I see (or in this case, fear) cross-platform APIs disappear. > On the API itself. I think it is a really good idea to make a new generic tcp/udp library. [...] I have no problem with a new, better, API. But I would certainly be more enthusiastic if any effort was presented to make it cross-platform and, hopefully, open-source and/or standardized.

by Yoric 8y ago

trothamel 8y ago

And I'm now wondering how long it'll be until Apple deprecates Sockets.

deleted 8y ago

[deleted]

pjmlp 8y ago

Not everyone cares about cross-platform, some developers rather specialize in a given platform. You can keep using sockets if that is your thing.

Yoric 8y ago
> Not everyone cares about cross-platform, some developers rather specialize in a given platform. True. > You can keep using sockets if that is your thing. For the moment, yes. However, as you know, earlier this week, Apple has officially deprecated OpenGL and OpenCL, a few years after introducing a competing (and admittedly suprerior) API. It is my understanding that Apple has not attempted to get this replacement API standardized, nor to offer it on any other platform. While it's hard to deduce from such a small sample, this precedent does suggest that the days of sockets are numbered. This would make the life of some of my colleagues quite more complicated, and it would, in time, simply get rid of the macOS version of a number of existing cross-platform applications whose authors have neither the time nor the energy to rewrite the network layer.
- pjmlp 8y ago
  Every effort to get rid of plain unsafe C APIs is a plus on my book. Apple has enough business with developers that care about macOS experience, not plain ports from other platforms. When I buy a computer with a specific OS, I want the experience provided by the OS APIs.
  - kitsunesoba 8y ago
    Yes precisely. I’m sure this varies from person to person but the applications that have the most staying power in my tool belt by far are those that are well executed first class citizens of my platform of choice. Cross platform apps written by developers who are more concerned with an easy one size fits all solution nearly always fall to the wayside. I chose the platform I use for a reason. Why should I be ok with apps that undermine that by taking the lowest common denominator approach to porting?
    - falcolas 8y ago
      Interesting. As a counterpoint, if I look at the toolkit I'm using right now on my MacBook, it's: Chrome Firefox Hipchat Vim Git So, not one single-platform tool in the bunch. I'd even go so far to say that, aside from my terminal emulator and app install tool, I don't use any single-platform tools in my day to day job. > Why should I be ok with apps that undermine that by taking the lowest common denominator approach to porting? Because they're, in many cases, as good if not better than the native-only alternatives?
      - kitsunesoba 8y ago
        I guess it depends on what types of apps one tends to use and what work you do. While I make frequent use of the terminal, I live in UI apps all day, so bad ports tend to stick out more prominently. If I lived in vim or emacs I could see it not mattering as much.
      - jose_zap 8y ago
        Do you use iTerm for opening vim?
        jexah 8y ago
        Clutching at straws.
  - geodel 8y ago
    I agree. I extend same to other software like databases etc. I have seen so many project over abstract and that turns out useless when migrating or supporting additional backend with same abstracted solution.
- jrs95 8y ago
  OpenCL didn't seem to be succeeding, so that's not entirely surprising. It is disappointing that they've chosen to deprecate OpenGL and ignore Vulcan in favor of Metal, though. Although I don't know much about this particular area, and I couldn't tell you about the merits of Vulcan vs Metal. It's hard to tell whether there's any good technical reasons for their decisions or if it's purely just business in that they don't want to contribute their resources to something that will benefit Android.
  - doctorsher 8y ago
    Admittedly, I am also not well versed in this area. My guess is, because Metal is proprietary, they can include intimate details of their hardware platform to squeeze out the most performance. And they probably would not feel comfortable having that same level of detail in Vulcan.
    - MBCook 8y ago
      They also started making/using (and deploying?) Metal before Vulkan was announced/available. Doesn’t mean they couldn’t have changed course, but I’m sure it was a factor.
      - ovao 8y ago
        And they may still yet change course. At this point it’s hard to say.
vesinisa 8y ago
> Not everyone cares about cross-platform, some developers rather specialize in a given platform. Yeah. This is exactly what people thought in the early 2000s of IE6. It was the de facto 'standard' web browser. Whole enterprises were built on the assumption that no other browser matters. But the world around changed. IE6 became obsolete. Then insecure. People kept running it to use the old apps that would not work on modern browsers. But eventually, IE6 had to be buried. Thousands of apps containing billions of lines of code had to be re-written at an astronomical cost. Just because, for a short while, we once thought specializing on one platform was a sustainable long-term strategy.
- pjmlp 8y ago
  Which is why those devs now specialize in Chrome instead.
  - Yoric 8y ago
    Sad but largely true. On the other hand, it is easier to install Chrome on your machine, if you need a Chrome-locked webapp, than to install macOS on the same machine. In fact, the only platform on which you cannot install a Chromium-based Chrome is iOS, and that's a political choice by Apple. edit Rephrased entirely.
    - dwaite 8y ago
      Blocking all third party code (and most first party code) from creating executable pages is a pretty strong security decision, but yes it has political ramifications.
- ksk 8y ago
  You are claiming a false dichotomy. Specialization doesn't mean future-deprecation. Every single cross-platform app is written to an abstraction. There is no implicit assumption that all abstractions are good. Whenever I hear cross-platform code I think slow bloated web-apps or slow bloated java apps with a funky UI. Websites written for IE6 can still be used today with minor changes. The problem is activex and other crappy plugin technologies. If people had just targeted Win32, those apps would still be working today - but probably still end up requiring a rewrite because of modern security requirements.
api 8y ago
You can also code in a language with good cross platform network APIs like Go or use a wrapper library like boost::asio or libuv. The latter are likely to add support for this eventually if there is a strong benefit to doing so on MacOS. I'm ambivalent about platform-specific solutions but I welcome any attempt to obsolete socket() and select()/poll() and friends. I absolutely loathe that API.
xHopen 8y ago
I couldn‘t care less about cross Platform honestly, and yeah the most of the mobile market use Andoird, well, the android user (average) don‘t download apps, do not spend money in apps, so... is out of my target.
- jexah 8y ago
  Wot. Citation needed? I may not be an "android user (average)" but I download apps every day (paid and free) and have spent far more money than I'd like to admit on the Play Store.

s73v3r_ 8y ago

If you're writing it in Swift, you're probably doing native apps anyway. So there isn't much reason to not use the native things the platform provides.

deleted 8y ago
[deleted]
coldcode 8y ago
At our company (in one of the largest companies in the US) all of our employee related tools are iOS devices. So cross platform is unnecessary. It's not like we standardized on Palm or Windows Phone, Apple is not going anywhere and neither are we.
- deleted 8y ago
  [deleted]
- Yoric 8y ago
  Well, Apple has demonstrated more than once that they are willing to U-Turn and entirely drop core technologies. By opposition, Linuxen and Microsoft try very hard to avoid breaking applications. So, while Apple is not going anywhere, whichever technologies you're using to build your iOS apps might.
  - pram 8y ago
    Microsoft intentionally broke compatibility with every major release of Windows Phone though, and then ultimately killed the entire platform?
    - Yoric 8y ago
      Ah? I wasn't aware of that. Still, that doesn't mean that Apple won't :)
      - saagarjha 8y ago

zamalek 8y ago

> yet another manner in which my next application won't be cross-platform I skimmed the video and it really looks like sockets++: once you have the connection the rest is up to you. It doesn't seem to break anything on the wire. Unless you're referring to compilation - but we can assume that Libuv will soon abstract this platform away (just like it does with Windows IOCP).

int0x80 8y ago

1st thing: The people here asking if they are going to deprecate BSD sockets. No way that is going to happen. We are talking about 30yo+ API deeply integrated in the kernel, unix and userspace. OpenGL/CL is a very very different case. It's always been a third party thing an doesnt have the same level of usage. Not even close. 2. Not everything is a webapp or http. You may absolutely need to use the raw network without any encapsulation. This posibility must simply not die. Its true that most people will not need to use this apis and will use a http webapp. On the API itself. I think it is a really good idea to make a new generic tcp/udp library. With everything we use today included, and as a first class citizen from the first minute of the design. The particular API they present looks good and it is very well thought out. Mostly integrates async tcp/upd/tls seemless and supports changing interfaces on the fly. This alone is a big improvement. Does this while still providing raw access to the out/input net queues. You can even access the lowlevel details and parameters if you want or need to. However this is not the first modern network API. QT (qt network) has a good network layer for one. There are simpler alternatives: libuv, libevent etc. This are more speciallized and dont handle all that Network.framework offers.

Yoric 8y ago
> 1st thing: The people here asking if they are going to deprecate BSD sockets. No way that is going to happen. We are talking about 30yo+ API deeply integrated in the kernel, unix and userspace. OpenGL/CL is a very very different case. It's always been a third party thing an doesnt have the same level of usage. Not even close. I agree that removing sockets would break large chunks of the ecosystem. On the other hand, after OpenGL's removal, it's not clear to me that Apple cares anymore about anything outside of Cocoa. > 2. Not everything is a webapp or http. You may absolutely need to use the raw network without any encapsulation. This posibility must simply not die. Its true that most people will not need to use this apis and will use a http webapp. Of course. Nearly 100% of my code is not webapp/http. Which is why I'm annoyed when I see (or in this case, fear) cross-platform APIs disappear. > On the API itself. I think it is a really good idea to make a new generic tcp/udp library. [...] I have no problem with a new, better, API. But I would certainly be more enthusiastic if any effort was presented to make it cross-platform and, hopefully, open-source and/or standardized.