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

Some Go web dev notes

jvns.ca

Post reply on HN
Print view View original

141–150 of 154 posts

Re: Some Go web dev notes

#141

Post by demi56 »

sureglymop wrote: post #127
demi56 wrote: post #91

Earlier quoted context omitted.

You can’t just compare a library from another language, because they’re different, if all flag parsing library were inspired by Clap it’ll be a living nightmare for language that isn’t rust

Why can't I compare a library from another language? I have spent a significant amount of time with all of the popular flag parsing libraries in Go and none were as flexible yet easy to work with as clap. Anyway, I am not necessarily talking about syntax but moreso about the feature sets and overall quality.

[dead]

Re: Some Go web dev notes

#142

Post by sacado2 »

voigt wrote: post #2

> In general everything about it feels like it makes projects easy to work on for 5 days, abandon for 2 years, and then get back into writing code without a lot of problems. To me this is one of the most underrated qualities of go code. Go is a language that I started learning years ago, but did't change dramatically. So my knowledge is still useful, even almost ten years later.

As a teacher, I have a program I've been using for the last 8 years or so. I distribute the compiled version to students for them to compare their own results with what's expected. The program's written in go. I update it every other year or so. So I'm exactly in the case you describe.

I never had any issue. The program still compiles perfectly, cross-compiles to windows, linux and macos, no dependency issue, no breaking change in the language, nothing. For those use-cases, go is a godsend.

Re: Some Go web dev notes

#143

Post by peterldowns »

glenjamin wrote: post #136
peterldowns wrote: post #122

Earlier quoted context omitted.

Thanks for taking a look! Long-running index creation is a problem for pgmigrate and anyone else doing “on-app-startup” or “before-app-deploys” migrations. Even at moderate scale (normal webapp stuff, not megaco size) building indexes can take a long time — especially for the tables where it’s most important to have indexes. But if you’re doing long-running index building in your migrations step, you can’t deploy a n…

I think that’s the safest approach, but it’s inconvenient for the common case of an index that’ll be quick enough in practice. The approach I’ve seen flyway take is to allow detecting / opting out of transactions on specific migrations As long as you always apply migrations before deploying and abort the deploy if they time out or fail, then this approach is perfectly safe. On the whole I think flyway does a decent j…

Makes sense — Flyway is so good, copying their behavior is usually a smart choice. Thanks for the feedback!

Re: Some Go web dev notes

#144

Post by tinodb »

jpc0 wrote: post #102
kolja005 wrote: post #28

Earlier quoted context omitted.

I'm curious in what sense you find Python difficult to deploy? My company has tons of Python APIs internally and we never have much trouble with them. They are all pretty lightly used services so it it something about doing it on a larger scale?

Forcing something like WSGI and distributed computing is the biggest thing architecturally. I'm currently moving 4 python microservices into a single go binary. The only reason they were ever microservices was because of WSGI and how that model works. In any conventional language those are just different threads in the same monolith but I didn't have that choice. So instead of deploying a single binary I had to deplo…

I don’t see why WSGI would enforce any of that. Just sounds like someone jumped the microservices hype train…. You can as easily fit it in one python program as in one go binary.

Re: Some Go web dev notes

#145

Post by sethammons »

coffeeindex wrote: post #129
sethammons wrote: post #79

Earlier quoted context omitted.

I am just trying Templ. I like what I am seeing for the most part. There are some tooling ergonomics to work out. Lots of "suddenly the editor things everything is an error and nothing will autoimport or format" back to mostly working. Click to definition goes to the autogenerated code instead of the templ file. Couple things like that. But soooooooooo much better to deal with code gen than html/template. That thing…

What’s so bad about html/template?

passing data to templates that call templates that (maybe call other templates that) use the data. It is easy to call things in the wrong order, not provide the right values, think you have access to some data and totally don't, there is no type help, there is a bit of ceremony to get functions available, and I'm sure there is something else I'm forgetting. Just overall, a pain to work with.

So far, I'm enjoying in Templ that I can clearly see what arguments and types are passed to whichever views/partials and that I can simply use standard Go functions to do whatever I need them to do.

Re: Some Go web dev notes

#146

Post by azemetre »

mewpmewp2 wrote: post #120
arp242 wrote: post #119

Earlier quoted context omitted.

