[deleted]
I Want Off Mr. Golang's Wild Ride
241–250 of 508 posts
Re: I Want Off Mr. Golang's Wild Ride
#242Earlier quoted context omitted.
A type alias binds a new name to a type. All of the type’s methods are available through the new name.
I fixed my comment. I didn't mean to have equal signs in there. Proof that `type X Y` causes the issue: https://play.golang.org/p/erfcSIe-Z7b
The type definition `type X Y` declares new type X with the underlying type of Y. X and Y share underlying types and nothing else.
This is a useful feature and there's nothing weird or special case about how this works. It's just not the aliasing feature you expected.
Re: I Want Off Mr. Golang's Wild Ride
#2432+ years on Go, 13 years on Python and JS. Some Kotlin and Java as well. Go is by far the best programming language you can find to build scalable microservices. Hands down, years ahead of anything else.
Re: I Want Off Mr. Golang's Wild Ride
#244The author spent a lot of time dwelling on Window's filesystems, at which point many of the readers got bored and started commenting. There are actually a couple of excellent points in here, the majority of which relate to Go's tendency to just be silently completely wrong in its behaviors from time to time, and is absolutely packed with hidden gotchas.
On the other hand, why care about Windows?
Re: I Want Off Mr. Golang's Wild Ride
#245Earlier quoted context omitted.
> the majority of which relate to Go's tendency to just be silently completely wrong 100% right on. Go's handling of errors is often ridiculed for its verbosity and lack of thought, but the fact that Go makes it so easy to sweep errors under the rug has real and devastating consequences in the real world. Go programs are much less safe than programs written in Rust or Java for that reason.
It's not surprising that other pieces of golang have incredibly broken assumptions, I know this particular one was discovered independently by many people: https://github.com/golang/go/blob/71ab9fa312f8266379dbb358b9... https://marcan.st/2017/12/debugging-an-evil-go-runtime-bug/
That debug report was incredible, I have to say. Hats off to the author for their patience.
Re: I Want Off Mr. Golang's Wild Ride
#246Re: I Want Off Mr. Golang's Wild Ride
#247With 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…
If you want to half-ass it like Go you go https://doc.rust-lang.org/std/ffi/struct.OsString.html#metho... or https://doc.rust-lang.org/std/ffi/struct.OsString.html#metho... if you want to potentially get an error. If you want to deal with bytes / invalid Unicode, you go https://doc.rust-lang.org/std/ffi/index.html#conversions
I'm aware of the conversions, unfortunately, you can’t really do any processing before you convert and you can’t (unlike C++) write generic code that works on both types of converted values.
On Unix you get Vec and on Windows you get an iterator over u16. This is hot garbage, to say the least, if you want to do any kind of processing. I can go into more details, but in C++ you would just be working with std::string and std::wstring, depending on platform, and at least in that case you can hide everything away like this:
#if defined WIN32
using OsChar = wchar_t;
#else
using OsChar = char;
#endif
using OsString = std::basic_string;
Note that I’m not advocating that you make everything in your code into OsString, just that it’s common to need to do some small amount of manipulation of OsString and Rust makes this much harder than it should be.
Re: I Want Off Mr. Golang's Wild Ride
#248Earlier quoted context omitted.
I'm no Rust expert, but Rust doesn't enforce that either. There is no language that enforce error checking afaik.
You have to either propagate the error up the stack or face a panic. Rust does force you to deal with the error.
I didn't make myself clear enough, if something returns an error in Rust and you don't check it will it compile or not?
Re: I Want Off Mr. Golang's Wild Ride
#249Earlier quoted context omitted.
fn main() { let x = 1; let x = "foo"; } Does this make rust not strongly typed? Here's a Rust program with no types in the source code. It seems the issue you're objecting to is that python doesn't differentiate variable declaration from assignment (The fact we need let twice in this code is a result of Rust doing this). Which is a fair thing to complain about (and why Python had the "nonlocal" and "global" keywords)…
That's not an identical translation, the identical Rust would be fn main() { let mut x = 1; x = "foo"; } which indeed fails to compile with a type error. (That being said there is a conflation of static/dynamic and weak/strong going on in this thread, as there always is in these kinds of discussions.)
I'd disagree that this is a better translation. In python-land, `x` is just a name binding. The closest thing might be that `x` is something akin to a Box, but I don't know that that's cleanly expressible in rust.
Like in (modern) python you can totally do
def foo():
x: Union[str, int] = 1
x = "foo"
Specifically the semantics don't work here because if you do ~this:
def foo():
x = 1
async takes_int(x)
x = "foo"
Or I guess another way of putting this is that names in python can't be mutable.
Re: I Want Off Mr. Golang's Wild Ride
#250Earlier quoted context omitted.
You have to either propagate the error up the stack or face a panic. Rust does force you to deal with the error.
I didn't make myself clear enough, if something returns an error in Rust and you don't check it will it compile or not?
It will not compile. (As I said earlier, you can always fallback to a panic aka "I don't wanna deal with the error so let my program crash", but an error will not silently propagate through the stack)