11 ms·

C++ interop is impressive, and notoriously hard to get right. This seems like it would be able to cover a lot of APIs. Swift and C# are the well-designed langu

by kubb 3y ago

C++ interop is impressive, and notoriously hard to get right. This seems like it would be able to cover a lot of APIs. Swift and C# are the well-designed languages I'd rather use at my work instead of Go. It's a real shame both are effectively locked into a specific platform. You can really tell that they had years of attention and careful design by experts in PL poured into them. Go seems like an amateur hobby project in comparison.

wilg 3y ago
I'm not sure why you're saying Swift is locked in to Apple platforms, it's definitely cross-platform. It's no problem to run Swift on Linux or Windows. Of course, Apple's UI libraries aren't cross-platform. And they're putting a bunch of effort into making it better for servers and such. I wish more people realized how usable it is cross-platform, I think this is a misconception that hampers Swift adoption. Swift is definitely my favorite programming language from a language standpoint. I really like the way Swift works. It's safe, concise without being terse, and easy to extend. Sure, some people can argue there's some "bloat", but I think that's inevitable in a language that was designed to immediately be usable within Apple's existing APIs and frameworks. There's going to be complexity with Objective-C interop, C++ interop, etc. But that stuff is necessary for Swift to be usable for big projects. And I think Apple has done quite a good job of evolving Swift to be cleaner, clearer, more ergonomic, etc. I'm very excited that there's a lot of effort behind an open-source, cross-platform type-safe, compiled language that also prioritizes ergonomic high-level programming.
- t0ps0il 3y ago
  > I'm not sure why you're saying Swift is locked in to Apple platforms, it's definitely cross-platform I think the key word in OPs comment is "effectively". The tools for building cross platform Swift exist and work in various levels but they aren't at the point where you would want to choose Swift over existing cross platform tools.
  - wilg 3y ago
    That caveat does not match the definition of “effectively” to me.
- SubjectToChange 3y ago
  I don't trust Apple to care about platforms or developers that aren't directly benefiting them.
  - duped 3y ago
    They barely care about developers for their own platforms. Their docs are atrocious.
  - wilg 3y ago
    Who do you trust to do that?
    - SubjectToChange 3y ago
      Lots of open source projects and foundations, or businesses where you can actually pay for guarantees. Apple just doesn’t like making solid commitments to outsiders, especially for something as mundane as legacy support. They want to mold swift into anything they want/need.
coryrc 3y ago
IMO Go would have been 70% better with Result instead of (*type, error). So, so much duplicative code would have been avoided. It's not even a different paradigm. What a wasted opportunity.
metaltyphoon 3y ago
>It's a real shame both are effectively locked into a specific platform. This view of C# will be wrong for a almost a decade very soon! (if you don’t count mono)
- pjmlp 3y ago
  Depends on where on C# ecosystem one is, Web development, versus desktop.
dcgudeman 3y ago
How is C# locked in? It's pretty well supported on linux and mac.
- pjmlp 3y ago
  It is kind of, given the tooling that is still bound to .NET Framework, or that if you want to analyse profiling data, that is only available in VS/Windows. Also many .NET shops still only target VS for their SDK plugins. Additionally, VSCode seems to be getting a new developer experience, also tied to the same licenses as VS and VS4Mac. Finally, if you really want a cross platform GUI, you're better off with 3rd party like Avalonia and Uno, than anything Microsoft. This stuff in many shops is what makes them go Java instead of .NET, regardless of .NET Core/.NET 5+, as there are no "yes but" when discussing frameworks versus OS support.
bsaul 3y ago
Currently developing both in swift and go and i have the exact inverse feeling. Go seems to have been developped by true masters that really understand that less is more. They've also kept a laser sharp focus on working on things that really matters and took the time to do things right. Swift on the other hand looks like more and more bloated every day, without adressing the main pain points of the experience of coding in swift in the real world.
- SubjectToChange 3y ago
  Go seems to have been developped by true masters that really understand that less is more. "The key point here is our programmers are Googlers, they're not researchers. They're typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They're not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt." - Rob Pike Ignoring complexity on the language level simply passes the buck to application code, and developers end up paying that price across the ecosystem in perpetuity. They've also kept a laser sharp focus on working on things that really matters and took the time to do things right. Go's async model is underspecified, its implementation of generics incurs runtime overhead, much of the "wonderful tooling" only exists because of severe shortcomings in the language design and/or compiler implementation, its FFI is... difficult, etc. To be blunt, the values that Go embraces are none of the values I seek in a programming language or community. And I feel sorry for anyone too heavily invested in Go to turn back.
  - bsaul 3y ago
    golang concurrent programming is by far the best i've ever used for its application domain which is mainly infrastructure middlewares running in a connected environment. The tradeof between language features and maintainability is also IMHO the best in class. Never before have i ever looked at a stdlib sourcecode and told myself "hu, yeah i see how that works".
  - jstimpfle 3y ago
    I'll offer a different take: Thinking that complexity can be offloaded into the language is not seeing the whole picture. Offloading complexity into the language works for the simple cases, but the more one is trying to fit a solution into a physical box with physical constraints, and the more flexibility is required from the business logic, the situation will change in such a way that more control about the specific of the solution becomes a requirement, and the language shortcuts will fit less and less, to the point where they become a liability. Doubly so if it is difficult or impossible to unwrap the layers of language features. Of course, many problems can be solved with just a few Python scripts, or even with a huge pile of them. On the other hand, we can find a possible explanation why it could make sense for some teams to code huge apps in low-level languages (C or C++) or languages with few language features (e.g. Golang), or even to try and control the whole stack by maintaining their own language infrastructure.
