131–140 of 151 posts
Side note, does anyone know the effort required to get various python based libraries running on swift? i.e. numpy, scipy, pandas and so on?
Earlier quoted context omitted.
You don't know what you're talking about.
Tell me where I'm wrong
Also it's not a high overhead runtime. The runtime itself is compiled to highly optimized machine code (it can even compile, say the derivative of f(x) = 5x+3 down to the machine immediate "5" at compile time).
There is a lot of lifting to get that compilation framework into place, so there is a load-time overhead.
I vaguely know tensor flow as the most(?) popular lib of his kind, but I wonder how is the history of swift on non-apple platforms and its impact of the actual users. Is TensorFlow "huge" in linux, windows, android? Because I also evaluate swift for my use case ( https://www.reddit.com/r/swift/comments/8zb9y1/state_of_swif... ) and decide instead on use rust mainly because the lack of solid support on non-apple platf…
The story of Swift on Linux is now quite good. Windows is less far along, but recently a contributor got nightly builds started on Azure, and it appears there is serious work on this front. In any case, it's already possible to run Swift for Tesorflow on Windows using WSL and Docker.
But is not tensor flow popular on windows? Because then build on top of swift will mean:
- Put swift on a fast track to be decent on windows, linux, android(?)
- Ignore the windows users and let them battle a bad dependency?
Earlier quoted context omitted.
As I pointed out in two lengthy comments on day one[1][2], that reasoning is nonsense. If Chris wants to use the language he created in this new endeavor for machine learning simply because he made it , that's totally fine and completely his prerogative, but he should just say so, rather than trying (and failing) to convince people that other languages aren't better suited for this task. From my point of view, a weak…
> If Chris wants to use the language he created in this new endeavor for machine learning simply because he made it, that's totally fine and completely his prerogative, but he should just say so, rather than trying (and failing) to convince people that other languages aren't better suited for this task. Do you have any insider knowledge that Chris Lattner had the unilateral power to choose Swift for this project? I w…
Yes, and companies are even doing it in production. Sentry probably being the best well known.
As as python machine learning practitioner and previous iOS engineer I have for while come to miss using swift and type safety for that matter. I really like the language and wish great success for the TF team with swift. Side note, does anyone know the effort required to get various python based libraries running on swift? i.e. numpy, scipy, pandas and so on?
Earlier quoted context omitted.
what's the problem with deploying julia in production in inference? Some occasional piece of data that looks wrong in an unanticipated way causes a runtime type fault? People deploy high uptime websites with django - how do they do it? Well you use kubernetes (or, gasp, systemd) and have restart and load balancing logic. Even if you were typecheck-compiled, you can't guarantee some other developer logic or system err…
Just because you can deploy production code without static checking does not make it a good idea. And to me if you need to rely on an external process to restart your application for NPE's etc. it is a sign your application is not that robust. It's possible to write production code in brainfuck if that's what you really want to do. Statically checked code is easier to implement correctly, easier to modify, and easier…
If that were true literally no one would program in python. Static checking is not the end all to uptime and stability. I wrote an elixir program in three days that served as a testbench for a senior's go program (which took him six months to write). This senior believes in static typechecking for everything and doesn't write unit tests. The testbench handles thousands of parallel async requests without a hiccup and even survives operating system resource exhaustion, where the go program falls over and panics.
Erlang is not statically checked (there is a static typechecker, but it's not fully typed). I promise you a well written erlang program has much higher stability than a well written go program. There is a reason why kubernetes exists, after all.
The lack of windows support is addressed in just two lines. Julia being an already established language in the domain of data science does not seem to be especially important to them.
I think the most honest part of the document is:
> because we were more familiar with its [Swift's] internal implementation details
Earlier quoted context omitted.
Just because you can deploy production code without static checking does not make it a good idea. And to me if you need to rely on an external process to restart your application for NPE's etc. it is a sign your application is not that robust. It's possible to write production code in brainfuck if that's what you really want to do. Statically checked code is easier to implement correctly, easier to modify, and easier…
> Statically checked code is easier to implement correctly, easier to modify, and easier to maintain. If that were true literally no one would program in python. Static checking is not the end all to uptime and stability. I wrote an elixir program in three days that served as a testbench for a senior's go program (which took him six months to write). This senior believes in static typechecking for everything and does…
There are many cases in which people don't choose the optimal language. But I would say the size of the python community has more to do with inertia, the breadth of libraries available, and a relatively shallow learning curve than it says about its strengths as a tool for writing good software.
I actually find that Python has some rather serious warts: the whole story around environment/version management is a mess, and the less I have to work with Python in a serious capacity the better.
> I wrote an elixir program ... The testbench handles thousands of parallel async requests without a hiccup and even survives operating system resource exhaustion, where the go program falls over and panics.
Well Erlang is specifically designed for concurrency and stability: if you want to judge your result on those two metrics I hope it is going to perform well.
I never made the claim that static typing is the "end all to uptime and stability" - static typing makes it easier to reason about your code, and to provably eliminate many issues. It's very nice that you implemented a test harness quickly, but come back to me when you've worked on a complex codebase with several other people over an extended period of time.
Why not Rust? Edit: I wonder if Swift could be replaced with Rust for iOS development?