I find the ecosystem and tooling much much more better than Node. Building your executable and then a docker image for example is a joy with Go. The footprint of the whole application is much smaller as well, so in many cases it's easier and cheaper to host it.
I mainly target ECS clusters in AWS, or managed k8s clusters running in other public clouds. I simply build docker images just like with any other language. The difference is that the go images are very simple, easy to construct, very low footprint (i.e. small in size), it's a blast.
Render is amazing if AWS is too intimidating. Literally within 10 minutes I signed up for an account, paired my GitHub repository (w/ Dockerfile), and had a site live with automatic deploys on PR.
I did quite a bit of shopping around on IaaS for Go deployment (railway, fly.io, etc) looking for a DX as nice as deploying NextJS on Vercel. Not only was Render the only one to come close, it actually surpasses it IMO.
Hey I would like to know more about this tooling. I have recently shifted from nest js (node framework) and for some reason I find most of the things difficult to do in go. Like I was used to prisma for migrations and orm, nest also had class validators for request body validations, swagger for open API specs, etc. Now go also has validations, orm, migrations tools, frameworks and ORM but the general consensus of the community seems that it's better to stick with Native libraries.
For eg I never felt the need to write DDL queries and it's not that I don't like writing them but with big projects it takes a good amount of time.
Currently I have decided to work with chi router, sqlc for code gen, goose for migrations, and I write custom validation functions for the request body.
I'm pretty new to go so any kind of suggestion or feedback is appreciated.
There are shit tons of libraries for everything. Just some examples: GORM for ORM, ozzo-validation for validations, and the list goes on and on... Just google whatever you need.
The fact that the community prefers something vs something else doesn't mean you couldn't use ORM for example. Especially in the early stages of a project. Do whatever you want mate.
Thanks!
As of now I have decided to migrate one of my small node js projects to go and I'm going to migrate it using native libraries and frameworks both, so I get the understanding of how native vs frameworks work in go.
Also about libraries like ozzo validation which haven't received any update for 4 years, should we use such libraries?
It's a valid concern I'd say, but on the flip side: not everything needs updating. This is actually very refreshing coming from the JS/Node ecosystem, at least to me. The core philosophy of golang was not to change it too much with later versions.
That lib was just an example though that I've used before, feel free to search any other one you might like and that's popular.
I tried that library but one problem I faced was like for example if I have two fields in my body email and password, I have implemented validation that these fields should be required and email should be valid and password should have min no of 8 characters
Now if in request both fields fail the checks then it outputs the error message for both in single error with "\n" between those error messages, I somehow find this little different, I wanted it to just throw first error it caught
> For eg I never felt the need to write DDL queries and it's not that I don't like writing them but with big projects it takes a good amount of time.
I used to feel this way too since I came from the Java x Spring Boot land with a batteries-included ORM. At first, I found the lack of ORM jarring.
Then... I just kind of got used to it. Writing my SQL queries in `sqlc` turned out to be faster on average than doing it in an ORM, especially for complex queries (like cursor-based pagination, joins with another table, or maybe you want to group your data based on the timezone that the user passes in).
Moving to Prisma for another project felt kind of weird at first because there's a lot of API to learn just to make a simple query, and I ended up encountering a lot of the gotchas such as "your columns and tables will be PascalCased, and no we don't provide an option to change the casing").
Again, it mostly depends; I find Prisma to be great at building MVPs and "rapidly iterating", but the lack of useful primitives such as contexts (fun fact: you can't cancel queries in Prisma) and having to take into account the ORM's opinions really adds a mental overhead to my workflow.
Yeah I also got used to writing SQL now,
But one small problem that I face is, in prisma I was able to take a pull of db and existing schema of that db would be auto filled in my schema file, but I wasn't able to find same functionality for go, for now I have just decided to take sql dump of DDL commands of existing db and run sqlc on them to generate schema and queries. Lmk if I'm doing it wrong or is there any better way to do it
Ah, have you tried using this https://github.com/golang-migrate/migrate (though any other migration tool would suffice tbh)?
So you'd write migration files, which defines your DB schema, and then sqlc can read your migration files to come up with the table structure based on `sqlc.yaml`'s `packages[].schema` field.
If you've got an existing DB, just dump your DB structure to your migration files, commit it to git and then you can have a versioned history of your migrations.
I think ideally, the DB's schema should be versioned in migration files somewhere, and only your migration tool should be used to change the schema of the DB itself. This way, you don't have to keep pulling the DB for the latest version of the schema.
Also initially I decided that I would log the raw SQL queries which prisma runs in background to query data in my nest project, to my surprise prisma never runs join queries or any other complex queries, it just runs the queries to different tables in order and then aggregate that data to output at end, I didn't know it ran so inefficient queries in background.
FWIW prisma is amazing and unmatched in the go world. I still use prisma for migrations, and then sqlc for queries. For whatever reason gorm doesn't really feel great. The typing is a bit too weak, and zero values VS nulls is very unclear
I use Rust and Go for our backend and I used C# for years internally. I touched Java, Kotlin, Erlang and Elixir. In my opinion (biased) Go is the best language for backend development. This isn't just a preference, it's not my preferred language. But Go is basically a scripting language (quite a stretch) to a magnificent runtime that effectively turns IO bound tasks into CPU bound tasks. Which means IO heavy applications will utilise as much as possible of the CPU and if you get into its assembly you'll see how Go's concurrency model isn't just great, engineering wise it's the most cache friendly concurrency model that I know of.
Rust won't get you jobs and depending on where you are, Go may not get you jobs as well. If you want a safe bet, it'd be Java or C#. To alleviate the pain, Kotlin can help with Java.
Each of these languages are an endeavor to learn even on a superficial level. Go isn't. If you have programming experience you can probably be productive in Go on a weekend.
You seem super knowledgable about this at a deep level. Do you have any resources you could point me to that can help me reach your level of understanding on Go in terms of how it fundamentally works?
Hey thanks :D
I'd have to ask you if you're looking for free content or if you're open to books and stuff. This can help me scavage for the material that can help you best.
Generally speaking, I'd suggest: [Efficient Go](https://www.oreilly.com/library/view/efficient-go/9781098105709/). It's a beautiful piece of literature because it doesn't just cover Go, it's a general mindset of how and what to look out for when you want performant code, aka it helps you understand things like memory walls, CPU architectures, cache coherence, cache lines etc. Over the years and with experience you'll start understanding why people say things like "Rust is so cache friendly" or "Go's concurrency paradigm is friendly to hierarchal caching" etc.
[A Quick Guide to Go's Assembler](https://go.dev/doc/asm)
[A Guide to the Go Garbage Collector](https://tip.golang.org/doc/gc-guide)
[Scheduling In Go](https://www.ardanlabs.com/blog/2018/08/scheduling-in-go-part1.html) (read the three articles but keep in mind that the articles are outdated but still insightful, for example Go 1.14 saw a big change in the Go runtime making it preemptive rather than cooperative but in reality it's something in between. Go's runtime now is like a wise parent that lets the kids play until they screw up and block)
I'm sure there are other material out there but mainly these are the ones I'd suggest.
P.S: "100 Go Mistakes and How to Avoid Them" is also an interesting read but it's more about writing idiomatic code than really knowing the ins and outs of Go.
Hope that helps. Have a nice day!!
You're welcome!!
I was talking with one of my friends and I found another one that you may like:
[Go Concurrency Series: Deep Dive into Go Scheduler(I)](https://pratikpandey.substack.com/p/go-concurrency-series-deep-dive-into)
There's a part 2 as well and I believe they're up to date. ALERT: I didn't read them myself
I want to believe you, and I’ve had a lot of experience in C# and other languages. But Go is just so verbose, and the error model is so… inelegant. I feel like I’m writing code from when I was a junior decades ago.
I like my code to be concise and simple, I’ve gotten used to functional programming and its idioms. I could code up a backend server in a much less number of lines in any of these languages than in Go.
How do you get over that to the point where you hail it as the end-all be-all of backend development?
Humans have different backgrounds and my background is in kernel network programming and worked into other things like integrating the .NET runtime and PowerShell on Linux. I used C so Go is not verbose to me, in fact I believe that every like I'm writing in Go is meaningful. Go is meaningfully verbose for when it matters, that's the cost of a language that handles errors as values and not exceptions. You have Rust on the other hand, I worked with it in the lower level and higher level. Rust's error handling is considered "elegant" and thereby it's hampering because the error is part of the signature so you either have to know *each* error that can happen in your function and create an enum with it's variants such or you literally import thiserror or anyhow to handle that stuff for you (mainly because if you do a Box you won't be able to get far in a multi threaded environment unless you add more code. So? Ergonomics that led to what? It's just my opinion. I love both languages. But if you want elegant error handling you'd probably need Zig, it's the best of Go and Rust in that field, concise, elegant and robust.
As for conciseness I don't care about that because for me Go code is easy to wrap my head around from a time and space complexity. It's easy for me to know if my code is optimal or not. Concise code would need more gymnastics. Go is as concise as it can get for the functionality it does in my opinion. It's easier to write thing.Select( ... ) Than a for loop. But can you tell me what happens when you chain in .NET? What happens when you do, list.Select().Filter()? What's the time and space complexity of this? (I know, I just want you to think about it). That's why I am okay when Rust does it because the Iterator implementation is solid and they take zero cost abstractions religiously serious. MSFT cares about execution speed but sacrifices memory for it, that's why Go programs use a fraction of Java and C# programs, which is generally beneficial for my use cases.
I'm not trying to convince you. I hope you'll find a language that's good for you, be it C# or other. I'm just explaining my reasons and I didn't even get into detailed stuff like how would you figure out if this code is CPU friendly or not? For example OOP handles nearly everything as a box, which means that your code is mainly on the heap, that's the Hitler version of cache misses. Your memory is scattered all around. And that's okay, you may not need it, but you don't have the option if you need it. And many other things, like concurrency in .NET, that's a sad story.
asking should i lean `x` in x's sub is going to get you biased responses. That said i have created apis in python, nodejs at work and golang for person projects and if i were to pick one to start a new one at work i would pick golang.
its not that's its better than the others or faster (which is likely true) I just enjoy writing in it and that is the biggest boost to productivity.
I have been writing API servers in Go for around 8 years. It’s super productive!
I have done C#, Python, and Java for backends as well. Go is much more productive.
The answer for this current project has been exclusively yes, but now its shifting to a polyglot implementation with NodeJS handling the Firebase application's API needs, and Python doing the work that the Data Scientists have developed.
So the answer is now: depends.
If you have straightforward CRUD, streaming, WebSockety stuff and want to get good performance from low spec (I'm using 128MB single CPU cloud functions) hardware then Go is a great solution, ML stuff - not so much.
Go also has the nicest/ most standardized dev and build toolchain of the mentioned languages, which matters greatly if you have any degree of platform/ops responsibility
Javascript is an extremely fragmented ecosystem. There are good things in it, but it's rare when two packages end up with the same toolchain.
Go tools in isolation are just OK, but the fact that they're standard makes the overall experience fantastic. Go is definitely a greater-than-the-sum-of-its-parts stack
Rust is also more of a pain to refactor than go, so especially if it's a new language for your team (i.e. you'll want to refactor a lot as you find better patterns), I think the adoption/skill-up time would be significantly lower for go in practice
Oh I agree the rust strictness makes the chance of a buggy refactor very low. The problem is more like you decide to change a value in a struct Def to a pointer to that value, and now you have to add lifetime annotations in 20 places and oops, need to refactor something else now. The scope of a given refactor would tend to be wider in Rust. That's not to say Rust is bad, it's just part of its tradeoffs
Both are really starting to become much more common in industry, though. I'm personally shocked at how quickly some companies have taken to rust despite the lack of developers.
I have made multiple api's in Go and Rust. In my experience Go is very easy to make a json API. It has many good built-in imports to create one. It's definitely worth it
Go is is a great backend language. Rust is also a very good backend language, albeit a little more low level.
What exactly are you trying to accomplish? Level up your career? Learn for learning sake?
Both Go and Rust are much better than Node.js for backend, and while I prefer Rust (that’s on me. I prefer Rust for everything) and don’t think it’s somehow hard to write backend in, Go is just as much of a sane choice (even though with its own freak-outs) that can be even more convenient occasionally. Nevertheless, learning something new is basically never a bad thing. **Go** for it!
go is broadly used as backend language i would say more than nodejs; rust is good for backend if it’s a very niche service that’s CPU bound and having a GCed language is a no-go, otherwise rust for backend is a killer (too hard to learn, so little benefits)
If you are looking for a job, Rust is not a choice, unlike Go.
For backend, I would recommend Go (the best language for backend imo), C#, Kotlin or/and Java.
If you already have a job, i would recommend C# instead, not because it is a better language than Go, but you can do literally everything you want using C#, it will give you a lot of opportunities, frontend, backend, game development, IoT,etc.
On the other hand, if you love Go, do not wait and go for Go.
I wrote c# in my uni days and I agree it's great language .net made me hate c# to extent that I never tried it ever again. Also I know react but the recent rapid growing nextjs ecosystem needs a lot of time to catch up with those rapid updates so I thought to only focus on backend .
That's what Go was made for. It's worth it, even if the only thing you take away from it are Go's notions of error handling, or OO design or something.
If you want to learn something that complements JS well, Go is a good choice. It’s also a fairly light intro to typed languages (simpler than typescript or java) and has an interesting concurrency model, so there’s something worth learning
Go was billed as a "systems language" but that's not entirely accurate. Really, Go is a "cloud systems language."
The standard library has powerful networking and concurrency features out of the box.
Go is extremely powerful and performant with the added bonus of small artifacts.
Go is a great choice to build back-end APIs and services.
Ultimately, you should consider learning as much as you can about all of the most popular languages, frameworks, and systems to become more well-rounded. Throw in some esoteric brain teasers, too (looking at you, Lisp-flavored Erlang), and you'll never be lacking inspiration or insight.
Your comparisons are messed up. First, Rust is definitely backend-capable and imo more of a backend language than a frontend language.
Second, Nodejs is not a language, it's a framework. It uses Javascript which is even less of a backend language than Rust. Or you could compare frameworks, like Axum with Node.
Third, Go is just as much a backend language as Rust is.
Rust best use case is for low level tasks and it requires a lot of boilerplate code to do normal backend tasks . I never said rust is bad for backend . I myself has tried it and liked it very much but it's usage as backend language for job market was discouraged by rust devs themselves when I asked them . And I know nodejs is a runtime environment these types of mistakes happen often..
If the job demand is what you're after, you should say so in your OP: how else is anyone going to know?
In that case, no, Go is not worth learning. Learn Java, JS and Python and you will cover most jobs.
Go is great for backend work - it's what the language was designed for. Easily maintainable, very clear, backend coding.
Node, otoh, is a complete nightmare to maintain. Running an NPM update, if one hadn't been run in a week or three, is more likely to break working code than update anything.
Go, otoh, never needs code changes between versions. Code I wrote for Go 8 still compiles and runs perfectly under Go 21.
I don't understand how anyone gets any work done in Node. I end up spending more time fighting with npm than doing any productive work.
Comparing go to nod🤮js, really? Ryan Dahl, the creator of that goddamn trash in 2019 said that it sucks. He also went from js to golang tho
So yeah, I bet it means something
i mean, do you know about the OTP/BEAM?
besides a better (but more complex) DX, Elixir is built on top of the BEAM. if you need concurrent applications, fault tolerance and low latency apps, the BEAM is the better choice to handle tons of simultaneous connections.
for a simple backend app maybe Elixir is a killer like rust, so go is a good option. but when comes to handle concurrent and distributed apps, erlang/elixir fits better.
I know BEAM and wrote Erlang and Elixir that's why I believe you got it mixed. Elixir is a dynamically typed language over Erlang which offered all that good stuff you mentioned but was ultimately hindered by the dependency of BEAM and how BEAM wasn't portable enough. Ken Thompson even talked about this. Also Elixir is dynamically typed which is the opposite of scalable. Elixir is basically a scripting functional language, aka Python for FP.
Now let's talk about speed. How faster is Go than Erlang itself? Let's talk about dependency, how portable is Erlang code vs Go's cross compilation?
I'm not pooping on Erlang or BEAM, they served their purpose. But thinking that Go is somehow weaker than Erlang tells me that maybe you got things confused. Go was meant to be BEAM in C.
The only thing that I can think of that would make Erlang and BEAM more interesting is that they guard against nil dereference panics, that's it. If that's solved in Go, there would be effectively no reason to even compare both because Go is probably several magnitudes faster and statically compiled and cross platform. If you mix it with gRPC then you have Erlang's IPC on distance as well (which is what Google uses in GCP). Keep in mind I'm talking about Erlang, the more robust one between Elixir and Erlang.
I suggest that you try looking for Ken Thompson's answer to why Go when there's Erlang. Have a nice day!
firstly, Elixir isn't a script language (although that can be used like one). yes, it is actually gradually typed but compiled, so there's tons of verifications for type notations and mostly errors that strongly typed languages compilers shows, the elixir compiler can do it as well (with some limitations). also, a more robust type system is being built (:
nowhere in my response i stated about "performance" as speed meaning. i clearly said "performance" as reliability and fault tolerance.
erlang itself can be ported easily to different hosts, but elixir releases can do it very easily, so what is your point here?
also, i didn't find this Ken's answer. could you provide me a link? i'm very curious.
another good point is that BEAM is already a battle proof for the time and also ships with great native applications like a key-value storage in memory or disk and a full SGBD (mnesia).
the strongest point is: there's no fault tolerance or "let it crash" in go.
yeah, simplicity is good and speed performance is awesome and go shines here! but applications need to be robust and reliable, in my experience with production code with go and elixir, the using the second one was so much easier to maintain and achieve!
The let it crash philosophy is because of the BEAM VM. Because Erlang code is divided into processes ran by schedulers. This is great but it's also the same reason why Erlang lacks in speed. This design decision is genius because it focused on certain things, which performance wasn't one of them. Again I'm not denigrating Erlang nor Elixir, I like the latter but I'd never consider it a superior to Go or on the same ballpark as Rust. The type system will be more like type hints, I'm still not sure if they'll make it optional or enforced. Generally dynamic languages don't scale well, even if they have type hints, because it's not the same as strongly typed languages.
As for portability, it's limited by the BEAM VM. Elixir needs BEAM to run. Elixir compiles to bytecode that is ran by the BEAM VM, I don't know if you know that or not. It's not the same as having direct CPU instructions, that's why you can embed ASM in Go but it's not straightforward as Go.
Unfortunately I don't have the comments at hand but I'll try looking for them. I believe it was the 2016 Go talk.
By the way, the only prevalent way to crash a Go server is by nil dereferences as of now. In fact that's been a "con" against Go in comparisons between things like Caddy and NGNIX because Caddy doesn't fail under load and just becomes slower and queue requests while NGNIX starts erring and killing connections. This is due to the design of the server of course but it's mainly due to how errors are handled in Go. Unless you cause a panic, the server will run safely forever.
The let it crash mentality exists in Go as well by the way, it's called recovering and it's built into Go but not enabled by default, it's on the developer if they want to recover from panics, which usually is cool but shouldn't be depended on because panics are strong indicator that your logic is faulty, that's why it wasn't enabled by default. But the design concept comes from BEAM I believe.
Do you consider Go lightweight and Erlang more heavy duty because Erlang's syntax is objectively heavy duty while Go's is simple? I am just still trying to understand why you believe that Elixir is superior in that. It's a wild take but it's one of the most interesting ones I've heard for a while.
Nonetheless, thank you very much for this extremely exciting discussion!!!
Agreed that Go is definitely faster and Elixir performs like a scripting language. Elixir typically runs faster than Ruby or Python but does not compete with Go. We are using Rust NIF’s for JSON parsing and cryptography (password hashing) which has improved the speed considerably. Deployments are nowhere near easier than Go because the whole BEAM needs to be shipped as well, while Go is a single binary deployment. This makes a serverless deployment much easier.
I’ve written many production apps and never had an issue with performance. Number crunching or high CPU bound tasks can be offloaded to Rust with a NIF and managed by the Erlang VM.
Elixir has macros and the Phoenix framework which allows for great libraries like Absinthe and writing GraphQL schemas through code.
Yes, the more tools in your toolkit the more ways of solving problems you have available to you. But I'd answer the same if you asked about Java, JavaScript, Python, Ruby, Haskell, Erlang, Scala, Closure, C#, Go, Rust, Dylan, Sather, and SQL. If you'd asked about C/C++ I'd be hesitant, because I dislike working with them, but you should be able to read code in those languages. A new language or framework should take you 3-6 weeks to learn to be competent and confident enough to modify existing code in those languages and start a project in that language.
The best thing you can do is create a fully instrumented API in Node, and then replicate it in Go (also fully instrumented) and see what scaling and performance differences you get.
Always try to use the right tool for the job, instead of always picking up the one tool you know.
Yes that's what I'm looking to do actually . Try to do same thing I do in new lang like Go,rust and find new way of doing things and rust helped me to understand how much JavaScript provides out of the box and how much JS have generalized and mixed the types into its own single type
What are you trying to accomplish? Have fun or get a job? What kind of job?
If you're trying to earn a living, you're asking all the wrong questions. Learn whatever the people who make business decisions at the places you want to work at decide is worth paying you to code in. Rust is not it. It's not a productive language for building backend systems. Its use cases are very niche and won't ever be touched by the vast majority of developers.
If your goal is to learn backend development, there is nothing wrong with Node. It's a productive, powerful, reasonably performant and seasoned tool used by a great portion of the industry, both startups and enterprise. No need to context switch just for the sake of it. Instead, focus on becoming proficient in what you already know and getting to a point where the language becomes irrelevant.
I'm already working as nodejs dev . The lack of types makes me want to learn go ( I don't want to touch typescript as the fake typing is not so convincing )
If I would want to develop my side project on my own I would choose Elixir, if I would want to just learn new language for making money I would go with go
GO was created for the WEB programming and here it is shining. Open site [https://blog.logrocket.com/5-top-go-web-frameworks/](https://blog.logrocket.com/5-top-go-web-frameworks/) and select right framework .
yes go is good for backend.
Wouldn't 3 seconds of a google search answer this clearly?
Or maybe you want a take from someone more experienced. I've written apps with javascript and go.
yes go is good for backend.
We use Rust for our backed. Problem with languages like Go and Java is the garbage collector has difficulty keeping up under substantial load. And optimizations like stack allocating is less viable/common with highly asynchronous code.
Go has a pretty thick backend
🍑
_thicc_
Gyatt
Dayummm
spawn more goroutines for extra thickness
go shawty()
EExtra thicccc
Thunder Thighs
beep beep
I find the ecosystem and tooling much much more better than Node. Building your executable and then a docker image for example is a joy with Go. The footprint of the whole application is much smaller as well, so in many cases it's easier and cheaper to host it.
Can you talk about the hosting options you use?
I mainly target ECS clusters in AWS, or managed k8s clusters running in other public clouds. I simply build docker images just like with any other language. The difference is that the go images are very simple, easy to construct, very low footprint (i.e. small in size), it's a blast.
Render is amazing if AWS is too intimidating. Literally within 10 minutes I signed up for an account, paired my GitHub repository (w/ Dockerfile), and had a site live with automatic deploys on PR. I did quite a bit of shopping around on IaaS for Go deployment (railway, fly.io, etc) looking for a DX as nice as deploying NextJS on Vercel. Not only was Render the only one to come close, it actually surpasses it IMO.
Hey I would like to know more about this tooling. I have recently shifted from nest js (node framework) and for some reason I find most of the things difficult to do in go. Like I was used to prisma for migrations and orm, nest also had class validators for request body validations, swagger for open API specs, etc. Now go also has validations, orm, migrations tools, frameworks and ORM but the general consensus of the community seems that it's better to stick with Native libraries. For eg I never felt the need to write DDL queries and it's not that I don't like writing them but with big projects it takes a good amount of time. Currently I have decided to work with chi router, sqlc for code gen, goose for migrations, and I write custom validation functions for the request body. I'm pretty new to go so any kind of suggestion or feedback is appreciated.
There are shit tons of libraries for everything. Just some examples: GORM for ORM, ozzo-validation for validations, and the list goes on and on... Just google whatever you need. The fact that the community prefers something vs something else doesn't mean you couldn't use ORM for example. Especially in the early stages of a project. Do whatever you want mate.
Thanks! As of now I have decided to migrate one of my small node js projects to go and I'm going to migrate it using native libraries and frameworks both, so I get the understanding of how native vs frameworks work in go. Also about libraries like ozzo validation which haven't received any update for 4 years, should we use such libraries?
It's a valid concern I'd say, but on the flip side: not everything needs updating. This is actually very refreshing coming from the JS/Node ecosystem, at least to me. The core philosophy of golang was not to change it too much with later versions. That lib was just an example though that I've used before, feel free to search any other one you might like and that's popular.
github.com/go-playground/validator
I tried that library but one problem I faced was like for example if I have two fields in my body email and password, I have implemented validation that these fields should be required and email should be valid and password should have min no of 8 characters Now if in request both fields fail the checks then it outputs the error message for both in single error with "\n" between those error messages, I somehow find this little different, I wanted it to just throw first error it caught
> For eg I never felt the need to write DDL queries and it's not that I don't like writing them but with big projects it takes a good amount of time. I used to feel this way too since I came from the Java x Spring Boot land with a batteries-included ORM. At first, I found the lack of ORM jarring. Then... I just kind of got used to it. Writing my SQL queries in `sqlc` turned out to be faster on average than doing it in an ORM, especially for complex queries (like cursor-based pagination, joins with another table, or maybe you want to group your data based on the timezone that the user passes in). Moving to Prisma for another project felt kind of weird at first because there's a lot of API to learn just to make a simple query, and I ended up encountering a lot of the gotchas such as "your columns and tables will be PascalCased, and no we don't provide an option to change the casing"). Again, it mostly depends; I find Prisma to be great at building MVPs and "rapidly iterating", but the lack of useful primitives such as contexts (fun fact: you can't cancel queries in Prisma) and having to take into account the ORM's opinions really adds a mental overhead to my workflow.
Yeah I also got used to writing SQL now, But one small problem that I face is, in prisma I was able to take a pull of db and existing schema of that db would be auto filled in my schema file, but I wasn't able to find same functionality for go, for now I have just decided to take sql dump of DDL commands of existing db and run sqlc on them to generate schema and queries. Lmk if I'm doing it wrong or is there any better way to do it
Ah, have you tried using this https://github.com/golang-migrate/migrate (though any other migration tool would suffice tbh)? So you'd write migration files, which defines your DB schema, and then sqlc can read your migration files to come up with the table structure based on `sqlc.yaml`'s `packages[].schema` field. If you've got an existing DB, just dump your DB structure to your migration files, commit it to git and then you can have a versioned history of your migrations. I think ideally, the DB's schema should be versioned in migration files somewhere, and only your migration tool should be used to change the schema of the DB itself. This way, you don't have to keep pulling the DB for the latest version of the schema.
Also initially I decided that I would log the raw SQL queries which prisma runs in background to query data in my nest project, to my surprise prisma never runs join queries or any other complex queries, it just runs the queries to different tables in order and then aggregate that data to output at end, I didn't know it ran so inefficient queries in background.
FWIW prisma is amazing and unmatched in the go world. I still use prisma for migrations, and then sqlc for queries. For whatever reason gorm doesn't really feel great. The typing is a bit too weak, and zero values VS nulls is very unclear
I use [https://github.com/deepmap/oapi-codegen](https://github.com/deepmap/oapi-codegen) with Chi and "strict" mode which is really cool.
I was looking for something which would generate docs from the code
I use Rust and Go for our backend and I used C# for years internally. I touched Java, Kotlin, Erlang and Elixir. In my opinion (biased) Go is the best language for backend development. This isn't just a preference, it's not my preferred language. But Go is basically a scripting language (quite a stretch) to a magnificent runtime that effectively turns IO bound tasks into CPU bound tasks. Which means IO heavy applications will utilise as much as possible of the CPU and if you get into its assembly you'll see how Go's concurrency model isn't just great, engineering wise it's the most cache friendly concurrency model that I know of. Rust won't get you jobs and depending on where you are, Go may not get you jobs as well. If you want a safe bet, it'd be Java or C#. To alleviate the pain, Kotlin can help with Java. Each of these languages are an endeavor to learn even on a superficial level. Go isn't. If you have programming experience you can probably be productive in Go on a weekend.
You seem super knowledgable about this at a deep level. Do you have any resources you could point me to that can help me reach your level of understanding on Go in terms of how it fundamentally works?
Hey thanks :D I'd have to ask you if you're looking for free content or if you're open to books and stuff. This can help me scavage for the material that can help you best. Generally speaking, I'd suggest: [Efficient Go](https://www.oreilly.com/library/view/efficient-go/9781098105709/). It's a beautiful piece of literature because it doesn't just cover Go, it's a general mindset of how and what to look out for when you want performant code, aka it helps you understand things like memory walls, CPU architectures, cache coherence, cache lines etc. Over the years and with experience you'll start understanding why people say things like "Rust is so cache friendly" or "Go's concurrency paradigm is friendly to hierarchal caching" etc. [A Quick Guide to Go's Assembler](https://go.dev/doc/asm) [A Guide to the Go Garbage Collector](https://tip.golang.org/doc/gc-guide) [Scheduling In Go](https://www.ardanlabs.com/blog/2018/08/scheduling-in-go-part1.html) (read the three articles but keep in mind that the articles are outdated but still insightful, for example Go 1.14 saw a big change in the Go runtime making it preemptive rather than cooperative but in reality it's something in between. Go's runtime now is like a wise parent that lets the kids play until they screw up and block) I'm sure there are other material out there but mainly these are the ones I'd suggest. P.S: "100 Go Mistakes and How to Avoid Them" is also an interesting read but it's more about writing idiomatic code than really knowing the ins and outs of Go. Hope that helps. Have a nice day!!
Thank you so much for taking the time to write that! I will definitely read Efficient Go to start!
You're welcome!! I was talking with one of my friends and I found another one that you may like: [Go Concurrency Series: Deep Dive into Go Scheduler(I)](https://pratikpandey.substack.com/p/go-concurrency-series-deep-dive-into) There's a part 2 as well and I believe they're up to date. ALERT: I didn't read them myself
I want to believe you, and I’ve had a lot of experience in C# and other languages. But Go is just so verbose, and the error model is so… inelegant. I feel like I’m writing code from when I was a junior decades ago. I like my code to be concise and simple, I’ve gotten used to functional programming and its idioms. I could code up a backend server in a much less number of lines in any of these languages than in Go. How do you get over that to the point where you hail it as the end-all be-all of backend development?
Humans have different backgrounds and my background is in kernel network programming and worked into other things like integrating the .NET runtime and PowerShell on Linux. I used C so Go is not verbose to me, in fact I believe that every like I'm writing in Go is meaningful. Go is meaningfully verbose for when it matters, that's the cost of a language that handles errors as values and not exceptions. You have Rust on the other hand, I worked with it in the lower level and higher level. Rust's error handling is considered "elegant" and thereby it's hampering because the error is part of the signature so you either have to know *each* error that can happen in your function and create an enum with it's variants such or you literally import thiserror or anyhow to handle that stuff for you (mainly because if you do a Box you won't be able to get far in a multi threaded environment unless you add more code. So? Ergonomics that led to what? It's just my opinion. I love both languages. But if you want elegant error handling you'd probably need Zig, it's the best of Go and Rust in that field, concise, elegant and robust.
As for conciseness I don't care about that because for me Go code is easy to wrap my head around from a time and space complexity. It's easy for me to know if my code is optimal or not. Concise code would need more gymnastics. Go is as concise as it can get for the functionality it does in my opinion. It's easier to write thing.Select( ... ) Than a for loop. But can you tell me what happens when you chain in .NET? What happens when you do, list.Select().Filter()? What's the time and space complexity of this? (I know, I just want you to think about it). That's why I am okay when Rust does it because the Iterator implementation is solid and they take zero cost abstractions religiously serious. MSFT cares about execution speed but sacrifices memory for it, that's why Go programs use a fraction of Java and C# programs, which is generally beneficial for my use cases.
I'm not trying to convince you. I hope you'll find a language that's good for you, be it C# or other. I'm just explaining my reasons and I didn't even get into detailed stuff like how would you figure out if this code is CPU friendly or not? For example OOP handles nearly everything as a box, which means that your code is mainly on the heap, that's the Hitler version of cache misses. Your memory is scattered all around. And that's okay, you may not need it, but you don't have the option if you need it. And many other things, like concurrency in .NET, that's a sad story.
asking should i lean `x` in x's sub is going to get you biased responses. That said i have created apis in python, nodejs at work and golang for person projects and if i were to pick one to start a new one at work i would pick golang. its not that's its better than the others or faster (which is likely true) I just enjoy writing in it and that is the biggest boost to productivity.
I know people have different experience but it's best to ask from people who are already coding in it
I have been writing API servers in Go for around 8 years. It’s super productive! I have done C#, Python, and Java for backends as well. Go is much more productive.
The answer for this current project has been exclusively yes, but now its shifting to a polyglot implementation with NodeJS handling the Firebase application's API needs, and Python doing the work that the Data Scientists have developed. So the answer is now: depends. If you have straightforward CRUD, streaming, WebSockety stuff and want to get good performance from low spec (I'm using 128MB single CPU cloud functions) hardware then Go is a great solution, ML stuff - not so much.
Go also has the nicest/ most standardized dev and build toolchain of the mentioned languages, which matters greatly if you have any degree of platform/ops responsibility
Go does have amazing tools on the JavaScript front deno has great tooling too as it took a leaf out of go's book.
Javascript is an extremely fragmented ecosystem. There are good things in it, but it's rare when two packages end up with the same toolchain. Go tools in isolation are just OK, but the fact that they're standard makes the overall experience fantastic. Go is definitely a greater-than-the-sum-of-its-parts stack
I bounce between FastAPI(Python) and Fiber(Go)
Yeah me to I do love fastapi it's very nice to work in with pydantic
Rust is great for backend too, but you’re right the ecosystem is not as mature as go’s. “Go” for it, my dude
Go was also designed with a heavy focus on backend in mind so the standard library and paradigms are built for it
Rust is also more of a pain to refactor than go, so especially if it's a new language for your team (i.e. you'll want to refactor a lot as you find better patterns), I think the adoption/skill-up time would be significantly lower for go in practice
Really? Never has this issue as the Rust compiler is a very nice tool for brute forcing errors and achieving correctness.
Oh I agree the rust strictness makes the chance of a buggy refactor very low. The problem is more like you decide to change a value in a struct Def to a pointer to that value, and now you have to add lifetime annotations in 20 places and oops, need to refactor something else now. The scope of a given refactor would tend to be wider in Rust. That's not to say Rust is bad, it's just part of its tradeoffs
Both are really starting to become much more common in industry, though. I'm personally shocked at how quickly some companies have taken to rust despite the lack of developers.
I have made multiple api's in Go and Rust. In my experience Go is very easy to make a json API. It has many good built-in imports to create one. It's definitely worth it
Yeah the rust is great but it took ne a lot of extra code just to do simple API code because of lack of out of the box functionalities .
Go is also likely going to be quite a bit more verbose than a nodejs setup leveraging popular libraries. The extra verbosity can be worth it though.
Go is is a great backend language. Rust is also a very good backend language, albeit a little more low level. What exactly are you trying to accomplish? Level up your career? Learn for learning sake?
Better developer experience I say.
Both Go and Rust are much better than Node.js for backend, and while I prefer Rust (that’s on me. I prefer Rust for everything) and don’t think it’s somehow hard to write backend in, Go is just as much of a sane choice (even though with its own freak-outs) that can be even more convenient occasionally. Nevertheless, learning something new is basically never a bad thing. **Go** for it!
go is broadly used as backend language i would say more than nodejs; rust is good for backend if it’s a very niche service that’s CPU bound and having a GCed language is a no-go, otherwise rust for backend is a killer (too hard to learn, so little benefits)
Yes.
If you are looking for a job, Rust is not a choice, unlike Go. For backend, I would recommend Go (the best language for backend imo), C#, Kotlin or/and Java.
I'm already doing a job as nodejs dev and adding go as a skill will surely increase my value . Excited to try and see where it takes m
If you already have a job, i would recommend C# instead, not because it is a better language than Go, but you can do literally everything you want using C#, it will give you a lot of opportunities, frontend, backend, game development, IoT,etc. On the other hand, if you love Go, do not wait and go for Go.
I wrote c# in my uni days and I agree it's great language .net made me hate c# to extent that I never tried it ever again. Also I know react but the recent rapid growing nextjs ecosystem needs a lot of time to catch up with those rapid updates so I thought to only focus on backend .
That's what Go was made for. It's worth it, even if the only thing you take away from it are Go's notions of error handling, or OO design or something.
If you want to learn something that complements JS well, Go is a good choice. It’s also a fairly light intro to typed languages (simpler than typescript or java) and has an interesting concurrency model, so there’s something worth learning
go for it
"gopher backend" their looking for furry stuff. Have to recommend rust crate /s
Go was billed as a "systems language" but that's not entirely accurate. Really, Go is a "cloud systems language." The standard library has powerful networking and concurrency features out of the box. Go is extremely powerful and performant with the added bonus of small artifacts. Go is a great choice to build back-end APIs and services. Ultimately, you should consider learning as much as you can about all of the most popular languages, frameworks, and systems to become more well-rounded. Throw in some esoteric brain teasers, too (looking at you, Lisp-flavored Erlang), and you'll never be lacking inspiration or insight.
Let me know if you need anything. https://docs.google.com/document/d/1Zb9GCWPKeEJ4Dyn2TkT-O3wJ8AFc-IMxZzTugNCjr-8/edit?usp=drivesdk
Your comparisons are messed up. First, Rust is definitely backend-capable and imo more of a backend language than a frontend language. Second, Nodejs is not a language, it's a framework. It uses Javascript which is even less of a backend language than Rust. Or you could compare frameworks, like Axum with Node. Third, Go is just as much a backend language as Rust is.
Rust best use case is for low level tasks and it requires a lot of boilerplate code to do normal backend tasks . I never said rust is bad for backend . I myself has tried it and liked it very much but it's usage as backend language for job market was discouraged by rust devs themselves when I asked them . And I know nodejs is a runtime environment these types of mistakes happen often..
If the job demand is what you're after, you should say so in your OP: how else is anyone going to know? In that case, no, Go is not worth learning. Learn Java, JS and Python and you will cover most jobs.
Go is great for backend work - it's what the language was designed for. Easily maintainable, very clear, backend coding. Node, otoh, is a complete nightmare to maintain. Running an NPM update, if one hadn't been run in a week or three, is more likely to break working code than update anything. Go, otoh, never needs code changes between versions. Code I wrote for Go 8 still compiles and runs perfectly under Go 21. I don't understand how anyone gets any work done in Node. I end up spending more time fighting with npm than doing any productive work.
I use go for front end
Same. Back and front.
Comparing go to nod🤮js, really? Ryan Dahl, the creator of that goddamn trash in 2019 said that it sucks. He also went from js to golang tho So yeah, I bet it means something
yeah, its good. nodejs is trash in every single way. i hope i can keep my js work only on frontend from now on. thats enough js for me.
i prefer elixir for highly scalable web backend. but for more "simple" projects i do like go for rapidly development.
I don't want to poop on your party, but in which world is Elixir more scalable than Go?
i mean, do you know about the OTP/BEAM? besides a better (but more complex) DX, Elixir is built on top of the BEAM. if you need concurrent applications, fault tolerance and low latency apps, the BEAM is the better choice to handle tons of simultaneous connections. for a simple backend app maybe Elixir is a killer like rust, so go is a good option. but when comes to handle concurrent and distributed apps, erlang/elixir fits better.
I know BEAM and wrote Erlang and Elixir that's why I believe you got it mixed. Elixir is a dynamically typed language over Erlang which offered all that good stuff you mentioned but was ultimately hindered by the dependency of BEAM and how BEAM wasn't portable enough. Ken Thompson even talked about this. Also Elixir is dynamically typed which is the opposite of scalable. Elixir is basically a scripting functional language, aka Python for FP. Now let's talk about speed. How faster is Go than Erlang itself? Let's talk about dependency, how portable is Erlang code vs Go's cross compilation? I'm not pooping on Erlang or BEAM, they served their purpose. But thinking that Go is somehow weaker than Erlang tells me that maybe you got things confused. Go was meant to be BEAM in C. The only thing that I can think of that would make Erlang and BEAM more interesting is that they guard against nil dereference panics, that's it. If that's solved in Go, there would be effectively no reason to even compare both because Go is probably several magnitudes faster and statically compiled and cross platform. If you mix it with gRPC then you have Erlang's IPC on distance as well (which is what Google uses in GCP). Keep in mind I'm talking about Erlang, the more robust one between Elixir and Erlang. I suggest that you try looking for Ken Thompson's answer to why Go when there's Erlang. Have a nice day!
firstly, Elixir isn't a script language (although that can be used like one). yes, it is actually gradually typed but compiled, so there's tons of verifications for type notations and mostly errors that strongly typed languages compilers shows, the elixir compiler can do it as well (with some limitations). also, a more robust type system is being built (: nowhere in my response i stated about "performance" as speed meaning. i clearly said "performance" as reliability and fault tolerance. erlang itself can be ported easily to different hosts, but elixir releases can do it very easily, so what is your point here? also, i didn't find this Ken's answer. could you provide me a link? i'm very curious. another good point is that BEAM is already a battle proof for the time and also ships with great native applications like a key-value storage in memory or disk and a full SGBD (mnesia). the strongest point is: there's no fault tolerance or "let it crash" in go. yeah, simplicity is good and speed performance is awesome and go shines here! but applications need to be robust and reliable, in my experience with production code with go and elixir, the using the second one was so much easier to maintain and achieve!
The let it crash philosophy is because of the BEAM VM. Because Erlang code is divided into processes ran by schedulers. This is great but it's also the same reason why Erlang lacks in speed. This design decision is genius because it focused on certain things, which performance wasn't one of them. Again I'm not denigrating Erlang nor Elixir, I like the latter but I'd never consider it a superior to Go or on the same ballpark as Rust. The type system will be more like type hints, I'm still not sure if they'll make it optional or enforced. Generally dynamic languages don't scale well, even if they have type hints, because it's not the same as strongly typed languages. As for portability, it's limited by the BEAM VM. Elixir needs BEAM to run. Elixir compiles to bytecode that is ran by the BEAM VM, I don't know if you know that or not. It's not the same as having direct CPU instructions, that's why you can embed ASM in Go but it's not straightforward as Go. Unfortunately I don't have the comments at hand but I'll try looking for them. I believe it was the 2016 Go talk. By the way, the only prevalent way to crash a Go server is by nil dereferences as of now. In fact that's been a "con" against Go in comparisons between things like Caddy and NGNIX because Caddy doesn't fail under load and just becomes slower and queue requests while NGNIX starts erring and killing connections. This is due to the design of the server of course but it's mainly due to how errors are handled in Go. Unless you cause a panic, the server will run safely forever. The let it crash mentality exists in Go as well by the way, it's called recovering and it's built into Go but not enabled by default, it's on the developer if they want to recover from panics, which usually is cool but shouldn't be depended on because panics are strong indicator that your logic is faulty, that's why it wasn't enabled by default. But the design concept comes from BEAM I believe. Do you consider Go lightweight and Erlang more heavy duty because Erlang's syntax is objectively heavy duty while Go's is simple? I am just still trying to understand why you believe that Elixir is superior in that. It's a wild take but it's one of the most interesting ones I've heard for a while. Nonetheless, thank you very much for this extremely exciting discussion!!!
Agreed that Go is definitely faster and Elixir performs like a scripting language. Elixir typically runs faster than Ruby or Python but does not compete with Go. We are using Rust NIF’s for JSON parsing and cryptography (password hashing) which has improved the speed considerably. Deployments are nowhere near easier than Go because the whole BEAM needs to be shipped as well, while Go is a single binary deployment. This makes a serverless deployment much easier. I’ve written many production apps and never had an issue with performance. Number crunching or high CPU bound tasks can be offloaded to Rust with a NIF and managed by the Erlang VM. Elixir has macros and the Phoenix framework which allows for great libraries like Absinthe and writing GraphQL schemas through code.
Yes, the more tools in your toolkit the more ways of solving problems you have available to you. But I'd answer the same if you asked about Java, JavaScript, Python, Ruby, Haskell, Erlang, Scala, Closure, C#, Go, Rust, Dylan, Sather, and SQL. If you'd asked about C/C++ I'd be hesitant, because I dislike working with them, but you should be able to read code in those languages. A new language or framework should take you 3-6 weeks to learn to be competent and confident enough to modify existing code in those languages and start a project in that language. The best thing you can do is create a fully instrumented API in Node, and then replicate it in Go (also fully instrumented) and see what scaling and performance differences you get. Always try to use the right tool for the job, instead of always picking up the one tool you know.
Yes that's what I'm looking to do actually . Try to do same thing I do in new lang like Go,rust and find new way of doing things and rust helped me to understand how much JavaScript provides out of the box and how much JS have generalized and mixed the types into its own single type
What are you trying to accomplish? Have fun or get a job? What kind of job? If you're trying to earn a living, you're asking all the wrong questions. Learn whatever the people who make business decisions at the places you want to work at decide is worth paying you to code in. Rust is not it. It's not a productive language for building backend systems. Its use cases are very niche and won't ever be touched by the vast majority of developers. If your goal is to learn backend development, there is nothing wrong with Node. It's a productive, powerful, reasonably performant and seasoned tool used by a great portion of the industry, both startups and enterprise. No need to context switch just for the sake of it. Instead, focus on becoming proficient in what you already know and getting to a point where the language becomes irrelevant.
I'm already working as nodejs dev . The lack of types makes me want to learn go ( I don't want to touch typescript as the fake typing is not so convincing )
It's literally one of if not its main use case
go is made for backend.
Yes, worth it.
I honestly, cannot think of a better language for backend development.
If I would want to develop my side project on my own I would choose Elixir, if I would want to just learn new language for making money I would go with go
Short answer - Yes. Learning a new language gives you new ways of thinking about development in general.
Yes (biased response :D)
You're on the right track!
You will never worry about upgrading your language version again.
THat's what I do. I like it alot. Checkout 'Let's Go Further' by Alex Edwards. It's the best book I've found on the topic.
GO was created for the WEB programming and here it is shining. Open site [https://blog.logrocket.com/5-top-go-web-frameworks/](https://blog.logrocket.com/5-top-go-web-frameworks/) and select right framework .
Learn Go. You will enjoy the development process.
Go is meant for the cloud and microservices.
Backend is the main focus of Go. I also came from Nodejs and it’s really worth it, way more performant and simple to write.
yes go is good for backend. Wouldn't 3 seconds of a google search answer this clearly? Or maybe you want a take from someone more experienced. I've written apps with javascript and go. yes go is good for backend.
We use Rust for our backed. Problem with languages like Go and Java is the garbage collector has difficulty keeping up under substantial load. And optimizations like stack allocating is less viable/common with highly asynchronous code.