tempodox 3y ago
I'm using F# via the .NET SDK on macOS (i.e. I could also use C#), so it seems to have less platform lock-in than Swift at this point. It does have its limitations, for instance I can't for the life of me figure out how to make the F# REPL UTF8-capable. As ludicrous as that is, it's not really my use case, so I can live with that for now.

by kubb 3y ago

wilg 3y ago

I'm not sure why you're saying Swift is locked in to Apple platforms, it's definitely cross-platform. It's no problem to run Swift on Linux or Windows. Of course, Apple's UI libraries aren't cross-platform. And they're putting a bunch of effort into making it better for servers and such. I wish more people realized how usable it is cross-platform, I think this is a misconception that hampers Swift adoption. Swift is definitely my favorite programming language from a language standpoint. I really like the way Swift works. It's safe, concise without being terse, and easy to extend. Sure, some people can argue there's some "bloat", but I think that's inevitable in a language that was designed to immediately be usable within Apple's existing APIs and frameworks. There's going to be complexity with Objective-C interop, C++ interop, etc. But that stuff is necessary for Swift to be usable for big projects. And I think Apple has done quite a good job of evolving Swift to be cleaner, clearer, more ergonomic, etc. I'm very excited that there's a lot of effort behind an open-source, cross-platform type-safe, compiled language that also prioritizes ergonomic high-level programming.

t0ps0il 3y ago
> I'm not sure why you're saying Swift is locked in to Apple platforms, it's definitely cross-platform I think the key word in OPs comment is "effectively". The tools for building cross platform Swift exist and work in various levels but they aren't at the point where you would want to choose Swift over existing cross platform tools.
- wilg 3y ago
  That caveat does not match the definition of “effectively” to me.
SubjectToChange 3y ago
I don't trust Apple to care about platforms or developers that aren't directly benefiting them.
- duped 3y ago
  They barely care about developers for their own platforms. Their docs are atrocious.
- wilg 3y ago
  Who do you trust to do that?
  - SubjectToChange 3y ago
    Lots of open source projects and foundations, or businesses where you can actually pay for guarantees. Apple just doesn’t like making solid commitments to outsiders, especially for something as mundane as legacy support. They want to mold swift into anything they want/need.

coryrc 3y ago

IMO Go would have been 70% better with Result instead of (*type, error). So, so much duplicative code would have been avoided. It's not even a different paradigm. What a wasted opportunity.

metaltyphoon 3y ago

>It's a real shame both are effectively locked into a specific platform. This view of C# will be wrong for a almost a decade very soon! (if you don’t count mono)

pjmlp 3y ago
Depends on where on C# ecosystem one is, Web development, versus desktop.

dcgudeman 3y ago

How is C# locked in? It's pretty well supported on linux and mac.

pjmlp 3y ago
It is kind of, given the tooling that is still bound to .NET Framework, or that if you want to analyse profiling data, that is only available in VS/Windows. Also many .NET shops still only target VS for their SDK plugins. Additionally, VSCode seems to be getting a new developer experience, also tied to the same licenses as VS and VS4Mac. Finally, if you really want a cross platform GUI, you're better off with 3rd party like Avalonia and Uno, than anything Microsoft. This stuff in many shops is what makes them go Java instead of .NET, regardless of .NET Core/.NET 5+, as there are no "yes but" when discussing frameworks versus OS support.

bsaul 3y ago

Currently developing both in swift and go and i have the exact inverse feeling. Go seems to have been developped by true masters that really understand that less is more. They've also kept a laser sharp focus on working on things that really matters and took the time to do things right. Swift on the other hand looks like more and more bloated every day, without adressing the main pain points of the experience of coding in swift in the real world.

SubjectToChange 3y ago
Go seems to have been developped by true masters that really understand that less is more. "The key point here is our programmers are Googlers, they're not researchers. They're typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They're not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt." - Rob Pike Ignoring complexity on the language level simply passes the buck to application code, and developers end up paying that price across the ecosystem in perpetuity. They've also kept a laser sharp focus on working on things that really matters and took the time to do things right. Go's async model is underspecified, its implementation of generics incurs runtime overhead, much of the "wonderful tooling" only exists because of severe shortcomings in the language design and/or compiler implementation, its FFI is... difficult, etc. To be blunt, the values that Go embraces are none of the values I seek in a programming language or community. And I feel sorry for anyone too heavily invested in Go to turn back.
- bsaul 3y ago
  golang concurrent programming is by far the best i've ever used for its application domain which is mainly infrastructure middlewares running in a connected environment. The tradeof between language features and maintainability is also IMHO the best in class. Never before have i ever looked at a stdlib sourcecode and told myself "hu, yeah i see how that works".
- jstimpfle 3y ago
  I'll offer a different take: Thinking that complexity can be offloaded into the language is not seeing the whole picture. Offloading complexity into the language works for the simple cases, but the more one is trying to fit a solution into a physical box with physical constraints, and the more flexibility is required from the business logic, the situation will change in such a way that more control about the specific of the solution becomes a requirement, and the language shortcuts will fit less and less, to the point where they become a liability. Doubly so if it is difficult or impossible to unwrap the layers of language features. Of course, many problems can be solved with just a few Python scripts, or even with a huge pile of them. On the other hand, we can find a possible explanation why it could make sense for some teams to code huge apps in low-level languages (C or C++) or languages with few language features (e.g. Golang), or even to try and control the whole stack by maintaining their own language infrastructure.

tempodox 3y ago

I'm using F# via the .NET SDK on macOS (i.e. I could also use C#), so it seems to have less platform lock-in than Swift at this point. It does have its limitations, for instance I can't for the life of me figure out how to make the F# REPL UTF8-capable. As ludicrous as that is, it's not really my use case, so I can live with that for now.