5 ms·

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 nothin

by 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
- esparrohack 4y ago
  That’s because your premise is weak. You argue that Django is the wrong choice for lots of projects but the counter factual is that our job is to figure that out. We have to choose the lesser evil. It’s not convincing to just call everyone stupid. Everything is a trade off. You have no idea what those could be in any particular situation so that’s why your whole argument falls apart Then you focus on construction and coding and ignore everything else a framework offers, which has downstream effects on coding and construction. It’s not all about the code. The coding is actually the easy part The only projects ppl pay us is for the ones that are so large and complicated that if you don’t use frameworks, you’re going to either die or go crazy
  - robswc 4y ago
    This reminds me of an debate I was having with another dev who said python was "pointless" and that there was a better, more elegant way to do things. I asked him what is a better way to quickly/easily stand up microservices/apps for clients (90% of my job), if not Django (or Flask/FastAPI, etc). His response was "django is great, but it could have been written better and in another language" ... well, sure, great... but that doesn't solve my problem, lol. We use Django for tons of client projects and rarely ever hit the "limitations" wall. It is mostly CRUD apps, so that helps but I would argue the time saved using frameworks in our shop is much more than the time lost spent on working around limitations. I do think the author has good ideas tho, good principals... but if you know your craft well, you know what will/won't work in a framework and how to solve that.
    - esparrohack 4y ago
      Yeah, it’s a smart guy with a bad idea. Story of all of us in HN! There’s always a better way to do things but we live in a fallen world. Some bullshit will always arise to make your life more complicated. It’s like you said, when you hit whatever limitation, you’ll have to figure out a way around it.
      - robswc 4y ago
ovao 4y ago
I’ll vouch for chi here as well: if I’m building a Go web service and I really need to go one step above http.ServeMux, it’s the only library I consistently reach for.
pkphilip 4y ago
Spring Boot is actually a VERY easy to use framework. So much so that Netflix shifted out of writing their own libraries to using Spring boot. For example, the code below is a complete Spring Boot application with all of the default configuration in place. It will take just a couple of minutes to have this running and it provides quite a lot of features under the hood - which you don't need to worry about. @SpringBootApplication @RestController public class DemoApplication { @GetMapping("/helloworld") public String hello() { return "Hello World!"; } }
- dimitrios1 4y ago
  I write Spring full time these days. You may have Stockholm at this point (like me), but Spring is terrible in two areas: - when things go wrong - onboarding newer / more junior devs For point 1, there are so many layers of abstraction and 20 page stack traces that you could fill an entire log buffer with just one NPE... Kidding aside, I can't tell you how many times I've wrestled with the auto-configure magic. The reality is you'll include so many "starters" in a medium use app, you won't know whose including what. A polluted Spring container is a real problem. That isn't the only problem, but it's one of the more prominent. You may say "well write cleaner code!" and I would reply that Spring is conducive to writing code that doesn't fit well with the framework, and that's mostly because you have to understand 10+ years of architecture decisions when you want to do anything beyond the basics (That's why we mostly don't reach for the "Spring" way to do things anymore, just the simplest way). All that is to say, there is a reason Spring development has been supported by Spring consultants. For point two, It's very easy get started but it's very difficult to mature into a fully productive dev. The things juniors and mids struggle with the most is unpacking autowiring and how to resolve those issues, how to properly handle async behavior (especially with Spring fully embracing WebClient and Reactor now), and database connections. But yeah, outside of all of that, very easy to use, sure.
  - alexjplant 4y ago
    > Kidding aside, I can't tell you how many times I've wrestled with the auto-configure magic. Because everything in Go is explicit you can actually follow a short series of function calls when debugging instead of staring at a 50-function stack trace with a bunch of obscure Aspect4J magic while you feverishly search the Spring JavaDocs for whatever specific error message you're getting. Go is a dumb language and I like it. Everything's obvious and you can't get too cute. Now that there are generics the only thing that I'm really jonesing for is a decent collections framework in the standard library... generic map, filter, fold, etc. on slices would be a real boon to productivity IMHO.
jayd16 4y ago
Spring boot can be about as intrusive as the built in grpc server. This is just an, at best, outdated take.
- EFreethought 4y ago
  On one level, it is not an outdated take. There is a LOT of old Java out there: out of date JDKs, out of date versions of frameworks. There is still a lot of Struts 1.1 out there. I think our industry would look a lot different if more companies were keeping their Java apps up to date.
