News for hackers. Stuff that matters.
Re:Go + Services = One Goliath Project by tybit on Saturday December 21, 2019 @07:54PM (#21854378)
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.

Re:Go + Services = One Goliath Project by genuine_smiles on Saturday December 21, 2019 @08:05PM (#21854416)
> 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?

Re:Go + Services = One Goliath Project by pjmlp on Sunday December 22, 2019 @06:04AM (#21856477)
Delphi, Ada, .NET Native, OCaml.
Re:Go + Services = One Goliath Project by amedvednikov on Saturday December 21, 2019 @10:23PM (#21854972)
Re:Go + Services = One Goliath Project by sagichmal on Saturday December 21, 2019 @10:30PM (#21854994)
Still snake oil.
Re:Go + Services = One Goliath Project by fouc on Saturday December 21, 2019 @11:57PM (#21855284)
Site looks pretty legit, can you explain why it's snake oil?
Re:Go + Services = One Goliath Project by doteka on Sunday December 22, 2019 @04:50AM (#21856203)
Because it literally uses string manipulation to generate c code from source. There is no concept of an AST or anything - just string bashing.
Re:Go + Services = One Goliath Project by gilbertmpanga12 on Sunday December 22, 2019 @02:11AM (#21855740)
Looks super lit with everything baked;- faster compilation, small binaries, and performance... Still scared to jump in
Re:Go + Services = One Goliath Project by iteratorloopmap on Saturday December 21, 2019 @11:02PM (#21855098)
LoL
Re:Go + Services = One Goliath Project by guitarbill on Saturday December 21, 2019 @09:17PM (#21854706)
in 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?)

Re:Go + Services = One Goliath Project by dangoor on Saturday December 21, 2019 @09:52PM (#21854847)
We essentially run in a serverless environment (App Engine), so fast startup does matter to avoid some unlucky users hitting the cold start.
Re:Go + Services = One Goliath Project by guitarbill on Saturday December 21, 2019 @10:43PM (#21855042)
fair 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?
Re:Go + Services = One Goliath Project by dangoor on Saturday December 21, 2019 @10:50PM (#21855060)
Yes. 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.

Re:Go + Services = One Goliath Project by tybit on Sunday December 22, 2019 @12:33AM (#21855398)
Local 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.

Re:Go + Services = One Goliath Project by jacques_chester on Sunday December 22, 2019 @04:52AM (#21856210)
GraalVM 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.
Re:Go + Services = One Goliath Project by pushrax on Saturday December 21, 2019 @09:20PM (#21854720)
How 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.

Re:Go + Services = One Goliath Project by tybit on Sunday December 22, 2019 @12:36AM (#21855416)
I 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.
Re:Go + Services = One Goliath Project by _ph_ on Sunday December 22, 2019 @04:21AM (#21856116)
Go 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.
Re:Go + Services = One Goliath Project by PudgePacket on Saturday December 21, 2019 @09:39PM (#21854796)
One doesn't just write WASM though.. WASM is like the JVM. You still need to write code in some other language.
Re:Go + Services = One Goliath Project by pushrax on Saturday December 21, 2019 @09:45PM (#21854823)
Exactly. Hence posing the question (rhetorically, I suppose).