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

Go 1.22

go.dev

Post reply on HN
Print view View original

151–160 of 164 posts

Re: Go 1.22

#151

Post by WuxiFingerHold »

BillyTheKing wrote: post #34

I've been mostly writing Typescript the past 3 years - and recently started writing code in Go. Initially I was a little apprehensive, lack of array functions, slightly less flexible type-system, etc. But after spending some time writing Go I now had to re-initialise a typescript project for a small-ish team (4-5 devs). The amount of time spent on things such as linting, selecting the correct library for server routi…

Interesting ...

>> The amount of time spent on things such as linting, selecting the correct library for server routing, the correct server, coding standards,

I don't fully agree here. Those points are pretty straight forward and coding standards (not formatting, for TS prettier is pretty standard, btw.) need to be defined even in Go projects. Also, Deno has much of the setting up solved.

>> basic error-handling and enforcing it with a custom error or Result type to get out of this nested try/catch hell which still loses the majority of errors.

Fully agreed. Maybe I have a big lack of understanding of error handling in NodeJS, but how on earth do I find out what functions can throw errors and what are the errors thrown? If someone could enlighten me I'd be really grateful. To be on the safe side I would need to run my whole code in a try..catch block. How to decide how to handle different errors if I don't know which errors can occur? On the other hand, just yesterday I had to debug a Rust panic in a smallish code base. Even with stacktraces turned on it took half an hour to find out where there error occurred. Still, Go and Rusts error handling is much better. IIRC, in Java you see all types of exceptions that can occur in the docs of a function?

>> Setting up testing and mocking. Setting up Prisma

Again, not a big thing IMO. If you like an ORM, Prisma is one of the best.

>> Don't get me wrong, I really do like Typescript.

Yeah, that's the thing. Typescript is such a fantastic language. Writing Go feels like using a hand-axe. Typescript's null handling alone makes it 10 times better (I hope everyone is using it, but that underlines your point regarding the conventions needed ...). I recently found a lib that gives us compile time checked pattern matching like in Rust.

Re: Go 1.22

#152

Post by WuxiFingerHold »

Touche wrote: post #122
BillyTheKing wrote: post #34

I've been mostly writing Typescript the past 3 years - and recently started writing code in Go. Initially I was a little apprehensive, lack of array functions, slightly less flexible type-system, etc. But after spending some time writing Go I now had to re-initialise a typescript project for a small-ish team (4-5 devs). The amount of time spent on things such as linting, selecting the correct library for server routi…

Go is the language for getting sh*t done.

Best summary of Go. That should be the headline of the Go website.

Re: Go 1.22

#153

Post by WuxiFingerHold »

endtime wrote: post #71
BillyTheKing wrote: post #34

I've been mostly writing Typescript the past 3 years - and recently started writing code in Go. Initially I was a little apprehensive, lack of array functions, slightly less flexible type-system, etc. But after spending some time writing Go I now had to re-initialise a typescript project for a small-ish team (4-5 devs). The amount of time spent on things such as linting, selecting the correct library for server routi…

I got to spend a couple years writing Dart (not Flutter) and found it to be the best of both worlds. Such an underappreciated language.

Interesting, Dart for backend? Do you build APIs? How is the ecosystem? I heard good thing of Swift as well, but I have concerns that it's to niche for backend stuff.

Re: Go 1.22

#154

Post by lpribis »

maximus-decimus wrote: post #110
ctz wrote: post #103

Earlier quoted context omitted.

"yes, please run this loop minus 10 times" - statements dreamed up by the utterly Deranged

Back in my days, you had to do it this way for i := 0; i panic }

