alphaalpha101

I think you're still missing the point. It isn't all about what we can individually get. I don't want to live in a country where you have to have a special high-paying job to get fair and reasonable holidays and healthcare.

>In a lot of middle-income-class positions you get most of the things you described as perks.

I don't care about getting it myself. Although, it should be pointed out, you don't have to 'negotiate' for health care or notify someone of your preexisting conditions or any of that crap. You just have to turn up and you'll be treated entirely for free.

But I also want to live in a country where this applies to everyone that doesn't earn as much as me too.

If you write code that can be called without 'unsafe' then you are required to make that code safe. Whether you implement it using unsafe underneath is irrelevant.

The unsafe block is there because it does FFI, which hasn't actually been verified to be safe.

Sure, but this isn't unsafe code. Code using this library isn't written in an unsafe block, right? You just use it like any other Rust library?

So given that this isn't actually safe, you can presumably write some code that has undefined behaviour using this library for us?

Sustainable commercial open water fishing is completely acceptable to everyone, surely?

Signature mismatch? You have to sign your ballot? Doesn't that identify that it was your ballot?

It's been a couple of years since I last voted in NZ (election in 3 weeks, and it's every 3 years) but I definitely don't think you're allowed to put any identifying mark on your ballot here..

It was not a complaint, it was a question, just like my top-level comment.

Was that interpreted as a complaint as well? Is that the problem?

I really, really don't understand why this would get downvoted. Are people not allowed to ask questions now?

C++ uses `==` for whatever you want. But generally in C++, user-defined types will be documented as either having 'reference semantics' or 'value semantics' and all aspects of the type will conform to that.

So this new concurrent map? Am I right in understanding it's designed for cases where you have a map shared between goroutines but where each goroutine essentially owns some subset of the keys in the map?

So basically it's designed for cases like 'I have N goroutines and each one owns 1/N keys'?

Sorry I'll try to avoid the 'what are you smoking?' sort of thing. Comment works completely fine without it, it's just rude.

It's far too late for "we'll see".

>Growth in 2016 was 4%, not 1% and not -1%: https://www.google.com/publicdata/explore?ds=d5bncppjof8f9_&....

No it was not. Not per-capita. Growth ignoring population changes is literally completely irrelevant. It has never been relevant.

>It seems like NZ is growing at a pace of around 3%p.a. You're free to argue that there's some fantastic economic system that only you know, but most people will rightfully be sceptical of such claims unless you have a few examples of countries at NZ's high level of development growing at a much higher pace.

NZ before the horrific and inhumane neoliberal reforms of the 1980s ruined this beautiful country was growing at a much faster rate that it has ever grown since.

>Other than that I've lost track of what were arguing. It appears as if you just start making completely unrelated arguments when you're proven wrong.

Lol

>No, I don't. I look at the former snippet and I can easily tell each and every function invocation that can cause SomeError.

The reason that functions have type signatures is that you can read them. You can tell which functions can cause SomeError by going and reading their definitions.

>I prefer explicit over implicit since I find it far more readable.

'Explicit over implicit' is dogma. Rust requires you to annotate your code with gibberish in cases where it is not necessary.

>You can quibble about the names (Option and map), but Option is essentially the Maybe monad and map is bind, so you're kinda arguing against core functional programing constructs.

That's literally my entire point. The attitude that it's technically a Functor so it makes sense for it to be called map? No, it doesn't. It's not a map. You're not mapping over anything. Naming is important.

Calling it 'the Maybe monad' shows that you actually have no idea what you are talking about. It's not 'the Maybe monad'. The Maybe monad is the instance of Monad for Maybe. It is not Maybe itself.

The entire concept of having the literal 'Monad' word as a word in your language, a thing that you use in programming, is very stupid. Monad is not a useful or good abstraction. Maybe is a good abstraction. Or Optional, or Option, or whatever you decide to call it. But Monad is a bad abstraction. Abstracting over superficial syntactic similarities between completely different constructs is completely stupid.

