Live data from Hacker News

Re: Moving from PHP to Go and Back Again

blog.breakthru.solutions

151–160 of 281 posts

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

#151
post #136
post #82

Earlier quoted context omitted.

If you look for an oop or fp language you are also out of luck. You are only happy if you look for a better C which most people aren't.

> You are only happy if you look for a better C which most people aren't. I'd argue Rust is the "better" C. Go is a "simpler" C, at the expense of expressiveness, features, speed (only noticable in very low level usecases) and applicability for certain domains (Go is primarily for networked apps). In the same way Java wanted to be a simpler C++ (which came with it's own drawbacks). And for me Go is more of a competit…

To me, Rust is like C++, Go is like C.

Rust loves zero cost abstractions, and isn't afraid to be complicated. It gives the programmer as much power as possible.

Go is simple and actually very fast. The garbage collector is probably the biggest hurdle for performance and it's still best in class. Definitely higher level than C, but not enormously so.

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

#152
post #144

Earlier quoted context omitted.

>Turbo Pascal compilation speed, in MS-DOS, using 90’s hardware was already faster than Go. What relevance does this have on the compiler landscape today ? If you have to use a compiler from ~30 years ago to find a comparison supporting your claim, it sounds very much like Go is indeed much faster than what it competes against today.

The relevance is that a compiler running in 90's hardware is able to beat Go's compilation speeds of 2017. That same compiler has evolved through the years. If you want the 2017 version of it, it is called Delphi. Beats Go in language features and compilation speed. Go's compilation speed only surprises those developers that never used anything else beyond C and C++.

>The relevance is that a compiler running in 90's hardware is able to beat Go's compilation speeds of 2017

And beat 99% of other compilers today, meaning that overall compiler complexity has grown.

>If you want the 2017 version of it, it is called Delphi.

Ok, this is something actually relevant.

>Go's compilation speed only surprises those developers that never used anything else beyond C and C++.

For me (tm), Go compilation speed has compared equal or favorably against C, C++, Java, C#, Rust at least.

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

#153

Earlier quoted context omitted.

Solid module system? It's still the same as C, which is _not_ a solid module system.

I'm assuming he meant the dependency manager, which is really nice. https://getcomposer.org/

Correct. :)

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

#154
post #70
post #62

Earlier quoted context omitted.

> For example, the labstack echo framework in Go is one of my favorite frameworks, it does a lot of work for me. On the downside, I can't hijack HTTP connections in the router, This isn't a problem with "frameworks" but a problem with the library you specifically chose which is bad since it doesn't even fulfill your needs apparently. I wrote my own go http router, and I have no problem hijacking the connection and fi…

Writing a custom http router is kinda contra to the point of using a library, no? I don't want to bother with writing my own router and this was one of the few times I had problems. I think even if I wrote my own framework, I would eventually end up having to hack around it anyway when I inevitably need to do something the framework I wrote just fundamentally can't and I suggest this will be the case for your custom…

So don't evolve your project based on HTTP stack more than an HTTP stack may allow you to.

Suddenly, you'd like to have real-time comm? Don't add WebSockets, simply because they fit right above the whole of your stack based on HTTP. Use TCP.

There's a very gentle balance between using what you've already got and introducing a set of newer entities into the system; and sadly this is not always that clear, which one you should use.

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

#155
post #21

Earlier quoted context omitted.

I've been eyeing up Pony ( https://www.ponylang.org/ ) a lot lately. To my eye, it has a lovely syntax and a very useful mix of modern programming features. I'm particularly enamored of the types, safety, actor model, and absence of exceptions. From a distance, it looks like the best parts of Rust, Golang, and Python. > Haskel? Where are the libraries? Well, I suppose the same drawback would apply to Pony. :)

I've seen a lot of stuff on Pony as well and it looks promising. Have you built anything with it yet?

Not yet, but I'm looking forward to it; just need to find a good project.

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

#156
post #146
post #143

Earlier quoted context omitted.

