571–580 of 777 posts
Earlier quoted context omitted.
C# is a better language, but the JVM is a significantly better ecosystem. Java will always be behind (and type erasure for generics is annoying enough as someone who started in C# that I don't think it will ever catch up) but between hotspot and being the preferred language of 2/3rds of the clouds I think it clearly wins.
If you like jvm, use closure instead.
Earlier quoted context omitted.
I did. Did Go professionally for ~5 years and went to JVM. Go is easy, but it's surface level easy. Building and maintaining large applications in Go if you don't have a huge team is a giant pain. JVM (especially paired with Kotlin) for me atleast has meant regaining the expressivity I was missing from Ruby and Python when I moved to Go whilst retaining (well actually usually beating) it on performance and scalabilit…
I’ve got to disagree with this strongly. I built and operated the same large system in both languages (acquisition forced me to rewrite) and both the dev and operating cost of the JVM was much higher. Go is a high velocity language. Code reviews on language/style issues are non existent, it’s GC is blazing fast (not our experience with JVM) and it’s really easy to read. I’ve watched many new engineers ramp up on both…
Lack of a "default" stack for nearly anything. The stdlib is great but the ecosystem isn't. Which web framework? Does it come with a logger? If not which logger? Do the third party libraries I want to use work with my logger/have a mechanism to provide one via an interface or am I shit out of luck? This goes for so many more things though, cache libraries, data structures (because Go stdlib collections are a joke). Contrast to Java here you have a relatively minimal set of very long-lived deps for all of these "basic" things. Ecosystems like Spring, the slf4 facade, Apache etc provide the foundation that most Java programs sit on and that has no alternative in Go land.
Go module transition was also hot garbage. It's better after sure but going through it was worse than Java 8-9 or to Java 11+ both of which were "difficult" transitions for Java but vastly less disruptive for me personally at least. Then take all of this stuff and multiply it by the number of teams you have if you don't have a central team doing library choices and laying down architecture guidelines - which we eventually got but not before all the Go codebases had turned into by and large unmaintainable messes.
IMO Go is high velocity only in the simplest sense, it's very easy to pump out shit tons of code. With a big team of mediocre developers this is even more true. The problems all come later. Big change in requirements? Good luck with that. Had a team try to go crazy functional with Go and now they have immutable data everywhere and allocations are completely destroying the throughput of the Go GC? Good luck fixing that. etc.
The velocity eventually moves from it's strength to it's achilles heel once the codebases are big and bad they are really hard to fix.
I get that most of these problems are "big company" problems and maybe in smaller teams with a stronger hiring bar you won't run into these or maybe not at the same severity but they severely impacted my view of how well the language scales to large teams and codebases.
Earlier quoted context omitted.
> You mentioned "distribute software" but did not consider Electron for Node. Sorry for the snark, but users will undoubtedly be very grateful to them for not considering Electron.
I'm not so sure if the users of VS Code, Discord, Slack, etc would agree. Yes it's bulky and sometimes slow, but it offers a lot of features and allow developers to ship features and updates really fast, while only needing one codebase for all platform.
I've used Electron as a developer, too. While it may have been fast & easy at one time, I think that argument is losing merit. Electron had a lot of security holes and patching them has made common tasks harder. Security with Electron is a problem in general given its massive surface area.
Users definitely notice the performance issues. It's certainly not just devs complaining about abstract issues. Yes, people use these tools, but that's mostly out of necessity, not preference. Moreover, big players like VS Code have had to write swathes of the app in C++ for performance reasons.
I look forward to a return to optimizing for the user, not developer velocity. There will likely always be attempts at cross-platform toolkits and there may be a good solution in that space. I hope Electron isn't the best we can do.
[flagged]
Is golang still using mark and sweep gc?
Earlier quoted context omitted.
I'm curious to understand what dependency injection is in Django that you're referring to? I know pytest does DI with fixtures, and trying to figure out what you're pulling into a test can be difficult.
In django you're importing a default cache, a default storage etc, and write your code to the interface. In settings.py you wire it all up. It's basically the same, for testing you would have to mock the import or provide some implementation.
Earlier quoted context omitted.
I did. Did Go professionally for ~5 years and went to JVM. Go is easy, but it's surface level easy. Building and maintaining large applications in Go if you don't have a huge team is a giant pain. JVM (especially paired with Kotlin) for me atleast has meant regaining the expressivity I was missing from Ruby and Python when I moved to Go whilst retaining (well actually usually beating) it on performance and scalabilit…
> JVM (especially paired with Kotlin) I agree the Go lang compiler/runtime needs "a Kotlin", with more null-safey build in, proper sum types, a std lib that makes heavy use of null-safety and sum types, better story for polymorphism, better ergonomics for writing stream pipelines, and additional compilation targets (like JS, WASM). This all while proving stellar interop with all Go code, obviously. Kotlin is quite a…
Earlier quoted context omitted.
I don't think any existing Go developer is going back to Java. I worked with Java for 10 years and switched to Go and I will never go back. This is mostly because applications and libraries are so hard to reason about and understand due to inheritance, packaging, OOP, build tools ect compared to Go. Go is simple. It's easy to understand, read, and maintain. The packaging is like how you would package files on your co…
Exception handling and generics are missing key pieces from go. But adding them will make go look like java. I just wish java would add null safety in the type system in a first citizen way. For enterprise use java has no competitors. You have c# which is microsoft trying to estabilish nash equilibrium fu*ing the developers. I am a bit worried about ever increasing complexity and a steep learning curve, but seems lik…
You know that Go has generics since a couple of years now?
The biggest problem with Java is... the walled garden, the snob society, the elitist, exclusive culture. Go isn't like that, or at least wasn't when G+ was still around. Nowadays I don't get in touch much with people, but when I create issues Go people are usually not as unfriendly as Java/JVM people.
> The biggest problem with Java is... the walled garden, the snob society, the elitist, exclusive culture. No idea how you have managed to come to such a conclusion, or what kind of experienced you might have had. I have been part of some of the core JSR/groups, as rather independent/unaffiliated (not oracle/google/hp/ibm/twitter) - there was no gate keeping, elitism or anything alike. I'd consider mailing lists extr…
Earlier quoted context omitted.
I’ve got to disagree with this strongly. I built and operated the same large system in both languages (acquisition forced me to rewrite) and both the dev and operating cost of the JVM was much higher. Go is a high velocity language. Code reviews on language/style issues are non existent, it’s GC is blazing fast (not our experience with JVM) and it’s really easy to read. I’ve watched many new engineers ramp up on both…
The main pain-points in a large org at least: Lack of a "default" stack for nearly anything. The stdlib is great but the ecosystem isn't. Which web framework? Does it come with a logger? If not which logger? Do the third party libraries I want to use work with my logger/have a mechanism to provide one via an interface or am I shit out of luck? This goes for so many more things though, cache libraries, data structures…
>IMO Go is high velocity only in the simplest sense, it's very easy to pump out shit tons of code. With a big team of mediocre developers this is even more true. The problems all come later. Big change in requirements? Good luck with that. Had a team try to go crazy functional with Go and now they have immutable data everywhere and allocations are completely destroying the throughput of the Go GC? Good luck fixing that. etc.
I doublt things would go better for teams trying to go full OO in haskell, or full functional in Java.