6 ms·

Probably one of the most elegant languages around.

by sgt 7y ago

melling 7y ago
Yes, it’s my favorite language. Now it needs better cross platform support to be more widely accepted.
- gigatexal 7y ago
  I hear server-side swift is gaining traction
- clawoo 7y ago
  And a proper IDE and a faster compiler. Xcode is dreadful with its strange fetish for recompilation even if there were no changes and the compiler is slower with every iteration. The solution put forward for this always seems to be "buy newer hardware".
  - mojuba 7y ago
    Absolutely. One of the things I hate most is this thinking "run-time is more important than compile-time". Well the compiler and the IDE are runtimes too, we developers are users too, we sometimes work on our laptops unplugged and we do want our software to be fast and efficient!
    - skohan 7y ago
      > "run-time is more important than compile-time" This is a pitfall of Rust as well. I suppose there will always be a tradeoff between stronger static analysis and compilation time, and I'm firmly in the camp that I want my compiler to catch more issues so I don't have unexpected runtime failures, but iteration time matters too, and I'm hopeful improvements can be made in this area.
      - mojuba 7y ago
        Sometimes you introduce certain restrictions in the language just for the sake of simplifying the compiler. This is allowed, valid and will be understood by the developers. For example, for decades most static languages required a symbol to be defined before its first usage. Removing this restiction seemed like a nice little cute convenience but the outcome of it is this horrific slowdown of the build process. Personally I would agree to the restriction if I knew the compiler could be 5x faster which is pretty realistic to achieve, it seems.
        skohan 7y ago
        Those kinds of restrictions can have their own productivity pitfalls. For instance, it might be the case that requiring declaration prior to usage explicitly will speed up the compiler, but it might also mean that you can't move blocks of code around without paying careful attention to the order of declaration. I think having a permissive compiler, but also being able to profile the compilation process is a reasonable compromise.
        mojuba 7y ago
        Possibly, but there are other kinds of compromises such as allowing arbitrary order only within a class, the C++ way. Or another one: the first (quick) pass treats all function and reference type definitions as forward declarations and skips the details. This way the compiler might be able to do more permissive compilation though not 100% accurate like Swift currently does.
    - ajconway 7y ago
      But run-time is more important, isn't that why we compile stuff with optimizations that take ages to process when building products for the end users? Compilers are hard, compiler bugs can have a devastating effect on one's software, so it's understandable that developers may prefer to take things slow but safe.
      - skohan 7y ago
        I guess ideally this should be a tradeoff in the hands of the developer right? I should be able to produce debug builds quickly so that I can iterate quickly, and if I want a super-optimal release build it's fine if it takes longer.
      - Gibbon1 7y ago
        My half joke is the optimizations slow down compilers. So people then try to make the compilers faster by increasing the levels of optimization. Which means they have to work harder. So they are slower.
  - ajconway 7y ago
    In swift things have a module-wide visibility by default, that's why it often rebuilds the entire module after a single change that could implicitly affect other files. The only viable solution at the moment is to break the project into as many small modules as you can.
    - skohan 7y ago
      It's also useful to profile your compile times. Sometimes the compiler is spending most of its time on some small sections of code. For instance, I was working on a project where the use of one library constituted 80% of our compile time! The library allows you to declare autolayout constraints using operator overloads (i.e. `foo.top == container.top - 20`) and apparently the amount of type inference was just murdering our compile times. Changing libraries took this project from being awful to work on to quite pleasant.
      - ajconway 7y ago
        Swift also provides a compiler option specifically for debugging long compilation times: "-Xfrontend -warn-long-function-bodies=100"
      - gbrhaz 7y ago
        Ah, Cartography. Works great in a small project. We ended up moving to standard anchors for almost everything, with some helper methods to handle things like pinning to superviews.
