4 ms·
As much as I personally don’t enjoy writing Go I really can’t fault them. I still find it interesting that for a relatively obvious feature set of fast compile
by tybit 7y ago
As much as I personally don’t enjoy writing Go I really can’t fault them.
I still find it interesting that for a relatively obvious feature set of fast compiles, fast startup and fast runtime there really isn’t anything mainstream out there to compete with Go.
I really hope something like Kotlin, Swift, ReasonML or even AOT JVM/.NET brings something to the table soon. Or perhaps I’ll just have to wait for WASM to really take off server side.
- genuine_smiles 7y ago> fast compiles, fast startup and fast runtime All I can think of is D, but it’s not quite mainstream. Are there any other less popular languages that meet all 3 conditions?
- amedvednikov 7y agohttps://vlang.io https://vlang.io
- sagichmal 7y agoStill snake oil.
- iteratorloopmap 7y agoLoL
- gilbertmpanga12 7y agoLooks super lit with everything baked;- faster compilation, small binaries, and performance... Still scared to jump in
- pjmlp 7y agoDelphi, Ada, .NET Native, OCaml.
- guitarbill 7y agoin production is fast startup really such a boon outside of serverless? especially if you're already doing blue/green deployments, doesn't seem like it'll have much impact. (depends what "fast" vs "slow" means - are we talking about milliseconds vs a second or two, or startup times so horrendous they cripple your devs' ability to iterate and tests?)
- dangoor 7y agoWe essentially run in a serverless environment (App Engine), so fast startup does matter to avoid some unlucky users hitting the cold start.
- guitarbill 7y agofair enough. you say in the blog App Engine has worked well for you and you're sticking with it, so i'm assuming you considered moving to traditional servers but found it unappealing?
- dangoor 7y agoYes. Google Cloud now has multiple options for autoscaling servers (App Engine Standard, App Engine Flex, and Cloud Run) with the biggest differences being how they're deployed and specifics around the scaling. We _could_ manage our own Kubernetes clusters and such, but Cloud Run is pretty similar to that and takes away all of the management headache. There is essentially zero code difference, should we decide to change our deployment strategy later. We're using Google Cloud Datastore for persistence, and that automatically scales in both servers and storage, so it has worked out nicely for us as well.
- tybit 7y agoLocal iteration is most important to me, but serverless is a great example too, as are CLIs (slow CLIs have recently become my pet peeve). The nice thing about Go is it performs well in each of these use cases by ensuring nothing in its tool chain is slow, or produces slow code. Slow is in the eye of the beholder I suppose, but I guess I’m using it here to mean within an order of magnitude of its peers.
- pushrax 7y agoHow does WASM fill this gap? > fast compiles, fast startup and fast runtime ... mainstream C is this but it's harder to write secure/correct C, the standard library is smaller, and there's no canonical toolchain in the same way as Go.
- PudgePacket 7y agoOne doesn't just write WASM though.. WASM is like the JVM. You still need to write code in some other language.
- pushrax 7y agoExactly. Hence posing the question (rhetorically, I suppose).
- tybit 7y agoI guess I’m jumping to conclusions but it seems like a lot of lessons have been learnt since JVMs and .NET came onto the scene, and that WASM runtimes and the future languages that target them will prioritise speed at every stage.
- _ph_ 7y agoGo already cross-compiles to WASM, so if desired, Go code can be run via WASM. But on the server, you probably rather want to run the Go code natively. For the client, this should be quite interesting.
- jacques_chester 7y agoGraalVM looks to bring fast launch, at the expense of long-run performance optimisations from JITting. For FaaS-y purposes that will be a sane tradeoff, for long-running services the startup overhead is amortised over requests.