4 ms·

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

by stmw 6y ago

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 server-side Swift and the many good people who've worked on it, there seems little chance for it, in TensorFlow or other usecases.

cutler 6y ago
I think Kotlin will become the dominant JVM language in time.
- nsonha 6y ago
  that's obvious to me, what sounds more like a prediction is kotlin to be a dominant application development language (fullstack/scripting) natively compiled or on the JVM
yyyk 6y ago
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 Apple's ecosystem, its future will be as some Apple-niche language.
- stmw 6y ago
  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.
  - yyyk 6y ago
    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.

by stmw 6y ago

cutler 6y ago

I think Kotlin will become the dominant JVM language in time.

nsonha 6y ago
that's obvious to me, what sounds more like a prediction is kotlin to be a dominant application development language (fullstack/scripting) natively compiled or on the JVM

yyyk 6y ago

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 Apple's ecosystem, its future will be as some Apple-niche language.

stmw 6y ago
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.
- yyyk 6y ago
  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.