7 ms·

On the other hand I can't wait when Swift becomes general, non-Apple language, available on most platforms (including the most popular one) "with batteries" - t

by zerr 9y ago

On the other hand I can't wait when Swift becomes general, non-Apple language, available on most platforms (including the most popular one) "with batteries" - that will be the end of Go and Rust I think :)

rf15 9y ago
while I think that that would be a good thing (I like what happened with C#), I see the languages specified and controlled by Microsoft, Google and Apple as second-class languages, since they are often lacking in community input and are usually designed with certain platform-specific goals in mind instead of being cross-platform. (or company-strategic goals when it comes to Google)
- blub 9y ago
  Yes, there's something not quite right with these company languages. Whoever is smart will take note of what happened to VisualBasic and is happening to Objective-C.
  - pjmlp 9y ago
    You mean like C and C++ being developed at AT&T, nowadays designed at ANSI, with people on ARM, Google, Apple, Blommberg, Sony, IBM, Microsoft's payroll?
    - blub 9y ago
      Looking into the past can have some predictive value, but looking that far back and at a different company is of very limited value. If one evaluates C# they should obviously look at what MS are doing. Same thing for Swift and Apple.
      - pjmlp 9y ago
        If Google, Apple or Microsoft take their employees out of ANSI or from GCC/LLVM contributions, I can assure you they won't move much beyond the current state.
        blub 9y ago
        What are the odds that all big players would remove support for something that their platforms are built on? At the same time? C++ is one of the healthiest languages in existance. It hits all the important checkboxes of standardisation, wide industry and platform support and large community.
        pjmlp 9y ago
        I imagine you never lived through the days when each C++ compiler had a different understanding what it meant to compile C++ code. It is just like trying to compile the Linux kernel with clang instead of gcc, with the source code full of gcc extensions.
      - pdimitar 9y ago
        I think what <pjmlp> is saying is that (1) these languages are too widely adopted to fail -- somebody is bound to take the ball and continue dribbling it even if the worst happens (company abandons language) and (2) to have a widely adopted language means you have to be a member of a number of committees -- because without standards you wouldn't become a widely adopted language in the first place. In short, we're quite safe in terms of if C#, Swift and Go will live on. They will.
        blub 9y ago
        The issue with C# and Swift is that the Apple and MS dev communities enjoy having a ready made solution that they can pick up and work with immediately. Official support is very important. C# and to some extent Swift are also two huge platforms, there are very few organisations out there that would be able to steer their development. Finally, they are not standardised in any way. MS tried something with 2.0 and then gave up. My impression is that these two live and die by the will of their corporate masters. I'm not saying they will kill them or anything, that would be pretty stupid of them to do.
        pjmlp 9y ago
        > Finally, they are not standardised in any way. MS tried something with 2.0 and then gave up. They are standardized, you just need to look at the right place. https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/ https://docs.microsoft.com/en-us/dotnet/csharp/language-refe... https://docs.microsoft.com/en-us/dotnet/visual-basic/reference/language-specification/ https://docs.microsoft.com/en-us/dotnet/visual-basic/referen... http://fsharp.org/specs/language-spec/ http://fsharp.org/specs/language-spec/ https://swift.org/documentation/ https://swift.org/documentation/
        deleted 9y ago
        [deleted]
        blub 9y ago
        Documentation & specs is not standardisation, not in the C or C++ sense. But you already know that, so why are we having this conversation?
    - maelkum 9y ago
      You know... there's a difference between "(...) with people on ARM, Google, Apple, Blommberg, Sony, IBM, Microsoft's payroll?" and "people on Google payroll". In one case you have many companies cooperating, in the other - just one company.
    - bryanlarsen 9y ago
      Actually, C was a lot worse. For the first 9 years C was basically whatever AT&T wanted. In 78 K&R published The C Programming Language, creating a specification. In the next decade C was very much tied to Unix and non-Unix usages often had some oddities and interoperability issues. The last 3 decades have been good though.
- hnlmorg 9y ago
  I can understand conservative choices when it comes to picking a language but what you describe is a potential risk for plenty other existing languages as well as any new language too. Rust wouldn't be where it is today if it wasn't sponsored by Mozilla. Java was Sun Microsystems baby and I remember all the concerns at the time with the Sun vs Microsoft fighting over control of the ecosystem. Plus even many of the non-corporate languages are still heavily dependant on a small subset of maintainers. At the end of the day if a language proves popular enough in other domains outside of the area which is directly controlled by the language maintainers, then the community will usually find a way of taking over maintenance of it. We've seen this with Pascal, various BASIC dialects (including Visual Basic), and to an extent Java too. The problem with Objective-C was that - as far as I'm aware at least - it wasn't widely used outside of Apple / NeXT's ecosystem so if Apple deprecate support for Objective-C on their own platforms then there's little incentive for the community to keep using language (much like the problems with Visual Basic - which is why few know about it's open source forks). But languages like C# and Go are used massively across a multitude of domains so even if MS/Google were to kill them tomorrow, the community would almost certainly find a way to keep language alive. Heck, Go might even become more popular if that happened since many of the complaints against it are down to the highly opinionated approach of the current leadership. Let's also not forget that Go and C# tooling are open source so the community wouldn't have to reinvent the wheel like they did with Delphi / Object Pascal and Visual Basic.
