New at Go? Start Here.

Comment removed by moderator

Hey ! I'm fairly a newbie to go and I wanted to learn how to build backend applications with htmx and templ. Do you think you'd have any resources for where I can learn those from?

Comment removed by moderator

Comment removed by moderator

It's look great.

I’ve really liked Learn Go with Tests: https://quii.gitbook.io/learn-go-with-tests/

You learn go concepts along with writing and running tests and benchmarks.

https://quii.gitbook.io/learn-go-with-tests/

https://roadmap.sh/golang

A pretty good resource for all things development related - lots of useful materials for building up your knowledge as a developer as well

https://go.dev/doc/effective_go

You should start a project. I doesn't have to be a big one. But it's a good heuristic approach to learn a new language. You'll suddenly find yourself stuck on something, and that'll make you start some research on that, and so you'll be accumulating experience and confidence in the language. Even if you know nothing, with just knowing how to install it and run it, you're good to gol.

Really looking forward to an answer to this one. Specifically for people who have very little coding background at all. A lot of books etc for Go seem to focus on people learning Go as a second language rather than complete beginner if anyone has anything to recommend for that?

The most common answer is to use net/http directly and that frameworks are not necessary.

I have a bit of a spin on that. net/http is what a lot of other languages would call a "minimal framework". It defines how a web request comes in and how it is handled, but does not on its own do much more than that. But it does it in a fairly standard way across the Go ecosystem. As a result, the things we typically call "frameworks" in the Go ecosystem like gin or echo aren't really themselves free-standing frameworks. They plug in to net/http themselves and extend and augment it, rather than replace it. The community commonly says that the best framework is "no framework", but I would say net/http already is one. It's just "minimal" rather than fully featured, which in the web framework world is a category of framework. (For instance, web.py is a Python example.)

As a result, they can be mixed and matched, and it is possible to create middleware that works with almost all the Go web frameworks by writing to the net/http.Handler interface.

My advice is, budget a week to spend on net/http directly. It is a good idea to get a feel for what it does itself and how to utilitize it to write some simple stuff. You may find it is all you need; in the case of an API-driven website without strong pre-existing URL structure requirements this is actually reasonably likely. In those cases you may just mix in a couple of individual components (a popular source for high-quality implementations of these is the gorilla project) and call it a day.

But if it is not enough, at this point you will have enough information to evaluate the Go framework landscape and come to your own conclusions.

One word of warning. There is a somewhat popular framework called fasthttp. There is nothing wrong with this project, but it is kind enough to have a note at the very top of its README about how this framework may not be for you. I advise you to read it and take it to heart. fasthttp does what it does by completely reimplementing a web server unconnected to net/http, which means you will be locked into its smaller ecosystem rather than the greater net/http-compatible ecosystem. Many programmers make the mistake of looking out across their options and evaluating their choices on one singular metric: performance. They just blindly choose the fastest. Go web frameworks are not a good place to do this. You may have been bitten in the past by slow frameworks in dynamically-typed scripting languages, or you may just not be thinking about your real requirements, so this may appeal. But Go is fairly fast and net/http is fairly high-performance; used like a static file server net/http can reach about half the speed of nginx on its own. That's actually really, really fast already. Or to put it another way, net/http can crunch through many, many thousands of requests per second on the very smallest VMs you can get and still have time for you to do useful work. Be sure you have a task where that is going to be your bottleneck. In many cases it literally can't be your bottleneck because the work your web pages are going to do is already the bottleneck. You should only take fasthttp if you are looking at something that will be serving literally hundreds of thousands of very small requests per second, and even then I'd benchmark my options. But if you do have that need, fasthttp can be a lifesaver.

I'd suggest doing adventofcode.com in Go. They are great coding challenges for just about any skill level and will push your learning.

I also learned quite a bit by doing a few of the projects on codecrafters.io, where you build a rudimentary BitTorrent client, DNS server, SQL server, etc. These were interesting because they not only help you practice and improve your coding skills, but they teach you about real-world technologies in the process.

Finally, I'd recommend https://quii.gitbook.io/learn-go-with-tests. It may go over some material you already know, but using a test-driven development (TDD) process. If you haven't tried building projects with TDD, you may be in for a pleasant surprise. It's changed the way I work on my projects.

Start by making simple projects like terminal calculator, then learn how to make a rest api and so on...

My suggestion for this is a networked chat server.

Start with a server that opens a local listening port that two clients can connect to, and then those clients can send network messages to each other and display them on the other side.