throwaway894345 4y ago
> You're saying that grpc and protobuf are over engineered but you're happy with Spring? This was my reaction. Every Spring app I've been involved with was a nightmare of gratuitous complexity that was nearly impossible to debug. I'm sure if I were a master of Spring I could figure it out, but that's the nice thing about Go--pretty much any programmer could work out what's happening even if they aren't particularly familiar with Go. You don't have to trace something from XML to Java, and there is basically no magic (maybe the odd bit of Go reflection is the exception to the rule, but it's much less common than in Java/Spring and the "magic" is much less magical).
- mk89 4y ago
  You can use yaml nowadays with Spring. It's not anymore that ugly stuff it used to be 10 years ago where you had to wire everything together bit by bit. I believe one thing that really tells the Java world apart from others is the heavy reliance on DI containers like spring/karaf/osgi etc. Once you understand that, everything is simpler. I would say "believe me" in a face to face conversation, but even then it's proven useless :) Working with Spring for me has become one of those things like when people suggest to "choose a boring technology" to build something. Yes, that's it. In the positive sense, of course. There is literally an easy integration with everything you need, the learning curve is relatively smooth, and yes while it's true there are quite a few annotations you need to get used to, I believe after a few days you finally get used to it, and finally it simplifies a lot your development experience rather than making it worse. For me the only reasons I would pick Go is because of native binaries (smaller footprint, memory, cpu etc), and it's "slim" for simple programs (like Python, but again binaries/native). I also like a lot Go's syntax so that's another pro. Finally they are both very solid languages with strong tooling and wide communities. Ps: the cool "new" guy seems to be Quarkus, though :)
nindalf 4y ago
GP is extrapolating from their experience and assumes that everyone would feel the same way. “I’m less productive in Go compared to Java Spring” => “the whole world is less productive in Go compared to Java Spring”.
fyzix 4y ago
I use chi for one of my projects and though it was fun implementing everything myself. Having a framework would greatly reduce the length of my handler functions and the chance that I mess something up. I had to: manually manage sessions and jwt token Implement message flashing Even reading data from a form was a little too verbose for my liking

by Thaxll 4y ago

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

esparrohack 4y ago
That’s because your premise is weak. You argue that Django is the wrong choice for lots of projects but the counter factual is that our job is to figure that out. We have to choose the lesser evil. It’s not convincing to just call everyone stupid. Everything is a trade off. You have no idea what those could be in any particular situation so that’s why your whole argument falls apart Then you focus on construction and coding and ignore everything else a framework offers, which has downstream effects on coding and construction. It’s not all about the code. The coding is actually the easy part The only projects ppl pay us is for the ones that are so large and complicated that if you don’t use frameworks, you’re going to either die or go crazy
- robswc 4y ago
  This reminds me of an debate I was having with another dev who said python was "pointless" and that there was a better, more elegant way to do things. I asked him what is a better way to quickly/easily stand up microservices/apps for clients (90% of my job), if not Django (or Flask/FastAPI, etc). His response was "django is great, but it could have been written better and in another language" ... well, sure, great... but that doesn't solve my problem, lol. We use Django for tons of client projects and rarely ever hit the "limitations" wall. It is mostly CRUD apps, so that helps but I would argue the time saved using frameworks in our shop is much more than the time lost spent on working around limitations. I do think the author has good ideas tho, good principals... but if you know your craft well, you know what will/won't work in a framework and how to solve that.
  - esparrohack 4y ago
    Yeah, it’s a smart guy with a bad idea. Story of all of us in HN! There’s always a better way to do things but we live in a fallen world. Some bullshit will always arise to make your life more complicated. It’s like you said, when you hit whatever limitation, you’ll have to figure out a way around it.
    - robswc 4y ago

ovao 4y ago

I’ll vouch for chi here as well: if I’m building a Go web service and I really need to go one step above http.ServeMux, it’s the only library I consistently reach for.

pkphilip 4y ago

Spring Boot is actually a VERY easy to use framework. So much so that Netflix shifted out of writing their own libraries to using Spring boot. For example, the code below is a complete Spring Boot application with all of the default configuration in place. It will take just a couple of minutes to have this running and it provides quite a lot of features under the hood - which you don't need to worry about. @SpringBootApplication @RestController public class DemoApplication { @GetMapping("/helloworld") public String hello() { return "Hello World!"; } }

