Earlier quoted context omitted.
Kotlin.
Have you gone to production with it yet for your backend? Curious Android dev here.
Not yet, but zero issues so far. Currently running Spring Boot 2M7 on AWS EB just fine. I was surprised how smooth it went.
Re: Moving from PHP to Go and Back Again
161–170 of 281 posts
Re: Re: Moving from PHP to Go and Back Again
#162Earlier quoted context omitted.
Which other languages? Turbo Pascal compilation speed, in MS-DOS, using 90’s hardware was already faster than Go. There are lots of languages with modules support, with static linking and native compilation to choose from.
:D You're comparing turbo pascal with Go today? You're gonna write microservices and web applications with Turbo Pascal?
Well, personally I wouldn't, but generally, why not?
Re: Re: Moving from PHP to Go and Back Again
#163I 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…
I came to it from embedded C, and would not call it a better C. Not that it is bad. It is just a wildly different use case. The lack of a preprocessor alone (as ugly as that may be) rules it out for a great many embedded and cross-platform scenarios. The binaries are also fairly enormous. 10M for a shell util on a desktop may be good enough. Beneath that level, it is a deal-breaker and a scandal. Agree with the strai…
You are unfortunately right about the embedded scenario. It always ends up being a C/Go abomination - and eventually you end up asking yourself...why didn't I just use C?
Re: Re: Moving from PHP to Go and Back Again
#164Re: Re: Moving from PHP to Go and Back Again
#165Earlier quoted context omitted.
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 yo…
Yes and that's quite obvious. However, frameworks are stil a limiting fact in code. If I use a framework it won't let me do certain things. Which means I have to hack around or introduce newer entities/dependencies.
A balance must be found, in one of the earlier examples, a quick hack was easier.
Re: Re: Moving from PHP to Go and Back Again
#166Not strictly about Go, but how is it supposed to impress that 'big company X' uses language Y (in this case the author uses Uber as if that's some kind of + for Go); I would be far more interested in the language + framework used to solve what level of complexity and scale problem with how many servers + people. If you can build & run something with less people and servers than your competitor and which makes you mak…
How is restarting a go-based server harder than restarting a PHP-based server?
For most setups at most ISPs, PHP servers are zero setup, self contained systems which, without any setup from the client (the user, you), comes back after reboot with no issues. It has also been the case for 15+ years so it's quite something you can actually trust to happen.
This is not so for Go or Node for most hosters out-of-the-box. Sure in the HN echo chamber, every hoster offers this maybe, but there are literally 100000s of small/big hosting companies/resellers in the world that run, say, CPanel. And the only thing that is trivial there is LAMP (with PHP/MySQL) hosting; the rest is just not very convenient or even impossible.
So once you set it up, no there is no difference, but then you have to know how to set it up, secure it, have access to set it up and secure it and know how to maintain it which is the point i'm making (not meant about specific environments besides PHP/MySQL); if you are a small company that needs to make money, you might not(!) want to bother.
Edit: Cpanel, in some near-future version will offer Node, I cannot find Go though.
Edit2: I'm definitely not recommending anything here or saying Cpanel is any good; I just know it well and I know that it's the most installed 'admin panel' on hosting servers.
Re: Re: Moving from PHP to Go and Back Again
#167PHP is unique in several ways: it's especially designed for the web, is a Web framework itself, comes with everything inbuilt, has C/Java syntax, has a shared nothing architecture, replaced VB as the most popular language for beginners, is used by most websites, is easy to use just drop a php file to Apache www dir. You simply can't objectively compare PHP to other languages because it's different to all others, it's…
But a pokemon character was rather unkind to it back in 2012, so here you are. Two years after that, Mickens wrote a glorious takedown[0] of Javascript--which must not have been as glorious as I thought--since people still seem hell-bent on using in as many places as possible. Alan Kay said that computing is now a pop culture... [0] https://scholar.harvard.edu/files/mickens/files/towashitalla...
I mean, the way people bash PHP and praise javascript is completely ridiculous.
The two languages are comparable at best in the amount of warts they have, while my firm opinion is that the js ecosystem is the most horrible thing in the world.
Re: Re: Moving from PHP to Go and Back Again
#168Earlier quoted context omitted.
I think you are confusing the language runtime with the Go "runtime" package that provides an API to the Go runtime. Golang runtime is basically a program, that is running whenever your Go application is running. As a programmer, you do not have full control over the language runtime. It runs things like garbage collection, and serializes/deserializes data in the channels. True system languages like C do not have a r…
By that definition every language has a runtime (yes, including C with crt0.o). Something has to set up the stack, enter the main() function etc. So how do you differentiate a systems language runtime? One that is bundled with the OS? Or is thin enough by some arbitrary measure?
> is thin enough by some arbitrary measure?
Colloquially, this. There's historically been a fairly big gap between "very little runtime" and "more runtime", so "no runtime" and "runtime" are what people say.
That said, the word is generally ill-defined; some people use it to mean "interpreter" or "vm" rather than the classic definition, which is (as you say) that every non-assembly language has a runtime.
Re: Re: Moving from PHP to Go and Back Again
#169Earlier quoted context omitted.
Go's "runtime" is just a library. Programs are still compiled to native machine code.
I think you are confusing the language runtime with the Go "runtime" package that provides an API to the Go runtime. Golang runtime is basically a program, that is running whenever your Go application is running. As a programmer, you do not have full control over the language runtime. It runs things like garbage collection, and serializes/deserializes data in the channels. True system languages like C do not have a r…
That memory stuff isn't even part of Rust's runtime; it's compile time stuff.
Here's Rust's runtime: https://github.com/rust-lang/rust/blob/master/src/libstd/rt....
Re: Re: Moving from PHP to Go and Back Again
#170Earlier quoted context omitted.
You're forgetting Java.
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