Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go at Digital Ocean

speakerdeck.com

Post reply on HN
Print view View original

101–107 of 107 posts

Re: Go at Digital Ocean

#101

Post by innocentoldguy »

hliyan wrote: post #76
innocentoldguy wrote: post #49

Earlier quoted context omitted.

Hmm. Must have made sensitive Go programmers cry. Go is a boring language, and it isn't as good at concurrency as other, better designed languages. I'm sorry, but that is a fact.

As someone with both a C++ and JS background, Go's boring nature is the best thing about it. It gets out of the way and lets you focus on the application logic. Programming languages are tools, not ends unto themselves.

Don't insert words into my commentary that I didn't say. I said Go was boring. You agreed. I said Go wasn't the best designed language, which it isn't. Look at its package/dependency management, memory usage for processes, inability to guarantee a process will relinquish control so other processes can run. Go enforces code bloat that other languages don't. For example, a program in D will often times be half the length of a Go program that does the exact same thing.

You are right. Programming languages are tools, not ends unto themselves (something you said, not I), and just as I can use tools from Snap-on or tools from Harbor Freight, I'm personally inclined to use tools with superior engineering. Tools that are designed and manufactured to be robust and to last, because they make it so much easier for me to build meaningful things.

I also think it is an unfair comparison to take two of the most awful languages in computer history and use them to make a case for Go's superiority. It is like saying a Fiat 500L is an awesome car because it isn't a Yugo.

Re: Go at Digital Ocean

#102

Post by stubish »

hasenj wrote: post #91
stubish wrote: post #88

Earlier quoted context omitted.

You can be conservative about adding dependencies and still end up with hundreds. Database driver, database utilities, gRPC framework, monitoring & metrics, CLI & configuration tools, /x/ packages such as crypto or net, logging, linters, libraries to talk to other moving parts like Rabbit or Vault, and then all the transitive dependencies like yaml, toml, websockets, and the various 'standard' helpers the authors of…

That's the definition of not being conservative about adding dependencies.

Oh, that could certainly be a conservative list. It depends on the requirements of the software. Drop any item on that list and you are either losing capabilities or have more software to implement yourself. And it is certainly tempting to reimplement things like Cobra, Viper, sqlx, prometheus end point, and everyone knows we should all implement our own crypto, but overall it ends up costing you time, and probably usability since your time is limited.

Re: Go at Digital Ocean

#103

Post by Thaxll »

innocentoldguy wrote: post #100
Thaxll wrote: post #63

Earlier quoted context omitted.

Maybe but better designed language doesn't mean better language overall. Also anything Erlang based is slower than Go.

And anything Erlang based is going to be more stable/scalable than Go because Go takes 10 times the memory to spawn a process, uses shared memory to store processes, and doesn't guarantee a process will relinquish control. Package/dependency control in Elixir and Erlang are better than the mess that Go started out with, and is still struggling with, apparently. Hot deploys are also much nicer in Elixir than they are…

Anything Erlang is doing for deployment is moot since Kubernetes / Docker and the like where you have a platform to do that better than Erlang does and it's language agnostic. No one cares about hot deploy tbh.

Re: Go at Digital Ocean

#104

Post by innocentoldguy »

Thaxll wrote: post #103
innocentoldguy wrote: post #100

Earlier quoted context omitted.

And anything Erlang based is going to be more stable/scalable than Go because Go takes 10 times the memory to spawn a process, uses shared memory to store processes, and doesn't guarantee a process will relinquish control. Package/dependency control in Elixir and Erlang are better than the mess that Go started out with, and is still struggling with, apparently. Hot deploys are also much nicer in Elixir than they are…

Anything Erlang is doing for deployment is moot since Kubernetes / Docker and the like where you have a platform to do that better than Erlang does and it's language agnostic. No one cares about hot deploy tbh.

I disagree, but even if you were right about Kubernetes and Docker being able to handle every use case out there, I still find it fascinating how you skip over all the other relevant issues with your beloved baby.

Re: Go at Digital Ocean

#105

Post by hasenj »

stubish wrote: post #102
hasenj wrote: post #91

Earlier quoted context omitted.

That's the definition of not being conservative about adding dependencies.

Oh, that could certainly be a conservative list. It depends on the requirements of the software. Drop any item on that list and you are either losing capabilities or have more software to implement yourself. And it is certainly tempting to reimplement things like Cobra, Viper, sqlx, prometheus end point, and everyone knows we should all implement our own crypto, but overall it ends up costing you time, and probably u…

