i wrote go professionally on a project for a year in a single very intense push, and i was burned by every single thing listed in the article. felt like uphill impedance mismatch the whole way. its nice to see it articulated well
> burned by every single thing listed in the article Really? That seems absolutely bizarre to me, I've been writing it professionally for ~8 years now and never hit… any of these. I mean I basically never interact with Windows on any level, but none of this has ever bit me.
I Want Off Mr. Golang's Wild Ride
501–508 of 508 posts
Re: I Want Off Mr. Golang's Wild Ride
#502Earlier quoted context omitted.
One company asked me to write a wrapper around database/sql that adds a connection pool. This is pretty easy until you want to implement any function that returns Row, which you just can't, because you can't make one of those. Amazing.
Take care, you may be wrapping your connection pool around a built-in connection pool. Furthermore, some dbs might not like log-lived connections. http://go-database-sql.org/connection-pool.html
Re: I Want Off Mr. Golang's Wild Ride
#503Earlier quoted context omitted.
https://doc.rust-lang.org/std/ffi/struct.OsString.html I'm puzzled what you think is missing. What should be part of the stdlib that isn't currently?
Basic stuff like starts_with() is missing. You cannot slice an OsString into parts or iterate over its components. Almost everything you want to do with a string is missing. If you are curious for yourself, try to write an argument parser that will parse something like "--output= " and store the path as an OsString, and make it work on both Linux and Windows. The OsString abstraction breaks, and you have to write pla…
Of course `starts_with` is missing: you haven't resolved what underlying type the value actually is yet, and you'd be trying to compare apples and oranges for all you know! Move the OsString to a concrete type and you'll have all that functionality and more. The only time that will fail you is if you don't have a valid string to begin with, under which case `starts_with` should fail, correct?
Everything about OsString makes it a type you convert to and from, but it's not intended to be one you work /in/, since that would make require you to make assumptions about which platform you are running on. You really want to manipulate it? Go to String and back, and pay the cost. This should also encourage you to use OsString as little as possible, at the edges.
Re: I Want Off Mr. Golang's Wild Ride
#504Here'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.…
Not to mention that sql.Result (the return value of Exec) has a LastInsertId() that's an int64, so if you're using uuids, you can't use that at all and have to call Query instead and manage generated IDs yourself.
UUIDs are not meant to be generated by databases.
Re: I Want Off Mr. Golang's Wild Ride
#505Earlier quoted context omitted.
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…
And that's all perfectly fine. If I'm running embedded with no OS, I'm in a very specific environment. My code is going to be tied to my specific hardware, including almost certainly the specific CPU chip. (In this situation, it's usual to have a "CPU" chip that includes several peripherals on-chip, to reduce parts cost. Code is not portable to a CPU with different peripherals, even if it's from the same family.) So,…
Re: I Want Off Mr. Golang's Wild Ride
#506Earlier quoted context omitted.
No, Python is not strongly typed by any serious definition of the concept.
Strongly typed: >>> "foo" + 3.141 TypeError: can only concatenate str (not "float") to str >>> object() + 3.141 TypeError: unsupported operand type(s) for +: 'object' and 'float' Weakly typed: > "foo" + 3.141 "foo3.141" > Object() + 3.141 "[object Object]3.141" > [] + {} "[object Object]" > {} + [] 0
> "foo" + 3.141
"foo3.141"
How is this weakly typed when it uses type information to work?No, this is strongly typed.
Re: I Want Off Mr. Golang's Wild Ride
#507Earlier quoted context omitted.
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 l…
FYI, you can convert an `OsStr` (or `OsString`) into a [`Path`](https://doc.rust-lang.org/std/path/struct.Path.html) with zero overhead and get all the useful things you want to do with paths: https://play.rust-lang.org/?version=stable&mode=debug&editio...
> 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
For commandline arguments that you actually need to parse there's nothing wrong with asserting that you only accept valid Unicode, and then you can just use `to_str()`: https://doc.rust-lang.org/std/ffi/struct.OsStr.html#method.t...
If you have a `Vec` or `String` or whatever you can just treat it as an `OsStr` (with no overhead) because both of those (and a bunch of other things) implement `AsRef`: https://doc.rust-lang.org/std/path/struct.Path.html#method.n...
Re: I Want Off Mr. Golang's Wild Ride
#508Earlier quoted context omitted.
that's true, but realize that golang is largely shepherded forward by a company with a legacy of C++ (maybe lesser C/java) heritage. you aren't getting legacy C++ programmers on board with "optional" types: they'll riot and pull the purity card (this doesn't look like "my C++"). google is probably grateful these people are no longer returning -1, -2 etc. for errors from their functions. consider things like the golan…
The authors just happened to work at Google ,while having a manager that supported their work (check Go Time podcast), most of Google's relevant products keep being done in C++, Java and Python, and they are one of the biggest contributors to LLVM/clang, and ISO C++.