191–200 of 269 posts
Earlier quoted context omitted.
Yes of course they are. Further I understand the "strategic decisions", "markets have spoken" , "faster feature due to single codebase" justifications to Electron usage. To me it just feels like saying we care about our servers meanwhile users can eat crap.
Yeah, one is free, one isnt
Earlier quoted context omitted.
Anything that has to do with UI in my opinion. Go's lack of classes (factories, inheritance, etc) and verbosity make graphical layouts very, very tedious.
I think this is only true for OOP-style "widget-based" UI toolkits. I've had a very good time writing console UIs using a reactive style; obviously console UIs are simpler, but I think when people want inheritance in UIs, it's for things like 2D layout (in typical OOP toolkits, every widget type is derived from some base Widget class that does layout things) which are also present in console UIs. I would be intereste…
While I do trust Rob Pike to not let personal biases sway his writing, I do have to wonder if the case studies weren't selecting because they were positive. So I'm curious: does anyone have a case study where using Go was a disaster? Every language has things it's good at, and things it's bad at. Where does Go not do well?
Earlier quoted context omitted.
I know a case (second hand) where they migrated from a Java backend to Go, then had to roll it all back to Java because it was too hard and error prone to maintain. This is a very successful business, not a startup. No idea why they felt they had to migrate to Go in the first place. I'd rather not mention the company, even though I did not work there.
Concurrency is something that Go makes much easier, or at least more ergonomic, that Java with Runnables and ExecutorPools.
Earlier quoted context omitted.
I had looked at the Discord GC blog issue [1] fairly carefully, and it certainly seemed that specific GC latency issue they hit and blogged about would have been solved by upgrading to a modern Go version.... Also, after publishing that blog, they also said they had wanted to try Rust for other reasons: wanted to try out rust as well for services like this, due to adoption elsewhere in the company. Also, after upgrad…
> it certainly seemed that specific GC latency issue they hit and blogged about would have been solved by upgrading to a modern Go version.... Do you know if that was the case when the decision to switch was made? They said elsewhere they tried Go 1.7-1.10 and none of those solved their issue, and at least back when the blog post was released I couldn't figure out whether the fix for the corresponding issue was known…
It’s a good question.
The timing is a bit confusing because the blog was apparently published a bit after the fact, but I think I saw that they said they made the decision mid 2019.
Go 1.12 seemed to address their latency issue, which was available as GA in Feb 2019.
That’s based on some retroactive benchmarks on a set of old Go versions starting with 1.9 and targeting what they described as the problem and symptoms.
Things seemed to line up, but I can’t be sure.
I don’t know if Go 1.11 would have addressed their issue.
(In general, Go GC tail latencies including for large heaps have improved a bunch since the last version they said they tried, which I think was Go 1.10).
In any event, they saw a problem, and made a rationale decision for multiple rationale reasons.
Earlier quoted context omitted.
I share much of the sentiment. I like the simplicity of Go, but I think they took it too far an ended up with something too dumbed down and lacking in abstractions and expressive power. It feels like a step backwards coming from other contemporary and popular languages like JS/TS, Python, Kotlin, C#.
I agree with this, but I suspect I disagree on the extent to which this is a problem. These things are minor annoyances in my opinion compared to concerns that are largely apart from the actual language itself, such as performance, ecosystem, tooling, deployment story, learning curve, etc. With respect to Python and JS, you can always drop down to `interface{}` for similar expressive power and type safety, but genera…
Personally feel like rust is better overall, but I don't know if you've tried it
Earlier quoted context omitted.
TS and Golang aren't comparable. I use both and I've never had a case where I needed to decide between the two. Golang is a high performance, modern language without the low-level or legacy headaches of comparably performant languages. Golang was written for an era where network communication and concurrency are commonly necessities and those use cases feel very natural. Typescript is JS (a conversation ending advant…
I always cringe when people proclaim that they need to "get shit done". It often pays to be mindful of what is getting done as a result.
Earlier quoted context omitted.
I'm not the person you're responding to, but I think there is a difference between positive and negative posts in this context. Negativity is inherently bad. There is a place for it, of course, but when it's off-topic it's especially unwelcome in my opinion. And programming language discussion already has far too much negativity.
Many people find the "pozzy vibes only" philosophy much more annoying than relentless cynicism, which can at least be refuted by just ignoring it & building stuff.
Earlier quoted context omitted.
TS and Golang aren't comparable. I use both and I've never had a case where I needed to decide between the two. Golang is a high performance, modern language without the low-level or legacy headaches of comparably performant languages. Golang was written for an era where network communication and concurrency are commonly necessities and those use cases feel very natural. Typescript is JS (a conversation ending advant…
I always cringe when people proclaim that they need to "get shit done". It often pays to be mindful of what is getting done as a result.
Earlier quoted context omitted.
> it certainly seemed that specific GC latency issue they hit and blogged about would have been solved by upgrading to a modern Go version.... Do you know if that was the case when the decision to switch was made? They said elsewhere they tried Go 1.7-1.10 and none of those solved their issue, and at least back when the blog post was released I couldn't figure out whether the fix for the corresponding issue was known…
> Do you know if that was the case when the decision to switch was made? It’s a good question. The timing is a bit confusing because the blog was apparently published a bit after the fact, but I think I saw that they said they made the decision mid 2019. Go 1.12 seemed to address their latency issue, which was available as GA in Feb 2019. That’s based on some retroactive benchmarks on a set of old Go versions startin…
> Another Discord engineer chiming in here. I worked on trying to fix these spikes on the Go service for a couple weeks. We did indeed try moving up the latest Go at the time (1.10) but this had no effect.
So I guess that means that there's a reasonable chance that they didn't see a fix on the horizon.
That being said, I have no idea if work to fix this issue was visible on Go's Github, so maybe the Discord engineers were unaware of said work or were unhappy with the pace of progress.
Kind of miffed at myself for missing that comment, since it directly addresses my question, but at least it's answered now.
[0]: https://old.reddit.com/r/programming/comments/eyuebc/why_dis...