13 ms·

I don't think Swift really competes with Rust or Go at all. - Go aims to be simple enough for many engineers to be productive with little investment. - Rust a

I don't think Swift really competes with Rust or Go at all. - Go aims to be simple enough for many engineers to be productive with little investment. - Rust aims to be extremely reliable and efficient. Swift is very complex, and makes many compromises away from reliability or efficiency in favor of application use cases. Swift may fill an interesting role for a "native C#" that is mostly reliable, mostly efficient, and somewhat productive, but on the other hand, C#, OCaml, Java, Kotlin, and so on already have various answers to that, and they're only becoming better at it. The only real advantage it has (as far as I can tell) is iOS (and TensorFlow almost as a knock-on of being the only serious language for iOS).

usmannk 6y ago
> Rust aims to be extremely reliable and efficient. Fair point, Swift will never be as predictable or efficient as Rust (not a negative perse, just different goals). But I disagree on the complexity re: Go. What about Swift gives you the impression of extreme complexity? Go is definitely comparatively simpler but I do not think it is so much so as to put it in a different league.
- novok 6y ago
  The type errors you start running into with generics with all of their weird limitations in swift can make things complicated fast. That and RxSwift. Also swift as a language doesn't scale well. There are a lot of bottlenecks in the build process that doesn't let you scale simply amongst many cores like you can with C++, Obj-C & C and probably many other languages too. You're also effectively limited to xcode & apple desktops, so you can't go rent out a 100 core build server on AWS for builds like you can for every other platform out there, not that is matters much yet with swift's build scaling issues. Also stuff like basic debugging often just... dies. The more I work with a badly scaling language the more I appreciate a design decision like go made with building fast. I hope with generics in go v2 the boilerplate should reduce a lot.
  - jshier 6y ago
    When was the last time you compiled Swift code? Xcode's new(er) build system has solved many of the scaling issues that affected the previous system, to the point where it scales linearly (on large enough projects) even on a 28/56 Mac Pro, and my 10/20 iMac. Additionally, with cmake's native Swift support in 3.18(?), the scaling should be more solved across platform as well. There's certainly nothing in the language itself that prevents scaling builds, only the compiler and build systems. The debugger is still rough, true, but improving. Apple just isn't spending the resources needed to bring lldb up to a great experience in a timely fashion.
    - novok 6y ago
      Yesterday! Swifts build system can split off enough threads to consume all of your CPU cores, and batch mode did improve things, but it's not actually doing so efficiently. There is a trade off between total compute time used and number of threads used. In compute time consumed, swift is the most efficient when it's single threaded in WMO mode, but this means you can only compile in parallel with separate modules that don't depend on each other. And even then it's not a very fast compiling language itself, multithreading issues notwithstanding Maybe something has changed recently, but as far as Xcode 12 goes, I haven't noticed much of a difference. I last checked deeply with swift 4. More details here: https://github.com/apple/swift/blob/master/docs/CompilerPerformance.md https://github.com/apple/swift/blob/master/docs/CompilerPerf...
  - vips7L 6y ago
    RxAnything makes any language unreadable. RxJava is the bane of my existence.
    - myko 6y ago
      I find Rx to be super clear usually. What problems have you run into? Combine (Apple's Rx framework) is pretty understandable/usable as well.
      - vips7L 6y ago
kitsunesoba 6y ago
I think one of Swift's advantages is its progressive disclosure. It can be written without using any of its more advanced features, making it approachable without limiting possibilities for more advanced users.
- usmannk 6y ago
  I agree. I referenced this (perhaps a bit too implicitly) in a sibling comment. Swift's complexity is there but only when you need it.
- cylon13 6y ago
  Can it be read without knowing about its more advanced features though? Production software is read much more often than it is written.
  - nicoburns 6y ago
    I've been able to dip into Swift codebases with zero previous experience without too much trouble. I do have Rust experience which helps. But never-the-less everyday Swift seemed pretty readable to me.
  - cutler 6y ago
    Swift has some really clunky "features" such as dual-identifier parameters and escaped opening parens as identifiers for string templates. WTF! As if function/method declarations weren't complex enough in a statically-typed language which supports generics.
    - pansa2 6y ago
      > escaped opening parens as identifiers for string templates Do you mean the use of “\(variable)” for string interpolation? What’s wrong with that?
      - cutler 6y ago
        It's just downright clunky. What's wrong with ${variable} as in Kotlin and Javascript?
wffurr 6y ago
Swift has almost seamless interoperability with existing C and C++ libraries and has much stronger safety guarantees than either of those languages. It's not on the same level as Rust, but ARC eliminates entire classes of memory safety issues. The Swift runtime is large-ish, but not outrageously so, and is generally statically compiled-in to the binaries, so there's no dependencies on dynamic libraries. It is, as you say, quite complex, but still an interesting choice IMO.
- dagmx 6y ago
  Minor nitpick but it does not have seamless interfacing with anything other than Objective C. C can be exposed as Objective C, but C++ has to go through C (potential objective C++) first. This is really no different than most other languages. What it does do is provide good auto binding tools however to expose classes and objects bidirectionally to objective C.
  - deleted 6y ago
    [deleted]
  - ladon86 6y ago
    My understanding was that there is no need to involve Objective-C if you’re directly interfacing with C. That interop is direct/seamless, and works on Linux etc. even without Objective-C or Darwin [0]. But the C++ story is what you’ve described above. [0] https://developer.apple.com/documentation/swift/imported_c_and_objective-c_apis/using_imported_c_functions_in_swift https://developer.apple.com/documentation/swift/imported_c_a... and https://developer.apple.com/documentation/swift/imported_c_and_objective-c_apis/using_imported_c_structs_and_unions_in_swift https://developer.apple.com/documentation/swift/imported_c_a...
    - wool_gather 6y ago
      I wouldn't say "seamless". Interacting with C directly from Swift is possible, and fine from a binary perspective, but quite clunky at the source level. (Which obviously is a motivation for the library that is being announced here.) There are still assorted gaps in C imports -- a key example is forward-declared structs, that _all_ arrive in Swift as a _single shared_ `OpaquePointer` type: https://forums.swift.org/t/opaque-pointers-in-swift/6875 https://forums.swift.org/t/opaque-pointers-in-swift/6875
webmobdev 6y ago
Where do you think Ada - a mature and tested language - fit in between these 3 newbies?
- wwright 6y ago
  I don't know Ada well personally, but from what I've read, it's a bit less advanced than Rust at static checks, a good bit simpler than Rust and Swift but more complex than Go, and a little bit old-fashioned in approach (verbose syntax and all that). But I'm not very educated. I would say that Ada and Rust probably compete on some things, but given the history of Ada in industry, it's probably only in fields that already use Ada (aerospace and what-not).
  - pjmlp 6y ago
    Rust lacks the formal specifications from SPARK. And SPARK 2014 will support ownership specifications. Rust is the less advanced one.
    - wwright 6y ago
      Good feedback there :)
  - thesuperbigfrog 6y ago
    >> I don't know Ada well personally >> But I'm not very educated. If you don't know, please don't speculate. I use Ada professionally and I am experimenting with Rust. Rust has great promise and I am interested to see where it will go, especially as an alternative to C++. >> it's a bit less advanced than Rust at static checks Ada 2012 has comparable and in many cases more advanced static checks than Rust with the exception of memory management. This is especially true of the Ada type system (https://learn.adacore.com/courses/intro-to-ada/chapters/strongly_typed_language.html https://learn.adacore.com/courses/intro-to-ada/chapters/stro...) and design by contracts (https://learn.adacore.com/courses/intro-to-ada/chapters/contracts.html https://learn.adacore.com/courses/intro-to-ada/chapters/cont...). If you use the SPARK subset of Ada, you can use advanced tools to prove the correctness of your program. See https://learn.adacore.com/courses/intro-to-spark/index.html https://learn.adacore.com/courses/intro-to-spark/index.html Rust's borrow checker approach to memory management is novel and SPARK is acutally adding similar concepts to the next version of SPARK (https://blog.adacore.com/using-pointers-in-spark https://blog.adacore.com/using-pointers-in-spark). >> a good bit simpler than Rust and Swift but more complex than Go Ada is a large and fairly complex language because it was designed for hard real-time, safety-critical, embedded systems and it has been in real-world use for 40+ years. I don't think it is that simple, but judging simplicity is subjective: what one person sees as complex, another person might see as simple. You can browse the Ada 2012 Language Reference Manual and see what you think: http://ada-auth.org/standards/12rm/html/RM-TOC.html http://ada-auth.org/standards/12rm/html/RM-TOC.html >> a little bit old-fashioned in approach (verbose syntax and all that). This comes from the Ada design philosophy to be explicit in everything and to prefer the use of keywords over symbols. "Readability is more important than conciseness. Syntactically this shows through the fact that keywords are preferred to symbols, that no keyword is an abbreviation, etc." (See https://learn.adacore.com/courses/intro-to-ada/chapters/introduction.html#philosophy https://learn.adacore.com/courses/intro-to-ada/chapters/intr...) Long-life programs tend to be read more than they are written. The Ada way is to make programs easier to read rather than faster to write. >> I would say that Ada and Rust probably compete on some things, but given the history of Ada in industry, it's probably only in fields that already use Ada (aerospace and what-not). This is largely true. Ada occupies a niche for aerospace and other safety-critical areas, but has not been widely adopted due to the "uncoolness" factor and the cost of most of the available Ada compilers and toolchains. I think the popularity of Rust has peaked some interest in Ada as well, but I am not sure if it will cause any change it where either are used. I would like to see Rust to continue to mature and get adopted for wide-spread use with multiple implementations and a language standard. As it currently stands, many aerospace and safety-critical spaces would not be willing / able to adopt Rust without a language standard and certifications. Here's hoping . . .
coldtea 6y ago
>Swift is very complex, and makes many compromises away from reliability or efficiency in favor of application use cases. Swift is only complex if you need it, otherwise very easy, with few caveats. And it's efficient enough for all application / cli etc use cases -- if Go can do it, Swift can do it even better. It's not Rust in performance and low-levelness, but Rust is the "really complex" one in its semantics and learning curve.
- mjlawson 6y ago
  > if Go can do it, Swift can do it even better. This might be hyperbole, but if not I'd love to see some examples on how Swift can improve on Go's concurrency patterns.
  - coldtea 6y ago
    It might not offer first class support for green threads like Go, but GCD is an even better imho model for 90% of concurrency needs of the average app: https://developer.apple.com/documentation/DISPATCH https://developer.apple.com/documentation/DISPATCH
    - microcolonel 6y ago
      "concurrency needs of the average app" is different from what Go does well with green threads; this seems like something Swift does notably worse, but well enough that it doesn't annoy you in your use case. I feel like this is a different standard from "if Go can do it, Swift can do it better".
    - harikb 6y ago
      Isn’t that just a bridge to an existing OS level feature? Also is GCD green? (As in light weight, co-operative muti-threading)
      - coldtea 6y ago
        >Isn’t that just a bridge to an existing OS level feature? Yes. A feature well designed for this very purpose. >Also is GCD green? GCD tasks are not green threads but they're not direct threads either (even though they're used under the hood). They're more lightweight and much faster to create (than direct OS threads).