The reasons I like this idea is that A: you immediately play into Go's networking strengths and B: from here you have an almost bewildering array of directions to go to continue to elaborate on your chat app, including but not limited to:

1. A concept of users so you can have people chatting directly with each other by name. Or channels where people can chat with nicknames like IRC.

2. Use a TUI or a GUI library to display the chat rather than dumping to screen.

3. Get on to the web; you can do anything from a Web 1.0 "refresh every five seconds" to server-sent events to a full websocket. Get into authentication and authorization on the web. Split things into distinct API versus web interface. Handle inlining images like Slack does.

4. Integrate with a database; log messages, store user information for login, store permissions, store history for channels, all sorts of things. Use GORM, use SQL, use Bolt, use anything you like.

5. Learn about TLS encryption and use TLS for either your web interface or your line protocol.

6. You'll pretty much have to learn about goroutines to work on this properly, but there's a lot of opportunity to use them beyond the bare bones. For example, you can write some sort of "bot" that sits in a (chat) channel and responds to inputs as its own entity.

7. Learn about strong testing practices by testing this stuff out. See if you can apply fuzz testing to your protocol.

8. Learn to break your code into a set of independent packages and develop a non-trivial layout.

9. Several cloud technologies could be used here, just for the sake of using them:

• Hosted DBs

• S3 or equivalent for file sharing

• Any of the various event busses for communication with the client/server

• Serverless/EC2/containers/all sorts of things for the deployment of servers or clients

• Almost anything can be used if it strikes your fancy through some sort of bot

And that's not even a complete list. What I like about this idea is that it starts out at just a couple page's worth of code, but then it expands out into almost arbitrary directions, and at the same time with only a bit of discipline, it is something you can show off at almost any point, starting from those very first two pages of code all the way to your home-made Slack clone. Just tag your functioning code as you go and you'll always have working code to show.

(Just about the only thing I would not recommend is, don't try to write this to be multi-server unless you already know what you're doing with that. You're going to have a very difficult time extending the load to the point that you would actually test that with this project.)

I typically learn a new programming language by building real-world projects too.

I've been publishing them here: https://codingchallenges.fyi/challenges/intro/ hopefully one or two are of interest/useful.

What kind of project will you be working on? I guess it's some kind of Web API (?)

In my case, I start by myself. But when I got started, I made a good research on project structures. So far, I've got a predefine project layout, which goes like this:

/components  
    /ui  
    /layout  
    /pages  
/database // (x) Unnecessary package since only main.go depends on it  
/docs  
/failure  
/handlers  
/mock  
/model  
/repositories  
/services  
/transfer  
/types  
README.md  
main.go  
middleware.go  
db.go  
pool.go // (x) These instantiations will go in main.go  
routes.go // (x) Routes will go in main.go

This is from a project that I'm just planning. It's a fullstack website that'll use an API and templ for rendering views.

The handlers package is like the controllers, from C#. The failure package is just for application errors. The transfer package is for my Data Transfer Objects (DTOs).

Here's another example: https://github.com/fontseca/noda

you kinda freestyle it, the project layout will take it shape the more you work at it, atleast thats the way i do it

Though it's good (depends on your taste), a core dev of the golang team posted an issue regarding how its inaccuracy.

But don't worry, Melkey created a cli tool for this exact problem for golang beginners (like me).

https://github.com/Melkeydev/go-blueprint

Think of it like the create-react-app or create t3-app but for golanng.

Here's a run through of the cli https://www.youtube.com/watch?v=1ZbQS6pOlSQ

In my experience as well, the golang-standards/project-layout stumped my progress more than it helped me because there were lots of patterns that I felt was conflicting with most big project examples that I tried to study and applying DDD, hexagonal architecture, and other architectural patterns felt confusing.

Hope this helps <3

I've seen this question asked a lot of times on this reddit (and I'm going to begin taking a stronger stance on directing those questions to this thread), but my generic answer, based on the conversations both here and in other language communities is, we can't really tell you. There are so many things that go into deciding to contribute to a particular project that there's just no reasonable condensation of that decision procedure.

