461–470 of 561 posts
Earlier quoted context omitted.
The author is active on HN, he was active on yesterday's thread. Shall we post tomorrow's response as well?
Anyone can post it if they want to. If it gets enough upvotes it will be on the front page for a while, just like this one...
Earlier quoted context omitted.
The author definitely understands that. The point is: when you don't have operator overloading you get stuff like that which does demonstrably confuse many people In languages with operator overloading this just isn't a concern at all because == does the obvious thing
== should do the obvious thing. But with operator overloading, it's not clear that it does , unless you need to read the implementation of == very carefully.
Earlier quoted context omitted.
I'm not really experienced with Boost so I'm having a hard time understanding what that snippet does. Is there any example that is completely self-contained (or at least limited to STL)?
Boost's io_service (since then renamed as io_context) is an implementation of a thread-safe event queue. Threads can put events in the queue (timer events, asynchronous read and write requests for networking, but one can also just push a generic lambda). This example sets up two timers which will regularly push events in the queue, while two threads processes these events. It's from before c++ had lambdas - nowadays…
#include
#include
#include
#include
int main() {
boost::asio::io_context io;
using work_guard_type = boost::asio::executor_work_guard;
work_guard_type work_guard(io.get_executor());
std::vector t;
for(int i = 0; i The 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…
No, the better alternative is thousands of different languages.
HN is just hype-driven as usual and can see only Go and Rust.
Flagging this post strikes me as shameful censorship of an unpopular opinion. 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. Presuming the author is making bad-faith arguments for internet blog points goes against the spirit of HN. I prefer to draw my own conclusions, thank you. I normally expect HN to take the higher ground wit…
I am also surprised that a reasoned discussion like this gets flagged while comments calling it a "shitpost" are not.
Any criticism of sacred icon is taken like an aggression to the reader's sense of self.
Earlier quoted context omitted.
Anyone can post it if they want to. If it gets enough upvotes it will be on the front page for a while, just like this one...
And users are free to flag if they deem the content spammy.
Earlier quoted context omitted.
And users are free to flag if they deem the content spammy.
Yes, exactly, although I personally don't see how a substantive post, responding to a well-discussed issue from the previous day, could possibly qualify as "spam". I guess others agree, since the post did not remain flagged.
The post is not explicitly flagged but nowhere to be seen in HN first pages. Take that as a hint.
I don't know nothin' about Go. But this complaint really surprised me: > Go not letting you do operator overloading, harking back to the Java days where a == b isn't the same as a.equals(b) Does this guy really not understand that in a mutable language, (eq ...) is not the same as (equalp ...) and should never be confused with it? Also: operator overloading is the spawn of Satan.
It's necessary for "powerful" generic programming. In fact, the entire reason user-defined data types can be easily used in C++ libraries like CGAL, Eigen, fmt, Kokkos, ranges-v3, etc, is because of operator overloading.
Earlier quoted context omitted.
Yes, exactly, although I personally don't see how a substantive post, responding to a well-discussed issue from the previous day, could possibly qualify as "spam". I guess others agree, since the post did not remain flagged.
And others are free to disagree with your opinion. I read the content as lacking maturity, emotionally loaded and not the kind of content that fosters productive conversation in HN (as can be evidenced by the caliber of most comments in this thread). The post is not explicitly flagged but nowhere to be seen in HN first pages. Take that as a hint.
It's been almost 24 hours since it was posted, a majority of posts are buried by then. The post seems to have followed a fairly normal lifecycle.
I am not a huge fan of the tone of the OP either, but it does have substantive content and discusses genuine issues (though it probably is not the best way to trigger discussion of those issues), some of which have bitten people at my workplace (dealing with bugs in two different very popular products written in Go, the kind of bugs that are simply not possible in other languages) in just the last week.
It would be interesting to see the response to a less inflammatory article discussing the same issues — I have noticed in general that criticism of Go is often badly received around here regardless of its tone.
Earlier quoted context omitted.
I have barely touched Go, but, from what I've seen, I think I might be able to add a couple more to that: Java is more intimidating to get in to. It starts with "Oh dear, which JDK do I use?", proceeds to, "Oh dear, now I have to pick a build tool and every single one has a near-vertical learning curve by modern standards." Then you're on to, "I want to do X. Why are there 28 competing libraries for X, and why are th…
While I think it is overstated how hard it is to choose a JDK (pretty much just get the first OpenJDK release you see, which is packaged everywhere), I do see the advantage of a default build tool. Though for beginner use cases both maven and gradle is just a copy-pastable few lines and you are ready to .. java (sorry for the joke). I don’t really agree about the 28 competing library thing though. First of all, Java…
It's not hard to choose if you know Java well, but this sort of thing is a huge barrier to entry for someone who is just getting into it, or trying to decide what platform to use.
The community doesn't help here. If you go Googling to try to figure it out, you'll find a mess of conflicting advice being argued with varying levels of passion. By definition, a newcomer doesn't have enough background knowledge to make their own decision, and they aren't necessarily in a position to know whether or not they really need to wade through all that dreck before deciding.
re: frameworks, it's a similar story. Java has a pretty big standard library compared to a lot of smaller programming languages, but it's really not much different here from other platforms that punch in its same weight class, and I believe that includes golang. But the standard library is background noise; if Go's on the table then I've clearly got a job to do, and that job is probably something like writing Web services. And 28 is probably an undercount of the number of Java service and microservice frameworks out there. With a lot of vigorous discussion among proponents of each. It's got to be just stupidly intimidating to face down when you're first getting started. By contrast, I wouldn't be surprised if, by choosing Go, one could have the whole job done in less time than it would take to compile a list of all the information it seems like you have to read before you can even dip a toe into Java.
Disclaimer, I don't think this translates into "Go is good, Java is bad." Personally, I would absolutely pick Java if it were a project I were getting paid to do. For several reasons, but mostly because I already know Java quite well and I know it can get the job done. And I suspect that Java has more general-purpose value than Golang does. But I don't think "Is Java a good platform?" was really the question. It was, "Why might someone choose Go over Java?" and that's a very peculiar question; one that I think you can only answer in an interesting way if you put yourself in the shoes of someone for whom it's a real decision to make - most likely someone who isn't too familiar with either.