... curly brackets on new lines do work perfectly fine in case you're writing code on your own. As soon as you start working in a team and each team member starts to use their own formatting, it becomes super messy and unreadable. Either you inforce a clear style guide which leaves you to explain the team why your style is the best, or you leave this task to the language itself and never ever have to start arguing ab…

But why should Go enforce it on behalf of everybody? A parser option to not automatically insert semicolons would be all I need, but no. To me, even with super short lines, braces at the end of the line are messy, and consistently messy is still messy. > Either you inforce a clear style guide which leaves you to explain the team why your style is the best, or you leave this task to the language itself Which then leav…

Go's authors didn't explicitly explain their choice of style, yet they explain why they enforce it:

https://golang.org/doc/faq#Is_there_a_Go_programming_style_g...

https://golang.org/doc/effective_go.html#formatting

Style guides are a matter of taste. None is better or worse. Yet, I really don't like discussing about my taste within a team of different tastes. It's like asking someone why he/she'd prefer black coffee over cappuccino. I'd prefer someone (or the language) making a clear decision upon code style and enforcing it rather than ending up with a messy, un-styled code base.

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

#157
post #134
post #124

Earlier quoted context omitted.

:D You're comparing turbo pascal with Go today? You're gonna write microservices and web applications with Turbo Pascal?

Ever heard of FreePascal and Delphi? In any case it doesn't change the fact that Go's compilation speed is nothing to brag about, it has been done before in many other languages, Turbo Pascal was just one example. If you wish I can provide other examples of languages that compile as fast, on such old hardware while matching Go's compilation speed, with richer language features.

Yes, I heard about these FreePascal and Delphi but I have no prior experience with them.

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

#158
post #127

I know this is about the weakest critique possible, but currently using Go, I know my next project won't be in it, simply for the impossibility to put an opening curly brace on its own line. Other languages that don't require semicolons at the end of a line have it, and even if they didn't, I'd rather have to put semicolons manually.. Go is "opinionated" I guess, but so am I. Whatever their target audience is, I'm no…

It's a shame to choose or dismiss a language based on what is an accident rather than essential, but I understand.

I, for instance, are not a big fan of reading and typing Lisp/Scheme/*, pretty printing or not, even though I understand why it is the way it is, or whether its otherwise fascinating.

:((((((((((

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

#159
post #9
post #3

Everyone I know who uses Go complains about it. Every day you write Go code you will come across some piece of code that would be shorter with templates in C++ or using , or you could do it more simply in Python, or if you were really clever it would be a single line of Haskell. And yet we keep writing Go. By comparison, I'm a bit put off by the Rust community's evangelism, but that might just be my personal experien…

> And yet we keep writing Go. What are the alternatives if you want something with type checking? Java? No, thanks. Haskel? Where are the libraries? C/C++? I guess Typescript is the only alternative

"Haskel? Where are the libraries?"

What libraries are missing? The only issue I've had with libraries are that some client libraries are wrappers over C libraries and this makes static linking difficult (or seemingly impossible on a Mac)

A few years ago there was a lack of libraries in some areas but that's not the case these days.

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

#160
post #27

Earlier quoted context omitted.

To be fair to the haters, even modern PHP can be horrible. The old nightmares are still around; we've just agreed to ignore them, and maybe deprecate a couple of the worst. (And ternary syntax is still broken, and the standard library is anything but standard.) But yes, if you're working on a modern PHP project, there's a lot to love: A solid module system, an enormous sea of high quality libraries, type checking, a…

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 easily the equal in my view of the highly regarded Python SQLAlchemy. Similarly with routing, frameworks, templating, etc., there's a huge amount of maturity on the PHP side that's missing from node.

The big question is going to be in the process model. Node has an event loop; PHP doesn't. For most purposes, I think an event loop makes writing good code harder to no real benefit, but in some cases (eg, acting as the endpoint for a ton of open websockets) it can be a big win. If you do need that, then you should probably lean towards node over PHP, and sure, why not use typescript? But for the general case, I'd still lean towards PHP.

(Then again, there's also a ton of other languages and frameworks. Just because PHP - or node - might be better than the other for some task doesn't mean there aren't a dozen more languages better than both.)

Post reply on HN