241–250 of 291 posts
Go is an example of how to be extremely successful by catering to the needs of the project's core audience (well-rounded stdlib, extremely fast GC, short build times, trivial deployment, etc) while paying much less attention to the vocal minority's complaints (generics, package system, etc).
How do you know that go would be less popular if it had generics and package system?
Earlier quoted context omitted.
> by far most of the Go developers still prefer to use the language without generics I've been writing Go regularly for at least 5 years, and my guess is that at most 60% of Go developers prefer no generics. I also think that number is climbing.
I write Go at work but have never heard anyone say this. Can you explain why you would prefer no generics to this dumb junior engineer who wants to be enlightened?
Things I love about go: 1. Probably the best ecosystem out there. 2. Go routines 3. (Enabled by (2) actually) `defer` 4. That I can add interfaces implementations to structs I don’t own 5. No exceptions. Actually (5) is one of the few things I don’t like about Haskell. If Go had ADTs and generics it would easily be my favorite language. Edit: and of course the channels. Edit2: yeah, i have no idea why i connected (2)…
The best ecosystem out there? Since when? I'd say that Java and Python have huge, wonderful and full ecosystems. Golang doesn't even come close to that, yet. Furthermore, Golang doesn't even have a community standard (or several standards) dependency manager.
There is nothing like Django in Java land? Instead you are sent into a confusing mess of interface standards like JPA and implementations (hibernate, ebeans, ...) and little guidance how to choose.
Earlier quoted context omitted.
i don't think you can "catch up" with go, because it has aimed at being minimalist. catching up by removing major features to a language isn't something i've ever witnessed.
> because it has aimed at being minimalist. You can absolutely catch up with the concurrency model, on the single binary deployment, and a other features. Go isn't "minimalist", that's false, go look at the reflect package, it's complex as hell.
Go is radically minimalist compared to other languages - it leaves a lot out, most notably inheritance.
Things I love about go: 1. Probably the best ecosystem out there. 2. Go routines 3. (Enabled by (2) actually) `defer` 4. That I can add interfaces implementations to structs I don’t own 5. No exceptions. Actually (5) is one of the few things I don’t like about Haskell. If Go had ADTs and generics it would easily be my favorite language. Edit: and of course the channels. Edit2: yeah, i have no idea why i connected (2)…
Lack of exceptions is the main reason I won't use it.
Earlier quoted context omitted.
I discovered Waitgroups during the project, but I have no formal training in concurrent programming, so it was a bit daunting for me. And as the error occured very rarely I could not be sure if using a mutex had solved my problem. But now I understand mutex was the way to go for accessing a shared resource. As for the second point, sorry for the wrong wording, I meant "methods". But interfaces don't work like that ev…
Java interfaces don't have properties either (nor do Java classes), and you can explicitly state interface conformance in Go as well as others have explained elsewhere in this debate: https://news.ycombinator.com/item?id=15672619 What Java does have (since 8) is default method implementations in interfaces.
Interfaces cannot require instance variables to be defined -- only methods.
(Variables can be defined in interfaces, but they do not behave as might be expected: they are treated as final static.)(Another useful link explaining that statements resembling instance variables in interfaces are in fact constants: https://coderanch.com/t/178630/certification/Instance-variab...)
Earlier quoted context omitted.
We’ve actually worked a lot to ensure that Mozilla can’t dictate what happens with Rust; we run a consensus based process, and while Mozilla has the largest single group of people involved in leadership, it’s still a very stark minority. As a huge production user, Mozilla’s needs are still important to us, but we think of Rust as an open source project Mozilla contributes to, not a Mozilla project per se.
I wonder if this is good or bad. Sometimes it helps to have that singular vision. I think here of all the systems C coders I know, who have never used complex numbers, yet that finds its way into the standard.
Earlier quoted context omitted.
Python's packaging is a nightmare of half-baked, incompatible approaches that puts the lie to the famous "Zen of Python" that "There should be one-- and preferably only one --obvious way to do it."
And yet pip has just worked for me. Can’t say the same about any of the go dep tools.
Earlier quoted context omitted.
No, it's saying: if my goroutines crash it's the same as if my main thread crashed, which means: game over, application down. Which gets handled by the container scheduler
So every unrelated request that happened to be currently processed is thrown away because of a rare corner case, and with no way to intercept shutdown and save state, flush buffers, or anything. Yes, totally right granulation. Not to mention that you have just introduced a very complicated piece of software to run a single daemon.
Things I love about go: 1. Probably the best ecosystem out there. 2. Go routines 3. (Enabled by (2) actually) `defer` 4. That I can add interfaces implementations to structs I don’t own 5. No exceptions. Actually (5) is one of the few things I don’t like about Haskell. If Go had ADTs and generics it would easily be my favorite language. Edit: and of course the channels. Edit2: yeah, i have no idea why i connected (2)…
> If Go had ADTs In the process of hacking on my PureScript2Golang "transcompiler", I've realized that under the hood ADTs, also known as "tagged unions", will likely more often than not be represented exactly as just that: a "tag flag" and a data pointer. (Of course if all of an ADT's ctors are nullary, an enumish int will do the trick just as well --- I doubt this gains anything over interface{}-boxed 0-size struct…