15 ms·

It's a shame. I had high hopes at the beginning that S4TF - and the investment in Swift from Google - would help Swift break out of the iOS ghetto and cement it

• wrinkl3 6y ago
  > I think Serverless would be another ideal use-case for Swift, where the productivity, clarity and correctness tools it offers would be a huge benefit. I agree, but sadly none of the big cloud providers has any interest in pushing it - Google's got Go, AWS and Azure seem focused on Typescript.
  • chris_st 6y ago
    I know AWS lets you just deploy a docker container, so you can use whatever tools you want -- anyone know about Azure and Google cloud?
    • skohan 6y ago
      Yes theoretically I think there is nothing stopping you from shipping Swift code on AWS. I am pretty sure you could do it in a lambda and you don't even need a docker container. If you're talking about a container workflow, I'm pretty sure every cloud provider will support this just fine currently.
    • ec109685 6y ago
      Google’s CloudRun has been based on docker containers and simple http interface for a while for their serverless approach.
    • jabwd 6y ago
      I'm running Swift server side on Azure. You simply package it in a docker container and run it in an appservice. The only problem really is not having native blobstorage support (like AWS S3) but I wrote an opensource implementation that supports the basics at least. Im not going to plug the library here however coz its far from finished :)
  • oflannabhra 6y ago
    AWS has a Swift runtime for Lambda [0], and Amazon has an open source server framework for Swift, Smoke [1]. [0] - https://swift.org/blog/aws-lambda-runtime/ https://swift.org/blog/aws-lambda-runtime/ [1] - https://github.com/amzn/smoke-framework https://github.com/amzn/smoke-framework
• wendyshu 6y ago
  What are some ways in which Python's type system should improve?
  • suyash 6y ago
    First, managing python dependencies and versions, current system is horrible. Focus on fixing that, then performance. Swift is much faster than Python. Third, Swift is a much advance and intelligent language to program in than Python. When I write Swift code, I feel like a PhD and when I write Python, I'm back in elementary school.
    • swagonomixxx 6y ago
      It doesn't matter that "Swift is faster than Python". Your TensorFlow graph is gonna be slow as all hell if it's running on the CPU. The bottleneck here really isn't performance on a CPU. That's a no-brainer for all non-ML applications. But for applications that require a GPU (i.e, most ML applications) cutting over to Swift from Python will likely win you nothing in performance, and wouldn't be worth it at all.
  • superbcarrot 6y ago
    It fundamentally can't be improved in a significant enough way and still be Python. The more realistic options are to be okay with Python's type system (I personally am) or to look at different languages if you really want something more robust.
    • 6gvONxR4sf7o 6y ago
      I don't think that's accurate. Python's type system is largely defined by mypy + the annotations, in addition to runtime python. In that regard, python's type system has been evolving really quickly, and it's becoming something quite interesting. I'm a fanboy of static type systems, and in the last bunch of years, python's type system has gone from just bearable to really useful. I'm excited to see where it goes from here.
      • 6y ago
• nextos 6y ago
  I love all languages in the ML/Haskell tradition, but I think Julia would have been a better fit because it's dynamic yet efficient, and because it has a really decent probability/statistics/ML ecosystem already. Long term, I think it's the best replacement we have for Python in the ML world. Python has exceptional libraries but, as a language, it's a bit dated on several fronts. This has an impact on library design. In Python, ML libraries are huge monoliths and they depend on a lot of code written in other languages. They are really hard to understand or modify. In Julia, things are really small and composable. For example, you have a probabilistic programming library like Turing and a differentiable programming one like Flux, and it's trivial to implement some Bayesian neural networks. Same applies to many other things. It's small and beautiful, but it needs more manpower to compete against Python.
  • Karrot_Kream 6y ago
    > In Julia, things are really small and composable. For example, you have a probabilistic programming library like Turing and a differentiable programming one like Flux, and it's trivial to implement some Bayesian neural networks. I was taken aback when looking at Turing for Bayesian modelling that the distributions were just the standard distributions found in the Distributions package! In Python, every Bayesian framework has its own implementation of everything from distributions to log probabilities, but it all composes in Julia. > It's small and beautiful, but it needs more manpower to compete against Python. Agreed. Docs of major projects are still incomplete or non-existent, there's a lot of projects that have been nigh abandoned (cough naive bayes cough), and the composability of Julia coupled without strong leadership leads to an ecosystem of overlapping functionality. Still, I hope by leveraging PyCall, Julia can overcome some of these issues.
    • renerthr 6y ago
      > but it all composes in Julia. You mean that, in Julia, we the users have to "compose" our own implementations of models (e.g. log probabilities), as opposed to using the already-made ones in Python?
      • 6y ago
