jjnoakes

I think solving the context problem is key. I've seen a few proposals for go error handling that address the verbosity while also allowing you to provide proper local context in a terse and readable way. I'm hoping something like that makes its way into go eventually.

I see people rant about this, but not about other equivalent ways of getting scripts from the author to the system and running them.

If the instructions were "download, unpack, and run ./configure; make; make install" would you post the same reaction?

I've been working in a similar environment, and once a month (or more) someone comes to me with a crash they don't understand. It usually takes a couple of days to debug (since the easy bugs don't make it to me), and every single one is some kind of undefined behavior (temporary lifetime confusion, dangling reference, callbacks modifying containers during caller iteration, ...)

It's trivial to store sensitive data in a collection, for example, and then index it with the wrong index when trying to access and export adjacent non-sensitive data.

You absolutely can.

> I have all the definitions and vars in my REPL and so has my IDE. I get completion on all symbols, I can look at call trees, usages, refactor things with confidence, run functions in isolation, replace them, wrap them, all from the REPL and inside my application

This is great, but it only works if you are executing the code that you want to inspect/complete/refactor. In my experience, that just doesn't scale well.

> You need to do runtime validation.

Type systems don't eliminate this, sure, but when used correctly, they _drastically_ reduce it, which is extremely useful.

> And good luck untangling your type definitions when your requirements change.

That's the best part - the compiler tells me exactly what I have to fix to get things working again. If I do the same thing in a dynamic language, I have to track things down myself, wait for unit tests to fail (hopefully I have 100% coverage...), and pray that there isn't an escape.

I find that for many projects I start, I seem to want:

  - static types
  - small, static binaries for deployments
  - lower memory requirements and value semantics where appropriate
  - a reasonably large ecosystem
  - cross-platform with strong support for linux/cloud

These two languages usually end up at the top of my list when given these requirements.

I think you can choose nuances that minimize unexpected behavior in practice, and I think the go team did a good job here.

There's a second motivation in my opinion. Code might work today without the change, but it could be because the author originally wrote buggy code, caught it in testing, and had to waste time tracking it down and understanding nuances that don't need to be there. Once they figured that out, they implemented an ugly workaround (adding an extra function parameter to a goroutine or shadowing the loop variable with n := n).

Good language designers want to avoid both wasting developer's time and requiring ugly workarounds. Making a change that does both, especially if it doesn't break old code, is great imo.

I think of Java as more bloated than C++ at runtime - with C++ I can make smaller executables that start up faster, use less memory, etc.

But if you are talking about the source code itself, then things are quite different.

The safe alternatives are in the article.

I've effected positive change in the companies I've worked with in the past, so I guess I know firsthand of anecdotal counter-arguments.

Corporations are made up of people, and people can influence the actions of the corporation, if they try.

I tried it on Android and within the first few minutes I hit the following annoyances:

  - Changing the title of a note and then backing out of the note does not save the title change; I had
    to switch focus to the body of the note before the title change would save
  - Backing out of a note exited the app instead of bringing me to the previous view
  - Backing out of a sub-setting view exited the settings instead of bringing me to the parent settings
    view, so even looking for a setting that might help the first two annoyances was also annoying

I'm hoping to give it another go, and perhaps even suggest or improve the app when I have some time, but it was definitely an underwhelming first impression.

Lifetimes are still important in managed languages. You just have to track them in your head, which is fallible. The difference is that if you get it wrong in a managed language, you get leaks or stale objects or other logic bugs. In rust you get compile time errors.

You build them. Or if the latest compilers don't build against the older glibc (which is rare in my experience, but may be possible), then you just don't support the older glibc any more.

But I've never had trouble building against older glibcs.

Depending on glibc can be portable enough if you build against the oldest glibc version that you need. Running on newer systems works.

That post describes "something followed by a colon is a label in certain contexts", so you need to extrapolate a tiny bit to realize that "$:" is a label, even if the post doesn't explicitly enumerate all possible labels.

> it allows players who get stumped at a certain level to save their high score to the leaderboard without finishing the game

Have you considered saving the high score after every level automatically?

If by "learn" you mean "native mastery" then I suppose you are saying only kids reach that level, so they are "faster" simply because they are the only ones to finish.

The article considers "learn" to mean roughly "fluency", short of native mastery, and adults tend to reach fluency faster, then plateau.

So depending on nuance, you and the article are both right in some sense.

This is definitely true. I remember being able to quickly press and release the hangup button on a single phone and if I was quick enough the other person would remain on the line. I don't recall exactly where the threshold was, but I believe it was around a half a second or so.

The only thing clear to me is they are on a Mac and want a dev environment of some unspecified kind.

It isn't so clear to me. As I read it, OP might be asking about a dev environment on Mac, not necessarily for Mac-only development.

Config files work fine. But so does expressive code with the right abstractions. And I think code scales up better and down almost as well. Just my opinion.

Well-written code in an expressive language can be very close to a config file, but also has the nice ability to scale up in complexity when required.

I will look it up later, but maybe someone here knows off the top of their head. Does the rust tcp listener accept not fail with an EINTR equivalent upon receipt of SIGINT?

The claim above was that a for loop implied that the code couldn't be declarative.

> Please stop calling it such

I'm not claiming it is always declarative, I'm only claiming that a declarative example above can contain a for loop, and that laughing at that is the wrong response. That's it.

> When someone tries to make a sophisticated argument that up is down and white is black

This is where the deep misunderstanding is coming from.

The claim above isn't "imperative is impossible".

In general maybe, but in the specific context above, I think calling that loop declarative is accurate, and laughing at that classification is a poor response rooted in a deep misunderstanding.