>everyone's pet feature Isn't that C#? Java is very slow at adding new features, Java has only things that were proved to work in other languages.
> It needs close parenting. Java has been ruined by the push to include everyone's pet feature. Oracle is moving to a faster cycle of development. There are some of us who strongly feel that some of their decisions are based less on what's best for the language and more on catering to the popular-and-loud crowd. I'll never forgive the addition of `var` to the language.
I mean go also has var for very similar reasons as java has it.
I'm going to risk being labeled an ~incompetent dev~ or whatever but learning golang was seriously a breath of fresh air compared to literally any language I have ever tried to grok before. Everything felt like it was there on purpose. It always seemed like there was a "proper" way to achieve something. Being told to use this opinionated formatter was like removing a 40kg bag after a bush walk. You never have to worr…
> I'm going to risk being labeled an ~incompetent dev~ Why is that? I thought your comment made a lot of sense.
A common HN trope is that Go doesn't have enough features (Generics usually) and gets in the way of '10x'/'competent' programmers expressing their genius - unlike Haskell (or some other advanced language for advanced minds)
It's a great example, as it shows the complexity of the discussed topic and attempt to justify any changes to the language/stdlib. In the above-mentioned comment rsc replies to another Googler, not to "community". So we have a) Google having problems with lack of monotonic clock in Go b) Go team reluctant to break API and break promise of compatibility without really serious reason c) community feedback in form of we…
Or, you can view this from another angle, that the golang authors yet again disregarded previous established work in the industry for the sake of avoiding hard work in the language and the compiler. It's no wonder the time package in golang is garbage compared to established offerings in mature languages like Java and C#.
It's no wonder that a new language is lacking the maturity and features of an old language. Of course you can attribute it to 'avoiding the hard work', but that's the same reason you don't live in a crystal castle. A more salient criticism would highlight what they have been spending their time on, rather than pointing out that they haven't spent much time on something.
Security consultant here. I have audited many codebases in many languages. Go is by far the easiest language to audit: it always looks the same, it's not too verbose, there are no generics or OOP. Coincidentally it's always the most secure as well. My take on this is that it is easier to see logic problems because it is easier to read, understand and reason about. On top of that the standard library does so much for…
> it's not too verbose
that's a really puzzling statement to me, maybe aside from C, C++, and Java, (and maybe rust) Go is certainly on the "more verbose" side.
Security consultant here. I have audited many codebases in many languages. Go is by far the easiest language to audit: it always looks the same, it's not too verbose, there are no generics or OOP. Coincidentally it's always the most secure as well. My take on this is that it is easier to see logic problems because it is easier to read, understand and reason about. On top of that the standard library does so much for…
Go already supports generics - the hashmap is generic, and the array is generic. It's just you can't implement your own hashmap in Go, and make it compile time type safe.
> It's just you can't implement your own hashmap in Go, and make it compile time type safe.
Then it doesn't support generics. That is the entire point of the feature.
I like Go a lot, but the fact that Google doesn't use it extensively in their own environment makes me wonder why that is. It almost feels like a Trojan horse.
That this very thread exists suggests a certain “C++ ification” that happens to languages. I really respect the slowness of the go maintainers in adding new stuff. I also suggest that we all ponder our tooling some; Writing java with emacs or vi is a materially different experience than using eclipse or idea and var style type-inference seems almost silly with those tools which do it for you.
>Writing java with emacs or vi is a materially different experience than using eclipse or idea and var style type-inference seems almost silly with those tools which do it for you. It's not so much the extra typing that's the problem, it's the extra reading. All the stuttering is visual noise.
This. If you want to revolutionize the profession, come up with something that helps with reading as much as modern IDEs help with writing. My answer is that boilerplate should be generated somewhere else and largely ignored.
Could you name some I’m pretty curious? For my use case it’s a no brainer because only PostgreSQL have a decent GIS extension, last time I checked Oracle was lagging well behind.
Like automatically refreshing materialized views, by which I mean when a base table is changed, the engine uses the definition of the materialized view to run triggers to update materialized view.
This is related to default implementation details, this behavior can be achieved using trigger/materialized view on PostgreSQL as well.
"Java has been ruined by the push to include everyone's pet feature." Care to expand on this? Java is very careful to release new features.
It's not about being careful (they are--but always with the baggage of backwards compatibility), it's about not having a soul. Java has made a U-turn in adding streams and related functional features on top of a language that used to be strongly for OOP (actually defining the meaning of OOP for a generation of developers.) These different paradigms together make for code that does not read the same no matter who writ…
> I love how Go code usually ends up being extremely similar, no matter who write is.
I want expert code to be concise and uncluttered. When everything reads like a novice wrote it, that's a problem.