byt143

So Israel can't enjoy the same right to self defense that any other state would? They can't conduct a war in an urban environment with an actual intentionally genocidal enemy, and must resort to targeted assassinations? That standard is absurd. Surely you can admit some middle ground ,if you're discussing in good faith.

Second !

How about the misery of a loved one going untreated, undiagnosed and dismissed by physicians with a facile understanding of chronic multi system disease dynamics. People who do that are usually ones who cannot find physical relief elsewhere.

Don't expect a good answer. That brand of skepticism is performative rationality devoid of actual critical thinking.

It's really depressing that a handful of big corporations will be able to exert such control over labor and productivity

What tasks?

What's the difference between chat and instruction tuning?

How does mojo handle function polymorphism and abstraction? Julia uses multiple dispatch, Haskell type classes etc

Edit: I see you're going to have protocols/ traits. Can those be specializes/monomoprhized at function call time like Julia abstract types?

And how about function specialization? Will functions be attached to structs in a single dispatch fashion or free floating multimethods?

Interesting. What's your prompt?

If you're only looking for one novel view, can it use less views that are close to the novel one?

Even then shape errors would require a dependent type system not found in most static languages.

What are your concerns around the support / dev?

Google has a fairly sizable team around it, it has a fast path to adoption by the large pool of swift devs and fast.ai, and of course, google hype.

Chris leaving doesn't seem to be an issue: https://twitter.com/clattner_llvm/status/1222032740897284097

It does not have macros.

Why can't you just have the higher level representation of the code available and just recompile everything?

Perhaps this helps? https://github.com/apple/swift-evolution/blob/master/proposa...

and this

https://twitter.com/jckarter/status/1202260205074968578

So it's a package, not a language issue?

Here's a revamp based on protocols https://github.com/apple/swift-numerics

That makes sense. Swift is also way too complex and syntatically noisy imo. I like that Julia has a smaller set of very powerful abstractions.

Though isn't point (2) just a convention thing? Protocols can refine other protocols. So in S4TF there's a layer protocol and an RNN protocol which extends that, IIRC.

This can be done better with traits in Julia, which are more powerful, safer and faster.

See here: https://white.ucc.asn.au/2018/10/03/Dispatch,-Traits-and-Met...

Thanks. I mean in julia you can use traits for that, but it's not built in (yet). Though there's no speed penalty, as you probably know.

So this is about extending types, but it sounds like swift is strictly "better" then, since it's also statically checked? Or is there something that multiple dispatch gives that substantively better?

I'm trying to get a feel for if the Swift for Tensorflow project will afford the same kind of composability, while keeping static type checking, modules etc (assuming they work out cross module code specialization, which I think is happening).

Sure, but I'm more looking for something from the swift side of whether Swift can do the same sort of composable generic programming.

Anyone know how this compares to swift and its protocols etc?

Julia gives you the best of both worlds. And more.

All those pretty function like things you see above are actually callable objects that can be introspected, intercepted and dispatched on...so you can mix and match pure object abstractions, pure function abstractions and objects with function like properties depending on the usecase.

This is because Julia's philosophy is to make Differentiable Programming a completely seamless and normal programming paradigm inter-operable with all standard code patterns.

And all this is only possible because of a unique mix of amazing reflection, code gen (including hooking into the compiler from third party packages, allowing source to source autodiff and GPU codegen), fast generic/parametric polymorphism even across packages, multiple dispatch and macros, among other technologies.

It's not quite at the stage of "write any normal julia code and it just works", as there are some rough edges being worked out, but that's the vision and it's even now it's leaps and bounds above pytorch.

https://forums.fast.ai/t/swift-for-tensorflow/40167/72

https://twitter.com/clattner_llvm/status/1222032740897284097

Jeff Dean seems to disagree.

Also, I think it hasn't picked up steam because it just isn't mature enough yet

The people that maintain infrastructure/maintenance support for Julia apps are almost ready to quit their jobs. It sucks so bad.

Any specific examples?

To which version of Julia are you referring? All of those things are much improved now.

Even in swift it isn't "turtles all the way down".

The AD stuff is hardcored into the C++ guts of the compiler, whereas Julia's source to source autodiff accesses a compiler pass from a fully Julia user package.

Aside from making it easier to hack and improve the AD system as just a Julia user, this capability enables other package program transforms like that in https://github.com/MikeInnes/Poirot.jl for prob programming.

So Julia is already further ahead in that regard and it's more hackable.

Would you be open to doing a Fast.ai initiative in Julia? If so, what would that take?

Not sure the data supports that ,: https://juliacomputing.com/blog/2020/01/06/january-newslette...

Better static compilation and compile times which will reduce the time to first plot.