Back in my day you would do

    for (size_t i = 0; i
And it would panic 18446744073709551606 times.

Re: Go 1.22

#155

Post by Cthulhu_ »

ken47 wrote: post #67
KingOfCoders wrote: post #38

Earlier quoted context omitted.

In my CTO newsletter I recently wrote about TS vs Go releases, with Go 1.22 as an example. TS gets more and more complicated with each release, catering to the power users. Go adds things that makes it simpler to use, like the (missing) range over integers. It's like game sequels, they add more and more canon and game mechanics, then game sequels (or comics) need to reset to make them more accessible to newcomers aga…

Yes, but TS users can stay on the "type-newbie" path, which is still a huge improvement over vanilla JS and doesn't take much effort. What I've had issues with is devs who came from the vanilla JS world and love it, so they go out of their way to avoid utilizing more complex types when they would add no-cost safety (aside from the initial minutes or hour spent learning the feature).

And that's dangerous; give people a lot of advanced options and they will inadvertedly use them, and nobody will dare to touch it, and it'll cause a lot of headaches, etc etc etc. Scala made this mistake as well. Go is the antithesis to TS and Scala, and I hope they keep it up.

I also hope but doubt that they will do something few other languages dare: remove features.

Re: Go 1.22

#156

Post by Cthulhu_ »

avtolik wrote: post #63
cookiengineer wrote: post #43

Earlier quoted context omitted.

I feel very similar to your experience. What made me stay in go is its amazingly unified build toolchain. The things you can do with go:embed and go:generate blow my mind in every other project. The golang.org/x package is also another thing, where there is pretty much every internet RFC related implementation available, ready to use.

Can you give some examples how are you using go:embed and go:generate?

I've used go:generate to generate a set of structs based on an XSLT document. That said, since XML is fairly uncommon these days in popularity, the generator was a bit buggy still.

And I've used go:embed to include .sql files for database migrations and querying. I should really spend some time on this POC I made (sqlite, goose for migrations, and an implementation of temporal tables) and publish it as a demo.

Re: Go 1.22

#157

Post by Cthulhu_ »

hambos22 wrote: post #64
BillyTheKing wrote: post #34

I've been mostly writing Typescript the past 3 years - and recently started writing code in Go. Initially I was a little apprehensive, lack of array functions, slightly less flexible type-system, etc. But after spending some time writing Go I now had to re-initialise a typescript project for a small-ish team (4-5 devs). The amount of time spent on things such as linting, selecting the correct library for server routi…

> can't wait for some map/filter/find slice functions though Till that day comes, you could use the "lo" library (inspired from lodash). It's my goto Swiss army knife for golang projects. https://github.com/samber/lo

Only if you're willing to take the cost associated with that; it adds a "DSL", an extra language to the language, reducing its goal of simple and readable code. Compare also with using a testing library that adds human-readable assertion phrases (expect(x).toBe(y) etc).

Re: Go 1.22

#158

Post by Cthulhu_ »

mjw_byrne wrote: post #119

Perhaps I'm a dinosaur but I don't like the range-over-function addition. I don't think it adds enough convenience to justify the complexity it adds to the language, and the functional style feels at odds with Go's explicit, imperative (albeit verbose) and feature-lean style, which I think was one of its major strengths. For the same reason I think the range-over-integer feature is a misstep. Go's lean feature set an…

So at the moment this feature is optional / experimental and opt-in; if they make it standard on, I hope they add an opt-out mechanism of sorts, so that developers are discouraged to use it if it's not commonplace.

I find that one big problem with software developers is keeping developers from adding complexity, or "flexing". Especially developers earlier in their career, present company included, tend to overcomplicate a solution instead of just solve the problem in a straightforward albeit inelegant and wordy fashion and move on.

Re: Go 1.22

#159

Post by mjw_byrne »

Cthulhu_ wrote: post #158
mjw_byrne wrote: post #119

Perhaps I'm a dinosaur but I don't like the range-over-function addition. I don't think it adds enough convenience to justify the complexity it adds to the language, and the functional style feels at odds with Go's explicit, imperative (albeit verbose) and feature-lean style, which I think was one of its major strengths. For the same reason I think the range-over-integer feature is a misstep. Go's lean feature set an…

So at the moment this feature is optional / experimental and opt-in; if they make it standard on, I hope they add an opt-out mechanism of sorts, so that developers are discouraged to use it if it's not commonplace. I find that one big problem with software developers is keeping developers from adding complexity, or "flexing". Especially developers earlier in their career, present company included, tend to overcomplic…

Yep, one of the big wins for Go was preventing this by just not supporting complicated, "clever" code. It doesn't have a ternary expression, "i++" is not an rvalue, you cannot pack a huge amount of work into a single line, you can't overload operators or even functions and so on.

The opposite extreme is arguably C++, which I personally quite like (probably because I use it only for solo projects and don't try to collaborate with anyone), but I can't deny that it's an awkward, gnarly monster of a language. It'd be awful to see Go end up like that.

Post reply on HN