Live data from Hacker News

Swift for TensorFlow Shuts Down

github.com

341–350 of 432 posts

Re: Swift for TensorFlow Shuts Down

#341
post #26

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 as a mainstream language. Swift's a delightful language to use. It has a lot of the nice things about Rust's type system, but is a heck of a lot easier to use at the expense of a bit of performance. For a lot of use cases, I think this is a great value propos…

Example of features you miss?

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.

Re: Swift for TensorFlow Shuts Down

#342
post #151

Earlier quoted context omitted.

My guess is that's because ML researchers typically have not spent much time with statically typed languages. I was also once convinced that static typing was not so valuable - when I was working a lot with js, python and ruby, but the more time I spend with static typing the more I like it. There is an "activation energy" to overcome with static typing: when you first start it feels like a tedious burden to have to…

I am totally with you on statically typed vs. dynamically typed languages _in general_. I'm not denying that there are major advantages to using one for most kinds of programs. But I just don't see a benefit for ML. You can easily find out if you like it or not, you can use the C++ API for TF/PyTorch and you'll have a statically typed program running your model for you. Sure, it's not Haskell, but C++ is statically t…

And with C++20 relatively pleasing to use.

Re: Swift for TensorFlow Shuts Down

#343

Earlier quoted context omitted.

To say that Swift is "nowhere near as simple" as Javascript or Kotlin is a very strange opinion to me, and I have experience with all 3. Simple as in syntax, memory management, or in what regard? I can't think of a single example where Swift is not equivalent or better. Do you have the same criticism of Scala?

Swift has no traced garbage collector which means you cannot represent circular data structure/references. Also swift support for interfaces (protocol) is sub-par with today standards

> Also swift support for interfaces (protocol) is sub-par with today standards

interesting, what could be added/changed to make it better?

Re: Swift for TensorFlow Shuts Down

#344
post #272

Earlier quoted context omitted.

What's the difference to you for using {} vs ?

are comparison operators for checking if something is less than or greater than something else. This is okay in a static language where there are special slots for a type where only a restricted subset of things can happen. You'd know at the parser level that the are referring to the type meaning or the operator meaning. In julia, types are values and values can live in types, and arbtrary operations can happen in a…

I feel like this is a solvable problem. For instance you could require parens in the case of expressions using characters.

Re: Swift for TensorFlow Shuts Down

#345
post #199

Earlier quoted context omitted.

I disagree that it's "a lot " more readable. I have read a lot of camelCase code in my lifetime, and I can count on zero hands the number of times I ever had an issue parsing code due to the use of camelCase. Keyboard remapping seems like an extreme solution, and I don't want to train my fingers in such a way that when I sit down at a different workstation that doesn't have my .vimrc I can't type rust anymore. You do…

CamelCase is terrible as soon as you have an abbreviation in your function (like "DB"). I run into this extremely frequently at my place of work.

Can you give an example of where you find this "terrible?" I have never had an issue with it, and even if you don't like it aesthetically, I think the fact that you don't like looking at certain names (a subjective complaint) is objectively easier to overcome than being required to type one of the least ergonomic characters on the keyboard over and over, which is a matter of physical reality.

Re: Swift for TensorFlow Shuts Down

#346
post #316

Earlier quoted context omitted.

As weird as it sounds, the only thing that stops me from trying Julia is 1 indexing

IMO, Julia is good enough that you might not notice. you can use constructions like `for i in axes(V)` that will automatically give you the indexes, or `V[begin:begin+2]` to get the first 2 elements. Also higher order functions eg. `map` (and broadcasting) mean that you will rarely be manually working with indexes.

You still need to access indexes if you're working with arrays though, which is a very common data structure.

Re: Swift for TensorFlow Shuts Down

#348

Earlier quoted context omitted.

The name of the LLVM AD tool is actually Enzyme [ http://enzyme.mit.edu/ ] (Zygote is a Julia tool)

I think they probably mistook julia's IR from LLVMs IR

You are giving me more credit than I deserve. My brain had a bad reference.

Re: Swift for TensorFlow Shuts Down

#349
post #6

Swift now being a 100% Apple-sponsored & owned project again makes me a bit nervous. Anyone knows if chris latner is at least using swift in his new company ? I have the feeling swift never really worked in the server side, data science is now officially a failure, and all that is left is now a very niche market of 100% native mobile development. I love this language, but i'm eager to see it handled by a proper found…

[deleted]

Re: Swift for TensorFlow Shuts Down

#350
post #70

Earlier quoted context omitted.

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.

I agree with you, although I must say that as an occasional Python user the way type hints are implemented absolutely baffles me. In particular the fact that they are completely ignored by the standard implementation. They're glorified comments. Given how opinionated the Python maintainers can be, it baffles me that they accepted to get these optional, noisy, half backed type hints into the core language. In my exper…

My view is completely opposite to yours. I find type hints extremely useful and every new line of Python code I write uses them. I finally no longer have to do type checking / duck typing in my head but can simply write the types down. Moreover, an IDE like PyCharm will then do the type checking for me, notifying me of potential errors. (Even if I decide not to use Mypy.) Third, I finally only need to look at the signature of standard library functions to see what parameters they accept / what values they return. Previously, I always had to consult the Python documentation.
Post reply on HN