- pjmlp 9y ago
  So I guess you also see C and C++ as second-class languages, given the employers of the people meeting at ANSI.
- pdimitar 9y ago
  Would you please give an example on how are Google's company-strategic goals making Go platform-specific, or hampered in any way? Please note that I am not demeaning your statement. It's a legitimate curiosity on my side.
  - sanxiyn 9y ago
    One example that comes to mind is Go dependency management. For a long time (and still?) Go had no way to do versioned dependency. Obviously this is no problem for Google which reportedly build from HEAD, but this shows Google-bias in Go development.
    - AYBABTME 9y ago
      It does not show a strategic agenda that influences the language's governance, it only shows that Google was blind in that area.
cyber1 9y ago
Swift can't replace Rust in system programming domain because he uses ARC for memory management but Rust gives you choices.
- zerr 9y ago
  I don't think ARC is an issue here - it's just a deterministic reference counting - a la implicit using of smart pointers. Besides, Swift also has some unsafe pointer types as well.
  - cyber1 9y ago
    Yes, you right according to "deterministic" but you forget about overhead. Rust gives you more safe control on memory management and in most cases, you can always write the fast and efficient safe program without the overhead. Rust give different smart pointers and even sometimes when you 100% understand what are you doing you can use unsafe raw ptr.
    - zerr 9y ago
      Yes, there is a trade-off of course. I think Swift is in the middle on Usability - Safety axis (C++ being on the left and Rust on the right extremes).
    - imtringued 9y ago
      For certain programs a GC can basically make a programming language completely useless (no shared libraries with C abi, no realtime audio, videogames with stutter) regardless how fast the programming language is. This is not the case for swift. It's merely slower than rust.
      - pjmlp 9y ago
        Also to note that Swift has bindings to the 2D, 3D and real time audio APIs on Apple platforms.