I also am not convinced that trying to contribute to open source projects is a great way to learn (generally contributing involves you somehow using some knowledge or skill you have, it's not really an acquisition event on its own), nor do I feel like very many of the people who ask this question follow through anyhow.

What are you interested in?

I bought the first one you mentioned. I did about 1/3 of it, and I personally felt like I needed a more intro level course. He does a great job of explaining, and if you have questions he seems to reply rather quickly.

https://www.udemy.com/course/go-golang-develop-modern-fast-secure-web-applications/

What about this one?

last one is available for free on YouTube as well

The advice to use stdlib as much as possible and avoid frameworks isn't just dogma. IMO it's more about where the advantages and unique aspects of the language align. PHP has amazing frameworks for building full web apps. If you need that, and thus a framework becomes massively helpful, then the app might just be more appropriately built in PHP.

The advice to only use stdlib is also sometimes a bit of dogma. Specific routing requirements require using libraries at least and once you're doing that some features of some of the frameworks become sensible. Just do your homework on the actual tradeoffs.

I'm curious, what resources did you pick?

You might as well just try it out. You can come to your own opinion faster than you can get opinions online. I mean, I understand asking about for-pay courses in advance, but if it's just YouTube videos, go for it. It's not like you get a failing grade if you stop after an hour.

For Java developer, you should aware, this languages isn't 100% OOP you shouldn't create code as like in Java e.g. struct isn't equivalent of classes. You shouldn't create AbstractFactoryOfSomething.java or another builder, try to build as simple as possible architecture for you app without heavy architecture patterns. I don't mean Factory pattern or Singleton or Stragery are bad. Definitely NO. It's perfectly ok, but you create only when you need.

Code style(in standard library and third-part libraries) isn't the same as like Java e.g. in Go code isn't prefer using descriptive variables e.g. in java you can name some context: "networkingContext" but we Go we prefer using shorten names or single word variable e.g. context or ctx(shortcuts or single char variables is ok too). Read more about naming variables, package, or functions you can read this: https://go.dev/doc/effective_go#names

Structure in project is different between Java and Go. You haven't to create src/com/your.name/program/mongodb....., but in Go we prefer a simple structure e.g. db or mongodb. You can read more about project structure in Go here:

- https://go.dev/doc/modules/layout

- or you can use domain names for packages as like AnothoyGG https://www.youtube.com/watch?v=dJIUxvfSg6A (for me, it was very helpful to understand how can I think about project structure in Go)

And the last words from me about differences between Java and Go. Trust this language. Don't try using some patterns or structures from Java in Go. You can build some simple and beautiful function without Stream<T>, mapper or building apps with magical annotation. You don't need try...catch statement to handle errors, you have simple error interface. The true power in Go is the simplicity.

I did this ,it's great

The standard library.

Medium sized projects:

• https://github.com/perkeep/perkeep

• https://github.com/tailscale/tailscale

• https://github.com/upspin/upspin

• https://github.com/golang/website

• https://github.com/golang/pkgsite

• https://github.com/mjl-/mox

• https://github.com/robpike/ivy

An educational project https://github.com/benbjohnson/wtf

There are interesting discussions in https://github.com/benbjohnson/wtf/discussions and

No async/await. Look into Goroutines and Channels.

• https://gobyexample.com/goroutines

• https://gobyexample.com/channels

But not before doing the Tour of Go, it also covers it in the concurrency chapter.

That's pretty neat

It doesn't, something is wrong. Please make a new top -level post to the group, but read the "How to Ask Good Technical Questions" linked in the New page first, because you don't have anywhere near enough to help you.

Cloud services, web services, CLIs. You don't use golang for data transforming stuff as it is not popular in that realm.

Have you looked into https://tinygo.org/ ?

The standard library has what you'd need for that.

For multiprocessing, when I was doing this, I generally had a setup like this for cases where I was processing row-by-row:

1. One goroutine wraps a bufio.Scanner around the io.Reader input, and gathers up a chunk of lines, maybe about a thousand.

2. Those lines are sent over a channel to a worker. Several workers are spawned to read on that channel. They each JSON parse the line and do... whatever it is they're going to do. Then they JSON marshal the new line into a new []byte and store them all up, to send them down to...

3. A goroutine responsible for writing incoming lines to the new file or target location.

Variations on that theme can take summary statistics from a lot of lines and then combine them in the final goroutine, etc.

It's a good exercise to set that up, and then once you do the skeleton is useful for a lot of things where you can stream vast quantities of JSON through a single OS process that Python would not be able to handle.

encoding/json in the standard library is also not the fastest parser and you can get some further speed gains by using some of the faster libraries, but those come with tradeoffs of their own. Not terrible ones, but the really fast ones do require a bit more work. Start with encoding/json and if it's already fast enough there's no reason not to stick with it.

Separation of Concerns. If smth is wrong, you should check on your log for "ERROR:"-s.

Consistency.

Reusability of the code. The classic of programming.

Flexibility. DIY etc. You can flex your logger for your needs.

Efficiency. log.New is optimized.

EDT

If you use a third-party logger, there is a high chance that it has a lot of stuff that you don't need.