Earlier quoted context omitted.
How is Spring Boot not Java? Spring Boot is a simple Java library.
Spring boot is not, in any way shape or form, a "simple" java "library". Not only is it a complex framework , it also uses features very few java programmers are exposed to, such as runtime code generation.
Lies we tell ourselves to keep using Golang
371–380 of 561 posts
Re: Lies we tell ourselves to keep using Golang
#372Earlier quoted context omitted.
> You may say it's the snark/anger/frustration that got flagged, but I suspect it would not have been flagged if the topic were different. HN has had plenty of threads about Go over the years. What's different here is that there was just a big Go flamewar yesterday ( https://news.ycombinator.com/item?id=31191700 ), from the same site. Having another big Go flamewar the next day is a really bad idea, because then on t…
This strikes me as very odd. The post yesterday is about a 2-year-old article. This post is about a brand new article, from the same author, written more or less as a response to all of the responses to the original article over the past 2 years. If a flamewar is a problem, then that's what moderation is for, including potentially locking. I know you've posted comments on divisive articles before cautioning everyone…
Re: Lies we tell ourselves to keep using Golang
#373The author writes well and makes compelling points. His "I want to get off Mr Golang's Wild Ride" post is good too. But I don't find myself agreeing with his position, which is "you shouldn't use Go for production services" (he explicitly says this in one of his Go posts, I forget which one and don't have time to look right now). The better alternative to Go is Rust. Okay, sure, I'm willing to admit that in the examp…
It seems that C is a language/compiler/toolchain combo that lets you shoot yourself in the foot, but gives you enough access to stuff to be maximially performant in a random (i.e. not specialized) use case. (C++ is in this camp too).
Rust is a language/compiler/toolchain combo that tries its best to not let you shoot yourself in the foot by presenting those footguns for you to fix up front, without giving up much of the access to stuff (C++ tried some things in this camp like destructors and smart pointers. GC is also something that's in this camp)
Golang is a language/compiler/toolchain combo that lets you shoot yourself in the foot in some circumstances, and does not give you enough access to be maximally performant in every random case, but rather it seems to posit to give you opinions that will get you really, good performance in most random cases (if you need to tune the GC, for instance, you're probably worse off, like here: https://blog.twitch.tv/en/2019/04/10/go-memory-ballast-how-i...). Meaning it's making the tradeoffs of upfront complexity vs runtime issues, and Tim Toady vs The One True Way for you, because in the general case those are the most optimized tradeoffs. I don't disagree, especially when the closed-world ecosystem is good enough to not need to reach out to external tools whether those are via cgo or in the build toolchain.
In general, I think that if you reach the point where Golangs admittedly major warts are hindering your progress you're doing better than most companies, so its succeeded in not getting in the way of progress at least until that point.
In particular since the article keeps comparing Golang to Rust, for personal projects I do like the correctness of Rust, but some things are frustrating, like async being basically unusable without Async Drop, an uncertain future for completion apis, and apis that really want HKT but can't use them (yet?). I having to make up a lot of opinions that Go makes for you adds risk and uncertainty to a project where the most likely failure modes are not, in fact, those opinions.
I'm excited for the future of Java, with Loom and Valhalla coming to address as what I see as two core problems of Java in particular and other languages in general. I'm also excited for the present of js/node.js/maybe Deno. typescript has become good enough that I also think it's a really good competitor to Golang in the "just write code" arena, especially since there's significant synergy between the front end and the back end to help with build tooling, validation logic, and programmer expertise.
Re: Lies we tell ourselves to keep using Golang
#374Earlier quoted context omitted.
It matters a lot IMO. Most systems programming languages can implement whatever concurrency primitives you care to use, but most people default to whatever is provided by the OS/language because concurrency is hard. Having first-class syntactic sugar over a concurrent runtime bakes in a certain programming style in the language, which strongly determines how the language is used and the programming style. Go comes ou…
I think there's a difference between 'in the standard library' and 'in the language ', though. They seem to be praising Go for doing the latter. And the technical language in which it was expressed gave me to think there was some technical motivation for that, as opposed to sociological - but if what they meant is what you said, then I certainly wouldn't disagree with that.
Re: Lies we tell ourselves to keep using Golang
#375I generally like go and also see its problems as the author does. However, with respect to the points about Go as a prototyping/starter language, there is not better language to start writing a project with in my opinion. Lots of languages have big communities of packages of various levels of maintenance but almost no other language has a standard library that is as usable as Go with the same guarantees between versi…
If you want a big standard library why not use something like Java or C#? I mean, you even have UI toolkits available from the get go
With Java and C# there's a lot of other fuss involved with figuring out deployment. The code, build, test cycle is also much slower in C#/.NET ime. That's starting to improve a bit with the newer dotnet, but still feels behind other everything but the kitchen sink frameworks like Rails, which I would more compare C# to since C# without .NET/dotnet is uncommon.
Re: Lies we tell ourselves to keep using Golang
#376The author writes well and makes compelling points. His "I want to get off Mr Golang's Wild Ride" post is good too. But I don't find myself agreeing with his position, which is "you shouldn't use Go for production services" (he explicitly says this in one of his Go posts, I forget which one and don't have time to look right now). The better alternative to Go is Rust. Okay, sure, I'm willing to admit that in the examp…
* First you construct a request, and check the error on that
* Then you "Do" the request and check the error on that
* Then you check the status code (you did check it, right?)
* Then you deserialize the response and check the error on that
* Then you close the response body (you did remember to close it, right?) and check the error on that
Actually making an HTTP request with Go stdlib is a many-stage process and it is very easy to screw up or forget one of the steps. I see it all the time. Actually I have seen outages related to people being too zealous and reporting errors related to closing the response body on otherwise successful requests.
Re: Lies we tell ourselves to keep using Golang
#377Earlier quoted context omitted.
This strikes me as very odd. The post yesterday is about a 2-year-old article. This post is about a brand new article, from the same author, written more or less as a response to all of the responses to the original article over the past 2 years. If a flamewar is a problem, then that's what moderation is for, including potentially locking. I know you've posted comments on divisive articles before cautioning everyone…
The guiding logic here is 'it would be boring to have a discussion of X on the front page every day'. For many X, there's infinitely many things to say but the front page is finite and has a goal of not being boring. HN's been moderated like that for ages and it seems to work reasonably well.
The sheer number of upvotes on this article, despite the attempt at suppressing it, is a clear indication that, regarldess of what dang thinks, a lot of people in the HN community think that something that is most definitely not boring and worth reading has been said.
I'm inclined to agree? I personally do tend to agree that golang in and of itself is kind of a boring horse that's been beaten to death at this point. But this article was interesting, anyway, because it had an interesting and thoughtful perspective on what kinds of things matter when choosing a language ecosystem more generally. One that I, as a hobby language designer, was glad I read. Even the bits I don't think I agree with. Even some of the bits that seemed unnecessarily invective.
Re: Lies we tell ourselves to keep using Golang
#378Earlier quoted context omitted.
> You may say it's the snark/anger/frustration that got flagged, but I suspect it would not have been flagged if the topic were different. HN has had plenty of threads about Go over the years. What's different here is that there was just a big Go flamewar yesterday ( https://news.ycombinator.com/item?id=31191700 ), from the same site. Having another big Go flamewar the next day is a really bad idea, because then on t…
This strikes me as very odd. The post yesterday is about a 2-year-old article. This post is about a brand new article, from the same author, written more or less as a response to all of the responses to the original article over the past 2 years. If a flamewar is a problem, then that's what moderation is for, including potentially locking. I know you've posted comments on divisive articles before cautioning everyone…
Re: Lies we tell ourselves to keep using Golang
#379Earlier quoted context omitted.
I haven't used Go or Rust seriously, but have written some Go toy code. This part of your post struck a nerve with me. I modified it slightly, to relate to Go's error handling, for me at least: > often it's not worth taking on that burden just to theoretically handle cases that rarely occur and even more rarely cause any problem. Programming is a means to an end, and the cost of [Edit] adding if err != nil to every l…
> If something blows up in production in an unexpected way, sometimes that's okay. You log the problem, fix it, and it's fine. as the person on call for such events, it's really not fine. would you rather handle these errors upfront during development time or unexpectedly and uncontrollably, during runtime? having been on-call in one way or another for ~10 years, i know which i'd prefer. after having used golang in p…
Exceptions are in my honest opinion better on every single front. Checked exceptions would be the panacea but Java’s version is not the best due to subclassing. But overall bubbling up exceptions is the correct thing to do — in most cases a problem can’t be meaningfully handled at the call site. Let’s say you want to read from a file during a HTTP request but the read fails n methods deep. There can be any number of other error occurrences and the only sane choice here would be to return some error code to the web client requesting the site. Why do you want to handle it n times instead of only at the goal?
Re: Lies we tell ourselves to keep using Golang
#380Earlier quoted context omitted.
The guiding logic here is 'it would be boring to have a discussion of X on the front page every day'. For many X, there's infinitely many things to say but the front page is finite and has a goal of not being boring. HN's been moderated like that for ages and it seems to work reasonably well.
I don't think it's necessarily the HN moderation team's job to tell us what we should and should not find interesting. It's a crowdsourced news aggregation site and discussion forum, not a magazine with an editorial board. The sheer number of upvotes on this article, despite the attempt at suppressing it, is a clear indication that, regarldess of what dang thinks, a lot of people in the HN community think that someth…