- pjmlp 9y ago
readittwice 9y ago
> that will be the end of Go and Rust Will it? I don't think so, although I think Swift is great. IMHO Rust targets another market compared to Swift. Rust feels more low-level, e.g. Swift uses Reference Counting for everything. Swift also can't give you some of the nice guarantees you get in Rust. Go also has some nice stuff compared to Swift: simplicity, goroutines or tracing GC. Go is also already widely used. Swift is certainly great for Mac/iOS-Development, but I am somewhat skeptical for other platforms. I am afraid that non-apple-platforms will always feel a bit like second-class. It's just not Apple's main priority and most Swift-devs will always be paid by Apple. But who knows, I may be wrong.
hashmal 9y ago
All three have different goals and solve different problems. While you can compare things like "they both have MATCH statements" or "unions are safe", deeper they have nothing to do with each other. You would be crazy to use swift (or objc) in real-time stuff. You would be crazy to write a UI-heavy app in rust. (note: I'm talking about high level DOM-like manipulation, not about rendering engines)
- pdimitar 9y ago
  Very true. In the same lane of thought, I am in love with Go when it comes to microservices, network libraries/bridges and CLI tools but it's very ill-suited for web development. So I shrugged it off and only do web dev with Elixir. Conversely, Elixir is awesome for a multitude of things but it absolutely can't compete with Go in its strong areas. Language wars are pointless.
- blaenk 9y ago
  > You would be crazy to write a UI-heavy app in rust. (note: I'm talking about high level DOM-like manipulation, not about rendering engines) I think the jury is still out on that one. I agree with the current state of things but the potential to ease and facilitate this is tremendous through the use of syntax extensions (procedural macros) which can dramatically simplify that use case. In general I think procedural macros add a _lot_ of versatility/flexibility to the language. I anticipate that there will be a huge boom in that area once they stabilize, and it will catch many people by surprise. An example of the versatility that they enable is the work-in-progress async/await [0], whereas in other languages they would usually have to be implemented in the language itself. Note that this does not preclude their implementation in the language itself, but since it's a work-in-progress they're able to experiment with them without having to implement them in the language from the beginning. [0]: https://github.com/alexcrichton/futures-await https://github.com/alexcrichton/futures-await
  - hashmal 9y ago
    I have to agree, things could change in the future. However, my guts tell me rust GUI libraries/frameworks won't be as great as say, Cocoa, although that's something I would love.
geodel 9y ago
Yes next version of Swift will be so awesome it will kill all programing languages.

by zerr 9y ago

rf15 9y ago

while I think that that would be a good thing (I like what happened with C#), I see the languages specified and controlled by Microsoft, Google and Apple as second-class languages, since they are often lacking in community input and are usually designed with certain platform-specific goals in mind instead of being cross-platform. (or company-strategic goals when it comes to Google)

blub 9y ago
Yes, there's something not quite right with these company languages. Whoever is smart will take note of what happened to VisualBasic and is happening to Objective-C.
- pjmlp 9y ago
  You mean like C and C++ being developed at AT&T, nowadays designed at ANSI, with people on ARM, Google, Apple, Blommberg, Sony, IBM, Microsoft's payroll?
  - blub 9y ago
    Looking into the past can have some predictive value, but looking that far back and at a different company is of very limited value. If one evaluates C# they should obviously look at what MS are doing. Same thing for Swift and Apple.
    - pjmlp 9y ago
      If Google, Apple or Microsoft take their employees out of ANSI or from GCC/LLVM contributions, I can assure you they won't move much beyond the current state.
      - blub 9y ago
        What are the odds that all big players would remove support for something that their platforms are built on? At the same time? C++ is one of the healthiest languages in existance. It hits all the important checkboxes of standardisation, wide industry and platform support and large community.
        pjmlp 9y ago
        I imagine you never lived through the days when each C++ compiler had a different understanding what it meant to compile C++ code. It is just like trying to compile the Linux kernel with clang instead of gcc, with the source code full of gcc extensions.
    - pdimitar 9y ago
      I think what <pjmlp> is saying is that (1) these languages are too widely adopted to fail -- somebody is bound to take the ball and continue dribbling it even if the worst happens (company abandons language) and (2) to have a widely adopted language means you have to be a member of a number of committees -- because without standards you wouldn't become a widely adopted language in the first place. In short, we're quite safe in terms of if C#, Swift and Go will live on. They will.
      - blub 9y ago
        The issue with C# and Swift is that the Apple and MS dev communities enjoy having a ready made solution that they can pick up and work with immediately. Official support is very important. C# and to some extent Swift are also two huge platforms, there are very few organisations out there that would be able to steer their development. Finally, they are not standardised in any way. MS tried something with 2.0 and then gave up. My impression is that these two live and die by the will of their corporate masters. I'm not saying they will kill them or anything, that would be pretty stupid of them to do.
        pjmlp 9y ago
        > Finally, they are not standardised in any way. MS tried something with 2.0 and then gave up. They are standardized, you just need to look at the right place. https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/ https://docs.microsoft.com/en-us/dotnet/csharp/language-refe... https://docs.microsoft.com/en-us/dotnet/visual-basic/reference/language-specification/ https://docs.microsoft.com/en-us/dotnet/visual-basic/referen... http://fsharp.org/specs/language-spec/ http://fsharp.org/specs/language-spec/ https://swift.org/documentation/ https://swift.org/documentation/
        deleted 9y ago
        [deleted]
        blub 9y ago
        Documentation & specs is not standardisation, not in the C or C++ sense. But you already know that, so why are we having this conversation?
  - maelkum 9y ago
    You know... there's a difference between "(...) with people on ARM, Google, Apple, Blommberg, Sony, IBM, Microsoft's payroll?" and "people on Google payroll". In one case you have many companies cooperating, in the other - just one company.
  - bryanlarsen 9y ago
    Actually, C was a lot worse. For the first 9 years C was basically whatever AT&T wanted. In 78 K&R published The C Programming Language, creating a specification. In the next decade C was very much tied to Unix and non-Unix usages often had some oddities and interoperability issues. The last 3 decades have been good though.
hnlmorg 9y ago
I can understand conservative choices when it comes to picking a language but what you describe is a potential risk for plenty other existing languages as well as any new language too. Rust wouldn't be where it is today if it wasn't sponsored by Mozilla. Java was Sun Microsystems baby and I remember all the concerns at the time with the Sun vs Microsoft fighting over control of the ecosystem. Plus even many of the non-corporate languages are still heavily dependant on a small subset of maintainers. At the end of the day if a language proves popular enough in other domains outside of the area which is directly controlled by the language maintainers, then the community will usually find a way of taking over maintenance of it. We've seen this with Pascal, various BASIC dialects (including Visual Basic), and to an extent Java too. The problem with Objective-C was that - as far as I'm aware at least - it wasn't widely used outside of Apple / NeXT's ecosystem so if Apple deprecate support for Objective-C on their own platforms then there's little incentive for the community to keep using language (much like the problems with Visual Basic - which is why few know about it's open source forks). But languages like C# and Go are used massively across a multitude of domains so even if MS/Google were to kill them tomorrow, the community would almost certainly find a way to keep language alive. Heck, Go might even become more popular if that happened since many of the complaints against it are down to the highly opinionated approach of the current leadership. Let's also not forget that Go and C# tooling are open source so the community wouldn't have to reinvent the wheel like they did with Delphi / Object Pascal and Visual Basic.
pjmlp 9y ago
So I guess you also see C and C++ as second-class languages, given the employers of the people meeting at ANSI.
pdimitar 9y ago
Would you please give an example on how are Google's company-strategic goals making Go platform-specific, or hampered in any way? Please note that I am not demeaning your statement. It's a legitimate curiosity on my side.
- sanxiyn 9y ago
  One example that comes to mind is Go dependency management. For a long time (and still?) Go had no way to do versioned dependency. Obviously this is no problem for Google which reportedly build from HEAD, but this shows Google-bias in Go development.
  - AYBABTME 9y ago
    It does not show a strategic agenda that influences the language's governance, it only shows that Google was blind in that area.

cyber1 9y ago

Swift can't replace Rust in system programming domain because he uses ARC for memory management but Rust gives you choices.

zerr 9y ago
I don't think ARC is an issue here - it's just a deterministic reference counting - a la implicit using of smart pointers. Besides, Swift also has some unsafe pointer types as well.
- cyber1 9y ago
  Yes, you right according to "deterministic" but you forget about overhead. Rust gives you more safe control on memory management and in most cases, you can always write the fast and efficient safe program without the overhead. Rust give different smart pointers and even sometimes when you 100% understand what are you doing you can use unsafe raw ptr.
  - zerr 9y ago
    Yes, there is a trade-off of course. I think Swift is in the middle on Usability - Safety axis (C++ being on the left and Rust on the right extremes).
  - imtringued 9y ago
    For certain programs a GC can basically make a programming language completely useless (no shared libraries with C abi, no realtime audio, videogames with stutter) regardless how fast the programming language is. This is not the case for swift. It's merely slower than rust.
    - pjmlp 9y ago
      Also to note that Swift has bindings to the 2D, 3D and real time audio APIs on Apple platforms.
pjmlp 9y ago

readittwice 9y ago

> that will be the end of Go and Rust Will it? I don't think so, although I think Swift is great. IMHO Rust targets another market compared to Swift. Rust feels more low-level, e.g. Swift uses Reference Counting for everything. Swift also can't give you some of the nice guarantees you get in Rust. Go also has some nice stuff compared to Swift: simplicity, goroutines or tracing GC. Go is also already widely used. Swift is certainly great for Mac/iOS-Development, but I am somewhat skeptical for other platforms. I am afraid that non-apple-platforms will always feel a bit like second-class. It's just not Apple's main priority and most Swift-devs will always be paid by Apple. But who knows, I may be wrong.

hashmal 9y ago

All three have different goals and solve different problems. While you can compare things like "they both have MATCH statements" or "unions are safe", deeper they have nothing to do with each other. You would be crazy to use swift (or objc) in real-time stuff. You would be crazy to write a UI-heavy app in rust. (note: I'm talking about high level DOM-like manipulation, not about rendering engines)

pdimitar 9y ago
Very true. In the same lane of thought, I am in love with Go when it comes to microservices, network libraries/bridges and CLI tools but it's very ill-suited for web development. So I shrugged it off and only do web dev with Elixir. Conversely, Elixir is awesome for a multitude of things but it absolutely can't compete with Go in its strong areas. Language wars are pointless.
blaenk 9y ago
> You would be crazy to write a UI-heavy app in rust. (note: I'm talking about high level DOM-like manipulation, not about rendering engines) I think the jury is still out on that one. I agree with the current state of things but the potential to ease and facilitate this is tremendous through the use of syntax extensions (procedural macros) which can dramatically simplify that use case. In general I think procedural macros add a _lot_ of versatility/flexibility to the language. I anticipate that there will be a huge boom in that area once they stabilize, and it will catch many people by surprise. An example of the versatility that they enable is the work-in-progress async/await [0], whereas in other languages they would usually have to be implemented in the language itself. Note that this does not preclude their implementation in the language itself, but since it's a work-in-progress they're able to experiment with them without having to implement them in the language from the beginning. [0]: https://github.com/alexcrichton/futures-await https://github.com/alexcrichton/futures-await
- hashmal 9y ago
  I have to agree, things could change in the future. However, my guts tell me rust GUI libraries/frameworks won't be as great as say, Cocoa, although that's something I would love.

geodel 9y ago

Yes next version of Swift will be so awesome it will kill all programing languages.