Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lies we tell ourselves to keep using Golang

fasterthanli.me

Post reply on HN
Print view View original

501–510 of 561 posts

Re: Lies we tell ourselves to keep using Golang

#501

Post by ohgodplsno »

lupire wrote: post #496
ohgodplsno wrote: post #477

Earlier quoted context omitted.

Kotlin is quite explicit about nulls. Kotlin code requires you to use Type? if the value can ever be null. Java code that is annotated by @Nullable/@NonNull will automatically map to Type?/Type (and it is up of course to the developer to not fuck up their nullability promises.) Java code that is not annotated is a Type!, and encourages you to be wary about what could happen. The nullability story is miles better than…

If you enable nullness checks, Java is the same.

No such thing as nullness checks in Java. At best, your IDE is taking the annotations into account and giving you warnings. At worst, you have to run ErrorProne and have it yell at you.

Additionally, all Java code (including the one you wrote) is only optionally null checked. All Kotlin code _is_ null checked, no matter what.

Re: Lies we tell ourselves to keep using Golang

#502

Post by hu3 »

jhugo wrote: post #490
hu3 wrote: post #483

Earlier quoted context omitted.

> It's been almost 24 hours since it was posted, a majority of posts are buried by then. No. Here's a post with much less upvotes, much less comments still on page 2: https://news.ycombinator.com/item?id=31205139 There are many other examples if you care to compare. Meanwhile this post is nowhere to be seen because most conversation here is not up to HN standards. Flagging is detrimental to post ranking. And rightful…

... really? Come on. As of this writing, 29 out of 30 posts on page 2 are younger than this post. 30 out of 30 posts on page 3 are younger than this post. 29 out of 30 posts on page 4 are younger than this post. I could keep going. The fact that you can find one outlier and then wave your hands and say "there are many more" doesn't make your argument reasonable. > Flagging is detrimental to post ranking. And rightful…

You should have kept going on.

There are multiple posts older than this one that are listed within the first 9 pages, some of them 2 days older even. While this one isn't.

Take a guess why :)

Re: Lies we tell ourselves to keep using Golang

#503

Post by tptacek »

mumblemumble wrote: post #472
pvg wrote: post #429

Earlier quoted context omitted.

Well, yeah, that's your suspicion but it is not an argument, it's just a suspicion that something nefarious is going on. I don't think you've really responded to any of the explanations of why HN works this way. That doesn't mean the way HN works is right but you have to bring something more to it than aspersions if you want to argue for change.

"nefarious"? "nothing more to it than aspersions"? Please don't strawman me like that. If you're going to make "the rules of HN dupery" the place where you want to make your stand, then this seems like a peculiar response. These rules for HN dupery are not actually published anywhere outside of HN mod team comments when debates like this come up. By contrast, though, the published commenting guidelines clearly state…

Many of the rules of HN aren't published in a straightforward list; you learn them by following the log of moderator comments. That, too, has been has been explained innumerable times on HN: it's a common law system, not a civil law one, because if you build a site for nerds around a rigid set of enumerated statutes, the nerds will spend most of their time looking for clever loopholes (I'm not disparaging them; I'm one of them).

From the way you've written on this thread, it seems pretty clear that you're not the kind of message board nerd that makes 'dang's comments a daily read. That's fine! You have to be a pretty extreme nerd to do that, and there other, probably better things to spend those nerd points on. But you should take 'pvg's word for it on this stuff. He's not messing with you: he's trying to explain to you how the site works.

Re: Lies we tell ourselves to keep using Golang

#504

Post by warabe »

lupire wrote: post #493
ay wrote: post #404

Earlier quoted context omitted.

My experience in writing a small side project in both (on the order of 2-3 KLOC) was that the time to a working project is significantly shorter with golang. The time to the correctly working project was about the same between the two. Golang gets out of the way in me doing what I want. Rust actively resists me doing things I will later regret. Also, unexpectedly, I have gotten some positive comments on my C coding s…

99% of people don't need "correctly" working projects. Trillion dollar companies run on "incorrect" software.

Then, it's time to move on.

It is impossible to run "correct" software, but we can do better, maybe?

Re: Lies we tell ourselves to keep using Golang

#505

Post by the_gipsy »

mumblemumble wrote: post #475
the_gipsy wrote: post #458

Earlier quoted context omitted.

Had the same experience with Scala. Oh, Option types? Cool! Wait, why am I getting NPEs??? Oh, we're using some java library, nulls galore!

I've come to the conclusion that, for the most part, option types make no sense in object-oriented languages. There are exceptions, but they tend to fall into "proves the rule" territory. OCaml, for example. Not just because of the null problem. It's also that option types push you toward a "conditional logic everywhere" way of doing things, because that's how you handle the options. That's all well and good and holy…

