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

Swift at Apple: Migrating the Password Monitoring Service from Java

swift.org

Post reply on HN
Print view View original

221–230 of 235 posts

Re: Swift at Apple: Migrating the Password Monitoring Service from Java

#221

Post by hu3 »

georgeecollins wrote: post #152
miffy900 wrote: post #149

I'm going to call it now: Swift on the backend is pointless for everyone but Apple, and trying to make it takeoff as a backend service language is as pointless as porting Xcode cross platform and trying to lure non-Apple devs into using it over say VSCode, any JetBrains IDE or Visual Studio. The choices that already serve the market are just too numerous and the existing tooling is already far greater in features, fu…

I am really curious what people's take on Hacker News is of Swift. It feels like I heard about it more five years ago. People seem to like Go, Rust is cool (I learned that one), and Python, C#, Java seem here to stay. I mean I am asking as general purpose language, not just back end.

As for HN, I see comments about swift becoming complex and bloated with many ways to do the same thing. Like C++ish.

Re: Swift at Apple: Migrating the Password Monitoring Service from Java

#222

Post by pjmlp »

jen20 wrote: post #217
pjmlp wrote: post #200

Earlier quoted context omitted.

Ever heard of Swift macros? Do you know where Java EE comes from? It started as an Objective-C framework, a language which Swift has full interoperability with. https://en.wikipedia.org/wiki/Distributed_Objects_Everywhere

