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

I Want Off Mr. Golang's Wild Ride

fasterthanli.me

Post reply on HN
Print view View original

431–440 of 508 posts

Re: I Want Off Mr. Golang's Wild Ride

#431

Post by nickm12 »

umvi wrote: post #2

Maybe I'm a zealot, but I don't really consider "doesn't work as well on windows" a con of a language. C# is (or at least used to be) utter garbage on Linux compared to Windows. I don't hold that against C#, but rather recognize that Linux/Windows are very different, and that compiler maintenance and development is non-trivial (and obviously Microsoft is going to prioritize Windows). This article is basically a rant…

The gripe was not that it doesn't work well on Windows. It was about a culture of not caring about getting details right or valuing correctness. Windows was just used as an example of not caring about correctness. The time API was another.

Re: I Want Off Mr. Golang's Wild Ride

#432

Post by FridgeSeal »

taylodl wrote: post #413
bshacklett wrote: post #378

Earlier quoted context omitted.

Unfortunately that's becoming increasingly difficult with the amount of programs written in go that touch developers lives on a regular basis. Kubernetes, for example, is written in go. Want to fix a bug? You're now at least a part-time Gopher. I don't think we've seen the likes of this since PHP.

Kubernetes is always brought up when discussing Go. I wonder if Go might ultimately be its Achilles' heel? If so, I wonder how that might manifest itself?

I cannot assert to the full correctness, and I’m aware of the heresay-ness of it, but I’ve seen discussion before on how much “hacking around the lack of generics is in the Kubernetes codebase”

Re: I Want Off Mr. Golang's Wild Ride

#433

Post by nogridbag »

dehrmann wrote: post #421
alexhutcheson wrote: post #288

Earlier quoted context omitted.

The author of Joda-Time actually thinks that even Joda-Time didn't get it quite right, and believes the java.time libraries in Java 8 and above (aka JSR-310[1]) are better than Joda-Time: https://blog.joda.org/2009/11/why-jsr-310-isn-joda-time_4941... It turns out that abstractions for time are really hard to get right. [1] https://jcp.org/en/jsr/detail?id=310

Props to him for not having an ego with that. Jodatime even recommends using JSR-310 time for new development.

The author of Joda was the primary person responsible for the new Java Date and Time API (JSR-310).

Re: I Want Off Mr. Golang's Wild Ride

#434

Post by pjmlp »

dwohnitmok wrote: post #430
pron wrote: post #271

Earlier quoted context omitted.

There is a clear distinction. RuntimeException (and descendants) is an internal problem (e.g. divide-by-zero); Error (and descendants) is a VM-internal problem (stack overflow, OOM); checked exceptions are external problems (e.g. IO exceptions).

Yeah... but checked exceptions are controversial within the Java community to say the least. Some codebases eschew checked exceptions altogether, rewrapping any checked exceptions they find. This is in contrast to how sharp of a divide the community observes around Error vs Exception. In practice there's a lot of Java code that collapses "internal" and "external" errors into unchecked exceptions.

The blame Java gets for checked exceptions its unfair.

Firstly, CLU and C++ were there first, so the language designers were building on something that they though was a trend that would carry on.

Most never having learned how checked exceptions were done in CLU and C++, blame Java for them.

Then even though it is more convenient to work without them, I do miss in other languages, because developers hate documentation, so I have to keep fixing code or just had a catch all handler, just in case.

Re: I Want Off Mr. Golang's Wild Ride

#435

Post by Dylan16807 »

erik_seaberg wrote: post #422
ben509 wrote: post #384

Earlier quoted context omitted.

In fairness to Windows and Java, they weren't wrong. There was no UTF-16, rather, UCS-2 was the accepted standard because the plan for Unicode was to encompass languages in use, not emojis and historical langauges. That changed and we're stuck with that legacy.

Even without emoji, mashing up Chinese, Japanese, and Korean to fit in 21k was never going to happen. It’s sort of like asking Danes to stop spelling their names correctly because we can't afford the extra codepoint for “å”. https://en.wikipedia.org/wiki/Han_unification#Rationale_and_...

What I don't understand is how they miscounted so badly. Even ignoring Han unification, Chinese by itself uses more than 65k.

Or was there an intent to not encode some of these rarer characters? I haven't been able to find any info.