That's definitely not conservative.

Maybe you don't know what a conservative attitude about libraries is because you've never seen one.

Your original comment:

> You can be conservative about adding dependencies and still end up with hundreds

No. Just no. If you have hundreds of dependencies, you are by definition not conservative about adding dependencies.

> Database driver

About the only legit thing on the list.

> database utilities

Not needed.

> gRPC framework

Not needed.

> monitoring & metrics

Not needed.

> CLI & configuration tools

NOT NEEDED!

.. etc.

> Drop any item on that list and you are either losing capabilities or have more software to implement yourself

What are you losing by not using grpc? You can do a lot of things by just using the builtin rpc package or the encoding/gob with the http package.

Being conservative about adding dependencies means resisting the urge to add them and figuring out a way to do without them.

Every dependency you add is a potential point of failure and headaches.

Just like every layer of abstraction you create.

The cost for dependencies is huge, so every dependency has to justify itself by giving such a huge benefits that it's worth the cost.

> Cobra

Do you need a special library to handle command line arguments? How complex is your CLI interface? How many commands and sub commands do you have? 10? 20? It's trivial to handle that much manually using the builtin libraries.

> Viper

How hard is it to just read a json file using builtin libraries? How much do you lose by not using "Viper" or whatever?

How many times will you have to read config files? One time when the app launches? Does not justify adding a dependency.

> it is certainly tempting to reimplement things like Cobra, Viper, sqlx, prometheus end point, and everyone knows we should all implement our own crypto

You don't even need to re-implement anything. Just do the simplest thing that works using the standard library.

You know the standard library comes with a crypto package, right?

The mindset you are presenting is the exact opposite of conservative. You are just grabbing every library that you think can save you 20 lines of code.

Re: Go at Digital Ocean

#106

Post by stubish »

hasenj wrote: post #105
stubish wrote: post #102

Earlier quoted context omitted.

Oh, that could certainly be a conservative list. It depends on the requirements of the software. Drop any item on that list and you are either losing capabilities or have more software to implement yourself. And it is certainly tempting to reimplement things like Cobra, Viper, sqlx, prometheus end point, and everyone knows we should all implement our own crypto, but overall it ends up costing you time, and probably u…

That's definitely not conservative. Maybe you don't know what a conservative attitude about libraries is because you've never seen one. Your original comment: > You can be conservative about adding dependencies and still end up with hundreds No. Just no. If you have hundreds of dependencies, you are by definition not conservative about adding dependencies. > Database driver About the only legit thing on the list. > d…

Yes, you can certainly be conservative by ignoring the requirements of the project and throwing away features. It will be a complete failure, because it doesn't do what it is supposed to, but it won't have any dependencies.

I will stop instrumenting my projects because its not needed, no matter what operations says about our SLAs, and my gRPC endpoint will stop talking gRPC because its not needed, and it will be more reliable because clients can no longer talk to it by the expected protocol, and I'll ignore the usability requirements of the CLI and configuration management because specification documents and usability requirements be damned, and I'll implement by own helpers for the database code because NIH syndrome is fantastic, and I'm sure my employer will be happy for me to reinvent the wheel. Except I probably won't have an employer any more, because I seem to have stopped delivering the software they tasked me to.

Re: Go at Digital Ocean

#107

Post by hasenj »

stubish wrote: post #106
hasenj wrote: post #105

Earlier quoted context omitted.

That's definitely not conservative. Maybe you don't know what a conservative attitude about libraries is because you've never seen one. Your original comment: > You can be conservative about adding dependencies and still end up with hundreds No. Just no. If you have hundreds of dependencies, you are by definition not conservative about adding dependencies. > Database driver About the only legit thing on the list. > d…

Yes, you can certainly be conservative by ignoring the requirements of the project and throwing away features. It will be a complete failure, because it doesn't do what it is supposed to, but it won't have any dependencies. I will stop instrumenting my projects because its not needed, no matter what operations says about our SLAs, and my gRPC endpoint will stop talking gRPC because its not needed, and it will be more…

No, it will not be a complete failure when you are careful about what you include.

It will be a complete failure when things get so hairy with so many layers and failure points that you can't tell what's going on anymore.

Post reply on HN