> Ever heard of Swift macros? Yes, having lived on the daily build bleeding edge of Swift for several years, including while macros were being developed, I have indeed heard of them. > Do you know where Java EE comes from? Fully aware of the history. The point stands: it is substantially harder with Swift to make the kind of spring style mess that JVM apps typically become (of course there are exceptions: I typically…

First the amount of Swift server apps has to grow to a number that is actually relevant for enterprise architects to pay attention.

Then I can start counting.

Re: Swift at Apple: Migrating the Password Monitoring Service from Java

#223

Post by acdha »

pjmlp wrote: post #216
acdha wrote: post #213

Earlier quoted context omitted.

That’s why I said “culture” - by all rights the JVM should win that competition. I wrote a bit more about the most recent one in a sibling comment but I’d summarize it as “the JVM can’t stop an enterprise Java developer”. https://news.ycombinator.com/item?id=44179589

Enterprise developers and architects would be the same, regardless of the programming language. I am old enough to have seen enterprise C and C++ developers. Where do you think stuff like DCE, CORBA, DCOM has come from? Also many of the things people blame Java for, where born as Smalltalk, Objective-C and C++ frameworks before being re-written in Java. Since we are in a Apple discussion thread, here is some Objectiv…

> Enterprise developers and architects would be the same, regardless of the programming language.

This is true to some extent but the reason I focused on culture is that there are patterns which people learn and pass on differently in each language. For example, enterprise COBOL programmers didn’t duplicate data in memory to the same extent not only due hardware constraints but also because there wasn’t a culture telling every young programmer that was the exemplar style to follow.

I totally agree about C++ having had the same problems but most of the enterprise folks jumped to Java or C# which felt like the community of people writing C++ improved the ratio of performance sensitive developers. Python had a bit of that, especially in the 2000s, but a lot of the Very Serious Architects didn’t like the language and so they didn’t influence the community anywhere near as much.

I’m not saying everyone involved are terrible, I just find it interesting how we like to talk about software engineering but there are a lot of major factors which are basically things people want to believe are good.

Re: Swift at Apple: Migrating the Password Monitoring Service from Java

#224

Post by throwaway2037 »

acdha wrote: post #212
throwaway2037 wrote: post #169

Earlier quoted context omitted.

> I’ve replaced Java code with Python a few times ... while performance at least doubled Are you saying you made Python code run twice as fast as Java code? I have written lots of both. I really struggle to make Python go fast. What am I doing wrong?

More precisely, when deploying the new service microservice it used less than half as much CPU to process more requests per second. This is not “Java slow, Python fast” – I expected it to be the reverse – but rather that the developers who cranked out a messy Spring app somehow managed to cancel out all of the work the JVM developers have done without doing anything obviously wrong. There wasn’t a single bottleneck,…

Okay, I understand your point. Basically, you rewrote an awful (clickbat-worthy) enterprisey Java web app into a reasonable, maintainable Python web app. I am sympathetic. Yes, I agree: I have seen, sadly, far more trashy Java enterprisey apps than not. Why? I don't know. The incentives are not well-aligned.

As a counterpoint: Look at Crazy Bob's (Lee/R.I.P.) Google Guice or Norman Maurer's Netty.IO or Tim Fox's Vert.x: All of them are examples of how to write ultra-lean, low-level, high-performance modern Java apps... but are frequently overlooked to hire cheap, low-skill Java devs to write "yet another Spring app".

Re: Swift at Apple: Migrating the Password Monitoring Service from Java

#225

Post by jen20 »

pjmlp wrote: post #222
jen20 wrote: post #217

Earlier quoted context omitted.

> Ever heard of Swift macros? Yes, having lived on the daily build bleeding edge of Swift for several years, including while macros were being developed, I have indeed heard of them. > Do you know where Java EE comes from? Fully aware of the history. The point stands: it is substantially harder with Swift to make the kind of spring style mess that JVM apps typically become (of course there are exceptions: I typically…

First the amount of Swift server apps has to grow to a number that is actually relevant for enterprise architects to pay attention. Then I can start counting.

That is the reason I used percentages, rather than absolute. For Java, every single app I’ve ever seen has been a massive shit show. For Swift, 0 of the 40-50 I’ve seen are.

Re: Swift at Apple: Migrating the Password Monitoring Service from Java

#226

Post by acdha »

throwaway2037 wrote: post #224
acdha wrote: post #212

Earlier quoted context omitted.

More precisely, when deploying the new service microservice it used less than half as much CPU to process more requests per second. This is not “Java slow, Python fast” – I expected it to be the reverse – but rather that the developers who cranked out a messy Spring app somehow managed to cancel out all of the work the JVM developers have done without doing anything obviously wrong. There wasn’t a single bottleneck,…

Okay, I understand your point. Basically, you rewrote an awful (clickbat-worthy) enterprisey Java web app into a reasonable, maintainable Python web app. I am sympathetic. Yes, I agree: I have seen, sadly, far more trashy Java enterprisey apps than not. Why? I don't know. The incentives are not well-aligned. As a counterpoint: Look at Crazy Bob's (Lee/R.I.P.) Google Guice or Norman Maurer's Netty.IO or Tim Fox's Vert…

> but are frequently overlooked to hire cheap, low-skill Java devs to write "yet another Spring app".

Yeah, that’s why I labeled it culture since it was totally a business failure with contracting companies basically doing the “why hire these expensive people when we get paid the same either way?” No point at ranting about the language, it can’t fix the business but unfortunately there’s a ton of inertia around that kind of development and a lot of people have been trained that way. I imagine this must be very frustrating for the Java team at Oracle knowing that their hard work is going to be buried by half of the users.

Re: Swift at Apple: Migrating the Password Monitoring Service from Java

#227

Post by uticus »

pjmlp wrote: post #201
latchkey wrote: post #47

Earlier quoted context omitted.

> I don't see any reason to evaluate Go at all. https://devblogs.microsoft.com/typescript/typescript-native-...

I don't buy the reasoning. First of all, it is a missed opportunity for Microsoft to have another vector for people to learn C#. Secondly at BUILD session, Anders ended up explaning that they needed to rewrite the AST data structures anyway, given that Go type system is much inferior to Typescript. And Go's story on WebAssembly is quite poor, when compared with Blazor toolchain, they are hopping Google will make the…

This is fascinating. I really bought into the original explanation [0], but seems like it was not the (full) truth.

[0] https://devblogs.microsoft.com/typescript/typescript-native-...

Re: Swift at Apple: Migrating the Password Monitoring Service from Java

#228

Post by maz1b »

dwaite wrote: post #186
maz1b wrote: post #24

I've always wondered a slight amount as to why larger enterprises (which have the resources to hire specialists) don't hire people with expertise in say things like Rust, or Elixir/Phoenix? It's one thing to say that we want to hire commonly available developers like in Java or C#, but if you have a long term plan and execution strategy, why not pick technology that may pay off larger dividends? ITT: I get why they c…

it sounds like you are asking why enterprises aren't choosing to write Rust code vs Java code. I wouldn't turn away a developer just because they had experience with Elixir. It really comes down to whether there's someone making the case that a particular application/subsystem has specialized needs that would warrant hiring experts, and whether they can make the case successfully that the system should use technologi…

No, I was making a point about if the goal is lowering resource usage, more throughput, concurrency, speed/perf, etc, a larger company can achieve that "unfair advantage" of things like rust or elixir etc because they have the resources as compared to SMBs or startups.

Of course, every company and org has to see whats best and feasible for them. Valid points you brought up no doubt.

Re: Swift at Apple: Migrating the Password Monitoring Service from Java

#229

Post by pjmlp »

jen20 wrote: post #225
pjmlp wrote: post #222

Earlier quoted context omitted.

First the amount of Swift server apps has to grow to a number that is actually relevant for enterprise architects to pay attention. Then I can start counting.

That is the reason I used percentages, rather than absolute. For Java, every single app I’ve ever seen has been a massive shit show. For Swift, 0 of the 40-50 I’ve seen are.

For Swift to be a shit show on Fortune 500 Linux and Windows servers, someone has to start shipping them in volume, regardless of percentiles.

Any language can be a shit show, when enough people beyond the adoption curve write code in them, from the letcoders with MIT degree to the six week bootcamp learners shipping single functions as a package, and architects designing future proof architectures on whiteboards with SAFe.

When Swift finally crosses into this world, then we can compare how much of it has survived the world scale adoption exposure, beyond cozy Apple ecosystem.

Re: Swift at Apple: Migrating the Password Monitoring Service from Java

#230

Post by artdigital »

k_bx wrote: post #187
artdigital wrote: post #132

Hearing a company like Apple is using swift on the server side changed my view on server Swift I’ll definitely take a look again, great to see it becoming mature enough to be another viable option

The big questions are: how's package management, community, ease of forking, patching and other dependency management related stuff. Server-side development needs those questions to have good answers.

Swift has all of that already answered. Non Xcode swift with SwiftPM is solid
Post reply on HN