9 ms·

I couldn't disagree with this any harder. I'm a Java BE Engineer who joined a Go shop, so I have a direct comparison. Both are microservice environments for pro

by Spiwux 4y ago

I couldn't disagree with this any harder. I'm a Java BE Engineer who joined a Go shop, so I have a direct comparison. Both are microservice environments for products of similar complexity. It is insane to me how much less productive Go is for your average microservice enterprise environment. I'm sure it's great for systems programming or tool development. I like the simplicity. But the ecosystem is borderline useless for larger scale enterprise-y service landscapes. GRPC and Protobuf are overengineered and underdocumented, a lot of things are seemingly optimized for Google's specific needs. We are more people, we are more experienced and have a decent engineering culture. Yet we're definitely less productive than the last average, traditional Java Spring Enterprise team I've been in. "Circumventing" a framework restriction (which rarely happens if you stick to good practices) is MUCH less effort than building things yourself from scratch.

zackkitzmiller 4y ago
Then don't use GRPC and Protobufs. I've had exactly the opposite experience building enterprise software with Go.
- deleted 4y ago
  [deleted]
pleb_nz 4y ago
That is my thoughts as well. It sounds like this would lead to more reinventing the wheel than I'd like to see in a product like a web app/service.
asim 4y ago
This 100%. I think the people largely arguing for no frameworks have no idea what real productivity looks like at large scale engineering orgs. This mostly means you are not handcrafting libraries. There is a dedicated team who manages platform tooling including the frameworks/SDKs you use. Product teams may contribute to that but they will mostly be consumers. I always equate this to car manufacturing. I am not buying a kit car, I am not buying a hobby car, I'm buying a well engineered product from a large scale manufacturer. Frameworks and platforms fall into this category, especially for enterprises. I think it's fine for small teams not to use frameworks, and maybe 200 person engineering orgs are made up of many small teams who just want to agree on a protocol rather than shared framework/platform but once the scale starts to increase you really need to start tightening up and implementing some better standards. People constantly talk about not being Google, well let me tell you the people scale is all the same, the amount of legacy infra is all the same. If you haven't peaked into the depths of the messy multi-decade enterprise you have no clue. Your 4 year old company that you joined 6 months ago is no comparison to something with a legacy of 3 decades with 2k+ engineeers scattered across a disparate org trying to modernise in the cloud or whatever comes next. Full disclosure: I work on https://micro.dev https://micro.dev - a framework for Go
- pdpi 4y ago
  “Real productivity at large scale engineering orgs” means a bazillion different things, because a big org can afford to have different teams specialise in different things. No-framework Go makes the most sense to me, because a big framework doesn’t make sense for all types of project, and the set of projects where I’d reach for a big framework just doesn’t intersect _at all_ with the set of projects where I’d reach for Go.
  - asim 4y ago
    It goes back to, what is a framework and what qualifies as a big framework here. I think classic rails isn't the fit, but something that's an extension of gRPC definitely works. What gets handcrafted is a lot of layers around gRPC or far more stuff around HTTP. When I'm working on personal projects, frameworks don't make sense for me. When I'm trying to engineer something at scale e.g https://m3o.com https://m3o.com then I need that standardisation at the platform layer, the framework layer, the API layer.
    - pdpi 4y ago
      When you're building something "at scale", there'll be business logic API services, cache services, routing/dispatch services, and many other such things. What I'm saying is that I find business logic-centric API services to be a good fit for larger frameworks that take ownership of more of the low level logic, and I don't find Go to be a good fit for those, at all. Inversely, I find Go to be a much better fit for the more "technical" services (provided we're not at the must-squeeze-every-ounce-of-performance C++/Rust level of requirements), but I also don't want a framework getting in the way.
- nf17 4y ago
  micro.dev is different from an actual go framework go-micro.dev ?? (https://github.com/go-micro/go-micro https://github.com/go-micro/go-micro)
  - asim 4y ago
molodec 4y ago
I have to switch between Java Spring boot, Go and Rust. The latter two are framework less and easy to understand just by reading the code. Spring-boot development requires so much googling to figure out why I get UnsatisfiedDependencyException and what each annotation means. Even if I get it to work I still don't understand how it works.
- cduzz 4y ago
  I'm not sure that's contradicting the parent post. A framework is an added friction to picking up a development environment but potentially a huge asset to velocity once people are up to speed. You haven't gotten properly up to speed in that framework and that site's use of the framework. Perhaps you never spend enough time in that domain to really need to pick it up, in which case you'll always pay the "WTF is this?" tax. But it's equally likely that once a person's up to speed in the framework they're efficiency is greatly enhanced. A programming language isn't just the syntax of the language; there's also knowing the common idioms of the language, understanding the runtime / build environment, knowing when and how to leverage the standard and extended libraries/package ecosystem, etc. Frameworks fall into the "extended package ecosystem" which is vastly different from language to language, and sometimes _within_ a language if the language is sufficiently mature. Some of it is "just math" and some of it is understanding the culture.
  - Tainnor 4y ago
    Some of the pains with Spring Boot don't go away even when you understand it better. The fact that the framework relies so heavily on reflection makes debugging a pain, turns what should be compile-time errors into runtime errors (which, among other things, makes updating libraries annoying), and also leads to very slow integration tests. I also haven't yet met a developer who fully understands what @Transactional does, exactly. I agree Spring Boot brings a lot to the table (Spring Security alone, for example), but at the cost of significant downsides. I see the benefit for larger and more diverse teams, but personally I would choose lighter-weight frameworks and libraries, even if at the cost of having to do more plumbing myself.
mad_vill 4y ago
The lack of detailed documentation for grpc is pretty crazy considering how many people seem to be using it. So many hours wasted investigating fringe http2 characteristics causing odd bugs on the platform.
- tempest_ 4y ago
  It is so bad. Outside of Go (I assume because it seems pretty popular there) the clients for other languages are so hit and miss. I had to pipe a json into the python client to configure a grpc client (which seems bad) and it took me a while to dig up the correct incantation. I like the "contract" that GRPC implies but I am not sure I would choose it again.
  - dalyons 4y ago
    Try twirp! Same protos for contracts, but everything is much simpler , saner and slimmer , and just uses standard http. It’s great.
Thaxll 4y ago
You're saying that grpc and protobuf are over engineered but you're happy with Spring? gRPC and protobuf are just transport and serialization, they have nothing to do with business logic, on the other hand Spring is a heavy, bloated framework. Most Java frameworks are complicated backed by layers of abstraction and black magic. btw no framework does not mean you don't use any library, there are some good lib aka micro framework that have everything you need to build modern and decent api servers. https://github.com/go-chi/chi https://github.com/go-chi/chi https://echo.labstack.com/ https://echo.labstack.com/
- agotterer 4y ago
  Twirp (by TwitchTV) is a good gRPC alternative. It’s significantly lighter and easier to use.
  - staunch 4y ago
    Better than an alternative is Connect, which is gRPC but also supports gRPC-Web and the lighter weight Connect protocol (which seems inspired by Twirp) https://buf.build/blog/connect-a-better-grpc https://buf.build/blog/connect-a-better-grpc I like it because it solves most of my complaints about using gRPC from Go without giving up on gRPC.
- berkes 4y ago
  > btw no framework does not mean you don't use any library I hear that silly argument "no framework === rewrite everything from scratch" far too often. There's a giant difference between libraries and frameworks! It's terminology: it's a framework if you build your app inside it. It's a library if you build it inside your app. The later is fine. The former: I dislike it - even in JavaScript, Ruby, Rust or anything, I wrote a longer post on that[1], which got a lot of discussion on HN. Most of it too in the line of "lol, I use a framework because I don't want to write it all myself", completely missing the crucial first paragraph in which I carefully tried to explain the difference and explain that re-using code != using a framework. [1] https://news.ycombinator.com/item?id=33185010 https://news.ycombinator.com/item?id=33185010
linza 4y ago
You didn't specify what you meant with "more productive", but if it means "being able to produce more code in less amount of time" then i agree that one can be faster with frameworks/Java. If you look at the problem more holistically (say "run a reliable service customers want to use") then that metric is just one of many, and more often than not counterproductive vs some other metrics like maintainability and resilience for instance. IME frameworks reflect that and only let you write code fast, or get the hello-world-demo out fast, but neglect the later stages. I don't know if the conclusion is no framework is better overall, but the frameworks i worked with at least showed mixed results overall.
- jrumbut 4y ago
  We're not going to settle this today but I think the later stages are where frameworks shine. For instance, when Oauth became popular I was maintaining several apps where the original authors had never dreamed of an alternative login method (email and password had been the norm for longer than any of us had worked as developers). The Rails apps required a few small config changes which I could get from the documentation then HTML for the "Login with Facebook" button. The framework-less apps were disasters. Each had their own way of doing things. Some used libraries that were no longer maintained, others had rolled their own authentication workflow or half copied the code from another project. There is a lot to be said for frameworks when facing an unpredictable future. There is a cost to be paid up front as far as learning the framework but the benefits on the back end are enormous.
  - randomdata 4y ago
    > The Rails apps required a few small config changes which I could get from the documentation What Rails configuration would be pertinent to Oauth? Perhaps you mean the application was already using some kind of third-party authentication library (e.g. Devise) that supported Oauth? If that's the case, didn't you just luck out that the developers happened to choose a library that 1. Was still being maintained. 2. Had already added Oauth support? Most of the Rails apps I have encountered in my career (especially those predating Oauth popularity) used hand-rolled authentication, each different to the next, so it seems that you could have just as easily fell into the same trap you saw elsewhere. It is not clear how Rails saved you here.
geodel 4y ago
Well there are all sorts of programming. Writing code from scratch to solve problems, writing glue code to connect various libraries, fill in the gaps in code generated by framework scaffolding, drag-n-drop blocks in diagrams and code is generated in the background and so on. Java/SpringBoot/etc micro services developers have certain way of doing things and they are certainly going to hit lot of problems with Go. Since I have worked in typical Java/J2EE/Microservices project all my career, I think, for most devs coming from larger Java ecosystem, mapping their existing understanding to Go way of doing things is pretty much impossible.
liampulles 4y ago
Different strokes I guess. I've previously worked at big orgs. with Spring, now working with Go microservices and enjoying it by and large. I don't miss the days where I had to deal with random missing or conflicting beans stopping my app from starting. The nice things about a Go app is because the control flow is so exposed, if it compiles you can be pretty sure it is going to run, and if it doesn't compile you can go to the red in your IDE and fix it. Adding an endpoint is a matter of updating our OpenAPI file and doing `make oapi-gen` for the code generator we use. I think this is a similar level of effort to doing the same with a mvn or gradle command. The real difference I notice between Go and Spring microservices though is how much easier it is to dev and debug multiple microservices - it is trivial to compile all of our Go microservices and boot some of them up for debugging without eating all of my laptop's RAM, which is especially relevant if I also want to run them in Kubernetes locally. I will say I do miss some of the niceties of aspect oriented programming with Spring.
- cnity 4y ago
  By far my least favourite thing about the Java web ecosystem is how weirdly obscured the bootstrapping process for starting processes is. So much of how your application starts is determined by XML files and DI frameworks that I often have no idea (or am sometimes not even exposed to) where the `main` function is.
  - jcelerier 4y ago
    Caring about the main function in a framework-ey app generally makes as much sense as caring about the x86 initial boot code when launching mspaint.exe
    - digianarchist 4y ago
      I've seen devs write caches that were shared between customers because they didn't understand the lifecycle of Spring Autowired dependencies. Understanding how the framework wires things together is important.
    - cnity 4y ago
wtetzner 4y ago
When I did Java, I found the Java ecosystem to be very productive because of the libraries available, but Spring was basically useless and was just a way to convert compile-time errors into confusing runtime errors. Most of the useful stuff in Spring is just thin wrappers over other libraries (including the standard library) anyway.
esjeon 4y ago
Spring works really nice when working on monolithic services, but Golang is on the complete opposite side of the spectrum - Go is really good for microservices. Spring is more like traditional application development, where you revisit your code multiple time during its long life cycle. In comparison, Golang is more like spit it out fast and forget. Its syntax is so dumb that you can’t possibly misread the code from any angle, so maintenance is also brain dead simple. In this aspect, using frameworks in Golang simply defeats the point of using the language, because frameworks make codes harder to read. The language is to be used like C, where (almost) everything is manual and explicit.
- nicoburns 4y ago
  > In this aspect, using frameworks in Golang simply defeats the point of using the language, because frameworks make codes harder to read. The language is to be used like C, where (almost) everything is manual and explicit. That's very much a matter of opinion. In my opinion, making every manual and explicit makes it hard to read if you're trying to do anything vaguely high level, because you lose the forest for the trees.
rattlesnakedave 4y ago
> a Java BE Engineer who joined a Go shop I didn't need to read the rest of the comment after this.
- eddsh1994 4y ago
  He could have been working at Netflix, Facebook, or Amazon?
  - rattlesnakedave 4y ago
    Very little to do with the fact that it's a Java developer. More someone identifying as "x language developer working at y language shop." Most of the time, including this one, it shows that they see x language as a part of their identity. Hard to have objective conversations if that is the case.
randomdata 4y ago
> GRPC Assuming this means grpc-go, that's a framework. Perhaps your seemingly negative experience with it actually echoes that the best Go framework is no framework, contrary to your opening position?
62951413 4y ago
I expected to see some juicy golang bashing from someone used to sane error handling, pattern matching, and powerful collections libraries. But complaining about "GRPC and Protobuf are overengineered and underdocumented" just doesn't make sense to me. Those things were basically first implemented in Java. We could argue about subtle differences between Avro and Protobuf but I'm not aware of any credible competitor to gRPC on the JVM in the last 10 years. Thrift and Avro RPC libraries died out years ago, Akka clusters are rather exotic.
epolanski 4y ago
There's no word as meaningless as "enterprise-y". It means literally nothing. A huge company making lots of money has no relation to the quality of its code, processes or tools. That's not only true for non-tech companies, but even the heavily tech ones whose all products are software.
John23832 4y ago
This is an insane take lol. If you don't like GRPC and Proto, use REST. `http.Client{}`, boom make a call. Go is built for microsevices. It probably has the best std library for web services of any language.
za3faran 4y ago
I echo what you're saying. What's ironic is that having worked at an employer that heavily uses golang, they ended up inventing their own dependency injection, app framework, web framework, etc. that are outright terrible, and you end up with the long stack traces that some people like to complain about in Spring or other similar frameworks. So much money was wasted writing and maintaining those frameworks that was so flabbergasting.

by Spiwux 4y ago

zackkitzmiller 4y ago

Then don't use GRPC and Protobufs. I've had exactly the opposite experience building enterprise software with Go.

deleted 4y ago
[deleted]

pleb_nz 4y ago

That is my thoughts as well. It sounds like this would lead to more reinventing the wheel than I'd like to see in a product like a web app/service.

asim 4y ago

This 100%. I think the people largely arguing for no frameworks have no idea what real productivity looks like at large scale engineering orgs. This mostly means you are not handcrafting libraries. There is a dedicated team who manages platform tooling including the frameworks/SDKs you use. Product teams may contribute to that but they will mostly be consumers. I always equate this to car manufacturing. I am not buying a kit car, I am not buying a hobby car, I'm buying a well engineered product from a large scale manufacturer. Frameworks and platforms fall into this category, especially for enterprises. I think it's fine for small teams not to use frameworks, and maybe 200 person engineering orgs are made up of many small teams who just want to agree on a protocol rather than shared framework/platform but once the scale starts to increase you really need to start tightening up and implementing some better standards. People constantly talk about not being Google, well let me tell you the people scale is all the same, the amount of legacy infra is all the same. If you haven't peaked into the depths of the messy multi-decade enterprise you have no clue. Your 4 year old company that you joined 6 months ago is no comparison to something with a legacy of 3 decades with 2k+ engineeers scattered across a disparate org trying to modernise in the cloud or whatever comes next. Full disclosure: I work on https://micro.dev https://micro.dev - a framework for Go

pdpi 4y ago
“Real productivity at large scale engineering orgs” means a bazillion different things, because a big org can afford to have different teams specialise in different things. No-framework Go makes the most sense to me, because a big framework doesn’t make sense for all types of project, and the set of projects where I’d reach for a big framework just doesn’t intersect _at all_ with the set of projects where I’d reach for Go.
- asim 4y ago
  It goes back to, what is a framework and what qualifies as a big framework here. I think classic rails isn't the fit, but something that's an extension of gRPC definitely works. What gets handcrafted is a lot of layers around gRPC or far more stuff around HTTP. When I'm working on personal projects, frameworks don't make sense for me. When I'm trying to engineer something at scale e.g https://m3o.com https://m3o.com then I need that standardisation at the platform layer, the framework layer, the API layer.
  - pdpi 4y ago
    When you're building something "at scale", there'll be business logic API services, cache services, routing/dispatch services, and many other such things. What I'm saying is that I find business logic-centric API services to be a good fit for larger frameworks that take ownership of more of the low level logic, and I don't find Go to be a good fit for those, at all. Inversely, I find Go to be a much better fit for the more "technical" services (provided we're not at the must-squeeze-every-ounce-of-performance C++/Rust level of requirements), but I also don't want a framework getting in the way.
nf17 4y ago
micro.dev is different from an actual go framework go-micro.dev ?? (https://github.com/go-micro/go-micro https://github.com/go-micro/go-micro)
- asim 4y ago

molodec 4y ago

I have to switch between Java Spring boot, Go and Rust. The latter two are framework less and easy to understand just by reading the code. Spring-boot development requires so much googling to figure out why I get UnsatisfiedDependencyException and what each annotation means. Even if I get it to work I still don't understand how it works.

cduzz 4y ago
I'm not sure that's contradicting the parent post. A framework is an added friction to picking up a development environment but potentially a huge asset to velocity once people are up to speed. You haven't gotten properly up to speed in that framework and that site's use of the framework. Perhaps you never spend enough time in that domain to really need to pick it up, in which case you'll always pay the "WTF is this?" tax. But it's equally likely that once a person's up to speed in the framework they're efficiency is greatly enhanced. A programming language isn't just the syntax of the language; there's also knowing the common idioms of the language, understanding the runtime / build environment, knowing when and how to leverage the standard and extended libraries/package ecosystem, etc. Frameworks fall into the "extended package ecosystem" which is vastly different from language to language, and sometimes _within_ a language if the language is sufficiently mature. Some of it is "just math" and some of it is understanding the culture.
- Tainnor 4y ago
  Some of the pains with Spring Boot don't go away even when you understand it better. The fact that the framework relies so heavily on reflection makes debugging a pain, turns what should be compile-time errors into runtime errors (which, among other things, makes updating libraries annoying), and also leads to very slow integration tests. I also haven't yet met a developer who fully understands what @Transactional does, exactly. I agree Spring Boot brings a lot to the table (Spring Security alone, for example), but at the cost of significant downsides. I see the benefit for larger and more diverse teams, but personally I would choose lighter-weight frameworks and libraries, even if at the cost of having to do more plumbing myself.

mad_vill 4y ago

The lack of detailed documentation for grpc is pretty crazy considering how many people seem to be using it. So many hours wasted investigating fringe http2 characteristics causing odd bugs on the platform.

tempest_ 4y ago
It is so bad. Outside of Go (I assume because it seems pretty popular there) the clients for other languages are so hit and miss. I had to pipe a json into the python client to configure a grpc client (which seems bad) and it took me a while to dig up the correct incantation. I like the "contract" that GRPC implies but I am not sure I would choose it again.
- dalyons 4y ago
  Try twirp! Same protos for contracts, but everything is much simpler , saner and slimmer , and just uses standard http. It’s great.

Thaxll 4y ago

You're saying that grpc and protobuf are over engineered but you're happy with Spring? gRPC and protobuf are just transport and serialization, they have nothing to do with business logic, on the other hand Spring is a heavy, bloated framework. Most Java frameworks are complicated backed by layers of abstraction and black magic. btw no framework does not mean you don't use any library, there are some good lib aka micro framework that have everything you need to build modern and decent api servers. https://github.com/go-chi/chi https://github.com/go-chi/chi https://echo.labstack.com/ https://echo.labstack.com/

agotterer 4y ago
Twirp (by TwitchTV) is a good gRPC alternative. It’s significantly lighter and easier to use.
- staunch 4y ago
  Better than an alternative is Connect, which is gRPC but also supports gRPC-Web and the lighter weight Connect protocol (which seems inspired by Twirp) https://buf.build/blog/connect-a-better-grpc https://buf.build/blog/connect-a-better-grpc I like it because it solves most of my complaints about using gRPC from Go without giving up on gRPC.
berkes 4y ago
> btw no framework does not mean you don't use any library I hear that silly argument "no framework === rewrite everything from scratch" far too often. There's a giant difference between libraries and frameworks! It's terminology: it's a framework if you build your app inside it. It's a library if you build it inside your app. The later is fine. The former: I dislike it - even in JavaScript, Ruby, Rust or anything, I wrote a longer post on that[1], which got a lot of discussion on HN. Most of it too in the line of "lol, I use a framework because I don't want to write it all myself", completely missing the crucial first paragraph in which I carefully tried to explain the difference and explain that re-using code != using a framework. [1] https://news.ycombinator.com/item?id=33185010 https://news.ycombinator.com/item?id=33185010

linza 4y ago

You didn't specify what you meant with "more productive", but if it means "being able to produce more code in less amount of time" then i agree that one can be faster with frameworks/Java. If you look at the problem more holistically (say "run a reliable service customers want to use") then that metric is just one of many, and more often than not counterproductive vs some other metrics like maintainability and resilience for instance. IME frameworks reflect that and only let you write code fast, or get the hello-world-demo out fast, but neglect the later stages. I don't know if the conclusion is no framework is better overall, but the frameworks i worked with at least showed mixed results overall.

jrumbut 4y ago
We're not going to settle this today but I think the later stages are where frameworks shine. For instance, when Oauth became popular I was maintaining several apps where the original authors had never dreamed of an alternative login method (email and password had been the norm for longer than any of us had worked as developers). The Rails apps required a few small config changes which I could get from the documentation then HTML for the "Login with Facebook" button. The framework-less apps were disasters. Each had their own way of doing things. Some used libraries that were no longer maintained, others had rolled their own authentication workflow or half copied the code from another project. There is a lot to be said for frameworks when facing an unpredictable future. There is a cost to be paid up front as far as learning the framework but the benefits on the back end are enormous.
- randomdata 4y ago
  > The Rails apps required a few small config changes which I could get from the documentation What Rails configuration would be pertinent to Oauth? Perhaps you mean the application was already using some kind of third-party authentication library (e.g. Devise) that supported Oauth? If that's the case, didn't you just luck out that the developers happened to choose a library that 1. Was still being maintained. 2. Had already added Oauth support? Most of the Rails apps I have encountered in my career (especially those predating Oauth popularity) used hand-rolled authentication, each different to the next, so it seems that you could have just as easily fell into the same trap you saw elsewhere. It is not clear how Rails saved you here.

geodel 4y ago

Well there are all sorts of programming. Writing code from scratch to solve problems, writing glue code to connect various libraries, fill in the gaps in code generated by framework scaffolding, drag-n-drop blocks in diagrams and code is generated in the background and so on. Java/SpringBoot/etc micro services developers have certain way of doing things and they are certainly going to hit lot of problems with Go. Since I have worked in typical Java/J2EE/Microservices project all my career, I think, for most devs coming from larger Java ecosystem, mapping their existing understanding to Go way of doing things is pretty much impossible.

liampulles 4y ago

Different strokes I guess. I've previously worked at big orgs. with Spring, now working with Go microservices and enjoying it by and large. I don't miss the days where I had to deal with random missing or conflicting beans stopping my app from starting. The nice things about a Go app is because the control flow is so exposed, if it compiles you can be pretty sure it is going to run, and if it doesn't compile you can go to the red in your IDE and fix it. Adding an endpoint is a matter of updating our OpenAPI file and doing `make oapi-gen` for the code generator we use. I think this is a similar level of effort to doing the same with a mvn or gradle command. The real difference I notice between Go and Spring microservices though is how much easier it is to dev and debug multiple microservices - it is trivial to compile all of our Go microservices and boot some of them up for debugging without eating all of my laptop's RAM, which is especially relevant if I also want to run them in Kubernetes locally. I will say I do miss some of the niceties of aspect oriented programming with Spring.

cnity 4y ago
By far my least favourite thing about the Java web ecosystem is how weirdly obscured the bootstrapping process for starting processes is. So much of how your application starts is determined by XML files and DI frameworks that I often have no idea (or am sometimes not even exposed to) where the `main` function is.
- jcelerier 4y ago
  Caring about the main function in a framework-ey app generally makes as much sense as caring about the x86 initial boot code when launching mspaint.exe
  - digianarchist 4y ago
    I've seen devs write caches that were shared between customers because they didn't understand the lifecycle of Spring Autowired dependencies. Understanding how the framework wires things together is important.
  - cnity 4y ago

wtetzner 4y ago

When I did Java, I found the Java ecosystem to be very productive because of the libraries available, but Spring was basically useless and was just a way to convert compile-time errors into confusing runtime errors. Most of the useful stuff in Spring is just thin wrappers over other libraries (including the standard library) anyway.

esjeon 4y ago

Spring works really nice when working on monolithic services, but Golang is on the complete opposite side of the spectrum - Go is really good for microservices. Spring is more like traditional application development, where you revisit your code multiple time during its long life cycle. In comparison, Golang is more like spit it out fast and forget. Its syntax is so dumb that you can’t possibly misread the code from any angle, so maintenance is also brain dead simple. In this aspect, using frameworks in Golang simply defeats the point of using the language, because frameworks make codes harder to read. The language is to be used like C, where (almost) everything is manual and explicit.

nicoburns 4y ago
> In this aspect, using frameworks in Golang simply defeats the point of using the language, because frameworks make codes harder to read. The language is to be used like C, where (almost) everything is manual and explicit. That's very much a matter of opinion. In my opinion, making every manual and explicit makes it hard to read if you're trying to do anything vaguely high level, because you lose the forest for the trees.

rattlesnakedave 4y ago

> a Java BE Engineer who joined a Go shop I didn't need to read the rest of the comment after this.

eddsh1994 4y ago
He could have been working at Netflix, Facebook, or Amazon?
- rattlesnakedave 4y ago
  Very little to do with the fact that it's a Java developer. More someone identifying as "x language developer working at y language shop." Most of the time, including this one, it shows that they see x language as a part of their identity. Hard to have objective conversations if that is the case.

randomdata 4y ago

> GRPC Assuming this means grpc-go, that's a framework. Perhaps your seemingly negative experience with it actually echoes that the best Go framework is no framework, contrary to your opening position?

62951413 4y ago

I expected to see some juicy golang bashing from someone used to sane error handling, pattern matching, and powerful collections libraries. But complaining about "GRPC and Protobuf are overengineered and underdocumented" just doesn't make sense to me. Those things were basically first implemented in Java. We could argue about subtle differences between Avro and Protobuf but I'm not aware of any credible competitor to gRPC on the JVM in the last 10 years. Thrift and Avro RPC libraries died out years ago, Akka clusters are rather exotic.

epolanski 4y ago

There's no word as meaningless as "enterprise-y". It means literally nothing. A huge company making lots of money has no relation to the quality of its code, processes or tools. That's not only true for non-tech companies, but even the heavily tech ones whose all products are software.

John23832 4y ago

This is an insane take lol. If you don't like GRPC and Proto, use REST. `http.Client{}`, boom make a call. Go is built for microsevices. It probably has the best std library for web services of any language.

za3faran 4y ago

I echo what you're saying. What's ironic is that having worked at an employer that heavily uses golang, they ended up inventing their own dependency injection, app framework, web framework, etc. that are outright terrible, and you end up with the long stack traces that some people like to complain about in Spring or other similar frameworks. So much money was wasted writing and maintaining those frameworks that was so flabbergasting.