8 ms·

Couple points (I've worked on app servers): 1- This is exactly how we should all be thinking about server engineering moving forward, as we aim to drastically

Couple points (I've worked on app servers): 1- This is exactly how we should all be thinking about server engineering moving forward, as we aim to drastically reduce carbon footprint within 11 years. Efficiencies at the language level are one of biggest bangs for buck here. Just by redeploying, you can reduce energy consumption by perhaps double digits. Imagine how hard that is to do at the hardware or energy farm level. Think about it: You, brave software engineer, can literally make a significant contribution to saving the world by adopting a more energy-efficient language, if you are fortunate enough to deploy something at scale. 2- Rust is killing it in these metrics but developer productivity / friendliness is important to overall success. Looking at these results I have a conjecture that is maybe provocative: The top two candidates for long-term success at supplanting Java on the server in my eyes are a) Go b) brace yourself.. Swift Swift is extremely young on the server, to the point where I'd expect your natural reaction to be "WTFLOL?! never heard of it". But here's some food for thought: the Netty team, one of the top performing Java server stacks, has been recruited by Apple and is chewing through all that stuff and just launched their NIO2 release[1] which I've heard is already very close to Netty. Go has an amazing concurrent garbage collector and has really pushed the envelope with that.[2] Swift is unique in the server world in that it uses reference counting which sidesteps the whole GC collection problem, which could translate into very low, very consistent latencies as well as memory usage. It's still quite early days for Swift, but these are the two languages I'm watching the closest. [1] https://forums.swift.org/c/server https://forums.swift.org/c/server [2] https://blog.golang.org/ismmkeynote https://blog.golang.org/ismmkeynote

mises 8y ago
> Swift That's a pretty cool idea. I read something on HN the other day about using swift in the back end, but haven't used it myself. Hopefully Apple gets support for non-ubuntu linuxes as well as windows out the door (especially since they're no longer making their own hardware). I've heard anecdotally that it has very slow compile times, so that might be another issue. > Swift is unique in the server world in that it uses reference counting Out of curiosity, why has no-one done automatic reference counting on the server side before? C++11 has smart pointers, and I believe python does as well (can't speak to this one personally). I also feel like most languages using the llvm backend could achieve performance at least close to c++; wasn't that part of the purpose? It seems like Swift might be especially ripe for this because Apple is the big developer of both LLVM and Swift.
- favorited 8y ago
  While I'm also bullish WRT Swift-on-the-server, reference counting has absolutely been done in server-side languages before. At least Python and PHP use reference counting, though they both also have runtime cycle breakers. Those examples are both interpreted languages, and they have a higher runtime cost for memory management because they're actively breaking reference cycles, so it's not apples-to-apples, but it's still reference counting.
- abalone 8y ago
  > Out of curiosity, why has no-one done automatic reference counting on the server side before? My guess is you fall into one of two categories: 1- You don't care a ton about efficiency because you can scale out to infinite servers that are relatively cheap and affordable. So you can run on django or rails or whatever and it's fine at "pre-IPO" scale. 2- You do care, but Java is good enough. So you kind of have to be at Google's scale to care about creating a new server language. In Swift's case, the motivation was super constrained mobile devices, so bringing it to the server side is more of an incremental engineering cost against that massive investment.
raz32dust 8y ago
Not sure why you picked on Java though. As per this study, Java is doing better than both of them. So at least if the goal is to improve on those, you need to look at Rust/C++/C/Ada.
- abalone 8y ago
  I'm not trying to pick on it. But those languages are significantly harder to develop for. Go/Swift are trying to be general improvements that maintain and improve upon developer productivity while achieving great performance and efficient memory utilization (which if you look at the paper is one area Java is not necessarily great at).
  - raz32dust 8y ago
    Makes sense. It didn't come across that way since you mentioned the energy savings and then immediately mentioned those alternatives. Interestingly though, while Java used a lot of memory, the energy expenditure for DRAM is still one of the lowest for Java. And they found little correlation between memory usage and DRAM energy in general. I wonder why that is.
    - abalone 8y ago
      Yeah they only looked at peak memory. They noted it would be more useful to look at continuous memory usage in future research. Also take note that the scale of the graphs is different. E.g. Figures 5 & 6 makes it look like Java energy is super low when it's really just similar to the compiled languages.[1] [1] http://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sleFinal.pdf http://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sleF...
  - cestith 8y ago
    Ada is not particularly difficult. It does suffer from a lack of tooling compared to some languages. It's a large language with many ways to do things and some dark corners. The same never stopped C++, Ruby, Perl, nor in its day PL/1. If you can learn C++ or Java then Ada is largely syntax changes, not wildly different semantics. If you know Pascal it's basically a huge extension with support for features like concurrency and pointers never standardized into Modula 2 or Pascal.
bilbo0s 8y ago
Two completely serious questions here, 1 - Why would you want to replace java on the server? (Seems obvious that it provides the best balance of productivity and performance per watt.) 2 - Assuming a company would want to replace jave, why, on earth, would we not use C++? (Or, perhaps, rust if we want to use a newcomer?) Why are we better off going all the way down this list to go and swift?
- abalone 8y ago
  > 1 - Why would you want to replace java on the server? Well one reason, if you look at the paper, is memory consumption. One of the ways Java gets good performance despite being a GC'd language is less efficient memory usage. (Although there are many advancements in this area akin to what Go has accomplished but as the paper's metrics show, often Java uses a lot of mem.) Also probably lots of people will agree that it has accumulated some cruft over the years and predates lots of modern trends and things like concurrency and functional programming and whatnot require more complicated code patterns.. a classic example is the getter/setter verbosity of a simple value type (not trying to start a flame war here). However it's fair to say Java is the thing to beat in terms of "goldilocks" languages that blend productivity/safety with performance. > 2 - ...would we not use C++? Because it's a huge regression in productivity and safety. The goal is to reduce memory consumption while achieving great performance and, crucially, consistently low latency which is a greatly underappreciated server metric and really should be the number one benchmark IMHO.
  - bilbo0s 8y ago
    >* is memory consumption...* ??? You're recommending a slower language, that uses more watts, on a presumably 24/7 backend... to save a few bucks on memory? As I said, if you want a company to switch to c++ or rust because you want to save money on memory IN ADDITION to all the money you're saving on watts, while getting the same or better performance? That might make some sense. Switching to go makes, No, sense. You end up paying more money per user session to do the equivalent work. (Even worse, each user waits longer because the work is done slower.) And then, like typical engineers, we'd proceed to explain to our bosses that all of this is actually better... because our new program uses less memory.
phlakaton 8y ago
I don't think carbon footprint is the be-all end-all you suggest. In a startup that has yet to scale, trading off efficiency for, say, flexibility, safety, or expressiveness may have minimal carbon impact but major benefit for your business. After all, few here will defend the choice of C for web service development these days.
- abalone 8y ago
  > In a startup... few here will defend the choice of C... Not sure what you're responding to but I specifically said "at scale" and "developer productivity / friendliness is important to overall success."
- maweki 8y ago
  I think 'safety' is the key term here. In the future we will see more self-driving cars and other self-... machines. I would like them to provably not crash (into me). If it were up to me, no matter the energy consumption, a piece of software in that realm should be proven correct (both crash-free and doing what the specification says).
  - bilbo0s 8y ago
    >a piece of software in that realm should be proven correct (both crash-free and doing what the specification says)... You do realize that a lot of autonomous driving software uses ML techniques that make providing guarantees like that difficult, right? (To be honest, oftentimes we can't even provide an explanation of why an ML decision was made, let alone "prove" why an ML decision is made. We only show tha most of the time, 98.3995% or whatever, the system should do "something like this".) But in any case, none of that would affect the languages at issue here, because no one would write self driving software in any of these languages. There's about a 10,000% chance that any such startup would use GPU languages to do the meat of that work. Almost 0% chance any reputable company relies on something like go or swift to drive an automobile out on public roads.
    - abalone 8y ago
tomcam 8y ago
How do you get the 11 years figure? What is your idea of a drastic reduction? How will you measure it? And should all countries observe it equally?
- abalone 8y ago
  Fortunately there are really extensive online resources you can consult for details! For example the United Nations Intergovernmental Panel on Climate Change.[1] [1] https://en.wikipedia.org/wiki/Intergovernmental_Panel_on_Climate_Change https://en.wikipedia.org/wiki/Intergovernmental_Panel_on_Cli...
  - tomcam 8y ago
    The United Nations has something like 30 different climate models. Also no one can forecast next month’s weather accurately, much less the weather from 12 years from now. Or do you know of a more accurate forecasting model? Such a model would be extraordinarily useful in agriculture and emergency management, for example.
    - abalone 8y ago
      This is like arguing that the science behind vaccines is invalid because doctors can’t predict when you’re going to catch your next cold. It’s willfully obtuse and has no place on HN.
      - shstalwart 8y ago
        Climatology is not science. There is no falsifying experiment.
        abalone 8y ago
        More anti-science nonsense. Here, let's let NASA tell you the definition of the scientific method.[1] [1] https://climate.nasa.gov/news/2743/the-scientific-method-and-climate-change-how-scientists-know/ https://climate.nasa.gov/news/2743/the-scientific-method-and...
the8472 8y ago
Go's GC is not really pushing the envelope. They have merely improved from a STW, non-compacting, non-generational collector with a 25% CPU overhead to a concurrent, non-compacting collector with reasonable overhead. JVMs and CLR had those a decade ago. The state of the art are concurrent, compacting, region-based pauseless or millisecond-pause collectors.
- hu3 8y ago
  Comparing Go's GC to one of the many specialized fine-tunned Java GCs is pointless, I find. I'm sure you're also aware that recent Go's GC pauses are sub millisecond for most use cases: "We now have an objective of 500 microseconds stop the world pause per GC cycle." - 2018 Go team https://blog.golang.org/ismmkeynote https://blog.golang.org/ismmkeynote My personal experience with microservices is to expect STW pauses in the 350 microsecond range. The best part is that it requires zero tunning or developer's attention while still being light on memory usage. Can't say the same for Java's default GC.
  - the8472 8y ago
    I was talking about technology state of the art, not out-of-the-box experience. OpenJDK's default collector - parallel or G1GC, depending on version - is not the best available among JVMs and if your goal is pause times then yes, it will be worse than Go's. But if you switch to say C4 or ZGC you'll get comparable pause times and compacting on top and being able to scale to terabyte heaps. 10 years ago we had Metronome and CMS, which are more comparable to Go's collector. And pause-times are not everything. Throughput and fragmentation resistance matter too. Compacting collectors fare much better on the latter metric. I don't know how the former is now, but those slides talked about 25% GC overhead in older versions of Go, that's utterly terrible. Go is facing one challange that java doesn't: internal pointers. But the CLR's collectors have to deal with those too, so that's not terra incognita either.
    - hu3 8y ago
      Of course gains are to be expected when switching from Java's default GC to something specialized. > 25% GC overhead in older versions of Go, that's utterly terrible. 25% overhead of what? And compared to what? Just throwing numbers in the air and saying it's terrible makes no sense. The only 25%'s if could find in the slide were these: https://blog.golang.org/ismmkeynote/image6.png https://blog.golang.org/ismmkeynote/image6.png 2014 Go: 25% of CPU used by GC 2018 Go: 25% of CPU used during 2x STW GC of < 500 microseconds So even if STW GC occurred as frequent as every second (which it doesn't in my use cases), this would amount to 0.025% of the CPU being used for GC, not 25%.
rudedogg 8y ago
I've spent the past several years programming w/ Swift, but the performance is a little concerning. Maybe the switch in Swift 5 to utf-8 backed Strings improves the performance? I think Rust w/ macros like you see in Rocket (https://rocket.rs/ https://rocket.rs/) looks promising. I haven't used it, but the guarantees, simplicity, and performance (possibilities - it doesn't use async yet) are really interesting.
ramensea 8y ago
I work in Swift on iOS. I think the "Swift on a server" idea is way over hyped. There are so many issues with the whole Swift stack adopting that servers side would be a mistake IMO. One of issues with Swift on a server is ARC vs a Go-like GC. If a company is legitimately concerned about runtime efficiency, they already have such great solutions. Go being one of those.
- abalone 8y ago
  I would love to hear your perspective but this is not a well supported argument. ARC is one of the most interesting things about Swift on the server. Historically one of the greatest challenges with servers is the impact of GC on the long tail of performance and latency. So, so much work has gone and continues to go into addressing the problem of low-overhead GC. You can appear to get great performance but then when you look at your stats you see that some significant percentage of your users are exceeding your maximum latency goals due to GC kicking in. Go and Java have made great strides but sometimes at the cost of memory inefficiency and/or optimizing for specific cases. Reference counting, by contrast, is entirely predictable. It doesn't defer any work. I would argue that CTOs are a lot more interested in consistently low latency than in requests per second. So it's very interesting to see an approachable, performant language take the ARC route on the server. It is early days though.
  - ramensea 8y ago
    My main issue of Swift's implementation of ARC is it commonly leads to memory leaks. Even experienced developers can cause unintentional memory leaks. It's extremely common in iOS development. It's also hard to even detect and eliminate them, you just seem memory usage climb as your app ages. It not an issue with iOS because it is commonly very small and an app's have such a short lifecycle. ARC would be just one my issues using Swift outside of iOS. I think you are overstating the pause duration of a modern GC. I have used both Go and the JVM server side, not at a huge scale but enough to see GC effecting response times. They add some fluctuate, but nothing compared to network latency or the multitude of other factors that fluctuate heavily. It was never significantly relevant for response times. I'm looking at my server logs right now and theres not even a real correlation between GC and response time. Unless you are considering a 0-10ms fluctuation. If you are interested in using an ARC server side I know Kotlin Native is using ARC however their implementation eliminates the cyclical reference issue.

mises 8y ago

> Swift That's a pretty cool idea. I read something on HN the other day about using swift in the back end, but haven't used it myself. Hopefully Apple gets support for non-ubuntu linuxes as well as windows out the door (especially since they're no longer making their own hardware). I've heard anecdotally that it has very slow compile times, so that might be another issue. > Swift is unique in the server world in that it uses reference counting Out of curiosity, why has no-one done automatic reference counting on the server side before? C++11 has smart pointers, and I believe python does as well (can't speak to this one personally). I also feel like most languages using the llvm backend could achieve performance at least close to c++; wasn't that part of the purpose? It seems like Swift might be especially ripe for this because Apple is the big developer of both LLVM and Swift.

favorited 8y ago
While I'm also bullish WRT Swift-on-the-server, reference counting has absolutely been done in server-side languages before. At least Python and PHP use reference counting, though they both also have runtime cycle breakers. Those examples are both interpreted languages, and they have a higher runtime cost for memory management because they're actively breaking reference cycles, so it's not apples-to-apples, but it's still reference counting.
abalone 8y ago
> Out of curiosity, why has no-one done automatic reference counting on the server side before? My guess is you fall into one of two categories: 1- You don't care a ton about efficiency because you can scale out to infinite servers that are relatively cheap and affordable. So you can run on django or rails or whatever and it's fine at "pre-IPO" scale. 2- You do care, but Java is good enough. So you kind of have to be at Google's scale to care about creating a new server language. In Swift's case, the motivation was super constrained mobile devices, so bringing it to the server side is more of an incremental engineering cost against that massive investment.

raz32dust 8y ago

Not sure why you picked on Java though. As per this study, Java is doing better than both of them. So at least if the goal is to improve on those, you need to look at Rust/C++/C/Ada.

abalone 8y ago
I'm not trying to pick on it. But those languages are significantly harder to develop for. Go/Swift are trying to be general improvements that maintain and improve upon developer productivity while achieving great performance and efficient memory utilization (which if you look at the paper is one area Java is not necessarily great at).
- raz32dust 8y ago
  Makes sense. It didn't come across that way since you mentioned the energy savings and then immediately mentioned those alternatives. Interestingly though, while Java used a lot of memory, the energy expenditure for DRAM is still one of the lowest for Java. And they found little correlation between memory usage and DRAM energy in general. I wonder why that is.
  - abalone 8y ago
    Yeah they only looked at peak memory. They noted it would be more useful to look at continuous memory usage in future research. Also take note that the scale of the graphs is different. E.g. Figures 5 & 6 makes it look like Java energy is super low when it's really just similar to the compiled languages.[1] [1] http://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sleFinal.pdf http://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sleF...
- cestith 8y ago
  Ada is not particularly difficult. It does suffer from a lack of tooling compared to some languages. It's a large language with many ways to do things and some dark corners. The same never stopped C++, Ruby, Perl, nor in its day PL/1. If you can learn C++ or Java then Ada is largely syntax changes, not wildly different semantics. If you know Pascal it's basically a huge extension with support for features like concurrency and pointers never standardized into Modula 2 or Pascal.

bilbo0s 8y ago

Two completely serious questions here, 1 - Why would you want to replace java on the server? (Seems obvious that it provides the best balance of productivity and performance per watt.) 2 - Assuming a company would want to replace jave, why, on earth, would we not use C++? (Or, perhaps, rust if we want to use a newcomer?) Why are we better off going all the way down this list to go and swift?

abalone 8y ago
> 1 - Why would you want to replace java on the server? Well one reason, if you look at the paper, is memory consumption. One of the ways Java gets good performance despite being a GC'd language is less efficient memory usage. (Although there are many advancements in this area akin to what Go has accomplished but as the paper's metrics show, often Java uses a lot of mem.) Also probably lots of people will agree that it has accumulated some cruft over the years and predates lots of modern trends and things like concurrency and functional programming and whatnot require more complicated code patterns.. a classic example is the getter/setter verbosity of a simple value type (not trying to start a flame war here). However it's fair to say Java is the thing to beat in terms of "goldilocks" languages that blend productivity/safety with performance. > 2 - ...would we not use C++? Because it's a huge regression in productivity and safety. The goal is to reduce memory consumption while achieving great performance and, crucially, consistently low latency which is a greatly underappreciated server metric and really should be the number one benchmark IMHO.
- bilbo0s 8y ago
  >* is memory consumption...* ??? You're recommending a slower language, that uses more watts, on a presumably 24/7 backend... to save a few bucks on memory? As I said, if you want a company to switch to c++ or rust because you want to save money on memory IN ADDITION to all the money you're saving on watts, while getting the same or better performance? That might make some sense. Switching to go makes, No, sense. You end up paying more money per user session to do the equivalent work. (Even worse, each user waits longer because the work is done slower.) And then, like typical engineers, we'd proceed to explain to our bosses that all of this is actually better... because our new program uses less memory.

phlakaton 8y ago

I don't think carbon footprint is the be-all end-all you suggest. In a startup that has yet to scale, trading off efficiency for, say, flexibility, safety, or expressiveness may have minimal carbon impact but major benefit for your business. After all, few here will defend the choice of C for web service development these days.

abalone 8y ago
> In a startup... few here will defend the choice of C... Not sure what you're responding to but I specifically said "at scale" and "developer productivity / friendliness is important to overall success."
maweki 8y ago
I think 'safety' is the key term here. In the future we will see more self-driving cars and other self-... machines. I would like them to provably not crash (into me). If it were up to me, no matter the energy consumption, a piece of software in that realm should be proven correct (both crash-free and doing what the specification says).
- bilbo0s 8y ago
  >a piece of software in that realm should be proven correct (both crash-free and doing what the specification says)... You do realize that a lot of autonomous driving software uses ML techniques that make providing guarantees like that difficult, right? (To be honest, oftentimes we can't even provide an explanation of why an ML decision was made, let alone "prove" why an ML decision is made. We only show tha most of the time, 98.3995% or whatever, the system should do "something like this".) But in any case, none of that would affect the languages at issue here, because no one would write self driving software in any of these languages. There's about a 10,000% chance that any such startup would use GPU languages to do the meat of that work. Almost 0% chance any reputable company relies on something like go or swift to drive an automobile out on public roads.
  - abalone 8y ago

tomcam 8y ago

How do you get the 11 years figure? What is your idea of a drastic reduction? How will you measure it? And should all countries observe it equally?

abalone 8y ago
Fortunately there are really extensive online resources you can consult for details! For example the United Nations Intergovernmental Panel on Climate Change.[1] [1] https://en.wikipedia.org/wiki/Intergovernmental_Panel_on_Climate_Change https://en.wikipedia.org/wiki/Intergovernmental_Panel_on_Cli...
- tomcam 8y ago
  The United Nations has something like 30 different climate models. Also no one can forecast next month’s weather accurately, much less the weather from 12 years from now. Or do you know of a more accurate forecasting model? Such a model would be extraordinarily useful in agriculture and emergency management, for example.
  - abalone 8y ago
    This is like arguing that the science behind vaccines is invalid because doctors can’t predict when you’re going to catch your next cold. It’s willfully obtuse and has no place on HN.
    - shstalwart 8y ago
      Climatology is not science. There is no falsifying experiment.
      - abalone 8y ago
        More anti-science nonsense. Here, let's let NASA tell you the definition of the scientific method.[1] [1] https://climate.nasa.gov/news/2743/the-scientific-method-and-climate-change-how-scientists-know/ https://climate.nasa.gov/news/2743/the-scientific-method-and...

the8472 8y ago

Go's GC is not really pushing the envelope. They have merely improved from a STW, non-compacting, non-generational collector with a 25% CPU overhead to a concurrent, non-compacting collector with reasonable overhead. JVMs and CLR had those a decade ago. The state of the art are concurrent, compacting, region-based pauseless or millisecond-pause collectors.

hu3 8y ago
Comparing Go's GC to one of the many specialized fine-tunned Java GCs is pointless, I find. I'm sure you're also aware that recent Go's GC pauses are sub millisecond for most use cases: "We now have an objective of 500 microseconds stop the world pause per GC cycle." - 2018 Go team https://blog.golang.org/ismmkeynote https://blog.golang.org/ismmkeynote My personal experience with microservices is to expect STW pauses in the 350 microsecond range. The best part is that it requires zero tunning or developer's attention while still being light on memory usage. Can't say the same for Java's default GC.
- the8472 8y ago
  I was talking about technology state of the art, not out-of-the-box experience. OpenJDK's default collector - parallel or G1GC, depending on version - is not the best available among JVMs and if your goal is pause times then yes, it will be worse than Go's. But if you switch to say C4 or ZGC you'll get comparable pause times and compacting on top and being able to scale to terabyte heaps. 10 years ago we had Metronome and CMS, which are more comparable to Go's collector. And pause-times are not everything. Throughput and fragmentation resistance matter too. Compacting collectors fare much better on the latter metric. I don't know how the former is now, but those slides talked about 25% GC overhead in older versions of Go, that's utterly terrible. Go is facing one challange that java doesn't: internal pointers. But the CLR's collectors have to deal with those too, so that's not terra incognita either.
  - hu3 8y ago
    Of course gains are to be expected when switching from Java's default GC to something specialized. > 25% GC overhead in older versions of Go, that's utterly terrible. 25% overhead of what? And compared to what? Just throwing numbers in the air and saying it's terrible makes no sense. The only 25%'s if could find in the slide were these: https://blog.golang.org/ismmkeynote/image6.png https://blog.golang.org/ismmkeynote/image6.png 2014 Go: 25% of CPU used by GC 2018 Go: 25% of CPU used during 2x STW GC of < 500 microseconds So even if STW GC occurred as frequent as every second (which it doesn't in my use cases), this would amount to 0.025% of the CPU being used for GC, not 25%.

rudedogg 8y ago

I've spent the past several years programming w/ Swift, but the performance is a little concerning. Maybe the switch in Swift 5 to utf-8 backed Strings improves the performance? I think Rust w/ macros like you see in Rocket (https://rocket.rs/ https://rocket.rs/) looks promising. I haven't used it, but the guarantees, simplicity, and performance (possibilities - it doesn't use async yet) are really interesting.

ramensea 8y ago

I work in Swift on iOS. I think the "Swift on a server" idea is way over hyped. There are so many issues with the whole Swift stack adopting that servers side would be a mistake IMO. One of issues with Swift on a server is ARC vs a Go-like GC. If a company is legitimately concerned about runtime efficiency, they already have such great solutions. Go being one of those.

abalone 8y ago
I would love to hear your perspective but this is not a well supported argument. ARC is one of the most interesting things about Swift on the server. Historically one of the greatest challenges with servers is the impact of GC on the long tail of performance and latency. So, so much work has gone and continues to go into addressing the problem of low-overhead GC. You can appear to get great performance but then when you look at your stats you see that some significant percentage of your users are exceeding your maximum latency goals due to GC kicking in. Go and Java have made great strides but sometimes at the cost of memory inefficiency and/or optimizing for specific cases. Reference counting, by contrast, is entirely predictable. It doesn't defer any work. I would argue that CTOs are a lot more interested in consistently low latency than in requests per second. So it's very interesting to see an approachable, performant language take the ARC route on the server. It is early days though.
- ramensea 8y ago
  My main issue of Swift's implementation of ARC is it commonly leads to memory leaks. Even experienced developers can cause unintentional memory leaks. It's extremely common in iOS development. It's also hard to even detect and eliminate them, you just seem memory usage climb as your app ages. It not an issue with iOS because it is commonly very small and an app's have such a short lifecycle. ARC would be just one my issues using Swift outside of iOS. I think you are overstating the pause duration of a modern GC. I have used both Go and the JVM server side, not at a huge scale but enough to see GC effecting response times. They add some fluctuate, but nothing compared to network latency or the multitude of other factors that fluctuate heavily. It was never significantly relevant for response times. I'm looking at my server logs right now and theres not even a real correlation between GC and response time. Unless you are considering a 0-10ms fluctuation. If you are interested in using an ARC server side I know Kotlin Native is using ARC however their implementation eliminates the cyclical reference issue.