C# was my favorite language to use, though I haven’t touched it in 7+ years because I don’t do any windows or desktop UI development anymore. It feels the most expressive and doesn’t get in your way too much. It has all the mainstream OO language features while not feeling overly burdensome like Java.
Go is now my favorite to use because it’s super fast at runtime and I don’t have to deal with a bunch of environmental and framework nonsense at runtime. It’s hands down the fastest runtime for serverless lambdas, which is the majority of my work. I have several gripes about the language, namely the embarrassment that is their implementation of type inheritance and generics, but the lack of ease for the developer is offset by performance. Java handles that stuff better, but I’m not trading a little ease in dev cycles for 20x longer cold starts and 5x poorer runtime performance. (Actual stats based on some use-case specific testing we did)
TypeScript is my fav for frontend dev (React), but it’s not as if there’s any choice there. I used to be a plain-JS psychopath, but then I had to work with other people on projects and TS makes that waaaaay easier.
Yeah, my team maintains a C#/.NET SDK and we don’t use any windows machines. We use mono for compilation, because that was the only option at the time the project started, but hope to make some updates soon to be able to use the newer targets that have native cross-platform support. Microsoft has come such a long way with .NET!
I was listening to a podcast on SE Radio a few years ago when they were interviewing some high performance stock trader (or maybe even the NYSE engineers themselves, I don’t recall) and they were talking about how they used sun.misc.Unsafe to basically do the low level memory operations that lower level languages allow. I don’t remember their reasoning on why they were using Java instead of an actual low level language but it was still fascinating.
I think newer versions of the JDK have been making it difficult or impossible to access that class though.
Curious about the tests you made with java and go.
Did you test classic JVM or the new native builds?
We are currently using mainly java with some node sprinkled in there, but I try to move some thinks we have from K8 pods into lambdas as it doesn’t make sense having it running 24/7. One of my coworkers often looked for a reason /place to introduce go.
So might be helpful info for him haha.
I don’t recall which Java environment was used; I’m not a Java developer so some of those technical details went in one ear and right out the other. They did implement snapstart for Java lambdas and that made the warm start time similar to Go. But the runtime performance isn’t even close after they put a bunch of effort into trying to optimize it.
I truly can’t recommend anything other than Go for lambdas. It’s better by every metric and it’s a lot easier to manage your infrastructure (just a single binary file with no file or environmental dependencies; it doesn’t get any more straightforward than that.) I’d definitely recommend doing a PoC to compare performance for your specific workload in Java vs. Go. As long as you have devs capable of writing Go, it’s a real winner. If you don’t, I’d still go with nodejs lambdas over Java; Java still seems to require a lot of tweaking to get its performance comparable. It’s a 30 year old swiss army knife, and it shows.
It’s a 30 year old swiss army knife, and it shows.
There is a lot of improvementsn happening in the Java space , so that might change over the next years.
It’s better by every metric and it’s a lot easier to manage your infrastructure (just a single binary file with no file or environmental dependencies; it doesn’t get any more straightforward than that.)
With these new native builds you also get a single binary file as far as I know ( I’m still kinda new to Java) and much better startup times.
So today Java might perform a little better in this comparison.
But I take it as a good chance for getting a chance to introduce go as a language.
C# was my favorite language to use, though I haven’t touched it in 7+ years because I don’t do any windows or desktop UI development anymore. It feels the most expressive and doesn’t get in your way too much. It has all the mainstream OO language features while not feeling overly burdensome like Java.
Go is now my favorite to use because it’s super fast at runtime and I don’t have to deal with a bunch of environmental and framework nonsense at runtime. It’s hands down the fastest runtime for serverless lambdas, which is the majority of my work. I have several gripes about the language, namely the embarrassment that is their implementation of type inheritance and generics, but the lack of ease for the developer is offset by performance. Java handles that stuff better, but I’m not trading a little ease in dev cycles for 20x longer cold starts and 5x poorer runtime performance. (Actual stats based on some use-case specific testing we did)
TypeScript is my fav for frontend dev (React), but it’s not as if there’s any choice there. I used to be a plain-JS psychopath, but then I had to work with other people on projects and TS makes that waaaaay easier.
.net core now has all the framework stuff and all runs great on Linux. C# is a really nice language.
Yeah, my team maintains a C#/.NET SDK and we don’t use any windows machines. We use mono for compilation, because that was the only option at the time the project started, but hope to make some updates soon to be able to use the newer targets that have native cross-platform support. Microsoft has come such a long way with .NET!
I was listening to a podcast on SE Radio a few years ago when they were interviewing some high performance stock trader (or maybe even the NYSE engineers themselves, I don’t recall) and they were talking about how they used
sun.misc.Unsafeto basically do the low level memory operations that lower level languages allow. I don’t remember their reasoning on why they were using Java instead of an actual low level language but it was still fascinating.I think newer versions of the JDK have been making it difficult or impossible to access that class though.
Curious about the tests you made with java and go. Did you test classic JVM or the new native builds?
We are currently using mainly java with some node sprinkled in there, but I try to move some thinks we have from K8 pods into lambdas as it doesn’t make sense having it running 24/7. One of my coworkers often looked for a reason /place to introduce go. So might be helpful info for him haha.
I don’t recall which Java environment was used; I’m not a Java developer so some of those technical details went in one ear and right out the other. They did implement snapstart for Java lambdas and that made the warm start time similar to Go. But the runtime performance isn’t even close after they put a bunch of effort into trying to optimize it.
I truly can’t recommend anything other than Go for lambdas. It’s better by every metric and it’s a lot easier to manage your infrastructure (just a single binary file with no file or environmental dependencies; it doesn’t get any more straightforward than that.) I’d definitely recommend doing a PoC to compare performance for your specific workload in Java vs. Go. As long as you have devs capable of writing Go, it’s a real winner. If you don’t, I’d still go with nodejs lambdas over Java; Java still seems to require a lot of tweaking to get its performance comparable. It’s a 30 year old swiss army knife, and it shows.
Thanks for your answer.
There is a lot of improvementsn happening in the Java space , so that might change over the next years.
With these new native builds you also get a single binary file as far as I know ( I’m still kinda new to Java) and much better startup times. So today Java might perform a little better in this comparison.
But I take it as a good chance for getting a chance to introduce go as a language.