I Want Off Mr. Golang's Wild Ride • Hacker News Board

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

#191

Post by masklinn » Fri, Feb 28, 2020, 6:55 PM UTC

sagichmal wrote: post #147

whateveracct wrote: post #77

Here's an example of why Go's simplicity is complicated: Say I want to take a uuid.UUID [1] and use it as my id type for some database structs. At first, I just use naked UUIDs as the struct field types, but as my project grows, I find that it would be nice to give them all unique types to both avoid mixups and to make all my query functions clearer as to which id they are using. type DogId uuid.UUID type CatId uuid.…

Type aliases (type X = Y) are a niche feature and not meant for this use case. If you had done e.g. type X Y you would have had more success.

I think the OP simply wrote them the wrong way around, because `type X = Y` would not have broken anything as it'd make X a trivial alias to Y, and thus would not be losing anything. Even the reflected name doesn't change from the original.

type X Y however does create an entirely new type which is physically identical to the original but logically unrelated (without any of the methods or anything).

Which is fine in the sense that it's what OP was looking for (completely independent types) but less so in that it doesn't forward any method, and it's not necessarily clear how you'd do that (type conversion, which looks really shitty when it involves pointers)

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

#192

Post by draw_down » Fri, Feb 28, 2020, 6:55 PM UTC

I think this is a great, in-depth examination of why your spidey senses should be tingling when you hear about something being "simple". "Simple" at this point means "something I like", and "complexity" are all the things I don't like.

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

#193

Post by skrtskrt » Fri, Feb 28, 2020, 6:56 PM UTC

whateveracct wrote: post #77

Here's an example of why Go's simplicity is complicated: Say I want to take a uuid.UUID [1] and use it as my id type for some database structs. At first, I just use naked UUIDs as the struct field types, but as my project grows, I find that it would be nice to give them all unique types to both avoid mixups and to make all my query functions clearer as to which id they are using. type DogId uuid.UUID type CatId uuid.…

I'm not sure, I kind of like this?

Personally I would never create different UUID types for each DB struct, and have never seen that done.

    type DogId struct { uuid.UUID }

is type composition (Sorry if I'm not using the right term there). Isn't this exactly how you're supposed to do what you're trying to do in Go?

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

#194

Post by zxcvbn4038 » Fri, Feb 28, 2020, 6:57 PM UTC

What is the point of a ten page rant like this? If the guy doesn’t like coding in Go, just stop using Go, problem solved. How many more times are we have to have the language X is different then language Y and I hate feature Z discussion? These are popping up almost daily. We could probably automate generating a daily rant with commentary, and let all the Joe Nobody coders get back to whatever they are trying to accomplish.

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

#195

Post by tedmielczarek » Fri, Feb 28, 2020, 6:58 PM UTC

thestoicattack wrote: post #178

tedmielczarek wrote: post #171

Earlier quoted context omitted.

I'm not sure there's a meaningful distinction to be drawn there for the vast majority of usage, to be honest. A language's standard library is generally considered to be part and parcel of the language. Everyone's first sample program is "Hello World" which involves printing text to standard output. That being said, languages that do offer the ability to work without the standard library give you a lot of flexibility…

C and C++ don't have good stories for working on embedded systems without a standard library?

Not in the language standard they don't, no. The C99 standard basically says "good luck with that":

"5.1.2.1 Freestanding environment

1. In a freestanding environment (in which C program execution may take place without any benefit of an operating system), the name and type of the function called at program startup are implementation-defined. Any library facilities available to a freestanding program, other than the minimal set required by clause 4, are implementation-defined.

2. The effect of program termination in a freestanding environment is implementation-defined."

There are obviously numerous embedded toolchains that provide facilities for writing C/C++ to target embedded systems but they're generally all doing nonstandard things and every one is its own unique fork of GCC.

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

#196

Post by objektif » Fri, Feb 28, 2020, 6:58 PM UTC

jsjddbbwj wrote: post #74

objektif wrote: post #72

Earlier quoted context omitted.

You dont have to call Python sloppy just because Go sucks at some things.

Weakly typed is sloppy.

Sucking at certain things is sloppy. Weak type is not. Python is a much better language than Go in almost every aspect.

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

#197

Post by klodolph » Fri, Feb 28, 2020, 6:58 PM UTC

tedmielczarek wrote: post #184

klodolph wrote: post #149

With the path example… just try to combine this with flags, so we do something like: $ ./my_program --file="$(printf "\xbd\xb2\x3d\xbc\x20\xe2\x8c\x98")" Well, just try to write the program that does that in Rust, without using some option-parsing library that hides all the details, and then try to figure out how to get it to work equally on Windows. To spoil the answer, it turns out that OsString only exposes a coup…

The point isn't that it should be easy to do terrible broken things like this. The point is that you will encounter these things in the real world and have to deal with them in some way. Rust's OsStr[ing] let you do that. If you really have a burning need to create files whose paths are not valid Unicode you can do that in Rust but you will have to jump through some hoops. I don't see that as a problem.

I’m not saying that it should be easy, just that the API shouldn’t introduce significant amounts of additional complexity.

For the very simple case of "I want a command-line option which specifies a path as an OsString", Rust’s way of doing things makes things hard. By comparison, in C++, I am used to dealing with paths as std::string on Unix and std::wstring or std::u16string on Windows, and this C++ approach is a lot easier.

Rust’s OsString design is too smart by half, and if I use env::args_os(), I can’t easily do simple tasks like "test if this string starts with '-'" or "split this string by the first '=', if it exists". As far as I can tell, the way to go is to convert OsString to Vec, do your processing there, and then convert back… but that only works on Unix, because arbitrary Vec aren’t safe to convert back to OsString on Windows because they may not be valid WTF-8. So you can take the approach on Windows of going through encode_wide().collect() and it just goes downhill from there. :-(

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

#198

Post by saityi » Fri, Feb 28, 2020, 6:59 PM UTC

bsimpson wrote: post #181

> Nine out of ten software engineers agree: it's a miracle anything works at all There was a beautiful rant about a decade ago called something like "everything's broken all the time and nobody cares." The gist of it is that all software is written by people. Anyone who's written software knows that it's usually riddled with hidden corner cases, unfortunate tradeoffs, rushed deadlines, etc. Software is also moving in…

The first article that comes to mind for me is Programming Sucks, although it's not quite the same as your description.

https://www.stilldrinking.org/programming-sucks

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

#199

Post by hota_mazi » Fri, Feb 28, 2020, 7:00 PM UTC

philwelch wrote: post #151

hota_mazi wrote: post #129

Earlier quoted context omitted.

The language should make you handle the error and the compiler should refuse to compile your code until you have done so.

So checked exceptions, then?

That's one way, yes.

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

#200

Post by dom96 » Fri, Feb 28, 2020, 7:01 PM UTC

dilap wrote: post #23

If you imagine a spectrum of languages from sloppy-but-"easy" to precise-but-"hard", with something like Python or Ruby way off on the left and something like Rust way off on the right, Go is sitting somewhere in the middle. And so if what you're craving is absolute precision and maximal avoidance of errors or incorrect behavior, then Go is not going to be your jam. I sympathize w/ that. That said, these specific com…

If Go is somewhere in the middle and Rust is on the right then Nim is somewhere in between Go and Rust.

Personally I think that’s the sweet spot, and now that Nim is at 1.0 there is no excuse not to give it a try. As nice as Rust’s compile-time memory management is, it’s very often overkill.