> it's the opposite of good object-oriented design.

So what is good OO design? NPEs? Nil checks?

Re: Lies we tell ourselves to keep using Golang

#506

Post by azth »

pphysch wrote: post #491
azth wrote: post #445

Earlier quoted context omitted.

protobuf has issues with optional fields, as was pointed out in the post. Couple that with a language with a weak type system like golang (no sum types), and it's very verbose and slow to develop in. Targeting better languages helps alleviate the latter.

Ok, what's your alternative?

Because all protobuf fields are optional, they should be translated into optional fields in the target language (e.g. Optional).

Re: Lies we tell ourselves to keep using Golang

#507

Post by nevi-me »

cglan wrote: post #254
noisy_boy wrote: post #234

Earlier quoted context omitted.

> Or dealing with impossible to trace errors in Spring Boot. Spring Boot is not Java. You can debug Java just as easily. On the upside, you can probably get the same stuff done in probably one third less code + use the vast ecosystem. On the downside, compilation may be a bit slower and you don't get a nice little executable out of the box. I wrote a tool in Golang and while it did everything as advertised, the boile…

I don’t think I’ve ever seen Java used in isolation without spring boot

Not a CS, but a damn good technical accountant and well self-taught developer.

I led a team that wrote an accounting & reporting software for a specific technical problem. We had an architect who only knew Spring, and hasn't been out there pretty much in a decade.

I clashed severely with him, to the point where he made an arrogant argument about something he was clearly wrong with. He said "I bet my salary that you're wrong" in front of people. I bet mine too, and the following day I demonstrated that he was wrong. I gave him my bank account (it was pay day). It was a hard bet to lose, so I said he didn't need to pay it, and I asked him to be removed from the team (because he showed that he wouldn't learn).

We went on to build the system without Spring, without TomCat and with more freedom to write SAL where an ORM couldn't solve the problem better.

Interestingly, we used grpc between the front-end and the backend JVM microservices.

As other people say, check out projects in GitHub. Look at what new Java, Kotlin, Scala projects look like.

There's a lot of interesting stuff in JVM-land that don't touch Spring.

Interestingly on the software that we wrote, compute was the biggest bottleneck. I rewrote some parts in Rust, but ended up canning the work because nobody else would be able or willing to touch the code.

Re: Lies we tell ourselves to keep using Golang

#508

Post by afdbcreid »

weinzierl wrote: post #277
HL33tibCe7 wrote: post #98

The author writes well and makes compelling points. His "I want to get off Mr Golang's Wild Ride" post is good too. But I don't find myself agreeing with his position, which is "you shouldn't use Go for production services" (he explicitly says this in one of his Go posts, I forget which one and don't have time to look right now). The better alternative to Go is Rust. Okay, sure, I'm willing to admit that in the examp…

> "Even worse is the async story, in Rust you have to decide whether to use Tokio or whatever." I think this is going to change. I couldn't find the relevant blog post now, but I believe to remember there was an initiative to provide a standard async runtime.

No. Rust may provide some small async runtime for tutorials etc., but it'll never provide a rich async runtime like tokio because different people have different requirements from their runtime and Rust wants to satisfy them all.

What is planned is to standardize the API: that is, provide common traits for IO, tasks, etc. so libraries can be runtime-agnostic and you can change your runtime by only touching Cargo.toml (hopefully).

Re: Lies we tell ourselves to keep using Golang

#509

Post by zigger69 »

blindseer wrote: post #100

I've used Go and Rust professionally and in side projects, and I had used Go first before Rust. When I first used Go, I was like "oh wow, this is so simple and easy", and I didn't realize that I was putting up with the language. Learning Rust was relatively harder, but once I did and wrote some non trivial programs in Rust, it was like a pathway in my brain opened up and was previously blocked, and then when I went b…

> I do think on a long enough timescale, programmers will eventually move to a "better" language. But in my opinion, that time scale exceeds the lifespan of a human :)

Zig exists and is here today.

Re: Lies we tell ourselves to keep using Golang

#510

Post by zigger69 »

SeanLuke wrote: post #27

I don't know nothin' about Go. But this complaint really surprised me: > Go not letting you do operator overloading, harking back to the Java days where a == b isn't the same as a.equals(b) Does this guy really not understand that in a mutable language, (eq ...) is not the same as (equalp ...) and should never be confused with it? Also: operator overloading is the spawn of Satan.

> Also: operator overloading is the spawn of Satan.

It is. And I'm glad Zig has none of that. `==` only works for primitives and you will never be confused.

Post reply on HN