Live data from Hacker News

I Want Off Mr. Golang's Wild Ride

fasterthanli.me

501–508 of 508 posts

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

#501
post #488

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.

this was cross platform forensics software ripe with edge cases

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

#502

Earlier 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

Sorry, my original reply was unclear. The connections would be to different replicas, and it was just a hiring task rather than something one would actually use in production.

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

#503

Earlier 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…

Why not transfer it over to a full String instead? How many other libraries and core functions expect an OsString? Why rely on an abstraction that's intentionally been given minimal functionality?

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

#504

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.…

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.

In a lot of cases - esp. distributed systems - it's not up to a database to generate a UUID, but the application. In theory you can have a hundred servers that generate records and send them to a central storage platform (which may or may not be a database, or event bus, etc).

UUIDs are not meant to be generated by databases.

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

#505

Earlier 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,…

We're going off into the weeds here but in C this is implementation defined. In Rust you can use `#[no_std]` and the semantics are all well-defined. There's a thriving Rust embedded ecosystem that's doing just fine. Yes, the specifics of interfacing with hardware are platform-specific, but the language and the `core` bits (under `std`) are well-known.

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

#506

Earlier 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

#507

Earlier 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…

> 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.

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

#508
post #143

Earlier 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++.

Its podcast #100 for anyone who want to listen. https://changelog.com/gotime/100
Post reply on HN