Quoted post unavailable.
No post body was provided.
Lies we tell ourselves to keep using Golang
41–50 of 561 posts
Re: Lies we tell ourselves to keep using Golang
#42The author obviously doesn't like Go. Ok, he can have his own opinions. I've been coding professionally since 1987, using everything from mainframe assembler, Fortran, C, VB, Java, C++, to most recently Go. IMHO, the language itself plays a smaller role in its usefulness than most think. As important is the tooling, stdlib, ecosystem, community and "StackOverflow"-ability. Go has a few warts, like every language, but…
A couple of things to add to this: the language spec is like a page long and very readable. Also the entire compiler toolchain and everything is written in Go and doesn’t depend llvm etc. This doesn’t help the developer but is a pretty unique aspect of Go.
Re: Lies we tell ourselves to keep using Golang
#43Unrelated (though a fun read) to the content: Thank you for making your blog readable. The typography choices are exemplary.
Re: Lies we tell ourselves to keep using Golang
#44I 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.
> operator overloading is the spawn of Satan
I used to agree with you, because of the abuse of operator overloading like iostreams and making DSLs with it. D does support it, but in a way that discourages non-arithmetic uses (such as it won't allow = > to be overloaded separately).
Operator overloading allows for things like complex numbers, arbitrary precision numeric types, etc., to be done with a library module.
Re: Lies we tell ourselves to keep using Golang
#45Quoted post unavailable.
No post body was provided.
Re: Lies we tell ourselves to keep using Golang
#46how boring? Don't wanna use Go? Use something else. What's the point? Invest your time on questioning your knowledge and improving it instead of this.
The point of these articles and other opinion-making (such as right here on HN) is that we don’t choose tools. We are given the popular tools. They are popular because other developers chose them at the companies were we work. And they chose them because they thought they would be suitable for the purpose. So if you want to do everything in your power to prevent a tool you think is terrible from being more popular -…
Why should I care if Go/Rust/anything else becomes popular? I don't expect that if I don't "fight" against a language I'll be forced to use it in 2 years: there will be space for different techs, tools and so on.
I can agree with you if we talk about "tools" that attacks our privacy, our rights and our freedom: spend you time convincing people to abandon facebook or something similar and you'll do something good.
But in this case, it doesn't change much, imho.
Re: Lies we tell ourselves to keep using Golang
#47Meh, this blog post is a rather subjective rant. I can offer the opposite opinion, although I'm not sure that's helpful. The more I use Go, the more I like it. I'm very productive with it, similar to -- though not quite on a par yet -- the productivity I had when I was programming in REALBasic. Most of the benefits of Go result from the tooling and the availability of 3rd party, open source libraries with permissive licenses that are "good enough" for my purposes. I could probably also use Python instead and benefit from even more 3rd party support, but there would also be downsides to it. I appreciate Go's compact executables and easy deployment.
Quite honestly, in what concerns choices of languages, my experience is that it's not so much the language per se that counts, but rather the tooling, developer community, and the availability of 3rd-party libraries.
Re: Lies we tell ourselves to keep using Golang
#48The author obviously doesn't like Go. Ok, he can have his own opinions. I've been coding professionally since 1987, using everything from mainframe assembler, Fortran, C, VB, Java, C++, to most recently Go. IMHO, the language itself plays a smaller role in its usefulness than most think. As important is the tooling, stdlib, ecosystem, community and "StackOverflow"-ability. Go has a few warts, like every language, but…
This has perhaps been my biggest pain-point with Golang..
Woe unto those who do not follow the idiosyncrasies of how golang handles versioning, package management, tooling etc.
if this is really your most important part of a language I would whole-heartedly recommend looking at rust which has been a breathe of fresh air in terms of package management and tooling.
Re: Lies we tell ourselves to keep using Golang
#49The author obviously doesn't like Go. Ok, he can have his own opinions. I've been coding professionally since 1987, using everything from mainframe assembler, Fortran, C, VB, Java, C++, to most recently Go. IMHO, the language itself plays a smaller role in its usefulness than most think. As important is the tooling, stdlib, ecosystem, community and "StackOverflow"-ability. Go has a few warts, like every language, but…
Yeah, it's pretty obvious to me the author doesn't like Go and some of the arguments raised really aren't concerns in (my very limited part of) the real world.
I've written a fair amount of Go and I am not bothered at all by the general ergonomics of the language. Some of the issues the author points out (like accidentally copying structs with embedded synchronization primitives) are caught by linters which you should be using regardless of what language you are coding in.
Edit: I dabble with Rust from time to time as well.
Re: Lies we tell ourselves to keep using Golang
#50> Go's confusion between "type aliases" and "newtypes". The only way to make a newtype in go is to make a separate package with an opaque type and use interfaces for indirection, which is costly and awkward. It's very unclear what this is supposed to mean. 'type Foo int' in Go creates a new 'Foo' type that can't be used as an int without casting (a̶l̶t̶h̶o̶u̶g̶h̶ ̶y̶o̶u̶ ̶c̶a̶n̶ ̶a̶s̶s̶i̶g̶n̶ ̶a̶n̶ ̶i̶n̶t̶ ̶t̶o̶ ̶i̶t…
I moved some words around to make the nit less confused - thanks for the feedback!