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

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

#491

Post by hota_mazi » Mon, Mar 02, 2020, 9:42 PM UTC

pron wrote: post #485

dwohnitmok wrote: post #484

Earlier quoted context omitted.

There are many who do. There are many who don't and among those who don't they can have pretty strong opinions and be fairly influential (see e.g. Robert Martin's Clean Code). When I say controversial I don't mean that as a back-handed way of saying no one likes checked exceptions, I mean that to say there are large contingents on either side. Unfortunately that means practically speaking checked exceptions lose a lo…

> When you [say] solvable, I'm curious do you mean currently in Java or with future features? I meant future releases. That people can manage now make the problem not one of extreme urgency, so we're waiting until there's a solution we like.

Fundamentally, the problem is that whether an exception should be checked or runtime depends on the context. It makes no sense so say that "FileNotFoundException" is checked.

If that exception is thrown because a user selected a file that disappeared, it's recoverable, so it should be checked.

If that exception is being thrown at startup because the app failed to find a file that absolutely needs to be present otherwise everything is broken, then it should be runtime.

Obviously, Java will never be able to adjust to that perspective on exceptions since it would break pretty much everything.

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

#492

Post by rictic » Mon, Mar 02, 2020, 10:04 PM UTC

whateveracct wrote: post #473

rictic wrote: post #466

Earlier quoted context omitted.

There is no way to avoid leaking implementation details, it's just a matter of how much you leak. Even monads leak their performance characteristics.

*sometimes and not always State, for example, doesn't leak. You never worry about the fact that it's a function `s -> (s, a)` and it gets optimized away like nuts.

This is an example in favor of the fact that abstractions can't paper over performance characteristics. Users may depend on them.

In the unlikely event that there was a change to the implementation of the State monad, or to one's compiler, such that the State monad was not optimized away, it would be disruptive to users. It would probably be treated as a bug, even if the only change in behavior was in additional CPU and memory usage.

This is a corollary of Hyrum's Law.

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

#493

Post by dwohnitmok » Mon, Mar 02, 2020, 10:51 PM UTC

hota_mazi wrote: post #491

pron wrote: post #485

Earlier quoted context omitted.

> When you [say] solvable, I'm curious do you mean currently in Java or with future features? I meant future releases. That people can manage now make the problem not one of extreme urgency, so we're waiting until there's a solution we like.

Fundamentally, the problem is that whether an exception should be checked or runtime depends on the context. It makes no sense so say that "FileNotFoundException" is checked. If that exception is thrown because a user selected a file that disappeared, it's recoverable, so it should be checked. If that exception is being thrown at startup because the app failed to find a file that absolutely needs to be present otherw…

I completely agree that context matters immensely and ultimately it's the caller rather than the callee that should decide whether an exception is fatal.

FWIW though I think that Java the language could adjust to that perspective, if nearly all current exceptions were checked exceptions by default and then callers were expected to wrap as a RuntimeException (perhaps something that was a bit more suggestively named such as FatalException) whatever exceptions they deemed unrecoverable.

Unfortunately there's some implementation-specific problems of going that route (generating exceptions is expensive and you'd probably want a far more fine-grained exception hierarchy rather than lumping whole classes of things under say generic IllegalArgumentExceptions), but they don't seem insurmountable.

More importantly though I agree that I doubt Java the community would ever accept that, at least not for a long long long time.

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

#494

Post by klodolph » Mon, Mar 02, 2020, 10:52 PM UTC

Fellshard wrote: post #451

pjmlp wrote: post #439

Earlier quoted context omitted.

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

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 platform-specific code or use "unsafe", even though internally OsString is just a Vec and you should be able to strip off the "--output" as it is encoded the same on both platforms.

E.g., fill in the blank:

    /// Split an arg "--=" into (, ).
    fn parse_arg(arg: &OsStr) -> Option {
        // What goes here?
    }

This is trivial with &str.

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

#495

Post by klodolph » Mon, Mar 02, 2020, 10:58 PM UTC

dpc_pw wrote: post #330

klodolph wrote: post #247

Earlier quoted context omitted.

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

With Rust you can also convert to `Vec ` where T is either `u8` or `u16` and use generics to work on any. ️ And there are probably handful of libraries that would help with all that too. Also - whatever convenient functionality you might want, can be added in the future without issues. Hardly a language flaw - just a minor unimplemented functionality.

