Live data from Hacker News

Re: Moving from PHP to Go and Back Again

blog.breakthru.solutions

251–260 of 281 posts

Re: Re: Moving from PHP to Go and Back Again

#251
post #246

Earlier quoted context omitted.

In that case it sounds like you have a bone to pick with Rob Pike over Go. I suppose you can find him on Twitter if you want to settle your feud. I'd suggest to not bother when I have him on tape contradicting you. I did read Joe's blog, years ago. Your takeaway there also leaves you with a bone to pick with Microsoft, if it's just politics then you should be able to find someone in management at Microsoft to set str…

It doesn't matter what Rob Pike says regarding Go and systems programming, because Google, the company that employs him, has decided Go makes sense to write system components of Fucshia in Go. That is a fact, easily validated in Fuchsia's repository. According to you, Rob Pike should call management and let them know it is not a good idea to use Go for writing Fuchsia's TCP/IP stack. You only read Joe's blog years ag…

A TCP/IP stack isn't a stringent litmus test for a systems PL. So you can loosen your own standard for what comprises a systems PL, but Go fails more rigorous standards. Everytime. Even Rob Pike says you're wrong and he's certainly a sympathetic character towards Go.

All of this was hashed out years ago upon Go's release, and the Go team took down the "systems language" moniker. That was the end of it. Google knows it's not going to fulfill stringent litmus tests for a systems-language. We'll review the subject again if the folks at Google are brazen enough to ever add it back to the website.

Now Rob doesn't have to call management and let them know it's not for systems programming, Rob & Google already know it's not. He said so himself. You're the only one in the dark on that front at this point.

Re: Re: Moving from PHP to Go and Back Again

#252

Earlier quoted context omitted.

Hmm. I don't trust any external CDN, to be honest. No matter which one you choose, you lock yourself dead into the vendor - should it decide to kick you off for whatever reason you're toast, but especially I'm afraid of doing a tiny mistake in AWS leading to accidental disclosure of private data. Such "hacks" have hit too many too big firms for me. Out of interest, what issues have you had with NFS mounts? I run a fl…

Eventually, NFS ends up freaking out and consumes all I/O on the client machine until it is rebooted. I suspect that this occurs when the underlying network is saturated, but don't have evidence of such. CentOS 6/7, NFS v3/v4, tuned every setting I could think of, and spent dozens of hours Googling and reading. It may be worth mentioning that we had decent throughput with NFS. Roughly 10 writes per second (from 100kb…

Whoa. I have never hit this one, to be honest, in years. Maybe it was something CentOS specific, I have everything I have control of at either Debian or Ubuntu... but I will keep this in mind in case I ever do hit this error.

Might have been worth a try to get a RHEL support contract, but if you're a one-man show and happy with CDN, then that's the better solution for you definitely ;)

Re: Re: Moving from PHP to Go and Back Again

#253
post #228
post #185

Earlier quoted context omitted.

>C was also king of the zero cost abstractions. C++ has static dispatch classes, templates, constexpr, and macros. C just has macros. Any other abstraction costs machine code. C++ also offers a lot of low cost abstraction like RAII-style scoping. >C sure is not afraid to be complicated. Not sure in what sense you're talking. C is not complicated. It's low level. It's exposing complications in the underlying model of…

Good points about C. Thanks. > Go differs most in it's [...] built-in concurrency. That was what I was driving at, as well as Go not being fit for writing a kernel in. Sorry being so inarticulate.

Yeah, that is actually a pretty good point to be honest. Go is not ideal for low-level components such as that. I suppose the analogy of Go and Rust being successors to C and C++ is reasonably flawed, from that perspective.

On the other hand, I'm glad things are turning out the way they are. Rust and Go are both filling niches that C and C++ didn't, in ways that they couldn't have. I look forward to Rust-based OS kernels, for sure. It seems like with time, we can build very resilient foundations with Rust that wouldn't have been possible before.

Re: Re: Moving from PHP to Go and Back Again

#254
post #246

Earlier quoted context omitted.

It doesn't matter what Rob Pike says regarding Go and systems programming, because Google, the company that employs him, has decided Go makes sense to write system components of Fucshia in Go. That is a fact, easily validated in Fuchsia's repository. According to you, Rob Pike should call management and let them know it is not a good idea to use Go for writing Fuchsia's TCP/IP stack. You only read Joe's blog years ag…

A TCP/IP stack isn't a stringent litmus test for a systems PL. So you can loosen your own standard for what comprises a systems PL, but Go fails more rigorous standards. Everytime. Even Rob Pike says you're wrong and he's certainly a sympathetic character towards Go. All of this was hashed out years ago upon Go's release, and the Go team took down the "systems language" moniker. That was the end of it. Google knows i…

Rob never said Go wasn’t a systems programming language. He said the pedantic rules lawyering that plagued the internet after the initial claim was made — the tedious pablum that you’re continuing to propagate — was all noise and no signal, and made the claim not worth claiming anymore. For fuck’s sake, give it a rest.

Re: Re: Moving from PHP to Go and Back Again

#255
post #246

Earlier quoted context omitted.

It doesn't matter what Rob Pike says regarding Go and systems programming, because Google, the company that employs him, has decided Go makes sense to write system components of Fucshia in Go. That is a fact, easily validated in Fuchsia's repository. According to you, Rob Pike should call management and let them know it is not a good idea to use Go for writing Fuchsia's TCP/IP stack. You only read Joe's blog years ag…

