351–360 of 477 posts
Why is this flagged? I read the first page or so. I don't think I'm going to read it to the end, but it doesn't seem something that should be removed from the HN frontpage.
The author fundamentally misunderstands language design. He picks an arbitrary design constraint, in this case correctness, and argues that any language that does not provide 100% correctness is bad. He uses Rust for his examples, a language that has correctness as one of its top design goals, and contrasts it with Go, for which correctness is not that important. So of course Rust will come out on top when the only m…
What an extremely convenient template to dismiss any nuanced argument against "worse is better". You even get to question my credentials a couple times! (I apparently pick metrics that are convenient to my argument, and fundamentally misunderstand programming language design). Even if I accept the premise that "I'm challenging Go on things it doesn't promise to deliver" (which is disingenuous to begin with — correctn…
Author here: I wrote this in 2020, have changed jobs twice since. Both jobs involved Go in some capacity, where it's supposed to shine (web services). It has not been a pleasant experience either - I've lost count of the amount of incidents directly caused by poor error handling, or Go default values. If folks walk away with only one new thought from this, please let it be that: defaults matter. Go lets you whip some…
Is the Rust FFI story much better?
Serious question: I have a Go code base with performance-sensitive inner loops. Considering options now for the longer term.
This is a long blog post which is a huge rant, and honestly I find the whole tone extremely unproductive. # Point 1: Judging a tool (programming language) out of context (project) For some reason programmers really like to talk about the merits of programming languages without specifying anything about the context you're using it in. This article talks a lot about how Go handles its Windows support, yet the conclusio…
I'm baffled that the Go designers for a long time basically considered generics to be harmful - but had no problems adding reflection to the language.
Reflection is essential for things like code generation and introspection in go. It isn't something you can classify as wholly harmful. It is of course possible to write bad code using reflection, but not having reflection isn't the solution. https://go.dev/blog/laws-of-reflection
So I'm surprised that Go considers generics more harmful than reflection.
I liked the article. I think it was really well written and these are great points. So if not Go, then what's the alternative? I too am starting to feel a bit burnt out by some of Go's deficiencies, but one of the things I really like about Go is its concurrency model. What other languages have great concurrency models? Please keep in mind that I want to keep things simple... having a single binary to deploy is incre…
> I'd really like to avoid getting into Elixir/Erlang world or any kind of interpreted language that will complicate the deployment process For what it's worth, the deployment story for Elixir is great. Erlang has a built-in concept of "releases", which Elixir supports natively. In essence, it compiles all dependencies and outputs a directory containing the VM, and all the compiled bytecode. After that, you just copy…
Earlier quoted context omitted.
What an extremely convenient template to dismiss any nuanced argument against "worse is better". You even get to question my credentials a couple times! (I apparently pick metrics that are convenient to my argument, and fundamentally misunderstand programming language design). Even if I accept the premise that "I'm challenging Go on things it doesn't promise to deliver" (which is disingenuous to begin with — correctn…
> What an extremely convenient template to dismiss any nuanced argument against "worse is better". You say that like its a bad thing. If there is an easy template to dismiss your argument, it means you did a bad job arguing. Part of making a good argument is anticipating likely objections and addressing then in your argument
The author fundamentally misunderstands language design. He picks an arbitrary design constraint, in this case correctness, and argues that any language that does not provide 100% correctness is bad. He uses Rust for his examples, a language that has correctness as one of its top design goals, and contrasts it with Go, for which correctness is not that important. So of course Rust will come out on top when the only m…
What an extremely convenient template to dismiss any nuanced argument against "worse is better". You even get to question my credentials a couple times! (I apparently pick metrics that are convenient to my argument, and fundamentally misunderstand programming language design). Even if I accept the premise that "I'm challenging Go on things it doesn't promise to deliver" (which is disingenuous to begin with — correctn…
Well that’s a subjective statement. Are you basing that data or just your own feeling?
I love writing Go and I’m way faster in Go than Rust. If I need more acceleration, of course Rust is the place to be, but if I just need to hammer out an API, Go is going to be much easier to do that in. Also my code will be far more consumable than Rust because it’s way less complex and has enforced opinions.
> If you don't, you're just pushing the problem onto someone else.
Really? Maybe that happens occasionally but I’ve never had that happen. My Go services have been incredibly stable and easy to develop on.
With Rust your are pushing onto others code that’s very hard to understand because it’s a kitchen sink like c++. Go believes community is greater than the individual so it’s opinionated.
In general, I found this post incredibly inflammatory. Different tools are good at different things. Rust isn’t a panacea, neither is Go, but yes Go hits a sweet spot of lower level with rapid development. Why is that controversial to you?
Earlier quoted context omitted.
You can't base your opinion on anything, particularly computer languages, off of your Discord experience, come on. The Discord demographic is teenagers and young adults, that's the last place where you'd find professional and mature advice about a programming language. I mean, even Reddit is better, and it still is a cesspool.
I've found the rust discord nice and respectful (although I'm also a young adult). I also don't think [edit: PL] reddit is particularly a cesspool, at least compared to HN.
Earlier quoted context omitted.
I've done pet projects in Haskell, Ocaml, Racket, Rust... Now I'm learning Zig... I've worked for years with Java, Python, Javascript/Typescript... Use to work with Z3... Tried plenty of different stuff. After years my conclusion is that If I want to get a job done I'll choose Golang. Hands down the best productivity programming language nowadays. GC for memory management and productivity, explicit, easy to read, har…
I've done all kinds of stuff too, and agree that Go is pretty good to "get things done", especially networking. But I don't know about best. Maybe ten years ago when a static binary was important, but now that everything is deployed as a container, that's off the table and things like Python or Kotlin are equally deployable, but way easier to use. Nowadays, if you _really_ need a single binary, you probably also need…