Hacker News Reader

Comment by endisneigh | Hacker News Reader

I really like Go, but I'd love something like JavaScript that had the performance of C^. If and when that happens there really wouldn't be any need for other programming languages IMHO.

Oh well - that being said Go is way simpler than C++18 that I've done a tiny bit of work in. I think the issue is that Go generally competes with Ruby/Python/JavaScript in certain scenarios and just seems way more complex in comparison.

If you compare Go with C++/Java/C# it seems more reasonable and "easy."

^ the good news is that a ton of money is being spent to improve Node performance - whether it'll approach Java/C++ speed is TBD, but the performance gap is shrinking year by year.

View on HN

I find Java and C# to be significantly easier than Go. ("more reasonable" depends on your goals of course, though if I had to pick one language that makes it easy to do things in a reasonable way it would be Python.)

C# was one of the first languages I learned after HTML4 and Game Maker, no problem.

Java I learned later, no problem.

I also get C++ though I never used it enough to be really proficient.

And of course I know a bunch of other languages from awk to bash to javascript to php to ruby to sql to vba (not an exhaustive list).

But whenever someone makes something in Go, they seem to expect that the unique patterns and unusual operators for backgrounding tasks etc. to be intuitive to me and I should be able to pick up where they left off in a few minutes... it's not just not.

> C++18

(Out of curiosity, is this C++17 or C++20? I'd assume 17, and also I'm curious which aspects you find confusing.)

Several coworkers have remarked that it's just easier to reason about correctness of concurrent code in Go vs. C++, while not sacrificing performance as in, say, Python. (There's definitely a performance hit, per the use of a garbage collector.)

One thing that's always bothered me about Go is just the things that are missing from the standard library; I think that contributes significantly to it being "harder" to work with.

(A good number of these likely stem from the lack of generics, e.g. max(a, b int) int -- math.Max takes and returns floats.)

That said, the biggest thing I liked about Go from the first day I used it was the treatment of concurrency as a first-class citizen (goroutines, channels).

> but I'd love something like JavaScript that had the performance of C^

Java honestly is close. Data object creation is notably worse unless you're using Lombok or similar. Besides that, modern Java and JS syntax are similar. And Java doesn't have a horrible underlying object model based on prototype chains.

IMO Go seems easy because it's simple. I know Java and JS well and they're about the same complexity these days.

Knowing both I will never touch JS for backend again. Java is better suited for it. Strong typing is light-years easier to follow code paths and refactor. IDE's, debugging, profiling tools, memory usage, and performance are all better in Javaland. Real threading with proper shared memory exists. App size is smaller since Java bytecode is compact and distributed zipped.

My company stopped using JS on backend after the hype wore off. Our Java backends are easier to monitor and maintain.

How does Kotlin compare?

Kotlin is better on paper but IMO, only the better choice on Android. I always run into Kotlin tooling issues on "non-android" Java. Stuff like Maven plugins not working. Plus, IDE support is only good in IntelliJ and it's been that way for years so I don't expect it to change.

Kotlin fixes tons of issues in the frankensteined Java 8 of Android. You can use Java 15+ everywhere else and its adopting many features that made Kotlin worth using.

Google is pushing Kotlin so they have control over Android language like Apple does for iPhone. It's just a nice layer over Java in the end since 100% interop is required.

Java is a long way from Kotlin feature-wise and at the current rate of "innovation" we're more likely to have expired before Java catches up with Kotlin. I mean, come on, in the 25 years since 1.0 Java hasn't even fixed the requirement to escape metacharacters in a regex. The SAM lambdas of Java 8 are also a feeble compromise with FP at best. Kotlin has a much cleaner approach to FP, immutability and null safety.

I agree wrt to Java. Because Java has been around for so long it has a lot of emotional baggage that I think makes people reflexively dislike it. But, modern Java with any of the micro frameworks or something like Spring boot, plus jOOQ makes for a very easy and productive backend. And because Java has been around for so long, if you run into edge cases like parsing a weird file format, there is probably a library out there. Kotlin has a lot of same advantages, plus a more expressive syntax if that's what someone is after.

Go is also works for the backend, but you have to get into the mindset that you're probably going to write a lot of code. That's fine, but it's a shift from many other languages. As someone who has programmed for 20+ years, I like the single way to do most things in Go. There's also a bit of elegance coming full circle through many languages where a for loop is once again just a for loop.

And maybe I'm showing my age, but I also completely agree that backend languages need strong typing. The other option is significant test coverage, but we have all seen how that goes in practice. Code without strong typing always feels like it's meant to be written once and thrown away because it's so hard to read later. And, this style fits with how UIs often work where the life of a product will end up with many UIs on the same backend.

I was on the Java hate train till I was forced to use it. It became my favorite language. For being so old, Java has avoided feature creep and bad decisions that make old code painful to deal with.

Sometimes I work on 10+ year old areas of codebase and it's fine. Compared to dumpster fire of 10 year old JS/Python/C++ it's paradise.

I use lombok judiciously to avoid getters/setters, the cruftiest part of Java. Newer versions of Java are quite pleasant.

Java is extremely mature. I pull in a library and it "just works" 99% of the time. No worries about the version of Java is was built for or missing native dependencies. Practically every language falls short of the polished user experience in Java.

I don't like Kotlin because the non-Android experience is an afterthought and it's a captured language by Google and Jetbrains. Java has a lot more hands at the wheel.

There won’t be one ultimate language. The difference between low-level and high-level languages is significant. High-level languages allow you to not have to worry about intricacies of memory layout mostly, and thus even changing the data structures you use will not result in a refactor. While using low level languages, even ones like rust, you can change the allocation strategy/memory layout of your data structure, but you will need to refact on it. So it is a tradeoff between ease of code base change, and tight control on memory/resource usage.

I would try Kotlin.

Syntactically it's even more terse than JS and is as fast for most use cases as C. Main downsides are memory usage and needing to understand JVM limitations for latency sensitive codebases (TLDR: Use a modern JVM and ZGC or Shenandoah).

Note that with SubstrateVM/Graal native image, you get far lower memory usage and startup time equal to or even better than C.

Reply on news.ycombinator.com