throw_m239339 6y ago
> - Go aims to be simple enough for many engineers to be productive with little investment. Go isn't simpler, there is just a defered cost engineers pay later on when it turns out one cannot just do away with complexity by deeming it irrelevant.
- Thaxll 6y ago
  Some FUD right there... What exactly is the deffered cost? Give real examples please.
  - earthboundkid 6y ago
    I love Go, but there is a strong case that Kubernetes has a messy codebase because Go didn’t have good dependency management or generics when they started it. The strength of the ecosystem in other areas let them get started and now they have the tragedy of success, a la Wordpress.
    - studmuffin650 6y ago
      Part of the issues with Kubernetes is that it started as a Java project and then it became a Go project. If anyone started a large Go project with that mindset it would look messy no matter what you did.
      - bad_user 6y ago
        Can you point to any large Go project that isn’t a mess? I agree that from a single sample you can’t reach conclusions, but “it was their fault” isn’t a great defense.
        nix23 6y ago
        Can YOU point to any large project that isn’t a mess?
        6y ago
bilekas 6y ago
I'll tell you: You're wrong, so is OP. Benching languages against eachother is like pitting birds of prey against eachother, its pointless because they will hunt what they hunt. This language/framework dispute I though was fever back in bad PHP days has not changed. I'm not saying; 'oh you kids dont know shit' I'm saying the language is not the problem, the problem is the problem, the right tool for said problem is the answer. You find Swift complex and speak about why, you're not wrong with its application, iOS it does very well, therefore its a tool for an iOS job. If I grew up just learning Swift and nothin else, I would say swift is the best . Plato's cave springs to mind. We are all Engineers, Developers, Hackers, Designers and or Code Monkeys.. Don't try to pit against, know the right tool for the job, if you cant find it, make it. With people who can. I though thats how we roll
- wwright 6y ago
  To be clear, that’s kind of what I was trying to say :) maybe the “only advantage” part at the end made that unclear. I think the problems you’d want to use Go for, the problems you’d want to use Rust for, and the problems you’d want to use Swift for are largely non-overlapping (in spite of whatever similarities they do have).