A TCP/IP stack isn't a stringent litmus test for a systems PL. So you can loosen your own standard for what comprises a systems PL, but Go fails more rigorous standards. Everytime. Even Rob Pike says you're wrong and he's certainly a sympathetic character towards Go. All of this was hashed out years ago upon Go's release, and the Go team took down the "systems language" moniker. That was the end of it. Google knows i…

[deleted]

Re: Re: Moving from PHP to Go and Back Again

#256
post #190

Some background. I actually wrote a semi-popular book on PHP (published by a major publisher) and have contributed to the core project. And I have spoken at many PHP conferences. Perhaps tellingly, PHP is rarely my first choice anymore. Which I think it a great language (contrary to many opinions) I just find other languages a better choice. Today my language usage looks like this: - Web services / APIs: Node.js [1]…

in latest nodejs there is no a single place to catch exceptions in promise chain, which is very inconvenient.

I have many large applications running on NodeJS 9.3.0 that rely on exceptions in promises for both control flow and error logging...no issues here.

Re: Re: Moving from PHP to Go and Back Again

#257

Earlier quoted context omitted.

A TCP/IP stack isn't a stringent litmus test for a systems PL. So you can loosen your own standard for what comprises a systems PL, but Go fails more rigorous standards. Everytime. Even Rob Pike says you're wrong and he's certainly a sympathetic character towards Go. All of this was hashed out years ago upon Go's release, and the Go team took down the "systems language" moniker. That was the end of it. Google knows i…

Rob never said Go wasn’t a systems programming language. He said the pedantic rules lawyering that plagued the internet after the initial claim was made — the tedious pablum that you’re continuing to propagate — was all noise and no signal, and made the claim not worth claiming anymore. For fuck’s sake, give it a rest.

>Rob never said Go wasn’t a systems programming language.

Yes he did. He said it's a cloud-infrastructure language[0] and that he regrets calling it a systems language. That's why he took systems language off the Golang site.

>For fuck’s sake, give it a rest.

Why would we when we're right? Why don't you give it a rest, you've long been proven wrong.

You know, usage of the English language and the terms within matters. Claiming you have a systems language when you don't introduces confusion. You can loosen the terms all you want to but it will never change the fact that GC languages can never meet the strictest measure of a systems language. That's why it matters. No one should be apologizing to you because you don't like the facts.

[0]https://www.youtube.com/watch?v=BBbv1ej0fFo&feature=youtu.be...

Re: Re: Moving from PHP to Go and Back Again

#258
post #160

Earlier quoted context omitted.

Is it better than nodets?

nodets, as in typescript on node? I haven't personally tried it, but I imagine so, again depending on your particular use case. I quite like Typescript as far as syntax goes, but I think PHP 7.1+ is comparable. And PHP has a lot more support, libraries, and better tooling in my view. For example, my experience in node land is there aren't really any good ORMs; PHP has multiple, including one (Doctrine) which is easil…

In your view, if someone created an ORM for node which focused on creating object graphs for tables and fields (a-la sqlalchemy) instead of focusing on SQL building syntax (a-la knex) would it be popular?

Re: Re: Moving from PHP to Go and Back Again

#259
post #246

Earlier quoted context omitted.

It doesn't matter what Rob Pike says regarding Go and systems programming, because Google, the company that employs him, has decided Go makes sense to write system components of Fucshia in Go. That is a fact, easily validated in Fuchsia's repository. According to you, Rob Pike should call management and let them know it is not a good idea to use Go for writing Fuchsia's TCP/IP stack. You only read Joe's blog years ag…

A TCP/IP stack isn't a stringent litmus test for a systems PL. So you can loosen your own standard for what comprises a systems PL, but Go fails more rigorous standards. Everytime. Even Rob Pike says you're wrong and he's certainly a sympathetic character towards Go. All of this was hashed out years ago upon Go's release, and the Go team took down the "systems language" moniker. That was the end of it. Google knows i…

Unlike yourself I don't care what Rob says, because at the end of the day what matters is what people on the street are using Go for.

Developers don't have to ask him permission or blessing for whatever they are trying to do with Go.

Google is using Go in system components in Fucshia, and the new GPU debugger for Android is also written in Go.

You are in the one in the dark about using GC enabled systems programming languages. I have real life experience using them and have seen it works.

I lost interest on Go due to its spartan design, but certainly will encourage anyone trying to use it to build an OS from scratch, regardless of what is written in a web site.

"They did not know it was impossible so they did it"

-- Mark Twain

Re: Re: Moving from PHP to Go and Back Again

#260
post #79

I see no facts or genuine refutation in this article, just opinions. Therefore I can only assume that truth hurts because the article you are trying to argue with has a bunch of valid points. If you look at the history of Go you have to realize that it was created for the reason which is in the original article: to be a better C. If you come from C it is good, sure. And you can write big projects in it like in C (jus…

Okay, let's say I agree with your arguments: 1. Go "is still not as fast as Java can be" [1] 2. "Go lacks the most basic tools which any seasoned developer can expect from a language (like generics)" 3. "Go does not have a de facto build system and you can’t handle dependency management in an easy way" [2] 4. odd error handling 5. not a lot of libraries to choose from [3] 6. possibly more arguments that I missed when…

It is not about stupidity, more like the blub paradox. If you only know C and Go you have no idea why for example Kotlin would be better for the majority of the cases because to see it you have to use it.
Post reply on HN