Earlier quoted context omitted.
It starts about 2/3 of the way through the table of contents.
A link is fine.
Lies we tell ourselves to keep using Golang
541–550 of 561 posts
Re: Lies we tell ourselves to keep using Golang
#542Re: Lies we tell ourselves to keep using Golang
#543I 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
I dont know them as well as I do Go but the libraries (java especially) don't feel as coherent as the go libraries do, though that may be subjective and to do with my lack of experience with them. In addition both of these languages are large enough and have projects structured in such a way as to make it difficult to just use a text editor, which i consider a barrier to me just 'cracking out' a project.
C# also had pretty middling linux support the last time i worked with dotnet. and java tooling is not as out of the box as go is where I have to know is gradle good or still used or should i just use maven. Its all part of me not wanting to have to choose the best dependencies for my project and being handed for the most part good enough dependencies by the language standard library.
Another thing to appreciate in go is it produces good enough binaries and produces them very very quickly -- i've worked on several massive go projects and the build/test turnaround time is quite good.
Re: Lies we tell ourselves to keep using Golang
#544Re: Lies we tell ourselves to keep using Golang
#545Earlier quoted context omitted.
That points to the same page.
It's now become abundantly clear to everyone that you're using a different definition of "page" than everyone else in this conversation.
The only other person in this conversation is you, so not exactly the most representative of samples, but it is an interesting perspective. I've not heard anyone else consider the same HTML resource to be more than one page before. In fact, the term "single page application" hinges on a single HTML resource in the same way. The application may have more than one screen of content, but it is still considered one page.
Re: Lies we tell ourselves to keep using Golang
#546Earlier quoted context omitted.
It's now become abundantly clear to everyone that you're using a different definition of "page" than everyone else in this conversation.
The only other person in this conversation is you, so not exactly the most representative of samples, but it is an interesting perspective. I've not heard anyone else consider the same HTML resource to be more than one page before. In fact, the term "single page application" hinges on a single HTML resource in the same way. The application may have more than one screen of content, but it is still considered one page.
oxnrtr is in this conversation too. And when describing the length of a document, "pages" universally means the number of printed pages it would occupy, not the number of computer files it's stored in.
Re: Lies we tell ourselves to keep using Golang
#547Earlier quoted context omitted.
The only other person in this conversation is you, so not exactly the most representative of samples, but it is an interesting perspective. I've not heard anyone else consider the same HTML resource to be more than one page before. In fact, the term "single page application" hinges on a single HTML resource in the same way. The application may have more than one screen of content, but it is still considered one page.
oxnrtr is in this conversation too. And when describing the length of a document, "pages" universally means the number of printed pages it would occupy, not the number of computer files it's stored in.
There is no sign of anyone else participating in this conversation. Else we'd have heard their input by now. A page referring to a single HTML resource is standard nomenclature. Paper is antiquated technology, not how the Go specification is distributed, and carries no relevance to this discussion.
Re: Lies we tell ourselves to keep using Golang
#548We have tens of microservices written in Go. Go is good for onboarding new devs because it's simple. Our existing PHP devs were taught Go and it was painless. Jumping from PHP straight into Rust would be pretty painful, I think. Finding Rust devs isn't easy in our town. But I agree with most of the points. You got to be very careful when writing in Go, because there are many gotchas. So many gotchas that I had to wri…
That means Go was easy for those devs to pick up, not that Go is simple . Rich Hickey gave an all time classic presentation about this seemingly nitpicky but important distinction https://www.youtube.com/watch?v=SxdOUGdseq4
Interestingly, I have always heard Go is simple, but not easy.
Re: Lies we tell ourselves to keep using Golang
#549Earlier quoted context omitted.
> the Rust jihad As a Rust jihadist myself ... yeah I can't disagree with this description. Even I get sick of all the Rust chatter/evangelism on HN sometimes. I love it and it's my preferred tool, but I wouldn't mind hearing about some alternative topics at least some of the time. (As for the article: I wrote Go for several years professionally, and what he says, well - rem acu tetigit . I know a lot of people on th…
wtf is rem acu tetigit
Sorry - 'hit the nail on the head'. Literally: (you touched == tetigit (tangere)) ([the] point == rem (res)) (with [a] needle == acu (acus))'.[0] 'Point' (res) is already abstract - 'matter', 'thing' - not being used figuratively like the rest of the phrase.
It's one of those phrasoids which is permanently stuck in my head from Latin classes when I was a teenager, but I might've been wrong in thinking it was one of the more widely-recognised ones.
[0] 'You' is implied by the second-person verb ending on 'tetigit', 'with' is implied by the ablative case ending on 'acu' (the 'ablative of means'), while 'the' and 'a' are filled in altogether since Latin has no concept of definite/indefinite articles.
Re: Lies we tell ourselves to keep using Golang
#550Earlier quoted context omitted.
That's not the only/main reason to want a newtype though - it's also about restricting what the value can be, see something like NonZeroU64: https://doc.rust-lang.org/stable/std/num/struct.NonZeroU64.h... numeric literals (mentioned by paskozdilar in a parent comment) being untyped is another footgun I hadn't even thought of including - it makes it impossible to achieve in TypeScript/Java-level enums.
You can define NonZeroU64 in Go exactly the same way it's defined in Rust – as a struct with a private field. No interfaces required. But I was wondering why you would want an opaque type internally to a package . Presumably not to ensure that the value has passed some validation, since in that case you would want to encapsulate that validation logic in its own package. It's not like Go imposes a tax on packages. Pac…
> But I was wondering why you would want an opaque type internally to a package.
You can have a public function (a constructor) returning an instance of a private type. This way you ensure it's not zero-initialised by default (you can't do "var f privateType", you need to call the constructor).
But it's annoying to do. For every type you'd ever want to protect against zero-initialisation, you'd need to declare it private in some other package, and create a constructor. Therefore, most people just don't bother and prefer to live with the increased risk of bugs.