jillesvangurp 6y ago
I think you are focusing on a bit artificial things here with things like intentions and other biases and notions. Swift is a statically compiled, C like language, that can be used for system programming. Just like C, C++, Rust, Go, etc. This is not an accident. It was built from the ground up to do that. The goal with this OSS library is literally making swift easier to use in projects where you'd otherwise reach for exactly those languages. So, whether you like it or not, it's competing (or at least trying to) in that space (i.e. system programming). Actually, Swift was designed to replace Objective C, which of course was the system programming language that Apple standardized on as an alternative to C decades ago. It's designed from the ground up to be a drop in replacement in any project where you'd previously be using that. So, it's a natural fit for any kind of project where you'd otherwise be considering things like Rust, C++, Go, C, etc. Whether that makes sense or not in your context is of course up for debate and highly subjective.

usmannk 6y ago

> Rust aims to be extremely reliable and efficient. Fair point, Swift will never be as predictable or efficient as Rust (not a negative perse, just different goals). But I disagree on the complexity re: Go. What about Swift gives you the impression of extreme complexity? Go is definitely comparatively simpler but I do not think it is so much so as to put it in a different league.

novok 6y ago
The type errors you start running into with generics with all of their weird limitations in swift can make things complicated fast. That and RxSwift. Also swift as a language doesn't scale well. There are a lot of bottlenecks in the build process that doesn't let you scale simply amongst many cores like you can with C++, Obj-C & C and probably many other languages too. You're also effectively limited to xcode & apple desktops, so you can't go rent out a 100 core build server on AWS for builds like you can for every other platform out there, not that is matters much yet with swift's build scaling issues. Also stuff like basic debugging often just... dies. The more I work with a badly scaling language the more I appreciate a design decision like go made with building fast. I hope with generics in go v2 the boilerplate should reduce a lot.
- jshier 6y ago
  When was the last time you compiled Swift code? Xcode's new(er) build system has solved many of the scaling issues that affected the previous system, to the point where it scales linearly (on large enough projects) even on a 28/56 Mac Pro, and my 10/20 iMac. Additionally, with cmake's native Swift support in 3.18(?), the scaling should be more solved across platform as well. There's certainly nothing in the language itself that prevents scaling builds, only the compiler and build systems. The debugger is still rough, true, but improving. Apple just isn't spending the resources needed to bring lldb up to a great experience in a timely fashion.
  - novok 6y ago
    Yesterday! Swifts build system can split off enough threads to consume all of your CPU cores, and batch mode did improve things, but it's not actually doing so efficiently. There is a trade off between total compute time used and number of threads used. In compute time consumed, swift is the most efficient when it's single threaded in WMO mode, but this means you can only compile in parallel with separate modules that don't depend on each other. And even then it's not a very fast compiling language itself, multithreading issues notwithstanding Maybe something has changed recently, but as far as Xcode 12 goes, I haven't noticed much of a difference. I last checked deeply with swift 4. More details here: https://github.com/apple/swift/blob/master/docs/CompilerPerformance.md https://github.com/apple/swift/blob/master/docs/CompilerPerf...