• mrtksn 6y ago
  >I think Serverless would be another ideal use-case for Swift, where the productivity, clarity and correctness tools it offers would be a huge benefit. Oh yes, I would love to have Swift framework for Firebase on server, not only for iOS. Its atrocity to write the server logic in NodeJS after making the user App in Swift. Every time I switch from Swift to JS I deeply appreciate the beauty of Swift. On swift I do much less silly mistakes where the NodeJS code feels like up and running by some miracle and everything can collapse due to something I did but could't catch it before something horrible happens.
  • simonbarker87 6y ago
    It doesn’t solve the issue of JS but NestJS feels like a more robust way to make a server in JS - and the docs are great.
    • mrtksn 6y ago
      Thanks, I don't really need large framework for full blown app though.
      • jiofih 6y ago
        Swift and UIKit are already a much larger API than any node framework in existence.
        • mrtksn 6y ago
          They have good defaults and Xcode is a good IDE with full support of these frameworks, Swift is a good language with sensible conventions so you don't really need to learn that much. When you don't know something you can start typing keywords and see what Xcode autocompletes for and read the explanation about that function from the documentation that is provided to you right there. It's not perfect, sometimes there's no documentation but it's not a big deal as you can look into source files or try it out to see how it behaves.
          • 6y ago
• ragnese 6y ago
  I agree and am also disappointed. On the other hand, I really don't miss Swift outside of iOS because of Rust and Kotlin. I wonder if Kotlin is too far from "arms length" from the low level details in your mind? Because other than that, I actually prefer the language over Swift, generally.
  • RhodesianHunter 6y ago
    Agreed. Thomas Nield has some interesting talks and libraries available for doing data science work in Kotlin.
  • The_rationalist 6y ago
    Kotlin is one of the very few languages to have a compiler plugin API, this allows Facebook researchers to make it auto-differentiable on demand https://news.ycombinator.com/item?id=25128251 https://news.ycombinator.com/item?id=25128251
• adsharma 6y ago
  Python type system is improving. Another point in this ease of use vs type safety spectrum is python -> type safe language static compilation. I don't know which one is the best. So I've been experimenting with several. https://github.com/adsharma/py2many https://github.com/adsharma/py2many
  • dagmx 6y ago
    Is the Python type system improving or is it the type annotation system that's improving? Big difference between the two.
    • adsharma 6y ago
      The lack of algebraic data types is what python gets criticisms about. That situation is improving, but I would have preferred match to be an expression rather than a statement. What else is missing in the python3 type system?
      • dagmx 6y ago
        Actual static typing and forced type checking.
        • adsharma 6y ago
          I get that you're not particularly excited about gradual typing and the fact that type checkers are optional and live in a separate ecosystem from the interpreter/language runtime. I actually like the fact that python code without type annotations continues to work as before and allows for easy transcription of ideas into testable code. If a certain use case requires "forced" type checking, it shouldn't be hard to write a lint rule that disallows code from being committed if there are type checking errors, including missing type annotations.
          • dagmx 6y ago
            The issue though is that Python's type annotation is not a substitute for type checking. Annotations are optional and can be inaccurate. That's fine, this is part of the design of Python. However strict type systems are a benefit of other languages, that may not fit Python. Type annotation shouldn't be considered an alternative to a type system.
