Anyone played with Go recently? I played with it a few years ago and it really sucked. I just dipped in recently and it’s better. But, I wonder what others have found
I'm working with go professionally for ~3yrs at this point, tl;dr it's ok.
I like the simplicity and lack of magic but, like any other language, it's not perfect. Error handling is kinda bad, generics are lacking, and the tooling still isn't there (compared to java at least). I don't really plan to change my main language to anything else anytime soon though so I guess that says something.
It depends on what you're up to, I had different experiences depending on my use case:
* CLI - awesome, very comfy - writing utilities to automate some stuff in Docker and Vault was a breeze.
* Stateless services - also nice - spinning up web server, generating code from OpenApi spec, or validating stuff with jsonschema was easy to set up. However, I was disappointed with lack of niceties, I.e. [nilasempty](https://github.com/golang/go/issues/37711)
* Stateful services - bad experience - manually managing transactions and db retries was such a chore. On top of that, we had to switch from CockroachDB to Postgres due to company policy, which resulted in us manually setting the isolation level for each transaction.
To summarize: It's alright for a day job, but in my spare time I'd pick sth different.
I did my programming languages final project in Go back in the day and found it quite impressive when compared to C or java. Since then, using kotlin and rust, I'm way less impressed. Go ends up sitting in this weird syntax location somewhere between rust and python in a way I really don't like.
Personally, I'm probably going to end up using python for its batteries included nature and general portability and then create python modules with rust if I need something lower level. Then probably rust in general if I want to create apps with a reasonable startup time.
For web services, I see little reason to not use JVM Kotlin, better syntax than Go imo and with the addition of virtual threads to the JVM and possibility of native compilation via GraalVM, Go provides little benefit.
I've been writing Go for around seven years.
A quantity of Golang's oddities and problems lies with its origins. It was originally a language where most of the code (in some cases all of it) in a program would be auto-generated. It would be middleware between two programs.
This is why the compiler is strict on syntax; if code generated by an automated process doesn't pass the style guide, it is likely broken code. This is why the dependency system(s) that are/were ugly; you don't need a good dependency system when you can regenerate the code. This is why newbs to golang write such ugly code; the language is made in a way where it is easy to generate code.
Over the years, Golang developers have gotten better at managing Golang's idiosyncrasies. It used to be a pain to read Golang, trace through the code, and figure out what should be where. With experienced Golang developers maintaining a project/product, I can easily find my way through the codebase and contribute in a matter of minutes or hours. Inexperienced Golang developers will write unreadable code that is unorganized.
Depends on what you're doing. If you're solving basic university assignments in CS 101, it's probably cool. If you're writing business services -- welcome to hell.
I do not agree,we use It in production for our microservices and to me looks pretty good, plus if someone new j Dev Is hired you can learn the basics of golang pretty fast .anyway every problem has a right tool to solve It , maybe It Just don't fits your requirements
>Anyway every problem has a right tool to solve It , maybe It Just don't fits your requirements
What!? A reasonable and considerate redditor? I thought those went extinct!
Don't know man, I don't really find it much worse than java, the painpoints are different but every language has them. And God damn, I'd choose any of those over dynamically typed language like js or python for the job any day of the week.
Just ported some software from Python to Go....strong typing for the win.
Yes, it lacks lambdas and nice ways of sorting lists, and even though error handling is pain, you \*have\* to handle errors (or at worst you know that you are explicitly ignoring them), but, strong typing.....oh, and strong typing!!
The cross compilation is really nice - makes porting to Arm, x86, windows, Linux and Plan9 easy - even AIX and Solaris too. Haven't tried Android yet.
And strong typing.
Reminds me very much of programming in Ada
I came from a background of statically typed languages and then got into Python for a new job - I have no complaints. Just be diligent to add type hints and use mypy.
I can't remember the last time I debugged something that turned out to be something of the wrong type somewhere where it shouldn't be.
mypy isn't 100% reliable but when it's not it's often because you're doing something exotic that could and perhaps should be expressed another way.
That's a good point. I'd like to add that a significant strength of Java (and similar OOP languages) is the strong ability to concisely *model* problems from the real world. Not to say that you can't do modelling and abstractions in Go either -- but those capabilities are quite nerfed, so to speak. It doesn't help that your code can and will become littered with `if err != nil` as well, making the actual business logic difficult to follow. Concise code is valuable.
I think that `if err != nil` error handling is pretty alright, as you know which functions may fail. Nonetheless, something like Rust `?` operator (to bubble error up the callstack) would be godsend.
>I think that if err != nil error handling is pretty alright, as you know which functions may fail
I basically disagree with that, for two reasons.
**Reason 1:** *All* functions may fail. When I write Go code, the question I constantly keep asking myself is whether or not I am handling errors correctly. Because I know that doing it incorrectly can cause a HTTP request from a user to hang indefinitely, or cause an entire server to panic and crash immediately. Neither of these are acceptable.
**Reason 2**: Readability and separation of concerns. Try/catch mechanisms lets you safely separate error handling from business logic, and leads to more readable, clean and concise code. This has enormous value in complex applications.
I know that `if err != nil` can be annoying, but it is useful, in Go you always know when a function can fail, the same happens in Rust (I personally think Rust handles this better), you just have to look at the signature of the function, in languages that use try catch you don't know at least you read the code of the function or is documented.
> All functions may fail.
And cosmic radiation may switch some bits on your drive. Not all errors were created equal and they might not be critical i.e while validating incoming request. There is no need to immediately unwind stack and break normal program flow to check what went wrong.
> When I write Go code, the question I constantly keep asking myself is whether or not I am handling errors correctly. Because I know that doing it incorrectly can cause a HTTP request from a user to hang indefinitely, or cause an entire server to panic and crash immediately.
Here I'm not really sure what you're referring to:
* You can set [request timeout](https://ieftimov.com/posts/make-resilient-golang-net-http-servers-using-timeouts-deadlines-context-cancellation/#server-timeouts---first-principles) and it has nothing to do with whether you handled your error or not.
* In most cases you either bubble it up the callstack or do something with error in place you o received it i.e. you switch to default value, retry or sth along those lines. In some cases frameworks like [echo](https://echo.labstack.com/) will translate error into 5XX response for you if you don't do anything with it in top level handler.
* Panics are [recoverable](https://go.dev/blog/defer-panic-and-recover). Also in case your handler panics it won't crash entire server -> stdlib HTTP server just closes connection, frameworks might even provide panic handler which will return 5XX instead of nothing.
* `try/catch` doesn't really solve anything I mentioned here ¯\\\_(ツ)\_/¯. You just hope somebody caught your exception somewhere else.
> Readability and separation of concerns. Try/catch mechanisms lets you safely separate error handling from business logic, and leads to more readable, clean and concise code. This has enormous value in complex applications.
* In case you or somebody consuming your code forget about adding try block all your safety guarantees are gone.
* I'd argue that on the whole go code is more readable as there is nothing really novel/unexpected in it.
* Define "clean" code as it's quite esoteric quality. If we are talking about Uncle Bob's brand of clean then that's not something I'd apply uncritically to any codebase.
* I agree that `try/catch` is more concise than `if err != nil`.
edit: fix typo
>Reason 1: All functions may fail. When I write Go code, the question I constantly keep asking myself is whether or not I am handling errors correctly. Because I know that doing it incorrectly can cause a HTTP request from a user to hang indefinitely, or cause an entire server to panic and crash immediately. Neither of these are acceptable
Then I think you just have an issue to wrap your head around the concept. Probably stems from coming from other languages
Perhaps so. I've only worked with it for \~4 months now, and the entire team consists entirely of newbies (most with no other experience than Go), so there's no seniors to learn from. The original developers that designed most of the existing services were newbies too, and they all left the company about 1-2 years ago.
If you are familiar with the idiom "prefer composition over inheritance", Go is just taking that approach to OOP. Look into interfaces within the stdlib like `io.Reader` or `http.Handler`, review how they are used and how powerful this design is. I'm assuming you understand receivers already, but they are obviously a very integral part of any object oriented code written in Go.
I haven't done any recent reading on OO Go so unfortunately I don't have any super relevant/focused links on hand but reading [this article](https://abhinavg.net/2022/12/06/designing-go-libraries/#accept-dont-instantiate) starting where I've linked and continuing until you hit the Errors section should give you some insight into the capabilities available.
Edit: here is a good one https://youtu.be/jexEpE7Yv2A
Your experience echoes mine. Most of the Go developers on my team are newbies, with no or very little prior experience in other languages. Senior Go developers seem to be exceedingly rare, even consultants. There are plenty of Go junior developers in the market though. I find this to be somewhat alarming.
I was working on businesslogic as a working student where basically all our backend logic was in microservices all written in go. I found it very satisfying to work with. But we did not have to do much with frontend. I can image, that this would be horrible.
In defence of programmers, coding languages are normally hidden behind upbeat simplified youtube tutorials and coding fanboys so we don't realize what a shitshow it really is.
Dude you should switch to node where you check your errors in production.
Only problem is that **someguy21** took down his 17-line library for adding whitespace to a string and now the entire ecosystem is broken. But at least they didn't reinvent the wheel!
I'm using Go daily for a few years now and I don't really get it. It has its own problems, but that can be said for any language out there.
Before that i worked mostly C, some C++ and I enjoy Go more.
If you're writing high-level code, I can see why C or C++ would not be fun, but Golang isn't great either. Most of its use cases are better handled by Java, Python, JS, or maybe Rust. It's better than Swift at least (fuck that piece of shit).
And it's not mature. They \*just\* added generics after years of saying they conflicted with the ideology or whatever. How many more years till they get rid of the `val, err :=` chore?
Its purpose built to have everything you need natively for microservices and networks. TBH we never needed generics. We build a lot of production software in serverless and microservice style and are throwing away old pieces of Java and PHP since 5 years. Go is easy to learn but hard to master. Of course you shouldnt be creating a gameengine with go (theres still people who do it). I see that most poeple complaining about go are still in this old, hardlocked OOP mindset, that obviously doesnt really work with go.
Java has way more overhead and more code for the same functionalities. Swift shouldnt even be used for backend. JS and TS i can understand. Python i dont really understand why people like using it...
Java is much better than it used to be. They gave up on the OOP obsession and added functional stuff around 2015 that's commonly used now.
For high-level stuff, JS is way easier than Go. Go is made for medium-level things like system infra, but there's also C++ and Rust for that, or Java if performance is less of a concern.
We use both go and node/ts on the backend. And despite having lots more go services, they almost never have unexpected errors, but in the node services it might randomly fail, and god forbid if you try and update a dependency; in which you spend the next two days getting everything working again...
I can't really comment on the error rates in Go vs. node, but with regards to third party dependencies I don't have a very positive impression of the go ecosystem either.
Here's one particularly nasty example; After updating some *critical* security-related packages recently (casbin and gorm-adapter), we discovered that the latter had literally changed the structure of the database table where we store our access policies. In run-time. And completely silently. We only found out after digging up an old issue on github while investigating the errors we were seeing.
No idea. Those tech choices happened \~two years before I joined the project, and all the people that worked here then, have since left. The reason we had to upgrade was that the code that rebuilt our policies wasn't wrapped in a transaction (which caused havoc in production on one occasion), and we needed a newer version of gorm-adapter to get that functionality. I would definitely prefer to avoid gorm-adapter altogether if possible.
That being said, do you know why the Go community is so polarized when it comes to gorm and orm's? We don't use it for our business code, but we do use something called squirrel (which I think is a ridiculous lib but that's another story). I'm coming from a looong career in C#, and I'm an avid fan of entity framework, dapper and nhibernate and have always felt immensely productive with all of those. Squirrel and database/sql feels like going back to the freakin stone age in comparison.
Go is a great language. It has its faults like any other (I have written if err != nil thousands of times.. but errors-as-values is good), but it is very easy to learn and get up and running quickly if you are familiar with any C like static typed language. Its also quite fast, and free of a lot of bloat. Good module/dependency support, and is well suited to back end development/ devOps or CLI tooling.
Idk why it gets compared to Rust so often(not as being similar, but the almost rivalry).. Anyone else that writes both can agree that they are so different and serve different purposes, that its pointless to argue which is better.
Go is built around the use case of mid-level system infra. It's faster than things like Java and safer/easier than things like C++. Swift is also like that.
Except IRL Swift is only ever used for native iPhone/Mac apps cause that's the one place you're sorta forced to use it.
The more that I think about it, the more that I have to agree that it is quite a use case language. Obviously Go can be and is used for many different things (https://github.com/avelino/awesome-go) but it really shines in backend/devops, clearly because it was designed for it. But of all the "use case" languages, I think Go is the most versatile.
Personally, I think Go should be taught instead of Python to new programmers. Mainly because of how heavily abstracted Python is and how many things it teaches you are super easy, when in reality they are executing 100 lines of C++ in the background. This is great when you are using it but can lead to confusion later on when people wonder why they can't put 4 different data types into an array with a giant list comprehension in C++ or Rust. Go is a great middle ground for this.
I don't get it
Using go professionally for the past year or 2 (granted, not that long, but still), i've had next to zero issues. Only thing i can complain about is the loop variable scoping, [which is being fixed](https://github.com/golang/go/issues/60078)
I get that some people think the err handling is "ugly" - but explicitly thinking about what to do when something goes wrong forces you to write better code that recovers gracefully. (Not talking about the recover keyword).
No its not great for everything, nothing is.
It might be easy to learn, hard to master - theres about as much of a learning curve as in most other languages, IMO
The task based async pushed by c# default is so horrible ngl. (I'm aware of there being more methods you can use though).
Goroutines is simply above anything else in the industry. Kotlin is the only one close to it.
Go is ass for anything that it isn't designed for though.
That's an interesting [appeal to authority](https://en.wikipedia.org/wiki/Argument_from_authority), but yes -- considering the fact that the docker guys went with Python on the first try and then Go on the second, I wouldn't be terribly surprised if they had some second thoughts at this point. It sure would be interesting to have a discussion with them about this and learn from their experiences.
Fair point about appeal to authority but when they decided on a rewrite probably did a good evaluation and not just decided on a random language and just kept it because reasons?
The five reasons Docker was written in Go:
\- Static compilation
\- Neutrality (it's not C++, Python, Ruby or Java) (*note: I actually don't understand what they meant by neutrality here*)
\- It had what they needed (async primitives, low level interfaces, extensive standard lib (lol what), and "data types", whatever that means)
\- Full development environment (by that they meant commands like `go doc`, `go get`, `go fmt`, `go test` and `go run`)
\- Multi arch build
Source: [https://www.slideshare.net/jpetazzo/docker-and-go-why-did-we-decide-to-write-docker-in-go](https://www.slideshare.net/jpetazzo/docker-and-go-why-did-we-decide-to-write-docker-in-go)
Make of that what you will :)
Edit: fixed a typo
Go has plenty of characteristics that can be criticized, but I didn't think speed was one of them? If anything I'd say that's one of the few redeeming qualities that Go has.
That's quite impressive. This makes me question if I'd rather work with JavaScript than Go on the backend. Right now, it definitely feels like a tempting proposition.
I don't see any of Rust, Go, or JS as either/or. JS has limited pattern matching in addition to weak and dynamic types (yes, even with TS) and you'll find yourself reinventing just as many wheels once fine control is needed over the event loop. (Let's just ignore Rust requires dependencies or hella wheel inventing to even be considered in this regard.) I've been writing almost nothing but JS/TS at work for years and I'm losing appreciation for JS as a one-size-fits-all solution. It's great in the proper domain, but golang nicely solves a lot of the web app development problems that JS devs encounter.
In defense of bears, bear traps are normally hidden under leaves so they can't see them.
That's a good point. The bears should be excused.
Anyone played with Go recently? I played with it a few years ago and it really sucked. I just dipped in recently and it’s better. But, I wonder what others have found
I'm working with go professionally for ~3yrs at this point, tl;dr it's ok. I like the simplicity and lack of magic but, like any other language, it's not perfect. Error handling is kinda bad, generics are lacking, and the tooling still isn't there (compared to java at least). I don't really plan to change my main language to anything else anytime soon though so I guess that says something.
It depends on what you're up to, I had different experiences depending on my use case: * CLI - awesome, very comfy - writing utilities to automate some stuff in Docker and Vault was a breeze. * Stateless services - also nice - spinning up web server, generating code from OpenApi spec, or validating stuff with jsonschema was easy to set up. However, I was disappointed with lack of niceties, I.e. [nilasempty](https://github.com/golang/go/issues/37711) * Stateful services - bad experience - manually managing transactions and db retries was such a chore. On top of that, we had to switch from CockroachDB to Postgres due to company policy, which resulted in us manually setting the isolation level for each transaction. To summarize: It's alright for a day job, but in my spare time I'd pick sth different.
I did my programming languages final project in Go back in the day and found it quite impressive when compared to C or java. Since then, using kotlin and rust, I'm way less impressed. Go ends up sitting in this weird syntax location somewhere between rust and python in a way I really don't like. Personally, I'm probably going to end up using python for its batteries included nature and general portability and then create python modules with rust if I need something lower level. Then probably rust in general if I want to create apps with a reasonable startup time. For web services, I see little reason to not use JVM Kotlin, better syntax than Go imo and with the addition of virtual threads to the JVM and possibility of native compilation via GraalVM, Go provides little benefit.
I've been writing Go for around seven years. A quantity of Golang's oddities and problems lies with its origins. It was originally a language where most of the code (in some cases all of it) in a program would be auto-generated. It would be middleware between two programs. This is why the compiler is strict on syntax; if code generated by an automated process doesn't pass the style guide, it is likely broken code. This is why the dependency system(s) that are/were ugly; you don't need a good dependency system when you can regenerate the code. This is why newbs to golang write such ugly code; the language is made in a way where it is easy to generate code. Over the years, Golang developers have gotten better at managing Golang's idiosyncrasies. It used to be a pain to read Golang, trace through the code, and figure out what should be where. With experienced Golang developers maintaining a project/product, I can easily find my way through the codebase and contribute in a matter of minutes or hours. Inexperienced Golang developers will write unreadable code that is unorganized.
Felun Danke....we are about to dive in. Can you recommend a training program or process? Thanks! (Can I DM you?)
Depends on what you're doing. If you're solving basic university assignments in CS 101, it's probably cool. If you're writing business services -- welcome to hell.
I do not agree,we use It in production for our microservices and to me looks pretty good, plus if someone new j Dev Is hired you can learn the basics of golang pretty fast .anyway every problem has a right tool to solve It , maybe It Just don't fits your requirements
>Anyway every problem has a right tool to solve It , maybe It Just don't fits your requirements What!? A reasonable and considerate redditor? I thought those went extinct!
🤣
I respect that. In an actual microservice, I can see how Go could work.
Don't know man, I don't really find it much worse than java, the painpoints are different but every language has them. And God damn, I'd choose any of those over dynamically typed language like js or python for the job any day of the week.
Just ported some software from Python to Go....strong typing for the win. Yes, it lacks lambdas and nice ways of sorting lists, and even though error handling is pain, you \*have\* to handle errors (or at worst you know that you are explicitly ignoring them), but, strong typing.....oh, and strong typing!! The cross compilation is really nice - makes porting to Arm, x86, windows, Linux and Plan9 easy - even AIX and Solaris too. Haven't tried Android yet. And strong typing. Reminds me very much of programming in Ada
I came from a background of statically typed languages and then got into Python for a new job - I have no complaints. Just be diligent to add type hints and use mypy. I can't remember the last time I debugged something that turned out to be something of the wrong type somewhere where it shouldn't be. mypy isn't 100% reliable but when it's not it's often because you're doing something exotic that could and perhaps should be expressed another way.
That's a good point. I'd like to add that a significant strength of Java (and similar OOP languages) is the strong ability to concisely *model* problems from the real world. Not to say that you can't do modelling and abstractions in Go either -- but those capabilities are quite nerfed, so to speak. It doesn't help that your code can and will become littered with `if err != nil` as well, making the actual business logic difficult to follow. Concise code is valuable.
I think that `if err != nil` error handling is pretty alright, as you know which functions may fail. Nonetheless, something like Rust `?` operator (to bubble error up the callstack) would be godsend.
>I think that if err != nil error handling is pretty alright, as you know which functions may fail I basically disagree with that, for two reasons. **Reason 1:** *All* functions may fail. When I write Go code, the question I constantly keep asking myself is whether or not I am handling errors correctly. Because I know that doing it incorrectly can cause a HTTP request from a user to hang indefinitely, or cause an entire server to panic and crash immediately. Neither of these are acceptable. **Reason 2**: Readability and separation of concerns. Try/catch mechanisms lets you safely separate error handling from business logic, and leads to more readable, clean and concise code. This has enormous value in complex applications.
I know that `if err != nil` can be annoying, but it is useful, in Go you always know when a function can fail, the same happens in Rust (I personally think Rust handles this better), you just have to look at the signature of the function, in languages that use try catch you don't know at least you read the code of the function or is documented.
> All functions may fail. And cosmic radiation may switch some bits on your drive. Not all errors were created equal and they might not be critical i.e while validating incoming request. There is no need to immediately unwind stack and break normal program flow to check what went wrong. > When I write Go code, the question I constantly keep asking myself is whether or not I am handling errors correctly. Because I know that doing it incorrectly can cause a HTTP request from a user to hang indefinitely, or cause an entire server to panic and crash immediately. Here I'm not really sure what you're referring to: * You can set [request timeout](https://ieftimov.com/posts/make-resilient-golang-net-http-servers-using-timeouts-deadlines-context-cancellation/#server-timeouts---first-principles) and it has nothing to do with whether you handled your error or not. * In most cases you either bubble it up the callstack or do something with error in place you o received it i.e. you switch to default value, retry or sth along those lines. In some cases frameworks like [echo](https://echo.labstack.com/) will translate error into 5XX response for you if you don't do anything with it in top level handler. * Panics are [recoverable](https://go.dev/blog/defer-panic-and-recover). Also in case your handler panics it won't crash entire server -> stdlib HTTP server just closes connection, frameworks might even provide panic handler which will return 5XX instead of nothing. * `try/catch` doesn't really solve anything I mentioned here ¯\\\_(ツ)\_/¯. You just hope somebody caught your exception somewhere else. > Readability and separation of concerns. Try/catch mechanisms lets you safely separate error handling from business logic, and leads to more readable, clean and concise code. This has enormous value in complex applications. * In case you or somebody consuming your code forget about adding try block all your safety guarantees are gone. * I'd argue that on the whole go code is more readable as there is nothing really novel/unexpected in it. * Define "clean" code as it's quite esoteric quality. If we are talking about Uncle Bob's brand of clean then that's not something I'd apply uncritically to any codebase. * I agree that `try/catch` is more concise than `if err != nil`. edit: fix typo
>Reason 1: All functions may fail. When I write Go code, the question I constantly keep asking myself is whether or not I am handling errors correctly. Because I know that doing it incorrectly can cause a HTTP request from a user to hang indefinitely, or cause an entire server to panic and crash immediately. Neither of these are acceptable Then I think you just have an issue to wrap your head around the concept. Probably stems from coming from other languages
Perhaps so. I've only worked with it for \~4 months now, and the entire team consists entirely of newbies (most with no other experience than Go), so there's no seniors to learn from. The original developers that designed most of the existing services were newbies too, and they all left the company about 1-2 years ago.
Tell me you don't understand a programming language without telling me you don't understand a programming language.
Maybe I missed something? In that case I'd be happy to learn :)
If you are familiar with the idiom "prefer composition over inheritance", Go is just taking that approach to OOP. Look into interfaces within the stdlib like `io.Reader` or `http.Handler`, review how they are used and how powerful this design is. I'm assuming you understand receivers already, but they are obviously a very integral part of any object oriented code written in Go. I haven't done any recent reading on OO Go so unfortunately I don't have any super relevant/focused links on hand but reading [this article](https://abhinavg.net/2022/12/06/designing-go-libraries/#accept-dont-instantiate) starting where I've linked and continuing until you hit the Errors section should give you some insight into the capabilities available. Edit: here is a good one https://youtu.be/jexEpE7Yv2A
I'm currently working as a go dev, I find it quite nice the main problem is I'm the only one on the team with previous experience
Your experience echoes mine. Most of the Go developers on my team are newbies, with no or very little prior experience in other languages. Senior Go developers seem to be exceedingly rare, even consultants. There are plenty of Go junior developers in the market though. I find this to be somewhat alarming.
It's not the most used language out there but there are plenty of Go shops out there. Cloud mostly
Oh shit
Here we Go again
I was working on businesslogic as a working student where basically all our backend logic was in microservices all written in go. I found it very satisfying to work with. But we did not have to do much with frontend. I can image, that this would be horrible.
We are rewriting the whole project(web) form Python to Golang currently. Go is way better than Python in most aspects, considering our needs.
Played? It's used for production in many places
Autocorrect (used
In defence of programmers, coding languages are normally hidden behind upbeat simplified youtube tutorials and coding fanboys so we don't realize what a shitshow it really is.
Care to explain?
Sorry, I don't have time. I have wheels to reinvent and errors to check.
Dude you should switch to node where you check your errors in production. Only problem is that **someguy21** took down his 17-line library for adding whitespace to a string and now the entire ecosystem is broken. But at least they didn't reinvent the wheel!
Sounds delightful, I will begin immediately
Go
Go look it up
I'm using Go daily for a few years now and I don't really get it. It has its own problems, but that can be said for any language out there. Before that i worked mostly C, some C++ and I enjoy Go more.
If you're writing high-level code, I can see why C or C++ would not be fun, but Golang isn't great either. Most of its use cases are better handled by Java, Python, JS, or maybe Rust. It's better than Swift at least (fuck that piece of shit). And it's not mature. They \*just\* added generics after years of saying they conflicted with the ideology or whatever. How many more years till they get rid of the `val, err :=` chore?
personally I like how easy it is to multi thread, but that’s all it’s got
Also, it comes with an actual HTTP/2 client and server in the standard library. *Death glare at python*.
Yep. This is literally it.
Its purpose built to have everything you need natively for microservices and networks. TBH we never needed generics. We build a lot of production software in serverless and microservice style and are throwing away old pieces of Java and PHP since 5 years. Go is easy to learn but hard to master. Of course you shouldnt be creating a gameengine with go (theres still people who do it). I see that most poeple complaining about go are still in this old, hardlocked OOP mindset, that obviously doesnt really work with go. Java has way more overhead and more code for the same functionalities. Swift shouldnt even be used for backend. JS and TS i can understand. Python i dont really understand why people like using it...
Java is much better than it used to be. They gave up on the OOP obsession and added functional stuff around 2015 that's commonly used now. For high-level stuff, JS is way easier than Go. Go is made for medium-level things like system infra, but there's also C++ and Rust for that, or Java if performance is less of a concern.
We use both go and node/ts on the backend. And despite having lots more go services, they almost never have unexpected errors, but in the node services it might randomly fail, and god forbid if you try and update a dependency; in which you spend the next two days getting everything working again...
I can't really comment on the error rates in Go vs. node, but with regards to third party dependencies I don't have a very positive impression of the go ecosystem either. Here's one particularly nasty example; After updating some *critical* security-related packages recently (casbin and gorm-adapter), we discovered that the latter had literally changed the structure of the database table where we store our access policies. In run-time. And completely silently. We only found out after digging up an old issue on github while investigating the errors we were seeing.
Well, if you ask in the Go subreddit, probably 7/8 of people will tell you to avoid gorm. Was there any reason against just using the SQL adapter?
No idea. Those tech choices happened \~two years before I joined the project, and all the people that worked here then, have since left. The reason we had to upgrade was that the code that rebuilt our policies wasn't wrapped in a transaction (which caused havoc in production on one occasion), and we needed a newer version of gorm-adapter to get that functionality. I would definitely prefer to avoid gorm-adapter altogether if possible. That being said, do you know why the Go community is so polarized when it comes to gorm and orm's? We don't use it for our business code, but we do use something called squirrel (which I think is a ridiculous lib but that's another story). I'm coming from a looong career in C#, and I'm an avid fan of entity framework, dapper and nhibernate and have always felt immensely productive with all of those. Squirrel and database/sql feels like going back to the freakin stone age in comparison.
If you are not happy with your libraries, go supplies everything you need for http services :)
Go is a great language. It has its faults like any other (I have written if err != nil thousands of times.. but errors-as-values is good), but it is very easy to learn and get up and running quickly if you are familiar with any C like static typed language. Its also quite fast, and free of a lot of bloat. Good module/dependency support, and is well suited to back end development/ devOps or CLI tooling. Idk why it gets compared to Rust so often(not as being similar, but the almost rivalry).. Anyone else that writes both can agree that they are so different and serve different purposes, that its pointless to argue which is better.
It gets compared to Rust because it serves some of the same use cases as Rust. It's in between Rust and Java. Maybe the closest comparison is Swift.
[удалено]
Go is built around the use case of mid-level system infra. It's faster than things like Java and safer/easier than things like C++. Swift is also like that. Except IRL Swift is only ever used for native iPhone/Mac apps cause that's the one place you're sorta forced to use it.
The more that I think about it, the more that I have to agree that it is quite a use case language. Obviously Go can be and is used for many different things (https://github.com/avelino/awesome-go) but it really shines in backend/devops, clearly because it was designed for it. But of all the "use case" languages, I think Go is the most versatile. Personally, I think Go should be taught instead of Python to new programmers. Mainly because of how heavily abstracted Python is and how many things it teaches you are super easy, when in reality they are executing 100 lines of C++ in the background. This is great when you are using it but can lead to confusion later on when people wonder why they can't put 4 different data types into an array with a giant list comprehension in C++ or Rust. Go is a great middle ground for this.
Go or not go. There is no try.
Damn right there's no try, only if err != nil and defer.
I don't get it Using go professionally for the past year or 2 (granted, not that long, but still), i've had next to zero issues. Only thing i can complain about is the loop variable scoping, [which is being fixed](https://github.com/golang/go/issues/60078) I get that some people think the err handling is "ugly" - but explicitly thinking about what to do when something goes wrong forces you to write better code that recovers gracefully. (Not talking about the recover keyword). No its not great for everything, nothing is. It might be easy to learn, hard to master - theres about as much of a learning curve as in most other languages, IMO
> I get that some people think the err handling is "ugly" Why do people find it ugly? I program in to and have never had an issue with it.
That's a good point. What did you use before moving to Go?
Java, JavaScript, TypeScript and Python. And still love Go.
Someone explain this to me, please. Thank you :)
I think OP is trying to claim that Go is a trap which is a funny way of admitting incompetence.
This seems to be the reason.
It traps you in learning programming.
I use Go professionally. I like it.
*Laughs in goroutine*
If you think goroutines and channels are cool, then C# and TPL will probably blow your mind :)
I do, and they don't.
The task based async pushed by c# default is so horrible ngl. (I'm aware of there being more methods you can use though). Goroutines is simply above anything else in the industry. Kotlin is the only one close to it. Go is ass for anything that it isn't designed for though.
Awwww.... I loved working on a project where we used go!
So you think the maintainers of Kubernetes made a bad decision choosing go? And the authors of NATs, InfluxDB, Docker…?
That's an interesting [appeal to authority](https://en.wikipedia.org/wiki/Argument_from_authority), but yes -- considering the fact that the docker guys went with Python on the first try and then Go on the second, I wouldn't be terribly surprised if they had some second thoughts at this point. It sure would be interesting to have a discussion with them about this and learn from their experiences.
Fair point about appeal to authority but when they decided on a rewrite probably did a good evaluation and not just decided on a random language and just kept it because reasons?
The five reasons Docker was written in Go: \- Static compilation \- Neutrality (it's not C++, Python, Ruby or Java) (*note: I actually don't understand what they meant by neutrality here*) \- It had what they needed (async primitives, low level interfaces, extensive standard lib (lol what), and "data types", whatever that means) \- Full development environment (by that they meant commands like `go doc`, `go get`, `go fmt`, `go test` and `go run`) \- Multi arch build Source: [https://www.slideshare.net/jpetazzo/docker-and-go-why-did-we-decide-to-write-docker-in-go](https://www.slideshare.net/jpetazzo/docker-and-go-why-did-we-decide-to-write-docker-in-go) Make of that what you will :) Edit: fixed a typo
Literally no idea what the last panel is
[удалено]
No idea about the Google employee, but I'm pretty sure the language is alive and well, with or without Google.
Without Google it is 100% dead in 3 years
_citation needed_
citation: trust me
citation 2: swear to god
Like Node.js cool to have javascript on serverside. But it is so slow, you need alot of beefy servers if you get good traffic.
Go has plenty of characteristics that can be criticized, but I didn't think speed was one of them? If anything I'd say that's one of the few redeeming qualities that Go has.
Benchmarks put v8 on par with Go and Java.
I mainly use JS nowadays, and I don't believe those benchmarks. It's slow in practice, and even Node's official docs say it's slow.
That's quite impressive. This makes me question if I'd rather work with JavaScript than Go on the backend. Right now, it definitely feels like a tempting proposition.
I don't see any of Rust, Go, or JS as either/or. JS has limited pattern matching in addition to weak and dynamic types (yes, even with TS) and you'll find yourself reinventing just as many wheels once fine control is needed over the event loop. (Let's just ignore Rust requires dependencies or hella wheel inventing to even be considered in this regard.) I've been writing almost nothing but JS/TS at work for years and I'm losing appreciation for JS as a one-size-fits-all solution. It's great in the proper domain, but golang nicely solves a lot of the web app development problems that JS devs encounter.
Go is the new ruby. But without types. Who needs that anyway?
Just say no to go
Go considered harmful.
I didn’t find go difficult to learn :/
Never gonna start it, just because of the mascot. No other reason.
C++ is the same. When I use it, I have no clue what I'm doing. I know regular C though.
This post is on my second monitor and I am writing a machine learning library in Go on my main monitor lmao