- vips7L 6y ago
  RxAnything makes any language unreadable. RxJava is the bane of my existence.
  - myko 6y ago
    I find Rx to be super clear usually. What problems have you run into? Combine (Apple's Rx framework) is pretty understandable/usable as well.
    - vips7L 6y ago

kitsunesoba 6y ago

I think one of Swift's advantages is its progressive disclosure. It can be written without using any of its more advanced features, making it approachable without limiting possibilities for more advanced users.

usmannk 6y ago
I agree. I referenced this (perhaps a bit too implicitly) in a sibling comment. Swift's complexity is there but only when you need it.
cylon13 6y ago
Can it be read without knowing about its more advanced features though? Production software is read much more often than it is written.
- nicoburns 6y ago
  I've been able to dip into Swift codebases with zero previous experience without too much trouble. I do have Rust experience which helps. But never-the-less everyday Swift seemed pretty readable to me.
- cutler 6y ago
  Swift has some really clunky "features" such as dual-identifier parameters and escaped opening parens as identifiers for string templates. WTF! As if function/method declarations weren't complex enough in a statically-typed language which supports generics.
  - pansa2 6y ago
    > escaped opening parens as identifiers for string templates Do you mean the use of “\(variable)” for string interpolation? What’s wrong with that?
    - cutler 6y ago
      It's just downright clunky. What's wrong with ${variable} as in Kotlin and Javascript?

wffurr 6y ago

Swift has almost seamless interoperability with existing C and C++ libraries and has much stronger safety guarantees than either of those languages. It's not on the same level as Rust, but ARC eliminates entire classes of memory safety issues. The Swift runtime is large-ish, but not outrageously so, and is generally statically compiled-in to the binaries, so there's no dependencies on dynamic libraries. It is, as you say, quite complex, but still an interesting choice IMO.

dagmx 6y ago
Minor nitpick but it does not have seamless interfacing with anything other than Objective C. C can be exposed as Objective C, but C++ has to go through C (potential objective C++) first. This is really no different than most other languages. What it does do is provide good auto binding tools however to expose classes and objects bidirectionally to objective C.
- deleted 6y ago
  [deleted]
- ladon86 6y ago
  My understanding was that there is no need to involve Objective-C if you’re directly interfacing with C. That interop is direct/seamless, and works on Linux etc. even without Objective-C or Darwin [0]. But the C++ story is what you’ve described above. [0] https://developer.apple.com/documentation/swift/imported_c_and_objective-c_apis/using_imported_c_functions_in_swift https://developer.apple.com/documentation/swift/imported_c_a... and https://developer.apple.com/documentation/swift/imported_c_and_objective-c_apis/using_imported_c_structs_and_unions_in_swift https://developer.apple.com/documentation/swift/imported_c_a...
  - wool_gather 6y ago
    I wouldn't say "seamless". Interacting with C directly from Swift is possible, and fine from a binary perspective, but quite clunky at the source level. (Which obviously is a motivation for the library that is being announced here.) There are still assorted gaps in C imports -- a key example is forward-declared structs, that _all_ arrive in Swift as a _single shared_ `OpaquePointer` type: https://forums.swift.org/t/opaque-pointers-in-swift/6875 https://forums.swift.org/t/opaque-pointers-in-swift/6875

webmobdev 6y ago

Where do you think Ada - a mature and tested language - fit in between these 3 newbies?

wwright 6y ago
I don't know Ada well personally, but from what I've read, it's a bit less advanced than Rust at static checks, a good bit simpler than Rust and Swift but more complex than Go, and a little bit old-fashioned in approach (verbose syntax and all that). But I'm not very educated. I would say that Ada and Rust probably compete on some things, but given the history of Ada in industry, it's probably only in fields that already use Ada (aerospace and what-not).
- pjmlp 6y ago
  Rust lacks the formal specifications from SPARK. And SPARK 2014 will support ownership specifications. Rust is the less advanced one.
  - wwright 6y ago
    Good feedback there :)
