copergi

Yes, that is not good enough, and it was already over a day into their complete lack of communication. Just because you don't agree with it, doesn't mean it is not an argument. I would expect a company of amazon's size to give customers precise and useful info. Not a vague "should be done in a few hours" after a day of silence.

>now I've seen 2 different operators, which I presume are overloaded to deal with those types somewhere? Or we're dealing with a ton of built-in types and built-in operators to deal with them?

No. Remember we're talking about using a language that is not broken by design instead of go. You have one operator (>>=) and it works on one typeclass (Monad). Do notation (do and <-) is merely syntactic sugar that desugars to using >>=.

>I prefer the situation of "simpler environment, don't write bugs" to "really complicated environment that makes it theoretically impossible to write bugs"

And since those are not the options available, people tell you that those are not the options available. Doing it right is very simple. Your options are "simple and with lots of chances to create bugs" or "just as simple but with fewer chances to create bugs".

Nope, your definition of simplistic is precisely what I meant.

They don't need to be on one line. If you really want to pretend that having them on one line is a problem, then put them each on their own line. You can even be needlessly verbose if you want to:

    do
      a <- GetBar foo
      b <- GetBaz a
      c <- GetCat b
      return c

>Go cares about scalability in the large

Which features precisely have led you to believe this? I can't see any indication of that anywhere. You seem to be creating a false dichotomy: "caring about abstractions and caring about scalability are opposing goals", so that you can ascribe one side of a nonexistent spectrum to go.

>But if you're not on a large problem, that 10% of repetition will chafe you...

Except that is simply not the case. The larger the problem, the more that duplicate code causes problems.

>Your "unless" is the same as saying in a language like Java

And "our language is just bad as java" is a pretty awful sales pitch.

>That is still probably true, but I don't think its a bad thing.

No it is not a bad thing. It is a terrible thing.

>I attribute this to the fact that we were forced to handle every error.

But you aren't forced, that's the problem.

>Some people like exceptions, but I've always liked Go's way of things in this department.

Some people like proper error signaling and handling instead of either of the broken choices you suggest.

>Go thinks its job is to make it easier to write and maintain large scale software applications

It thinks wrong. Making people duplicate code makes it harder to write and maintain large scale software applications.

And look how poorly that worked out. People assume software will break all the time, because most of the software they are exposed to does exactly that. It is 2014. There is no excuse for using languages lacking important features from 1973.

>It's really not a good language for much else

It isn't even good for that. There isn't a single use case where one of: D, ocaml, haskell, rust, or C isn't better than go. Go is the new java, a language that was inferior and obsolete when it was made. And like java, it'll probably be popular for a long time.

Elegant is definitely the wrong word. Scheme is elegant. Go is simplistic. Not the same thing.

Yes, and "sit there refreshing a page over and over waiting to see if they update it because they refuse to even give you a hint of when they expect to be done" is not acceptable.

>The rest (retiring keys and stuff) can not be handled by them due to nature of the problem.

And they actively refused to let people know when they were safe to do that. That is the problem.

>if I make a site that turns off people using low resolutions, I don't get many visitors using low resolutions

This sounds fairly obvious doesn't it?

http://www.w3schools.com/browsers/browsers_display.asp

>What kinds of devices are you referring to?

Everything from monitors to PDAs to laptops of various form factors. Even as late as 2007, 20% of displays seen in web stats were 800x600 or smaller. There were also plenty of devices that could have accessed the web but people didn't bother because the web was so broken with IE 1024 crapsites. The iphone happened in 2007. There was no period where the number of people getting boned by fixed 960px sites was insignificant.

>Remember, we're talking about the days before mobile was a big enough market to justify making mobile versions of websites.

That is begging the question. You can't assume X as a premise to demonstrate X. 20%+ devices were smaller than 960px. It took (and still takes) no extra effort to design a website correctly rather than with a fixed grid. Just as it took no extra effort to design a website correctly rather than for IE only. It is not a co-incidence that "best viewed in IE 5" and "best viewed in 1024x768" buttons were best buds. Both stem from the same source.

Because we already had tons of different display devices with tons of different sizes and resolutions. People just said "it works on my screen so that's good enough". You don't need to have text fill the entire width of the display to have a site work everywhere, I don't understand why you brought that up at all.

>In practice, I think many developers just choose a fixed with, e.g. 960px, and leave it at that

Yes, but they were wrong to do that then, and the world is better off now that mobile devices are forcing those people to do things less badly.

>Dismissing things as garbage when they clearly are not

That is not the case here. Did you read the site?

>I never play video games, so the 30hz refresh rate wouldn't be a drawback for me

30Hz is painful just for normal use. You can't move your mouse precisely any more because the screen doesn't update fast enough.

Mostly is as good as not at all though. Yes, you should stop using class hierarchies. Composition is the path to salvation.

Lots of people build up massive amounts of technical debt by using the wrong things. Things like mysql literally hold back progress. "Stop using garbage" is an important message to spread.

Mysql has schemas too, they are just mislabeled as "databases". The fact that mysql doesn't offer multiple databases is a bit of a concern of course.

Net Applications are famous specifically for their incredibly wrong stats.

>should be able to expect at least a little bit dedication from their employees

No they shouldn't. They should expect exactly what they pay for, me to show up and do my job and then leave. If you want me to be invested in the company, then I need a stake in the company. It isn't complicated.

>but if you do not care at all for the business

Your business? Of course not. Unless I have equity, why would I fall for the "you need to care about the company even though it doesn't care about you" scam?

>or your team

You are the one screwing my team, not me.

>your not exactly a paragon of the model employee are you

I would certainly hope not. I try to me a model human. I have no interest in being a model employee. If you want a slave, buy someone else.

>If there is a major crisis which happens in average maybe once every three months, and you consistently can't be arsed to put in some extra hours of effort while your team mates and managers are, then yes, you are flaking out

If that is part of my job, sure. But you are aiming for a world record in strawmanning with that one. Remember the discussion is about employers feeling entitled to owning employees time?

>They're there to get paid

Everyone is there to get paid.

>when one of the guys always flakes out when the clock hits 17

Doing your job is not "flaking out".

It isn't the bandwidth that is the difference, that's the point. How are the beds in Burger King?

>Meanwhile, fast food workers, carpenters, and garbage collectors are completely irreplaceable.

How so? Automation in the food industry is going to be huge. It is starting behind the scenes, with automated meat cutting and such. But it will obviously come to McDonald's too. Teenagers that don't care provide much worse service and food than robots. And they are more expensive. It is a no-brainer to replace them.

I didn't say you would want to switch. I said most people use little photoshop functionality. If you think that is controversial, then I think you are delusional.

>He isn't using the functionality that Photoshop provides

And since that is the same for the vast majority of photoshop users, he provided a super helpful guide for them. It does not say "how everyone can switch to gimp".

>(the same reason they sell/create/display glossy monitors, because they demo well).

They create very few of them. The few they do create are because some of us want monitors that are not intentionally blurry. I am capable of controlling the lighting in my environment. I do not want my monitor to deliberately make everything fuzzy just to avoid a glare problem I don't have.