TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Go and Java: Rethinking Type Safety for the Pragmatic Age

40 点作者 ocean_moist6 个月前

10 条评论

tialaramex6 个月前
Both languages don&#x27;t do much about Tony Hoare&#x27;s Billion Dollar Mistake, and to me that&#x27;s an immediate black mark on type safety, though they fail in this regard in distinct ways.<p>In Java all of your user defined types are, alas, represented only referentially and a null reference is always possible, so even if there is no such thing as an invalid Goose, your variable of type &quot;Goose&quot; may just be null anyway.<p>In Go, it&#x27;s possible to actually make a Goose and have it as just a local variable living on your stack, but, the language insists that anybody can conjure one into existence despite having no basis for doing so, the resulting Goose is at best now in some invalid &quot;null&quot; state.<p>To me, avoiding the Billion Dollar Mistake in new software is table stakes. Even at work, in the relatively boring C# language, we can avert the Billion Dollar Mistake in new codebases and gradually wean old ones off this idea. The CLR is hostile to properly fixing the mistake eco-system wide, but this is a marked improvement.
评论 #42250209 未加载
评论 #42250356 未加载
评论 #42250650 未加载
评论 #42250806 未加载
评论 #42250379 未加载
henryjcee6 个月前
As a Java&#x2F;Kotlin dev now writing Go for a living I agree with quite a bit in here and actually think both languages have things they could learn from the other.<p>Having said that I cannot understand where the idea that &quot;the [Go] libraries and ecosystem are so much better&quot; comes from. The average quality of both the JDK libs and the popular 3p libs (Jackson, Jooq, even ...Spring) are one of the things I miss most about writing for the JVM and I&#x27;m yet to come across another ecosystem that comes close.
评论 #42250346 未加载
评论 #42250727 未加载
评论 #42250217 未加载
zmmmmm6 个月前
Kotlin feels like the Go 2.0 that the author is looking for in many ways. It is interesting that Kotlin hasn&#x27;t fully taken off in the way you might expect.<p>Reflecting on my own reasons : it comes down to that I&#x27;m not particularly fond of IntelliJ and even less fond in principle of being critically dependent on a language that is only so controlled by a single vendor, and has poor IDE support outside that vendor&#x27;s IDE. If I loved IntelliJ I might not care.<p>However I also find that there is still impedance mismatch with Java and it&#x27;s <i>just</i> enough that I always just prefer to accept the warts of Java rather than use a language that is less known and supported.
评论 #42250634 未加载
norir6 个月前
&gt; Java is very “simple” precisely due to its verbosity.<p>The author and I clearly have different definitions of simple. Indeed, I believe that the syntax bloat of Java, which is not a source of simplicity, is a significant source of complexity and causes overengineered frameworks to proliferate in the ecosystem to make up for the language defects. Moreover, Java is full of features and keeps adding new ones every six months. Every new feature is more complexity, possibly added for a good reason, but nevertheless increasing the complexity of the language.
RadiozRadioz6 个月前
Java matches my &quot;taste&quot; much more than Go does. I appreciate the more powerful type system. I also like the verbosity because it&#x27;s always obvious what everything is - as it&#x27;s written out in full. Go&#x27;s compiler can infer types in lots of places, which is cool, but I appreciate being able to see the types when reading code &amp; refactoring Java. People complain about Java&#x27;s exceptions, but you can very easily create a Result&lt;Error, Value&gt; class for your own code, whereas it&#x27;s much harder to emulate exceptions in Go. As for comparing the different flavors of the billion dollar mistake: I also found `null` far easier to understand and not footgun myself than Go&#x27;s zero values &amp; nil.
jpgvm6 个月前
Ironically Javalin is largely written in Kotlin.<p>Kotlin (from the perspective of this blog post) stands above both Java and Go here because it&#x27;s type system is even more expressive, it has null safety and it&#x27;s less verbose than both.<p>I love Kotlin because it&#x27;s unapologetically pragmatic, it largely forgoes ideology and instead focuses on getting things done. Go and Java have ideologies and while I am more partial to the Java ideology over the Go one I would prefer to not have to subscribe to either.
评论 #42250558 未加载
t435626 个月前
Go feels like a giant hack and it&#x27;s opinionated approach to modules and libraries and where source files can live and embedding git urls in imports..... :-( Little bits of it are joyous - like goroutines and channels..and binaries that run on almost any distro without one needing to install something else first. I don&#x27;t need to use them often enough though. At certain points you have to do things that feel ugly.<p>Java is just the perfect home for type enthusiasts. You sit down to prototype some idea and you need to debate what kind of class structure it&#x27;s going to need for the first 25 minutes - something really abstract or something more short term...are you really going to develop this idea into something big with all sorts of generic high level classes or are you going to be cheap and short about it? Are cats and dogs the same from the point of view of this system or not?<p>In both of them people love writing the kind of code that jumps all over the place and injects all sorts of dependencies and just looking at it, it&#x27;s almost impossible to understand what anything is doing. There&#x27;s no such thing as &quot;TOO SOLID&quot;<p>I admit I have a very jaded view. C&#x2F;C++ have the freedom to put your source code wherever you like, compile it in parallel on a cluster or not and so on but then they are cursed to hell with the C preprocessor. Perhaps Turbo Pascal is nice?
wrs6 个月前
&quot;Write once, run anywhere&quot; specifically meant that the execution semantics and the interface to the environment (OS, storage, GUI, etc.) of a Java program are the same everywhere. Relating that to &quot;simple, secure, stable&quot; seems like a stretch -- of course there&#x27;s a little overlap in practice, but those are really four separate dimensions. Java has had its own long-running battles about simple, secure, and stable.<p>Of course, in reality the isolation isn&#x27;t perfect, which is how we got things like deterministic (slow) floating point and &quot;write once, test everywhere&quot;.<p>Go does have a similar attitude, practically speaking, if you stick to the standard library. It&#x27;s more like &quot;cross-compile and run wherever&quot;.
mongol6 个月前
If the future is a mix between the two, I would prefer starting from Go and adding ideas from Java, than the other way around. Go feels lighter, simpler, more pleasant to work with. But Java has had a lot of good ideas added over time that would be nice to see in Go.<p>I sometimes like to compare programming languages to vehicles. Java is perhaps the long haul truck and Go the smaller and more agile delivery van. The smaller van is more approriate for the things I work with for my own pleasure, but the truck has its places for the bigger enterprise jobs.
munificent6 个月前
If you like both object-oriented programming and sum&#x2F;product types with deep support for pattern matching, you might like Dart.<p><a href="https:&#x2F;&#x2F;dart.dev&#x2F;language&#x2F;records" rel="nofollow">https:&#x2F;&#x2F;dart.dev&#x2F;language&#x2F;records</a><p><a href="https:&#x2F;&#x2F;dart.dev&#x2F;language&#x2F;patterns#algebraic-data-types" rel="nofollow">https:&#x2F;&#x2F;dart.dev&#x2F;language&#x2F;patterns#algebraic-data-types</a><p><a href="https:&#x2F;&#x2F;dart.dev&#x2F;language&#x2F;patterns" rel="nofollow">https:&#x2F;&#x2F;dart.dev&#x2F;language&#x2F;patterns</a>
评论 #42250537 未加载