4 ms·

We've been eye-ing it for a while at remind.com. Our hangup has been that we're heavily aws focused, but https://github.com/amzn/smoke-aws https://github.com/am

We've been eye-ing it for a while at remind.com. Our hangup has been that we're heavily aws focused, but https://github.com/amzn/smoke-aws https://github.com/amzn/smoke-aws is looking promising. We're interested because it's one of a handful of statically typed functional programming languages. Haskell/Ocaml are great as ML type languages, but it's a big paradigm shift for a team to jump into. Rust still has a pretty decent learning curve. Swift seems to have landed nicely in the "anyone can pick it up" territory. Kotlin is also in that territory, but the JVM is a beast. For now, we're heavily focused on Typescript as the statically typed functional language, and we leverage types pretty aggressively (conditional types, discriminant unions, etc). Our iOS devs bring a lot of the Swift style over to our backend Typescript systems and from what I've experienced I think Swift absolutely will have a place in backend development.

cageface 8y ago
Swift is a nice language but I think the reliance on ref counting is going to limit its adoption. You have to work a lot harder to avoid reference cycles in Swift than you do in a garbage collected language. Unless GC latency is a deal breaker for your problem domain it’s not worth the extra effort. My money is on Rust for really low level stuff and Kotlin for anything where JVM overhead is acceptable.
- saagarjha 8y ago
  It really depends on what you're doing. A lot of the time, neither garbage collection pauses nor reference cycles are an issue; and when they are it's typical that one or the other will solve the issue.
  - cageface 8y ago
    If GC pauses aren't an issue for your app then you're better off with a full-blown GC because it's a lot easier to code for. Reference counting, as used in Swift, forces you to think a lot about cases where you might be creating reference cycles and memory leaks. GCs can figure this out for you and take that burden off the programmer.
    - saagarjha 8y ago
      Yes, but reference counting doesn't have unpredictable pauses, which can be important in certain situations. That's what I was trying to say above.
    - millstone 8y ago
      One of the major advantages of reference counting is that it's easier to integrate with other languages. For example you can manipulate Swift objects from C via CoreFoundation, which then allows them to be used from C++, Rust, whatever. GC'd languages have some support (JNI, etc) but they require handles, pinning, write barriers, etc. which ends up being more complicated and less flexible.
      - cageface 8y ago
        Right, which is one of the reasons it makes sense for Apple to use it, since they have a lot of lower level C API to interact with. For more general purpose backend work this is not usually a major consideration though, which is one of the reasons I predict most backend work will continue to be done in a GC language.
- ilovecaching 8y ago
  What do you see as the advantage of Rust or ref counting?
  - cageface 8y ago
    I've just read the Rust docs and not written any code so I'm probably the wrong person to ask but Rust's ownership rules seem to make it possible to eliminate a lot of dynamic allocations in the first place. Ref counting can beat GC if you're in a domain where GC pauses can be an issue. Things like games, for example. Although I understand state-of-the-art GCs can also be fast enough to use for these kinds of applications in some cases now. Ref counting can also be more memory efficient than GCs.
    - pjmlp 8y ago
      Ref counting can also be slower than tracing GC when getting rid of complex data structures, heavy multi-threaded code and can lead to stack overflows if destructors are incorrectly written.
- phamilton 8y ago
  > You have to work a lot harder to avoid reference cycles in Swift It depends on how you use it. As I understand it, if you use enums everywhere it all sort of works out. If you start mixing in structs, there are certainly a lot of minefields.
- WanderPanda 8y ago
  I would assume good debug-tooling should make spotting such cycles quite easy, why is this even considered a problem?
  - cageface 8y ago
    It’s not easy and iOS developers spend a lot of time explicitly breaking ref cycles in code and tracking down resource leaks. I’ve seen a lot of code from experienced iOS devs that gets it wrong.
    - myko 8y ago
      What kinds of mistakes do you see? Forgetting to use capture lists entirely? Using them improperly? Not making delegates weak properties?
ilovecaching 8y ago
I don't really consider a language to be functional without a concise application and composition operator (also automatic currying and partial application). How can you be functional if you don't have the basic operators for combining and applying functions?
- ilovecaching 8y ago
  It looks like Swift has automatic currying though, so that's pretty close.
  - dbaupp 8y ago
    It doesn't have automatic currying. What code/docs are you getting that impression from?
    - plorkyeran 8y ago
      Swift used to have a special syntax for defining automatically curried functions, but it was removed in Swift 3: https://github.com/apple/swift-evolution/blob/master/proposals/0002-remove-currying.md https://github.com/apple/swift-evolution/blob/master/proposa...
      - dbaupp 8y ago
        Indeed, and the compiler still had the relicts of that functionality at least until Swift 4. I'm wondering how they got the impression Swift still has currying, given it sounded like a recent "discovery".
- bgorman 8y ago
  If you have automatic partial application you lose the ability to have multi-arity functions. Functional programming is about functions, not operators. In Clojure you can compose and partially apply functions with the normal functions "comp" and "partial". https://github.com/clojure/clojure/blob/clojure-1.9.0/src/clj/clojure/core.clj#L2549 https://github.com/clojure/clojure/blob/clojure-1.9.0/src/cl... https://github.com/clojure/clojure/blob/clojure-1.9.0/src/clj/clojure/core.clj#L2606 https://github.com/clojure/clojure/blob/clojure-1.9.0/src/cl...
