141–150 of 310 posts
I've switched most of my personal projects over to Rust and so far I'm not looking back...
Wow! 10 years already. I'm the founder of HashiCorp and I'd love to share my thoughts. Credentials: I started using Go around 9 years ago and since then I've built a company of over 1,000 employees with ~250 engineers that write Go full time. We maintain dozens of open source projects and libraries (Terraform, Vault, etc. etc.) all written in Go. We've shipped commercial products that are used by a significant percen…
> The cost of this is often verbosity or repetition
This may be seen as a cost but it's also a significant gain during debugging.
Earlier quoted context omitted.
Go has wide enough adoption that I don’t think you can call it niche anymore. It’s become somewhat of a de-facto systems/infrastructure programming language and is replacing Python in a lot of places where it was traditionally used for automation. The language is simple, performant and writing concurrent code is intuitive (although I feel Go developers tend to get carried away using channels/goroutines).
Because every time I need to use a lock I know I am not smart enough to do so. Channels and go routines, I can reason about. (Tho they are slower - I have a runtime stats package that just stuff the numbers into a channel and then returns to the calling goroutine. I did an implementation using Atomic’s and it could sustain like 20x more calls per second before using all the callers CPU. But I still use the channel im…
I don't code with it but I use Hugo (a static site generator) that's written in Go because it's ridiculously fast. Ruby and JavaScript static site generators I've tried end up taking several seconds to generate a handful of pages when Hugo spits out hundreds of pages in less than a second. It's pretty crazy how used we are now to slow dynamic languages. I also like how Hugo is available as a single binary file - much…
I think it's boring, overly simplistic, and ignores the last couple of decades of PL research.
Boring is actually what a lot of people look for.
Actually they mean something different with "boring": It is just a lack of courage for simply saying "We are most conservative, do not want to move forwards and are not willing to take any risk. Also we are scared of specialists and talent and want to stay mediocre. Actually working with us is boring."
Earlier quoted context omitted.
> While writing servers in Flask + Python is much more convenient The only time I had to use Flask, it was a nightmare to deploy. To this day I still fail to understand why I had to mess with Nginx, gunicorn, WSGI or whatever just for a basic backend. The dev experience was fine, but I don't remember it being more convenient than using Go
Because web servers look simple from the outset but are, underneath it all, very complicated. And it's not a web server. If you want something basic, gunicorn can run flask with one line.
Earlier quoted context omitted.
Because every time I need to use a lock I know I am not smart enough to do so. Channels and go routines, I can reason about. (Tho they are slower - I have a runtime stats package that just stuff the numbers into a channel and then returns to the calling goroutine. I did an implementation using Atomic’s and it could sustain like 20x more calls per second before using all the callers CPU. But I still use the channel im…
Oh, I didn’t mean lock vs channels/goroutines. I meant in general prematurely optimizing by using Go’s concurrency primitives. It’s so easy to goroutine-ize a simple for loop with a waitgroup, but it can quickly get complicated with stop channels, cancellations, error handling/propagating, graceful shutdown which is then a source of bugs.
Earlier quoted context omitted.
> They spent almost 10 years saying "we don't need generics", but now are implementing it You're making things up. Not a single member of the Go team ever said "we don't need generics". In fact, the FAQ stated from day one that they "continue to think about it", and that "Generics may well be added at some point".
They've always also said "show us some compelling use cases", as if those still need to be shown ~15 years after after every other language except C got them.
My fingers are getting real tired from typing if err != nil all the damn time. I do like it for small things - compiling to one (albeit huge) binary and its relative speediness is nice. I wouldn't use it for large systems though. The amount of code really balloons over time, relative to, say, python and that SLOC correlates to bugs and maintenance cost.
Have you considered using a snippet or macro to type the 13 characters for you? Snippets or macros are available in most editors.
(looking at you, java)
I’ve always loved playing with languages, so over the same period of time Rust was a language I’d often tinker with. It never really felt great for web stuff, but I kept going back to it to toy around with maybe a CLI here and there.
Fast forward to the pandemic and I found myself with a lot more free time at home, coupled with a newly mature async story in Rust, and everything changed for me. The error handling due to algebraic types is phenomenal (particularly with the ‘anyhow’ and ‘thiserror’ crates), rust-analyzer in my emacs is awesome, type safe SQL with sqlx is amazing, cargo is great, compiler error messages are super clear, and the list goes on.
I just started a new project with a client and the backend is written in Go, and honestly it’s a bit of a let down having to go back to it. It’s totally fine, it just doesn’t feel beautiful to me. Seeing empty interfaces with type casting makes me cringe (I mean it always has) and I’m really going to miss the Rust error handling. Thankfully a lot of this project I’m going to be able to use AWS lambda for and I’ll just use TypeScript since the front end team is using it there (no one is comfortable with Rust).
tldr; Go is a simple language that will let a team get things done and it’s easy enough for any developer to onboard with it. But personally I wouldn’t reach for it ever again because of Rust (and even TypeScript).