The name being terrible is not 'quibbling' by the way. Naming is incredibly important. Calling it 'map' just shows how out of touch Rust is with real programmers.

There's nothing remotely object-oriented about what I wrote. I don't see any inheritance. I don't see any polymorphism. I don't see any virtual member functions.

And of course I'm using RAII to roll back the transaction. When the object is destroyed the vector is destroyed and the transaction isn't run.

It doesn't make any sense at all, quite frankly, to use RAII to do what you wrote there. That's not what RAII is for, nor is it what RAII is good at. RAII is for managing resources.

Lol what have you been smoking?

What was disgusting about saying 'hey maybe the reason that women aren't in software is that they don't want to be in software and there's nothing wrong with that as long as the women that are in software are treated well'?

How so? It's on the code review. They see the change, and learn about it..?

99.9% of code review that I do, and that I get, is not training. So maybe don't make all the changes for new employees? I use vim. Most people at my work use vim. Our build process is complex. Everything we do is really complicated. It works for the experienced, yet it has a learning curve.

So, new people get a slightly different experience. That's fine.

>So many of the arguments surrounding Damore talk as if this is in a vacuum, when frankly, it isn't. Much of the message it carried(and did little to discourage) came off as insulting to a group of people who commonly spend every day harassed just for what they are, anytime they have gone online.

That would, presumably, be women in software? Because as far as I can tell, the only people being regularly harassed on Twitter are people that don't think women should get special rights...

It suggests that he sympathises with Nazis, which is close enough to being a Nazi for most people.

>some nazi fired

Did you actually read the memo? If he's a nazi, then so is 95% of the world's population.

>Have you ever did a code review, and gave feedback that was longer than doing the fix yourself, while you’re at it?

Yes. Yes yes yes. I hate this so much. I want my code reviews to involve fixing little things. I don't even have suggested edits, I can only highlight comments and make comments, and even suggested edits wouldn't be enough. I want to just make the changes. It's all on a branch anyway.

1% growth is completely irrelevant. That's what I said: effectively in recession. The difference between 1% growth and 1% shrink is nothing.

There's no reason we shouldn't be growing much more quickly. But we're not going to do so in a neoliberal world. That's just not going to happen. Draining the wealth of society to a small group of people that spend little money just doesn't drive growth.

People can't spend and drive the economy when they're dirt poor.

I don't really agree that it's inelegant to decide whether the reason for quitting is a success or an exception, or whether it's necessary. Like, you've either committed, in which case you shouldn't need to do any cleanup, or you haven't committed, in which case you need to clean up, right?

If you have an object representing some sort of transaction, and you just have actually-do-all-the-work-at-once-on-commit-being-called semantics, you don't actually need to do anything in your destructor at all, right?

    template<typename T>
    class transaction {
        std::vector<T> things_to_do;
    public:
        void add_work_item(T t) {
            things_to_do.push_back(t);
        }
        void commit() {
            for (auto t : things_to_do) {
                t.do();
            }
        }
    };

I disagree that this is elegant.

    import socket
    import threading
    import socketserver

    class ThreadedTCPRequestHandler(socketserver.BaseRequestHandler):

      def handle(self):
        data = str(self.request.recv(1024), 'ascii')
        cur_thread = threading.current_thread()
        response = bytes("{}: {}".format(cur_thread.name, data), 'ascii')
        self.request.sendall(response)

    class ThreadedTCPServer(socketserver.ThreadingMixIn, socketserver.TCPServer):
      pass

    def client(ip, port, message):
      with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as sock:
        sock.connect((ip, port))
        sock.sendall(bytes(message, 'ascii'))
        response = str(sock.recv(1024), 'ascii')
        print("Received: {}".format(response))

    if __name__ == "__main__":
      # Port 0 means to select an arbitrary unused port
      HOST, PORT = "localhost", 0

      server = ThreadedTCPServer((HOST, PORT), ThreadedTCPRequestHandler)
      with server:
        ip, port = server.server_address

        # Start a thread with the server -- that thread will then start one
        # more thread for each request
        server_thread = threading.Thread(target=server.serve_forever)
        # Exit the server thread when the main thread terminates
        server_thread.daemon = True
        server_thread.start()
        print("Server loop running in thread:", server_thread.name)

        client(ip, port, "Hello World 1")
        client(ip, port, "Hello World 2")
        client(ip, port, "Hello World 3")

        server.shutdown()