> With Rust you can also convert to `Vec` where T is either `u8` or `u16` and use generics to work on any.

That’s a very cumbersome way of doing things. I would love to see an illustration. It also involves a ton of conversions: if want to parse a command-line flag which contains a file path, it would go: wchar_t -> OsString -> Vec -> OsString -> wchar_t. It also makes it difficult to use Rust APIs in a more or less idiomatic way.

> Hardly a language flaw - just a minor unimplemented functionality.

It’s a flaw in the standard library, not the language. When you say that it’s minor, all you’re doing is saying, “I don’t care about the things you care about.” That’s not really an argument, just a statement of your own personal opinion.

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

#496

Post by neop1x » Tue, Mar 03, 2020, 10:49 AM UTC

dnr wrote: post #231

pmarreck wrote: post #152

Earlier quoted context omitted.

This is funny because after almost 4 years of working with Elixir and watching Go from arms’ length, I literally see NONE of the criticisms regularly leveled at Go. This is not an exaggeration. In fact, Elixir has few criticisms at all to begin with, and it’s driven very large sites already at this point. (Yeah, it can’t compile easily distributable self contained binaries. It’s not (yet) designed for that.) Not inte…

If you were using Go for those four years, you'd also see very little of the criticisms regularly leveled at Go. What you see on the internet is the union of everyone's complaints and frustrations. Each individual sees only some of those, maybe even none depending on the type of work they're doing. And the ones that are generally happy don't tend to post big rants, so the overall impression of an outsider can be pret…

You can find rants on any language because nothing can ever be perfect. Everything has pros and cons. https://yourlanguagesucks.com

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

#497

Post by jimsmart » Tue, Mar 03, 2020, 6:44 PM UTC

anonymoushn wrote: post #375

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

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

#498

Post by jimsmart » Tue, Mar 03, 2020, 7:25 PM UTC

HideousKojima wrote: post #118

DLA wrote: post #101

Windows-focused rant. Plus a few reasonable points. Every language is complex at some level and in their own ways-Rust included. Every language hides some of the complexity of layers below it like assembly and thus hides hardware details. Computers are complex. Point granted. Fact is Go is a very reasonable set of compromises that let's real enterprise-scale work get done and run with solid performance. I've done wor…

>Go has faults. The "OMG Go has no generics so it's total trash" argument is just silly. Generics are coming. Until it has them it's a valid complaint. And the fact that they're finally coming 11 years after the language's creation is another matter

FWIW: Java was originally released in 1996, it had no generics, and didn't gain them until 2004 - 8 years after the language's creation.

Was Java "total trash" before 2004? Not really, it was still useful in lots of use cases - it just didn't have any generics.

Go at least has generics for its built-in collection types (maps, slices) - which, in that respect, arguably places it ahead of where Java was for a whole 8 years.

https://en.wikipedia.org/wiki/Generics_in_Java

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

#499

Post by strbean » Tue, Mar 03, 2020, 10:40 PM UTC

kragen wrote: post #486

ric2b wrote: post #462

Earlier quoted context omitted.

Do you have an example of Python doing implicit type conversion?

Python2 implicitly converts int to long and str to unicode: >>> 2**100 1267650600228229401496703205376L >>> 'x' + u'y' u'xy' All Pythons implicitly convert int to float and int or float to complex: >>> 1 + .5 1.5 >>> 2 * 3j 6j Methods like list.extend now, in recent versions of Python (since 2.1), accept arbitrary iterables rather than just lists; it's more debatable whether this is an “implicit type conversion” or n…

Thanks for the examples. I was mainly thinking of int-float conversion that is present in the vast majority of languages.

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

#500

Post by kortex » Wed, Mar 04, 2020, 2:57 AM UTC

joshuamorton wrote: post #476

dilap wrote: post #452

Earlier quoted context omitted.

You lost me, boss! Why do you think mystery_c is closer to mystery_py than mystery_b?

Let's go on a journey. The answer is that I started with a hunch. You're treating x as a pointer sometimes, and a value other times. That seems strange, and unlike the python. In python the thing is always access the same way, it isn't a ptr type sometimes and a value type others. So first let's talk about scopes. In python, you aren't introducing a closure. If we do introduce a closure, like with an IIFE: def myster…

Quality content! You should write this up into a blog post or something.