- thesuperbigfrog 6y ago
  >> I don't know Ada well personally >> But I'm not very educated. If you don't know, please don't speculate. I use Ada professionally and I am experimenting with Rust. Rust has great promise and I am interested to see where it will go, especially as an alternative to C++. >> it's a bit less advanced than Rust at static checks Ada 2012 has comparable and in many cases more advanced static checks than Rust with the exception of memory management. This is especially true of the Ada type system (https://learn.adacore.com/courses/intro-to-ada/chapters/strongly_typed_language.html https://learn.adacore.com/courses/intro-to-ada/chapters/stro...) and design by contracts (https://learn.adacore.com/courses/intro-to-ada/chapters/contracts.html https://learn.adacore.com/courses/intro-to-ada/chapters/cont...). If you use the SPARK subset of Ada, you can use advanced tools to prove the correctness of your program. See https://learn.adacore.com/courses/intro-to-spark/index.html https://learn.adacore.com/courses/intro-to-spark/index.html Rust's borrow checker approach to memory management is novel and SPARK is acutally adding similar concepts to the next version of SPARK (https://blog.adacore.com/using-pointers-in-spark https://blog.adacore.com/using-pointers-in-spark). >> a good bit simpler than Rust and Swift but more complex than Go Ada is a large and fairly complex language because it was designed for hard real-time, safety-critical, embedded systems and it has been in real-world use for 40+ years. I don't think it is that simple, but judging simplicity is subjective: what one person sees as complex, another person might see as simple. You can browse the Ada 2012 Language Reference Manual and see what you think: http://ada-auth.org/standards/12rm/html/RM-TOC.html http://ada-auth.org/standards/12rm/html/RM-TOC.html >> a little bit old-fashioned in approach (verbose syntax and all that). This comes from the Ada design philosophy to be explicit in everything and to prefer the use of keywords over symbols. "Readability is more important than conciseness. Syntactically this shows through the fact that keywords are preferred to symbols, that no keyword is an abbreviation, etc." (See https://learn.adacore.com/courses/intro-to-ada/chapters/introduction.html#philosophy https://learn.adacore.com/courses/intro-to-ada/chapters/intr...) Long-life programs tend to be read more than they are written. The Ada way is to make programs easier to read rather than faster to write. >> I would say that Ada and Rust probably compete on some things, but given the history of Ada in industry, it's probably only in fields that already use Ada (aerospace and what-not). This is largely true. Ada occupies a niche for aerospace and other safety-critical areas, but has not been widely adopted due to the "uncoolness" factor and the cost of most of the available Ada compilers and toolchains. I think the popularity of Rust has peaked some interest in Ada as well, but I am not sure if it will cause any change it where either are used. I would like to see Rust to continue to mature and get adopted for wide-spread use with multiple implementations and a language standard. As it currently stands, many aerospace and safety-critical spaces would not be willing / able to adopt Rust without a language standard and certifications. Here's hoping . . .

coldtea 6y ago

>Swift is very complex, and makes many compromises away from reliability or efficiency in favor of application use cases. Swift is only complex if you need it, otherwise very easy, with few caveats. And it's efficient enough for all application / cli etc use cases -- if Go can do it, Swift can do it even better. It's not Rust in performance and low-levelness, but Rust is the "really complex" one in its semantics and learning curve.

mjlawson 6y ago
> if Go can do it, Swift can do it even better. This might be hyperbole, but if not I'd love to see some examples on how Swift can improve on Go's concurrency patterns.
- coldtea 6y ago
  It might not offer first class support for green threads like Go, but GCD is an even better imho model for 90% of concurrency needs of the average app: https://developer.apple.com/documentation/DISPATCH https://developer.apple.com/documentation/DISPATCH
  - microcolonel 6y ago
    "concurrency needs of the average app" is different from what Go does well with green threads; this seems like something Swift does notably worse, but well enough that it doesn't annoy you in your use case. I feel like this is a different standard from "if Go can do it, Swift can do it better".
  - harikb 6y ago
    Isn’t that just a bridge to an existing OS level feature? Also is GCD green? (As in light weight, co-operative muti-threading)
    - coldtea 6y ago
      >Isn’t that just a bridge to an existing OS level feature? Yes. A feature well designed for this very purpose. >Also is GCD green? GCD tasks are not green threads but they're not direct threads either (even though they're used under the hood). They're more lightweight and much faster to create (than direct OS threads).

