I think this discussions are mostly pointless... Most of the times I can see one side or the other being right depending on the size of the project, size of the team, time to learn something new.
Re: Moving from PHP to Go and Back Again
181–190 of 281 posts
Re: Re: Moving from PHP to Go and Back Again
#182From my point of view PHP 7.2 is a great choice for startups and with a small team, so build the product, make it run. If required then do some R&D to switch to go, jumping straight into go should cause some issue.
Good luck hiring actual software engineers and not the ones who just managed to get into IT during the SEO boom. They are probably less expensive than the Py ones, but they probably don't have much of a future either.
[deleted]
Re: Re: Moving from PHP to Go and Back Again
#183Earlier quoted context omitted.
A slightly different perspective. For the end user Go apps are by far the easiest to setup and use. Usually it's just a single binary to download. That is a huge advantage that can't be beat. Other languages usually need a large number of dependencies, with Ruby and Node, often an entire build environment, with plenty of potential for dependency hell and hours wasted. Some may advocate containers at this point, but i…
As far as I know this is only true for code written in Go. As soon as you try using C libraries you're going to have a non-trivial time statically linking everything. Isn't that the case?
No, only if by C you mean code compiled with gcc and linked against GNU libc.
There are other C compilers to choose from, with libc implementations that properly support static linking.
Re: Re: Moving from PHP to Go and Back Again
#184Everyone 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…
Everyone who uses any tool sufficiently frequently will complain about it. This is not a good proxy for quality.
It's so prevalent our industry has a term for it. "Use it in anger". You know you've gotten to know a language when you have had to work around a quirk of it's semantics.
Re: Re: Moving from PHP to Go and Back Again
#185Earlier quoted context omitted.
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.
> Rust loves zero cost abstractions C was also king of the zero cost abstractions. > and isn't afraid to be complicated. C sure is not afraid to be complicated. But at the time it was huge simplification. I'd say Rust's complexity is not there for it's own merit, but has huge advantages (though not that visible in a very small project). > It gives the programmer as much power as possible. C, C++, Rust are all in that…
>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 a computer. Example: pointers in C are not complicated. Understanding how they work may be for beginners, but that just reflects how hard it is to understand what's going on in a computer.
C is accidentally complicated where it is flawed; the non-orthogonal behavior with arrays and the syntax for function pointers are examples. Go fixes some of these flaws, which is unsurprising since it was informed by people close to the origins of UNIX and C (y'know, like, Rob Pike?)
>I'd say Rust's complexity is not there for it's own merit, but has huge advantages (though not that visible in a very small project).
Sounds a lot like C++. It isn't accidental or coincidental that it is a favorite for high performance but complicated stuff like game and browser development. This is no surprise since Mozilla wrote it to replace usages of C++ for memory safety and concurrency, not because C++ didn't offer enough. C++ is flawed in ways Rust isnt, but that doesn't mean the two don't share a lot of traits, and it was Not by accident. Complexity is one of them.
>C, C++, Rust are all in that corner. > >Go obviously isn't.
Since you've offered no reasons for why this would be true, I can't actually refute it. But it doesn't make a ton of sense. Go and Rust both let you shoot yourself in the foot literally as much as you want. Go directly facilitates assembly code and allows direct memory access with unsafe. Rust also does this. Go tries to be memory safe and provide concurrency primitives. Rust goes about this in a different way. I don't see where they significantly differ.
Rust differs most in it's superior memory safety model and low cost abstractions. Go differs most in it's simplicity and built-in concurrency. But they both feel close to their own origins.
Re: Re: Moving from PHP to Go and Back Again
#186Earlier quoted context omitted.
But nowadays it's pretty much installed everywhere? If not installed yet - it's a really easy and quite unobtrusive to install, one-liners in many OSes. So in the strict practical sense, is that such a big difference? What, extra 300MB for storing JVM? Who cares with 2TB commodity harddrives? (unless you're embedded, but then you wouldn't use Java or Go usually).
The JVM adds 64 MiB if compressed, for comparison, node.JS with CEF adds 280 MiB
Only if we are speaking about versions older than Java 9.
Java 9 added linking support for custom runtimes.
Re: Re: Moving from PHP to Go and Back Again
#187Earlier quoted context omitted.
> 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
I’d really like a strongly typed (or optionally typed) Python or Perl derivative. Rust feels most Perl-like so far.
Maybe you should look at Crystal, a Ruby derivative.
Re: Re: Moving from PHP to Go and Back Again
#188Earlier quoted context omitted.
> 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
PHP has object checking. This is why I started using value objects in PHP. The VO's I use trow exceptions when you construct them with some bad value. This is great because when you use for example a natural positive integer object you are sure it is one. So now I have 'type checking' and more secure code in PHP.
Runtime type checking while useful does not offer the same level of safety as compiler time. It will catch sinner classes of errors but you'll still have bugs lurking in production.
Re: Re: Moving from PHP to Go and Back Again
#189 > Would you rather?
>
> A – Be able to write new code 50% faster
> B – Have 90% less errors in all new code you write
Re: Re: Moving from PHP to Go and Back Again
#190Some 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.