dimitrios1 4y ago
I write Spring full time these days. You may have Stockholm at this point (like me), but Spring is terrible in two areas: - when things go wrong - onboarding newer / more junior devs For point 1, there are so many layers of abstraction and 20 page stack traces that you could fill an entire log buffer with just one NPE... Kidding aside, I can't tell you how many times I've wrestled with the auto-configure magic. The reality is you'll include so many "starters" in a medium use app, you won't know whose including what. A polluted Spring container is a real problem. That isn't the only problem, but it's one of the more prominent. You may say "well write cleaner code!" and I would reply that Spring is conducive to writing code that doesn't fit well with the framework, and that's mostly because you have to understand 10+ years of architecture decisions when you want to do anything beyond the basics (That's why we mostly don't reach for the "Spring" way to do things anymore, just the simplest way). All that is to say, there is a reason Spring development has been supported by Spring consultants. For point two, It's very easy get started but it's very difficult to mature into a fully productive dev. The things juniors and mids struggle with the most is unpacking autowiring and how to resolve those issues, how to properly handle async behavior (especially with Spring fully embracing WebClient and Reactor now), and database connections. But yeah, outside of all of that, very easy to use, sure.
- alexjplant 4y ago
  > Kidding aside, I can't tell you how many times I've wrestled with the auto-configure magic. Because everything in Go is explicit you can actually follow a short series of function calls when debugging instead of staring at a 50-function stack trace with a bunch of obscure Aspect4J magic while you feverishly search the Spring JavaDocs for whatever specific error message you're getting. Go is a dumb language and I like it. Everything's obvious and you can't get too cute. Now that there are generics the only thing that I'm really jonesing for is a decent collections framework in the standard library... generic map, filter, fold, etc. on slices would be a real boon to productivity IMHO.

jayd16 4y ago

Spring boot can be about as intrusive as the built in grpc server. This is just an, at best, outdated take.

EFreethought 4y ago
On one level, it is not an outdated take. There is a LOT of old Java out there: out of date JDKs, out of date versions of frameworks. There is still a lot of Struts 1.1 out there. I think our industry would look a lot different if more companies were keeping their Java apps up to date.

throwaway894345 4y ago

> You're saying that grpc and protobuf are over engineered but you're happy with Spring? This was my reaction. Every Spring app I've been involved with was a nightmare of gratuitous complexity that was nearly impossible to debug. I'm sure if I were a master of Spring I could figure it out, but that's the nice thing about Go--pretty much any programmer could work out what's happening even if they aren't particularly familiar with Go. You don't have to trace something from XML to Java, and there is basically no magic (maybe the odd bit of Go reflection is the exception to the rule, but it's much less common than in Java/Spring and the "magic" is much less magical).

mk89 4y ago
You can use yaml nowadays with Spring. It's not anymore that ugly stuff it used to be 10 years ago where you had to wire everything together bit by bit. I believe one thing that really tells the Java world apart from others is the heavy reliance on DI containers like spring/karaf/osgi etc. Once you understand that, everything is simpler. I would say "believe me" in a face to face conversation, but even then it's proven useless :) Working with Spring for me has become one of those things like when people suggest to "choose a boring technology" to build something. Yes, that's it. In the positive sense, of course. There is literally an easy integration with everything you need, the learning curve is relatively smooth, and yes while it's true there are quite a few annotations you need to get used to, I believe after a few days you finally get used to it, and finally it simplifies a lot your development experience rather than making it worse. For me the only reasons I would pick Go is because of native binaries (smaller footprint, memory, cpu etc), and it's "slim" for simple programs (like Python, but again binaries/native). I also like a lot Go's syntax so that's another pro. Finally they are both very solid languages with strong tooling and wide communities. Ps: the cool "new" guy seems to be Quarkus, though :)

nindalf 4y ago

GP is extrapolating from their experience and assumes that everyone would feel the same way. “I’m less productive in Go compared to Java Spring” => “the whole world is less productive in Go compared to Java Spring”.

fyzix 4y ago

I use chi for one of my projects and though it was fun implementing everything myself. Having a framework would greatly reduce the length of my handler functions and the chance that I mess something up. I had to: manually manage sessions and jwt token Implement message flashing Even reading data from a form was a little too verbose for my liking