Earlier quoted context omitted.
Could you link? I must have missed it.
https://news.ycombinator.com/item?id=31191700
Ah OK just the author's 2020 post. Thanks!
Lies we tell ourselves to keep using Golang
181–190 of 561 posts
Re: Lies we tell ourselves to keep using Golang
#182Flagging 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…
Quoted post unavailable.
What's "inappropriate" about the post? I for one wish that we had more posts like these instead of typical stuff that has been getting to the front page lately.
Re: Lies we tell ourselves to keep using Golang
#183Earlier quoted context omitted.
> Operator overloading allows for things like complex numbers, arbitrary precision numeric types, etc., to be done with a library module. Why is this desirable vs. implementing those types in the language itself? I think we've gone down a weird path where implementing things "in userspace" is seen as an inherent good -- why?
> Why is this desirable vs. implementing those types in the language itself? That's a very good question. 1. It's simpler. In D, we transitioned from a builtin complex type to a library type. It was a happy experience. The simpler the compiler, the easier it is to deal with. 2. Most any programmer can create a library type. Relatively few can modify a compiler to add a new type. 3. It takes the pressure off the compi…
Elaborating on 3/4: the domain experts don't need to be compiler experts too.
There are always going to be more numeric-like types (int, float, complex, bigint, rational, symbolic-comp types etc.). Numeric vectors that act like numbers are useful (see: numpy), and trying to stick those all into the language is far harder than allowing extensibility.
Re: Lies we tell ourselves to keep using Golang
#184You guys flagged this? That is not the move of a vibrant, growing, confident community. I’m no fan of the Rust jihad myself, but this isn’t spam or hate speech or whatever. That is a super weak move.
I guess it's because it's not anything that hasn't been said before. Go is easy to start with and gets harder as you debug deep problems. Rust is very hard to start, then it gets easier over time. This has been said in many other threads, and we all know it's true.
So the reason for the censorship is they read the entire article and saw nothing "new" about something you "all know is true"? That's indeed a "new" way to discourage reasoned discussions.
Re: Lies we tell ourselves to keep using Golang
#185You guys flagged this? That is not the move of a vibrant, growing, confident community. I’m no fan of the Rust jihad myself, but this isn’t spam or hate speech or whatever. That is a super weak move.
Discussion from yesterday on the same topic from the same author: https://news.ycombinator.com/item?id=31191700
This is in response to that post from yesterday. It's worth flagging this one, or else it's going to be an infinite loop of knee jerk reactions. We can do without these.
Re: Lies we tell ourselves to keep using Golang
#186Re: Lies we tell ourselves to keep using Golang
#187Earlier quoted context omitted.
This is the second day in a row where a post about Go in a negative light was flagged. The first one was an extremely detailed criticism, maintained the front page, and was flagged like crazy. What gives?
This is the second day in a row where a post about Go _from the same blog_ has been posted. I think that's enough, especially since it's mostly a knee jerk reaction from that very HN post from yesterday. https://news.ycombinator.com/item?id=31191700
Who cares if it is a legitimate criticism and makes unique points in both cases (also, they were both written two years apart!)? Some call it "inflammatory" but it has scientific and critical value nonetheless.
Re: Lies we tell ourselves to keep using Golang
#188You guys flagged this? That is not the move of a vibrant, growing, confident community. I’m no fan of the Rust jihad myself, but this isn’t spam or hate speech or whatever. That is a super weak move.
Flagging articles that criticize popular tools seems to be common. Particularly so with Go specifically.
Go and Rust seem to have some of the most rabid fan bases of all programming languages and this article mentions both. A perfect HN storm.
I think all the arguments against Go in this article are fair and I think you can write articles just as long about any programming language of your choosing. It's very strange to see the level professional programmers will stoop to if their favourite tool gets criticised.
The fanboys of programming languages are the worst part of a language community. The "why not rewrite it in Rust" and the "you're golanging it wrong" crowds only drive people away from their respective languages.
Re: Lies we tell ourselves to keep using Golang
#189Earlier quoted context omitted.
> As far as I know, no other popular language allows you to read from multiple queues at the same time Off the top of my head, that's certainly possible in Rust, C++ and Java - probably many others I just don't know about. That particular bit of concurrency goodness comes from the 70s, so you can be sure other languages picked it up.
Ada too, I think.
Ada has had this built-in for decades, and even allows selecting from one of multiple waiting queues (entries) using a `select` keyword.
Re: Lies we tell ourselves to keep using Golang
#190Earlier quoted context omitted.
As I understand it, he's talking about select/alt (i.e. guarded commands from CSP) being a native feature of the language rather than callback-based approaches. It's possible to implement CSP channels in most languages, but they're not first-class like go.
> It's possible to implement CSP channels in most languages, but they're not first-class like go. But does that matter ? In all my experience, I can't think of any instances where that wouldn't be a distinction without a difference. (Perhaps I'm missing something, though.)
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 out of the Newsqueak/Aleph/Limbo family which has a very different style of programming compared to a lot of other languages.