Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Swift for TensorFlow Shuts Down

github.com

Post reply on HN
Print view View original

401–410 of 432 posts

Re: Swift for TensorFlow Shuts Down

#401

Post by stmw »

yyyk wrote: post #309
stmw wrote: post #214

This is sad for the project itself, but I predict that the coming programming competition will be Rust vs. Go, not Swift -- as Swift was always a distant third among the "new" languages. And of course the more mature languages will continue to be popular and widely used for decades. In my opinion, Rust will end up winning this contest, but others have perfectly good arguments against that view. Unfortunately for serv…

The idea there's one language for everything was false even during C's heyday. Your list contains languages for very different uses. Rust will eventually win low-level programming from C++, but massively networked applications will always be slightly easier in Go. Swift is a bytecode language, it competes against .NET (mainly C#) and JVM (Java and variants), not Rust or Go. IMHO Swift seems to losing when not tied to…

I guess it's all in how you classify it... I'm not sure why "bytecode" vs. "non-bytecode" are an important distinction in the language's usecases, as opposed to implementation. For example, .Net supports both static compilation and bytecode interpretation, as do most LLVM-backed languages.

Re: Swift for TensorFlow Shuts Down

#402

Post by 6gvONxR4sf7o »

lmm wrote: post #351
6gvONxR4sf7o wrote: post #108

Earlier quoted context omitted.

The dependence on library authors is always a challenge in any language. You might have one author using `[a]` where another uses `PositiveNumeric a, Fin n => NonEmptyList n a` for the same thing. You can always just annotate whatever the library author used (e.g. they return a list of strings, so you use List[str]). There are some interesting further add ons that seem very python, allowing you to go further. For exa…

> You might have one author using `[a]` where another uses `PositiveNumeric a, Fin n => NonEmptyList n a` for the same thing. You can always just annotate whatever the library author used (e.g. they return a list of strings, so you use List[str]). The difference between these two cases is that a function that returns [a] will always return [a] and if you convert it to `NonEmptyList n a` you will be nudged towards han…

I was unclear. I meant the other way around. In the case that the third party code does in fact always return no empty lists of positive numbers, the author might just type it as a list. A third party author in even a language like Haskell won’t necessarily use the bells and whistles of giving very specific types.

And by the List[str] bit, I mean you can annotate it as doing whatever it in fact does. You aren’t protected if you get that wrong, of course, and that’s where things like stubs come in to help.

Re: Swift for TensorFlow Shuts Down

#403

Post by aplummer »

The_rationalist wrote: post #375
andrekandre wrote: post #343

Earlier quoted context omitted.

> Also swift support for interfaces (protocol) is sub-par with today standards interesting, what could be added/changed to make it better?

No support for default implementation methods. No support for generics in protocol. There might be workarounds but for a newcomer, this is a red flag of reinventing a basic and universal construct (interfaces) in a sub-par one, this show a dangerous mentality from the swift vm devs, what else did they wrongfully reinvent in a sub-par way?

As the other commenter pointed out, default implementations (with genetic constraints!) are supported, they actually my favourite swift feature.

Re: Swift for TensorFlow Shuts Down

#404

Post by grey-area »

geoffpado wrote: post #72
grey-area wrote: post #45

Earlier quoted context omitted.

Don't worry, in a few years Apple will rewrite all their SDKs again in a different language. The churn may not be a deliberate strategy but it is certainly very effective in locking developers in.

Apple churns languages every few years? They kept Objective-C around for 13 years before introducing Swift, and that was a language that was widely disliked by people from outside the Apple ecosystem. You can still use it for the vast majority of OS features today[0], nearly 20 years after it was first used on Apple platforms. Heck, Obj-C is used for Mac/iOS development because that was the preferred language for Mac…

Next is not MacOS so I think it’s a real stretch to claim that means long term support! Perhaps some of this is normal but I think Apple have made little effort to avoid churn and it suits them to keep things changing.

Apple have had significant churn in dev tooling, languages, sdks, frameworks, chip architectures over the last couple of decades. Perhaps that is completely normal but it does mean developers are always struggling to keep up, and an app written for iOS 1.0 needs significant alterations if not a rewrite to work with later versions. Almost everything has been completely replaced, from language to frameworks to dev tooling like resources.

Re: Swift for TensorFlow Shuts Down

#405

Post by yyyk »

stmw wrote: post #401
yyyk wrote: post #309

Earlier quoted context omitted.

The idea there's one language for everything was false even during C's heyday. Your list contains languages for very different uses. Rust will eventually win low-level programming from C++, but massively networked applications will always be slightly easier in Go. Swift is a bytecode language, it competes against .NET (mainly C#) and JVM (Java and variants), not Rust or Go. IMHO Swift seems to losing when not tied to…

I guess it's all in how you classify it... I'm not sure why "bytecode" vs. "non-bytecode" are an important distinction in the language's usecases, as opposed to implementation. For example, .Net supports both static compilation and bytecode interpretation, as do most LLVM-backed languages.

Maybe the better definition would be 'GC languages with a runtime'? There's a distinction between languages that require a runtime and impose a GC (with the associated penalties) and 'low-level' languages like Rust* .

I'd say 'GC runtime languages' are somewhat dubious for low latency etc. (but see Unity and ZGC!), while 'low-level languages' are overkill for typical UI/CRUD apps, I don't see any useful advantage for Rust there.

* Go would be in the middle I guess - technically requires a runtime, but the runtime is relatively light and all binaries are static - unlike .Net whose static compilation support is frankly rather theoretical right now due to common use of its powerful reflection capabilities.

Re: Swift for TensorFlow Shuts Down

#406

Post by jodrellblank »

socialdemocrat wrote: post #232
ZeroCool2u wrote: post #155

Earlier quoted context omitted.

function julia_blues(bummers...) I largely agree, Julia is such a cool language and had so much potential. It definitely surprised me when they went with Swift instead, but realizing that Chris Lattner worked at Google at the time explained a lot. Unfortunately, every time I try to get into Julia, it just feels awkward coming from Python and a bit like stepping back in time. The stupidest, (stupidest in the sense tha…

I would argue that `end` is a much better choice than both the Python approach and curly braces: https://erik-engheim.medium.com/the-case-against-curly-brace... `end` marks of blocks of code much more clearly than curly braces. It is also requires fewer keyboard taps. To type {} requires holding down four keys in total (shift-[ twice). end is just three key strokes. But more importantly is saves curly braces for othe…

That's not a particularly convincing blogpost - for example you don't need square brackets for indexing, one of Ken Iverson's changes going from APL to J was to see indexing as just another function application and remove square bracket syntax from it. Grouping arithmetic expression is worsened by complex precedence rules, APL always evaluating right-to-left and all operators having the same precendence changes how that works as well (even though it does have grouping parens too). Then complaining that "" are used in mathematical expression, but not being annoyed by "main()" in a function declaration or the "?" and ":" used in the complex type expression?

Seems to me that "end" is one of the worse available choices; if we're going for keywords, why not make them "endif", "endfor", "endwhile" (or "wend") which makes it explicitly clear what each of:

        end
      end
    end
is ending.

Re: Swift for TensorFlow Shuts Down

#408

Post by jodrellblank »

eigenspace wrote: post #280
renox wrote: post #274

Earlier quoted context omitted.

Sigh, isn't the only way, D (as usual) has a very simple and clever solution f!(types)(parameter)

Maybe it's just my julia indoctrination speaking but I find that rather ugly. In julia, f!(types)(parameter) means that f! is a mutating function acting on types which returns a closure which is then called on parameter. We just write Type{paramemer}

> "We just write Type{paramemer}"

It seems odd to say "we just write" for some arbitrary choice with its own tradeoffs; {} mean a set in Python or a literal array initialiser in C# or a scriptblock in PowerShell or a dfn in Dyalog APL or a JSON dictionary, etc. With only a limited set of whatever symbols happened to end up on a US ASCII keyboard 40+ years ago, there is heavy competition for them, it's why J broke the symmetry of pairs and went for two-character symbols, why PowerShell went for comparators like -gt and -lt, why C# has => which is completely different from To act like there's an objectively better use for {} is to miss how many tradeoffs there are, and how many things people want symbols for out of a standard keyboard.

Re: Swift for TensorFlow Shuts Down

#409

Post by dragonwriter »

dagmx wrote: post #400
dragonwriter wrote: post #399

Earlier quoted context omitted.

Oh, okay, the problem here is that we have different understanding of the relevant meanings of “type” and therefore “type system”, which is unsurprising because the term has many different uses in programming. I am using “type” in the standard computer science sense of statically enforced invariant and “type system” as the system of statically enforced invariants, distinct from annotations which are the syntax by whi…

There's multiple aspects to what a type system can entail. There's dynamic/static typing which is what most of the thread is about. Python is dynamically typed , which makes it really easy to pickup and make stuff in, but you get issues like runtime errors/bugs since there's no inherent type checking other than attribute access failure, or explicit isinstance calls. To the best of my knowledge, there's no advancement…

> Type annotation helps partially here since you can statically check the types notated post facto but this is not the type system.hatever a static type checker enforces is exactly a type system (and the only thing that is), in the standard CS sense.

The fact that the type checker isn't integrated with the compiler/interpreter is a different design choice from other systems, but it doesn't change what it is.

Effectively, mypy (and this was explictly what mypy was originally envisioned as, as is still reflected in its domain name) and other typecheckers for Python create separate statically typed languages with the same relation to Python as TypeScript has to JavaScript, except that source code in those languages is also valid Python source code with identical runtime behavior. That is, each typechecker creates a new language that is a statically typed strict subset of Python, with its own type system (most of which is common across the whole set of languages, but there are slight variations as each are ahead of the common baseline in different ways.)

> The type system in a language is a contract by the compiler/interpreter to enforce type safety

No, it's enforced by the typechecker. Now, in most languages implementations that have a type system, that's part of the compiler, or more rarely interpreter, but there is no inherent reason it needs to be.

> This is why I'm trying to draw the distinction between the type system vs the type annotation system.

Yes, you've invented artificial nonstandard terminology here that is clearly not the terminology that was being in the post you argued against, in order to make a really extended argument that vigorously exercises the fallacy of equivocation and badly misses the point of the post it sought to dispute.

To the extent there is a legitimate point here it boils down to “Strictly speaking, Python remains untyped, and what is advancing are the type systems of a family of statically typed languages built around Python, that are strict subsets of Python, that leverage feature built in to Python specifically to enable such languages, and which are developed in close collaboration with Python, in some cases sharing core team members.”

Re: Swift for TensorFlow Shuts Down

#410

Post by jiofih »

mrtksn wrote: post #320
jiofih wrote: post #282

Earlier quoted context omitted.

It will use typescript type definitions when available, even if you’re writing plain JS. Auto complete works perfectly, what’s not remotely the same?

It's not the same because in JS you usually would use a large number of libraries with varying degree of documentation and different conventions. Also, you would loose autocomplete when you expect to receive something as a parameter instead of defining it in that closure. The basic language API is not that large, the benefit of autocomplete discovery comes when you have autocomplete on custom types of a specific fram…

I’m sure NestJS, which sparked this thread, has very complete type defs, as does any major framework out there.

You seem intent on dismissing something you obviously haven’t tried in the past couple years; next time I’d suggest a simple “I don’t like it” instead to save us all time.

Post reply on HN