I have just embedded entire SPA dist in Go binary, much easier to deploy and reduce read from disk latency.
Thirteen Years of Go
111–120 of 217 posts
Re: Thirteen Years of Go
#112Earlier quoted context omitted.
Slight counterpoint - I have written Go in the past and now am working with Kotlin and to be honest, I prefer it. I wouldn't mind Kotlin being the new Java rather than Go.
Java is the new Java :) With features like records, virtual threads, pattern matching, sealed types, string templates, and more to come, it's shaping up very nicely.
Java runs nice and quick when it's ready, but it's slow to get there and quite a memory hog.
Re: Thirteen Years of Go
#113I've enjoyed writing Go for years. However, it's not been the language that does it for me. It's been the combination of features and ecosystem that makes it a default. It's hard to explain, but the language is one you can throw into a team of random developers and come out with benchmarks, tests, CI/CD pipelines, unified code formatting, and good parallel work models (via goroutines) almost every time. Builds are in…
I currently write a SaaS website in Go after doing quite some Rust. I do prefer Rust as a language - it's more expresive and I greatly prefer Result over error, but it has two major downsides for me compared to Go. First compilation is much slower and Go feels like a non-compiled language because of the compilation speed (my last startup I've used Scala with horrendous compilation speeds, the main reason not to use i…
Re: Thirteen Years of Go
#114I want to love Go, due to my background in C and UNIX sysadmin, but can't. Rust does it for me though.
This is an article about Go, not an article comparing Go to Rust. I'd say the same thing if the roles were reversed: don't start language debates. They spread like kudzu and choke everything else out of the threads.
Comment police/gatekeeping discussion (outside of dang actually enforcing the rules) is probably the most annoying behavior on this site.
Re: Thirteen Years of Go
#115Go has almost everything going for it. I only wish it was a bit more C-like and you had the ability to run it without a garbage collector, and that it was more suitable for systems and embedded programming. Perhaps one day someone will come up with an implementation of Go that doesn’t use a GC. It’s just such an incredible language, and it deserves the type of Rust fanaticism that Rust has, but I suspect Go users are…
Re: Thirteen Years of Go
#116Earlier quoted context omitted.
> > it's Bell Labs heritage > I have never met a person (in person, offline) who has cared about this at all. People care about it because the language has the Bell Labs "feel". They don't care about it the way a dog breeder would care about a dog's ancestry. (And of those who care about the "feel", some view it as a positive, others as a negative...)
> People care about it because the language has the Bell Labs "feel" I'm not attacking, I am honestly asking: What does that mean? That it feels C-like? Or something different? A lot of languages are C-like in syntax, so Go is not exactly unique in that aspect.
Contrast with e.g. Haskell which is based on the belief you can always improve some code by making it more general, or Rust on the belief you can improve it by making it safer, or Java that you can improve it by breaking it down into smaller chunks.
Languages carry aesthetic values. Most are aren't committed to them above literally all else - we all want our code to be somewhat simple and general and safe and isolated etc - but other than the most kitchen sink-y of them (C++, JavaScript) they have priorities among those which show through. (And even in those you can find some, muddled as they are.)
Re: Thirteen Years of Go
#117Earlier quoted context omitted.
Your comment has been good at generating some discussion around what makes Go special. Since the sibling comments already addressed everything else, I'll talk about this one: > For a compiled language it's not very fast This is essentially true, _but_ a lot of Go users are coming from Python, JavaScript, and maybe Ruby and Go is much faster. Additionally, it comes _close enough_ to Java while typically having a much…
I never got the feeling it was slower than Java, but I've only used the standard JVM. In benchmarks, they don't really differ. But the memory footprint is amazing. I've got three servers plus up to 10 test environments running on one small VPS (Virtual Private Server), and everything runs as smooth as can be; memory usage stays below 1GB, leaving enough space for the db server. In a previous job, we had a Java/Tomcat…
But, yeah, my experience with Go matches yours. It's really amazingly light on resource usage.
Re: Thirteen Years of Go
#118I've enjoyed writing Go for years. However, it's not been the language that does it for me. It's been the combination of features and ecosystem that makes it a default. It's hard to explain, but the language is one you can throw into a team of random developers and come out with benchmarks, tests, CI/CD pipelines, unified code formatting, and good parallel work models (via goroutines) almost every time. Builds are in…
Slight counterpoint - I have written Go in the past and now am working with Kotlin and to be honest, I prefer it. I wouldn't mind Kotlin being the new Java rather than Go.
Re: Thirteen Years of Go
#119Earlier quoted context omitted.
Slight counterpoint - I have written Go in the past and now am working with Kotlin and to be honest, I prefer it. I wouldn't mind Kotlin being the new Java rather than Go.
Java is the new Java :) With features like records, virtual threads, pattern matching, sealed types, string templates, and more to come, it's shaping up very nicely.