4 ms·

All three have different goals and solve different problems. While you can compare things like "they both have MATCH statements" or "unions are safe", deeper th

All three have different goals and solve different problems. While you can compare things like "they both have MATCH statements" or "unions are safe", deeper they have nothing to do with each other. You would be crazy to use swift (or objc) in real-time stuff. You would be crazy to write a UI-heavy app in rust. (note: I'm talking about high level DOM-like manipulation, not about rendering engines)

pdimitar 9y ago
Very true. In the same lane of thought, I am in love with Go when it comes to microservices, network libraries/bridges and CLI tools but it's very ill-suited for web development. So I shrugged it off and only do web dev with Elixir. Conversely, Elixir is awesome for a multitude of things but it absolutely can't compete with Go in its strong areas. Language wars are pointless.
blaenk 9y ago
> You would be crazy to write a UI-heavy app in rust. (note: I'm talking about high level DOM-like manipulation, not about rendering engines) I think the jury is still out on that one. I agree with the current state of things but the potential to ease and facilitate this is tremendous through the use of syntax extensions (procedural macros) which can dramatically simplify that use case. In general I think procedural macros add a _lot_ of versatility/flexibility to the language. I anticipate that there will be a huge boom in that area once they stabilize, and it will catch many people by surprise. An example of the versatility that they enable is the work-in-progress async/await [0], whereas in other languages they would usually have to be implemented in the language itself. Note that this does not preclude their implementation in the language itself, but since it's a work-in-progress they're able to experiment with them without having to implement them in the language from the beginning. [0]: https://github.com/alexcrichton/futures-await https://github.com/alexcrichton/futures-await
- hashmal 9y ago
  I have to agree, things could change in the future. However, my guts tell me rust GUI libraries/frameworks won't be as great as say, Cocoa, although that's something I would love.

pdimitar 9y ago

Very true. In the same lane of thought, I am in love with Go when it comes to microservices, network libraries/bridges and CLI tools but it's very ill-suited for web development. So I shrugged it off and only do web dev with Elixir. Conversely, Elixir is awesome for a multitude of things but it absolutely can't compete with Go in its strong areas. Language wars are pointless.

blaenk 9y ago

> You would be crazy to write a UI-heavy app in rust. (note: I'm talking about high level DOM-like manipulation, not about rendering engines) I think the jury is still out on that one. I agree with the current state of things but the potential to ease and facilitate this is tremendous through the use of syntax extensions (procedural macros) which can dramatically simplify that use case. In general I think procedural macros add a _lot_ of versatility/flexibility to the language. I anticipate that there will be a huge boom in that area once they stabilize, and it will catch many people by surprise. An example of the versatility that they enable is the work-in-progress async/await [0], whereas in other languages they would usually have to be implemented in the language itself. Note that this does not preclude their implementation in the language itself, but since it's a work-in-progress they're able to experiment with them without having to implement them in the language from the beginning. [0]: https://github.com/alexcrichton/futures-await https://github.com/alexcrichton/futures-await

hashmal 9y ago
I have to agree, things could change in the future. However, my guts tell me rust GUI libraries/frameworks won't be as great as say, Cocoa, although that's something I would love.