• liuliu 6y ago
  Yeah. I think unable to merge back into Swift mainline really makes the adoption harder. I made some efforts to having PythonKit / swift-jupyter run smoother and it feels really good as a replacement for Python: https://liuliu.me/eyes/data-science-setup-with-swift-in-2021/ https://liuliu.me/eyes/data-science-setup-with-swift-in-2021... Luckily, I don't think Swift on other platforms is dead. SwiftNIO seems worked quite well as a project. Bazel support is solid. They still release Linux / Windows Swift toolchains. Also shameless plug, I did implemented my own deep learning framework in Swift: https://libnnc.org/s4nnc/ https://libnnc.org/s4nnc/
• xiaodai 6y ago
  Example of features you miss?
  • skohan 6y ago
    So one of the big ones is dynamic method replacement. In Swift it's possible to declare a method `dynamic`, which means it will always be dispatched dynamically. It's then possible to load a dylib which "overwrites" the method at runtime, making it possible to implement hot code reloading in an elegant way which is fully type-checked and everything. I am not aware of a way to do this in rust. Most of the other things I miss are ergonomic: - Swift has better inference, so for example in a match statement over an enum, in rust you always have to type: `MyLongEnumName::SomeEnumCase`, where in swift you can just type `.someEnumCase` - Swift's operators for optionals are much cleaner imo than how it's handled in Rust. For instance, the `?` operator is kind of magical in Rust, because it effectively changes the flow of control of the enclosing function. Optional handling constructs in Swift are always local to the statement, which I find to be easier to reason about, and more composable. - Rust's module system is needlessly complex and verbose, and adds boilerplate and redundant busy work when you want to refactor code and move things around - Trailing closure syntax is really nice - It's sometimes useful to have types as runtime constructs as well as at compile time - I like Swift's more flexible approach to scopes/namespaces. Like in Swift, when I declare a struct, I can just declare the methods inside the struct body without needing a separate impl, which reduces boilerplate. Also for instance if you need to declare a throwaway data type which is only used internally by a couple functions in a Swift type, you can declare it right inside the struct declaration where it's relevant. Rust is more restrictive, and I have to declare types either at the module level, or inside an execution scope like a function body. So with Swift I just feel like my code is organized in a more semantically coherent way which reads like a book, where in Rust it's more organized according to the ceremony which is required by Rust syntax. I could go on, but basically I just feel that when I am coding with Swift, the syntax melts away and I am mostly focused on the problem domain. When coding in Rust, the syntax is very present, and is a big part of what I am dealing with.
• mleonhard 6y ago
  > I guess it goes to show that the governance and availability of a language have a lot more to do with adoption than the merits of the language itself. Nearly every Google project eventually gets abandoned because the engineers that made it get promoted and move on to their next promotable projects. The root cause is the ongoing failure of Google's leaders to align employee incentives with the long-term interests of the company or human society. Even if S4TF had become popular, I expect it still would become neglected and rot like most Google projects.
  • thoweir23434 6y ago
    From what I've seen S4TF is not widely used inside Google - don't think there's support for tfx here.
• qaq 6y ago
  I think given how fast the actor concurrency stuff is progressing it should be fairly good platform for web apps in a few years.
• deleted 6y ago
  [deleted]
• cutler 6y ago
  Agreed, adoption is everything. Something the Clojure community never quite grasped.
• higerordermap 6y ago
  While people can argue swift could be Golang, it's built with focus on iOS ecosystem. You have to manually handle reference cycles. The language is quite complex as well, and compiler is among the slow ones. Copy-on-write is generally despised these days even in C++. Just to keep in mind that this may give space for a next expressive general purpose language that improves in these aspects, we can be optimistic.