Re: I Want Off Mr. Golang's Wild Ride

#436

Post by masklinn »

usddddd wrote: post #305
munk-a wrote: post #238

Earlier quoted context omitted.

Being unaware of an exception thrown by a function when calling it in Java will cause compilers to bark at you - while doing the same in go will work until it doesn't. I think this is even more insidious with changes in third party code over time though - did the package your gigantic product uses to validate that a phone number is in European time just add an error return value to a function that previously had none…

Go will most certainly notify you if a 3rd party API suddenly returns a new error. Typically you would see an assignment mismatch.

The only situation in which that will happen is a function going from returning a value to returning a value and an error and you were actually getting & using the value.

If a function starts returning more variable errors Go likely won’t tell you (though in fairness that’s a pretty common issue).

If a function was not returning anything or you did not care for the value it returned, it adding an error will be a completely invisible event.

Re: I Want Off Mr. Golang's Wild Ride

#437

Post by Dylan16807 »

ajross wrote: post #419
int_19h wrote: post #415

Earlier quoted context omitted.

The whole point of OP is that many Go-internal features shouldn't be internal.

And my whole response is that that notion of "shouldn't" reflects an aesthetic or moral argument and not a technical one. How Go is implemented says nothing about whether Go is a good language or not.

If I understand you right, your entire argument depends on counting "Go exposes X internal feature" and "Go exposes something equivalent to X internal feature" as different things.

Because demanding Go do either one is an engineering argument.

But demanding the former over the latter is an 'aesthetic or moral' argument.

Well, nobody else is making that distinction! They're only making the engineering argument! You're interpreting their words way too literally if you think they're making the aesthetic argument.

Re: I Want Off Mr. Golang's Wild Ride

#438

Post by klohto »

ainiriand wrote: post #391
klohto wrote: post #156

Earlier quoted context omitted.

I seriously hate this argument. Go and have a look at the issue the golang is discussing currently. Do you seriously think that everything can be fixed by a simple request? Most of the time it wouldn't fit with the way Golang is going. It's not a critique of some bugs in Golang source code but the mentality and flow surrounding changes. Do you except the author that submitted change overhauling the whole way Golang h…

Obviously what I mentioned is just an oversimplification. I expect that when some particular piece of software (open source in this case) is causing major trouble to a big chunk of its users, they get together to fix it. In the particular case of this user, some of the problems are are really related so I can imagine that if they were widespread it would´ve been taken care of. I am sorry for using sarcasm to take a d…

Apologizes for not getting the sarcasm, it seemed real enough.

Re: I Want Off Mr. Golang's Wild Ride

#439

Post by pjmlp »

Fellshard wrote: post #311
klodolph wrote: post #251

Earlier quoted context omitted.

The problem is that this is not good enough. It’s not uncommon to need to do a small amount of manipulation of OsString and there is no good way to do it. In C++, it’s fairly easy. In Rust, it’s a damn nightmare. In theory, in Rust, since OsString is basically Vec on the inside (like String), you could implement e.g. Path::has_extension in the same way as str::ends_with. However, anyone who has gone in and tried to i…

Is that not the point? That you ought to map out that complexity in a type whose constraints must be satisfied in order to have a valid instance? If your string is invalid to start with and you need to correct it, then yes, you need to wrangle that complexity yourself. If you need some tools from another toolset - eg. String functions that can help you make a valid Path - then you will make multiple type conversion h…

The point is that should be part of the standard library, like wstring in C++.

Re: I Want Off Mr. Golang's Wild Ride

#440

Post by [deleted] »

gwd wrote: post #331
whateveracct wrote: post #157

Earlier quoted context omitted.

Is there a database library that uses reflection that properly descends into type aliases? Probably not, because it isn't always what you want. It's still fundamentally caused by Go's shitty design choices. encoding/json is at fault as well, which is also in the stdlib and a flagship library (basically part of the language - the maintainers wouldn't even extend its struct tag parsing to allow for required fields it's…

> It's still fundamentally caused by Go's shitty design choices. I mean, come on. In your playground example, one way of using the UUID type inherits its methods and another doesn't. Inheritance is inherently complicated, and if you're relying on it you need to know what you're doing, no matter what language you're using. I wouldn't call that a poor design choice.

[deleted]
Post reply on HN