Why not this:

    def handle(request):
      data = str(request.recv(1024), 'ascii')
      cur_thread = threading.current_thread()
      response = bytes("{}: {}".format(cur_thread.name, data), 'ascii')
      request.sendall(response)

and this:

    options = socketserver.ServerOptions(
       concurrency=socketserver.Threading,
       sockets=socketserver.TcpSockets)
    server = socketserver.Server((HOST, PORT), options)

There's really not any use of inheritance here anyway: it's just a hack. It's such a hack that you need to inherit those two classes (ThreadingMixin and TCPServer) in that order, because one overrides a method of the other, and if you inherit them in the other order it just doesn't work.

It might simplify the implementation, I don't know, but it definitely doesn't simplify the interface.

The difference is that in Go, it is unidiomatic to share mutable state across threads, while in C/C++/Java it's not.

This sort of attitude is never going to win over people that you are talking about. I hate to bring politics into things, but it's like calling all Trump supporters hopeless and backwards. Yeah maybe they are, but they're going to react to that by never listening to anything you say again, so even though it's true, it's not helpful.

The 'state of the art' is increasing, over-the-top complexity to a truly ridiculous level. Go programmers don't want to open up the documentation for a library and see this:

http://i.imgur.com/ALlbPRa.png

or look at the language reference and see this:

http://en.cppreference.com/w/cpp/language/constraints

and I don't blame them.

That's exactly what you have to do in Rust anyway though.

Except instead of just writing `throws SomeError` in the declaration line of the function, you have to annotate virtually every line of your function with `?` and wrap the return line in `Ok(...)`.

Personally I loathe this style of programming. It's not that it's difficult, it just seems to obscure code a great deal.

Writing this sort of thing in Rust:

    fun some_function(a: &A) -> Result<&B, SomeError> {
        let c = foo(a)?;
        let d = foobar(a, c)?;
        Ok(if xfoo(c) {
            let e = blah()?;
            bar(d, e)?
        } else {
            baz(d)?
        })
    }

where you have to write every function in this pseudo-do-notation where 'return' is just wrapping the return expression in 'Ok' and `a <- expr` becomes `let a = expr?;` is just horrible.

I'd much rather write this:

    fun some_function(a: &A) -> &B throws SomeError {
        let c = foo(a);
        let d = foobar(a, c);
        if xfoo(c) {
            let e = blah();
            bar(d, e)
        } else {
            baz(d)
        }
     }

See how that's so much cleaner? It's not actually any different from exceptions anyway, you're basically using them like exceptions, and they're implemented in the same way. The difference is that in the latter the code is much simpler and easier to understand. That's all.

In fact, that syntax could be added to Rust (after 6-12 months of bikeshedding as usual) and just have it automatically translated to the above anyway.

The other issue with Result/Option is that people start doing really horrible things like adding Option::map. Sorry but it's not a container that has 0 or 1 things in it. It's an optional value. That they're mathematically equivalent doesn't mean that they're the same thing conceptually. It's as bad as pretending that Result<T, Err> is useless and everyone only needs Either<L, R> where by convention R is the error value. God please just no.

Lol. I'm not anti-immigration, don't be so defensive, and I'm also not talking about the US. Stop bringing up the US. This is a thread about Japan and I'm talking about New Zealand.

The New Zealand government really wants people to believe that we're experiencing 'economic growth'. But while they might be technically right, they're effectively wrong. Economic growth that is so much entirely from immigration that we're effectively in per-capita-GDP recession is not real, useful, good growth.