throw_m239339 6y ago

> - Go aims to be simple enough for many engineers to be productive with little investment. Go isn't simpler, there is just a defered cost engineers pay later on when it turns out one cannot just do away with complexity by deeming it irrelevant.

Thaxll 6y ago
Some FUD right there... What exactly is the deffered cost? Give real examples please.
- earthboundkid 6y ago
  I love Go, but there is a strong case that Kubernetes has a messy codebase because Go didn’t have good dependency management or generics when they started it. The strength of the ecosystem in other areas let them get started and now they have the tragedy of success, a la Wordpress.
  - studmuffin650 6y ago
    Part of the issues with Kubernetes is that it started as a Java project and then it became a Go project. If anyone started a large Go project with that mindset it would look messy no matter what you did.
    - bad_user 6y ago
      Can you point to any large Go project that isn’t a mess? I agree that from a single sample you can’t reach conclusions, but “it was their fault” isn’t a great defense.
      - nix23 6y ago
        Can YOU point to any large project that isn’t a mess?
        6y ago

bilekas 6y ago

I'll tell you: You're wrong, so is OP. Benching languages against eachother is like pitting birds of prey against eachother, its pointless because they will hunt what they hunt. This language/framework dispute I though was fever back in bad PHP days has not changed. I'm not saying; 'oh you kids dont know shit' I'm saying the language is not the problem, the problem is the problem, the right tool for said problem is the answer. You find Swift complex and speak about why, you're not wrong with its application, iOS it does very well, therefore its a tool for an iOS job. If I grew up just learning Swift and nothin else, I would say swift is the best . Plato's cave springs to mind. We are all Engineers, Developers, Hackers, Designers and or Code Monkeys.. Don't try to pit against, know the right tool for the job, if you cant find it, make it. With people who can. I though thats how we roll

wwright 6y ago
To be clear, that’s kind of what I was trying to say :) maybe the “only advantage” part at the end made that unclear. I think the problems you’d want to use Go for, the problems you’d want to use Rust for, and the problems you’d want to use Swift for are largely non-overlapping (in spite of whatever similarities they do have).

jillesvangurp 6y ago

I think you are focusing on a bit artificial things here with things like intentions and other biases and notions. Swift is a statically compiled, C like language, that can be used for system programming. Just like C, C++, Rust, Go, etc. This is not an accident. It was built from the ground up to do that. The goal with this OSS library is literally making swift easier to use in projects where you'd otherwise reach for exactly those languages. So, whether you like it or not, it's competing (or at least trying to) in that space (i.e. system programming). Actually, Swift was designed to replace Objective C, which of course was the system programming language that Apple standardized on as an alternative to C decades ago. It's designed from the ground up to be a drop in replacement in any project where you'd previously be using that. So, it's a natural fit for any kind of project where you'd otherwise be considering things like Rust, C++, Go, C, etc. Whether that makes sense or not in your context is of course up for debate and highly subjective.