It's not just "old node", it's also "old webpack" and "old vuejs" and "old everything". Yes, "it works" and strictly you don't really need to update it, but you're going to add a lot of friction down the line by never updating and at some point the situation will become untenable.

Old webpack and vuejs yes, because it's the UI which does get quickly old, but APIs or also things you would do with Go don't really have to change much as time goes on. A simple Express server and that's it.

This hasn't really been my experience, maybe if you're only using a single dependency (like express) it's easy but if you have any reasonable amount of npm deps it becomes quite untenable very very quickly. Mostly in ways you don't expect.

Like one dependency upgrading needing you to move to node v16 but doing so causes half your app to implode.

I don't really see this type of things in modern projects with other languages.

Re: Some Go web dev notes

#147

Post by theshrike79 »

kolja005 wrote: post #28
jeffreyrogers wrote: post #5

Earlier quoted context omitted.

I like Go for this reason as well. In Python I found the Flask framework to be suitably unobtrusive enough to be nice to use (never liked Django), but deploying python is a hassle. Go is much better in that area. The error handling never bothered me either. I think if Go shipped better support for auth/sessions in the standard library more people would use it. Having to write that code yourself (actually not very har…

I'm curious in what sense you find Python difficult to deploy? My company has tons of Python APIs internally and we never have much trouble with them. They are all pretty lightly used services so it it something about doing it on a larger scale?

Deploying a Go application: copy executable to server, done.

Deploying a Python application: 1) Install python globally (oof) 2) figure out which venv system to use 3) copy project to server 4) install project to venv 5) figure out how to run it inside the venv so that it'll find the correct package versions from there instead of using the global ones.

Re: Some Go web dev notes

#148

Post by lenkite »

zaptheimpaler wrote: post #81

I've been using go for a month now in a new job and hate it. It feels like they learned nothing from the past 20 years of language development. Just one huge problem is that they REPEATED Java's million/billion dollar mistake with nulls. The usual way to get HTTP Headers using Go cannot distinguish between an empty header value and no header at all because the method returns "nil" for both these cases. They could've…

I fully agree that Go's error handling needs improvement, but you have gone into a rage about the language while fully forgetting the VERY basic Go "comma ok" idiom used everywhere.

Please read Effective Go https://go.dev/doc/effective_go before making production software.

Re: Some Go web dev notes

#149

Post by jpc0 »

tinodb wrote: post #144
jpc0 wrote: post #102

Earlier quoted context omitted.

Forcing something like WSGI and distributed computing is the biggest thing architecturally. I'm currently moving 4 python microservices into a single go binary. The only reason they were ever microservices was because of WSGI and how that model works. In any conventional language those are just different threads in the same monolith but I didn't have that choice. So instead of deploying a single binary I had to deplo…

I don’t see why WSGI would enforce any of that. Just sounds like someone jumped the microservices hype train…. You can as easily fit it in one python program as in one go binary.

I can keep an effective in memory store of data and expect it to even be the same in memory store of data? When a wsgi server is spawning multiple processes?

Or kick of long running backend tasks in a other thread?

These are things that python forces you to do in a distributed manner. Partly because of the gil and partly because those pesky cloud native best practices don't apply outside of the cloud...

And well if I'm going to have to reimplment an http server not ontop of wsgi how about just using a different language that doesn't have those same fundamental problems for the use case...

There's things I would happily use python for. A webserver just isn't one of them.

I mean it takes 10 lines of code to have a webserver running in golang, the language is build for it.

Re: Some Go web dev notes

#150

Post by zaptheimpaler »

Mikushi wrote: post #94
zaptheimpaler wrote: post #81

I've been using go for a month now in a new job and hate it. It feels like they learned nothing from the past 20 years of language development. Just one huge problem is that they REPEATED Java's million/billion dollar mistake with nulls. The usual way to get HTTP Headers using Go cannot distinguish between an empty header value and no header at all because the method returns "nil" for both these cases. They could've…

Your "sane" language looks quite insane to me, unreadable mess at a glance.

Yes, language design should cater to people who have spent a little bit of time using and learning it, because they represent the majority of hours spent using that language. What a language looks like to someone who's never seen it is sort of irrelevant. That code could also have been written more imperatively, and probably would be by many people for those who don't like the functional style.
Post reply on HN