tigershark 7y ago
F# and Kotlin seem better to me, and don’t have that hideous syntax for the closures. But it’s for sure another world compared to the awful objective c.
- saagarjha 7y ago
  > the awful objective c :(
- mojuba 7y ago
  I wouldn't say Kotlin is significantly better than Swift in terms of syntax, they are largely similar to the point you sometimes think: someone copied this from the other, I wonder who was the first. To me personally though the showstopper for Kotlin is that it runs on Java VM. That was the design goal of course, i.e. to become a major "upgrade" of Java esp. on Android. Java VM (with its GC) is a creation of the pre-mobile era when all we had was desktop computers, ever growing processing power and an assumption that you have infinite supply of electric power. It's a different philosophy and design. I think Google's choice of using it on a mobile platform was unfortunate, though at the time (i.e. before the iPhone) many popular mobile platforms did run on Java VM so it seemed like a natural choice.
  - algerd 7y ago
    what about kotlin native https://kotlinlang.org/docs/reference/native-overview.html https://kotlinlang.org/docs/reference/native-overview.html ?
    - singularity2001 7y ago
      Kotlinc takes 10 seconds to compile Hello World, 30 seconds with wasm target. Seems almost conceptually unfixable.
      - pjmlp 7y ago
        swiftc isn't also not that blazing fast. For me Delphi, .NET Native, D are some of the targets to beat in compilation time. They all share a common trait though, not built on top of LLVM.
jbverschoor 7y ago
I'ts def. one of the best designed languages, and has a ton of progress. They're also very agresive with deprecating things that should be changed.
seanparsons 7y ago
Words I never thought I'd see attributed to Swift, it's a blend of a Scala like design with Objective-C parts.
- saagarjha 7y ago
  It takes many of the good parts of both and wraps it in some very nice syntactic sugar. What's not to like?
  - seanparsons 7y ago
    Credit where credit is due, they did unicode "right", if you need to deal with those shenanigans it's really nice. However it also adopts a bunch of the bad parts like having variance but not really having a way to handle it. Last I remember the Equatable instance for tuples was just magic, it was impossible to rely on it with the types. Even maybe 6 months ago when I last tried this if you write some code that appends maybe 6/7 arrays together immutably the compiler would go into an exponential spin. The project I'm working on ending up dumping it entirely and moving over to being a web project written in TypeScript because it was so bad. Part of that being a laundry list of problems with the surrounding tooling like SourceKit which may or may not still apply.
ngcc_hk 7y ago
It is very easy to learn and use. Well compared with java and objective c. Learn it and push the app with v 1.0 is a bit hard but it works. In fact the app still there. Great language.
pharaohgeek 7y ago
I couldn't agree more. I'm anxious to see it build up a rich developer ecosystem like Java has. The availability of so many 3rd party libs for Java is a huge advantage. If Swift gets to that point I can see it taking over all of my server-side development.
- skohan 7y ago
  Which types of libraries in particular do you feel are missing?

Probably one of the most elegant languages around.

by sgt 7y ago

Probably one of the most elegant languages around.

melling 7y ago

Yes, it’s my favorite language. Now it needs better cross platform support to be more widely accepted.

gigatexal 7y ago
I hear server-side swift is gaining traction
clawoo 7y ago
And a proper IDE and a faster compiler. Xcode is dreadful with its strange fetish for recompilation even if there were no changes and the compiler is slower with every iteration. The solution put forward for this always seems to be "buy newer hardware".
- mojuba 7y ago
  Absolutely. One of the things I hate most is this thinking "run-time is more important than compile-time". Well the compiler and the IDE are runtimes too, we developers are users too, we sometimes work on our laptops unplugged and we do want our software to be fast and efficient!
  - skohan 7y ago
    > "run-time is more important than compile-time" This is a pitfall of Rust as well. I suppose there will always be a tradeoff between stronger static analysis and compilation time, and I'm firmly in the camp that I want my compiler to catch more issues so I don't have unexpected runtime failures, but iteration time matters too, and I'm hopeful improvements can be made in this area.
    - mojuba 7y ago
      Sometimes you introduce certain restrictions in the language just for the sake of simplifying the compiler. This is allowed, valid and will be understood by the developers. For example, for decades most static languages required a symbol to be defined before its first usage. Removing this restiction seemed like a nice little cute convenience but the outcome of it is this horrific slowdown of the build process. Personally I would agree to the restriction if I knew the compiler could be 5x faster which is pretty realistic to achieve, it seems.
      - skohan 7y ago
        Those kinds of restrictions can have their own productivity pitfalls. For instance, it might be the case that requiring declaration prior to usage explicitly will speed up the compiler, but it might also mean that you can't move blocks of code around without paying careful attention to the order of declaration. I think having a permissive compiler, but also being able to profile the compilation process is a reasonable compromise.
        mojuba 7y ago
        Possibly, but there are other kinds of compromises such as allowing arbitrary order only within a class, the C++ way. Or another one: the first (quick) pass treats all function and reference type definitions as forward declarations and skips the details. This way the compiler might be able to do more permissive compilation though not 100% accurate like Swift currently does.
  - ajconway 7y ago
    But run-time is more important, isn't that why we compile stuff with optimizations that take ages to process when building products for the end users? Compilers are hard, compiler bugs can have a devastating effect on one's software, so it's understandable that developers may prefer to take things slow but safe.
    - skohan 7y ago
      I guess ideally this should be a tradeoff in the hands of the developer right? I should be able to produce debug builds quickly so that I can iterate quickly, and if I want a super-optimal release build it's fine if it takes longer.
    - Gibbon1 7y ago
      My half joke is the optimizations slow down compilers. So people then try to make the compilers faster by increasing the levels of optimization. Which means they have to work harder. So they are slower.
- ajconway 7y ago
  In swift things have a module-wide visibility by default, that's why it often rebuilds the entire module after a single change that could implicitly affect other files. The only viable solution at the moment is to break the project into as many small modules as you can.
  - skohan 7y ago
    It's also useful to profile your compile times. Sometimes the compiler is spending most of its time on some small sections of code. For instance, I was working on a project where the use of one library constituted 80% of our compile time! The library allows you to declare autolayout constraints using operator overloads (i.e. `foo.top == container.top - 20`) and apparently the amount of type inference was just murdering our compile times. Changing libraries took this project from being awful to work on to quite pleasant.
    - ajconway 7y ago
      Swift also provides a compiler option specifically for debugging long compilation times: "-Xfrontend -warn-long-function-bodies=100"
    - gbrhaz 7y ago
      Ah, Cartography. Works great in a small project. We ended up moving to standard anchors for almost everything, with some helper methods to handle things like pinning to superviews.

tigershark 7y ago

F# and Kotlin seem better to me, and don’t have that hideous syntax for the closures. But it’s for sure another world compared to the awful objective c.

saagarjha 7y ago
> the awful objective c :(
mojuba 7y ago
I wouldn't say Kotlin is significantly better than Swift in terms of syntax, they are largely similar to the point you sometimes think: someone copied this from the other, I wonder who was the first. To me personally though the showstopper for Kotlin is that it runs on Java VM. That was the design goal of course, i.e. to become a major "upgrade" of Java esp. on Android. Java VM (with its GC) is a creation of the pre-mobile era when all we had was desktop computers, ever growing processing power and an assumption that you have infinite supply of electric power. It's a different philosophy and design. I think Google's choice of using it on a mobile platform was unfortunate, though at the time (i.e. before the iPhone) many popular mobile platforms did run on Java VM so it seemed like a natural choice.
- algerd 7y ago
  what about kotlin native https://kotlinlang.org/docs/reference/native-overview.html https://kotlinlang.org/docs/reference/native-overview.html ?
  - singularity2001 7y ago
    Kotlinc takes 10 seconds to compile Hello World, 30 seconds with wasm target. Seems almost conceptually unfixable.
    - pjmlp 7y ago
      swiftc isn't also not that blazing fast. For me Delphi, .NET Native, D are some of the targets to beat in compilation time. They all share a common trait though, not built on top of LLVM.

jbverschoor 7y ago

I'ts def. one of the best designed languages, and has a ton of progress. They're also very agresive with deprecating things that should be changed.

seanparsons 7y ago

Words I never thought I'd see attributed to Swift, it's a blend of a Scala like design with Objective-C parts.

saagarjha 7y ago
It takes many of the good parts of both and wraps it in some very nice syntactic sugar. What's not to like?
- seanparsons 7y ago
  Credit where credit is due, they did unicode "right", if you need to deal with those shenanigans it's really nice. However it also adopts a bunch of the bad parts like having variance but not really having a way to handle it. Last I remember the Equatable instance for tuples was just magic, it was impossible to rely on it with the types. Even maybe 6 months ago when I last tried this if you write some code that appends maybe 6/7 arrays together immutably the compiler would go into an exponential spin. The project I'm working on ending up dumping it entirely and moving over to being a web project written in TypeScript because it was so bad. Part of that being a laundry list of problems with the surrounding tooling like SourceKit which may or may not still apply.

ngcc_hk 7y ago

It is very easy to learn and use. Well compared with java and objective c. Learn it and push the app with v 1.0 is a bit hard but it works. In fact the app still there. Great language.

pharaohgeek 7y ago

I couldn't agree more. I'm anxious to see it build up a rich developer ecosystem like Java has. The availability of so many 3rd party libs for Java is a huge advantage. If Swift gets to that point I can see it taking over all of my server-side development.

skohan 7y ago
Which types of libraries in particular do you feel are missing?