_6pvr

> 7. Epic paid so far 1 billion USD to convince devs to not sell in competitor stores.

This is kind of a toxic disingenuous spin on store exclusives, no?

I'm not familiar with Clojure Specs, but it definitely sounds exactly like the "Dynamic language implements type checking tooling to assert correctness", as referenced in the above post. The spec website just looks like type assertions as "validation" - what am I missing?

> Even Nodejs doesn't always let you re-use code between backend and the front.

This is not true. Check out Lodash. It's a dependency of pretty much every FE and BE NPM package that exists. Ignoring rendering libraries like React, client side JS and backend JS are "just" JS.

> I've never experienced the joy of creating such robust, predictable, and reliable software with any other (statically typed or otherwise) language before.

I think you should definitely keep doing the things that bring you joy!

> Unfortunately I am too lazy and careless to use Clojure in any serious capacity though. I really need a Haskell or Rust compiler to remind me of all my silly mistakes. I can't be trusted to get to the same level of confidence through unit tests or linting or spec or malli.

I think most developers cannot be trusted to make these mistakes, I wouldn't call it "careless or lazy". Languages exist with tools baked into them to prevent slip ups. Why wouldn't you want to take advantage of that tooling?

Also, as a result of this comment section, this is the second time in the past week that I've seen the suggestion to use 3rd party typechecking/static analysis tooling in a dynamic language, which (to me) brings up the question: Do you really want a dynamic language, or do you just want the ability to be careless intermittently? There is no shame in saying "I just want to get happy-path code working quickly". There is joy in getting happy path working quickly. I just think, as a codebase in a dynamic language grows, codebases seem to build lots of tooling to make that dynamic language less dynamic.

It seems like if a tool is so essential to successful development in a language, it should probably not be a 3rd party library but instead baked into the language tooling itself, no? (I have never used Clojure and am not trying to be inflammatory)

I really want to work with "modern" Java. My experience with Java was from a massive awful J2EE enterprise Java fintech company, and from college. When I see modern Java apps it seems like a pretty decent combination of modern features/tooling and an incredibly mature runtime.

> Rust on the other hand is optimized for maintaining (it's right there in the name: software should be allowed to become old and "collect rust"). Rust APIs are very hard to misuse, everything is constrained and specified very explicitly. Documentation and testing live inline with your code. You know exactly what a piece of code can and can't do - you even know whether it's allowed to mutate an object you're passing it. And of course certain mistakes are impossible to make at all without (again, explicitly) dipping into unsafe { }.

A language that is touted as "difficult to learn" and "difficult to onboard" is by definition not built for maintaining. You could maybe make the argument that the guarantees provided by the language and compiler reduce the maintenance burden of software built in Rust, but I don't even really think that statement has been tested (via Rust being so young).

It is tiresome the frequency that legitimate language discussions for some reason turn into Rust vs. Go trash talking. It is almost certain that in 10 years, both will be used more than they are now by several x's. I think pretending you can predict what'll happen with either (and the industry) over that time is pretty silly. There will be legacy apps that people hate working with in all programming languages, and there's nothing that can save you.

This matches my experience (but replace UE4 with Unity).

Godot just doesn't fight you the way Unity does.

I've found both AWS Lambda and all Azure serverless tooling to be extremely frustrating. "Just don't do local development" is the feedback I see a lot, which just seems bonkers to me. Like the orgs that don't run tests locally and just use CI to validate builds. If your workflow involves long periods of waiting to test even very basic functionality, it is (to me) totally broken.

We have containers which unify local environment and production environment. In my opinion (and experience), there aren't any more efficient shared mediums to work with.

> I would not listen to any advice on HN. I have a pretty solid hiring strategy, but it got downvoted to hell because HN skews to people without much real world experience. They can only think of tech products to sell to other tech companies.

< Proceeds to give advice on HN >

This part doesn't really seem worthwhile to post.

> Focus on smaller companies that need help solving actual business problems with automation. Offer to do a project for $20 an hour. Get a job doing straight up IT stuff until you earn their trust, and then show them what you can do software wise. There is a lot of room for competent IT people, but you need to be way more realistic about who is going to hire you.

Excellent advice.

I'm not challenging you on whether or not you're smart. I'm commenting on the fact that you're unable to find employment, which means either you're carrying yourself incorrectly or you're unable to perform the tasks required of an entry-level applicant. You're bringing up this resume, these achievements, which can verify that you're intelligent and capable of critical thinking, so the greatest culprit would be that you're carrying yourself incorrectly, right?

In another post you brought up your longest stint being 2 months, and that you dropped out of college your freshman year. To be blunt, I don't think the achievements you list really count if you didn't actually complete them. There's a lot of "I worked with", "I got accepted to", "I got hired by" in your posts, but pretty much all of those things are followed by quitting almost immediately. When you're competing in a market with college grads and people with lots of previous experience, having gotten accepted to and then dropping out of a good school buys you much?

Am in the midst of shipping a medium sized game in Unity and I can confirm your takes are correct/relevant today. Unity is incredibly frustrating to me, and I would really aggressively challenge the notion that Unity is aimed at any sort of "Developer Productivity". More than anything it's a dumpster of features to allow Developers, Artist and totally nontechnical/non IC contributors to all contribute okay-enough. But the features that go into making Artists productive are at times orthogonal to those that make Devs productive. It's all a big tradeoff.

Godot is smaller and has way way less learning material (and no Asset Store), but purely from an Editor perspective it's miles ahead from a dX perspective.

> If you prefer Go, and are on a Java team, you'll want to convince others that Go is far superior, and vice versa.

If you prefer Go, and are on a Java team, does arguing with people that are unrelated to your work on the internet change your working environment?

I really hate the wave of language "competition" and contention. Go is a language that allows lots of developers to get great work done. So is Node.js, so is Haskell, so is Rust, so is Java. The list goes on.

If you find a thing you like, you should use it! If you find a thing you don't like, just don't use it! Find the language that lets you express your intention as easily and correctly as possible and run with it. For some people that is Go, for some people that is Erlang.

I'm certain this thread will devolve into "Go isn't a great programming language because..." type posts, but I really think those posts are kind of ill-intended. The author of this post likes Go, which they're allowed to do, and they should continue using and enjoying it.