pjmlp 8y ago
The JVM is indeed a beast in available tooling, libraries and production monitoring.
repolfx 8y ago
Kotlin has an LLVM backend these days and can compile to native binaries. It's more Swift-like, then.

cageface 8y ago

Swift is a nice language but I think the reliance on ref counting is going to limit its adoption. You have to work a lot harder to avoid reference cycles in Swift than you do in a garbage collected language. Unless GC latency is a deal breaker for your problem domain it’s not worth the extra effort. My money is on Rust for really low level stuff and Kotlin for anything where JVM overhead is acceptable.

saagarjha 8y ago
It really depends on what you're doing. A lot of the time, neither garbage collection pauses nor reference cycles are an issue; and when they are it's typical that one or the other will solve the issue.
- cageface 8y ago
  If GC pauses aren't an issue for your app then you're better off with a full-blown GC because it's a lot easier to code for. Reference counting, as used in Swift, forces you to think a lot about cases where you might be creating reference cycles and memory leaks. GCs can figure this out for you and take that burden off the programmer.
  - saagarjha 8y ago
    Yes, but reference counting doesn't have unpredictable pauses, which can be important in certain situations. That's what I was trying to say above.
  - millstone 8y ago
    One of the major advantages of reference counting is that it's easier to integrate with other languages. For example you can manipulate Swift objects from C via CoreFoundation, which then allows them to be used from C++, Rust, whatever. GC'd languages have some support (JNI, etc) but they require handles, pinning, write barriers, etc. which ends up being more complicated and less flexible.
    - cageface 8y ago
      Right, which is one of the reasons it makes sense for Apple to use it, since they have a lot of lower level C API to interact with. For more general purpose backend work this is not usually a major consideration though, which is one of the reasons I predict most backend work will continue to be done in a GC language.
ilovecaching 8y ago
What do you see as the advantage of Rust or ref counting?
- cageface 8y ago
  I've just read the Rust docs and not written any code so I'm probably the wrong person to ask but Rust's ownership rules seem to make it possible to eliminate a lot of dynamic allocations in the first place. Ref counting can beat GC if you're in a domain where GC pauses can be an issue. Things like games, for example. Although I understand state-of-the-art GCs can also be fast enough to use for these kinds of applications in some cases now. Ref counting can also be more memory efficient than GCs.
  - pjmlp 8y ago
    Ref counting can also be slower than tracing GC when getting rid of complex data structures, heavy multi-threaded code and can lead to stack overflows if destructors are incorrectly written.
phamilton 8y ago
> You have to work a lot harder to avoid reference cycles in Swift It depends on how you use it. As I understand it, if you use enums everywhere it all sort of works out. If you start mixing in structs, there are certainly a lot of minefields.
WanderPanda 8y ago
I would assume good debug-tooling should make spotting such cycles quite easy, why is this even considered a problem?
- cageface 8y ago
  It’s not easy and iOS developers spend a lot of time explicitly breaking ref cycles in code and tracking down resource leaks. I’ve seen a lot of code from experienced iOS devs that gets it wrong.
  - myko 8y ago
    What kinds of mistakes do you see? Forgetting to use capture lists entirely? Using them improperly? Not making delegates weak properties?

ilovecaching 8y ago

I don't really consider a language to be functional without a concise application and composition operator (also automatic currying and partial application). How can you be functional if you don't have the basic operators for combining and applying functions?

ilovecaching 8y ago
It looks like Swift has automatic currying though, so that's pretty close.
- dbaupp 8y ago
  It doesn't have automatic currying. What code/docs are you getting that impression from?
  - plorkyeran 8y ago
    Swift used to have a special syntax for defining automatically curried functions, but it was removed in Swift 3: https://github.com/apple/swift-evolution/blob/master/proposals/0002-remove-currying.md https://github.com/apple/swift-evolution/blob/master/proposa...
    - dbaupp 8y ago
      Indeed, and the compiler still had the relicts of that functionality at least until Swift 4. I'm wondering how they got the impression Swift still has currying, given it sounded like a recent "discovery".
bgorman 8y ago
If you have automatic partial application you lose the ability to have multi-arity functions. Functional programming is about functions, not operators. In Clojure you can compose and partially apply functions with the normal functions "comp" and "partial". https://github.com/clojure/clojure/blob/clojure-1.9.0/src/clj/clojure/core.clj#L2549 https://github.com/clojure/clojure/blob/clojure-1.9.0/src/cl... https://github.com/clojure/clojure/blob/clojure-1.9.0/src/clj/clojure/core.clj#L2606 https://github.com/clojure/clojure/blob/clojure-1.9.0/src/cl...

pjmlp 8y ago

The JVM is indeed a beast in available tooling, libraries and production monitoring.

repolfx 8y ago

Kotlin has an LLVM backend these days and can compile to native binaries. It's more Swift-like, then.