Comment by quadcore | Hacker News Reader

Comment by quadcore | Hacker News Reader

“I know: I’ll create a triple zoned redundant architecture with pub/sub database replication, a 32 node Kubernetes cluster and private networking across all regions – that way, I can handle anything!”

The good news is, once you've done that, you can get a pretty decent job.

The majority of software engineers seem to be under the illusion that potential customers care about the stack they are running.

This is not entirely true. The technology do surface in terms of user experience. It does in the details: app start, ui responsiveness, etc. I'm writing a game using go right now, and the end user can tell it's different because the user's cpu seems more powerful.

All in all, I think those are good mistakes, not bad ones. I wish more engineers could spot over-engineering, and they don't until they did the mistake a couple times. Side projects are, I believe, how one really learn to write programs. I think the right advice is: do whatever you want, do all the mistakes. How can you write a successful side project anyway if you never learn how to write a program? Also, the worse type of programmers are the ones telling you about over-engineering because they read about it in a blog. Code more, read less, I guess should be a good motto.

Potential customers do care about the stack you're running. They care if they have to download Java or Flash. They care if they have to be connected to the internet or can use your product offline. They care if your program starts quickly. They care if your program runs quickly once started. They care if your program has bugs (let's not pretend different languages aren't more or less error-prone). They care if your program is cross-platform. They care if your UI is consistent with their platform. They care if your product releases new features quickly.

All of these are stack-related.

Packaging and designing an application is a developer's problem, not a user problem.

Those are all client usability concerns, and none of them are stack intrinsic.

I think the point was that user doesn't care about your stack, but they care about the consequences of the stack you've chosen. It's a subtle but important distinction.

Of course. My point was that it's fairly common to write slow/unsuitable applications in spite of a stack's strengths, while stack limitations (or strengths) are generally overstated, depending on trends.

Proper engineering and design are required no matter what you choose.

No silver bullets ;-)

There are no silver bullets, but there are wooden bullets that are totally ineffective.

Have you figured out a way to make a mature implementation of the JVM start up fast? Nobody else in the industry has.

Is there some way I know of to package Flash games so that Firefox users can play them without downloading Flash?

I get that done of the examples I mentioned are arguable, but some of these are pretty unambiguously stack intrinsic. Some usability concerns cannot be addressed in some stacks.

Notice how just about none of them are the user caring about your stack.

In other words, when confronted about your high bug rate, you're not going to get anywhere going "heh, you see, Python was just more convenient than a statically-typed language and this lead to..."

All of those are pretty much influenced by your stack. If you need a highly reliable software, you would be stupid to write it in Python.

You are right that nobody will care if you use them as excuses. But that is not what the GP said.

"A customer will not know or care if you are using Ruby, Go, PHP or any other language as long as what you have written is performant and is fit for purpose (which all modern languages are)."

Where games are concerned I'd tend to agree (though Minecraft was built in Java and was TERRIBLE for the first couple of years, now look at it).

> Minecraft was built in Java and was TERRIBLE for the first couple of years, now look at it

Well, it still takes absurd amounts of memory for what it's doing, which I guess is on par for Java. (On my notebook with 4GB RAM, modpacks fall into one of three categories: "works well", "have to shut off as many OS services as possible before starting" and "forget it".)

well only because java has no value types/struct like data structure.

the reason why this makes memory so heavy is because even a simple int list, needs boxing. So you end up with a big chunk of garbage which you don't need. On the server, this is not a problem because most of the time the list is a young gen object and die really fast, so G1GC solves most problems. The problem of course is really big, because arrays are a pain to work with and not many people do that.

However as soon as java 10 hits, we might get value types and maybe this changes the game (but we will see, since it would've taken way to long for that thing). Also there are more and more types inside the standard library who would be great value types, i.e. LocalDate/LocalDateTime, but at the moment they take way more memory than needed, especially since they only contain 2 immutable shorts and 1 immutable int.. in the perfect case it would be something like 8 byte, however it takes way way way way more. (basically a simple class at least takes 16 bytes, which is already double the field size, so you end up with 24 bytes [probably more due to various other stuff])

btw. for a game like minecraft you probably have a lot of types that follow the same stuff like LocalDate, small class with immutable int's/short's for position, etc. these have the same problem and will fill the memory more quickly than needed

> Well, it still takes absurd amounts of memory for what it's doing

Does it though? There's a non-trivial amount of data being loaded (and generated) all the time.

You have mentioned modpacks. Those can be HEAVY. And a single not well programmed block can bring down and entire server.

comparing minetest (a c++ minecraft clone) and minecraft gives the following memory usage upon starting on a blank new world. Also, minecraft takes five times more time to launch.

  smem  | grep mine 
   5728 jcelerier minetest                           0   433136   439287   466348 
   7044 jcelerier java -jar /usr/share/minecr        0   691476   708501   753948

4GB? I wouldn't expect most open world games to perform well with 4GB. I think 2010 was the last time I had a laptop with less than 8GB. My current laptop has 16GB. Game developera and certainly mod developers don't optimize for bargain basement hardware.

These days, Java is on the faster side of languages in common use. At least it wasn't written in JavaScript or Python!

You can make fine games in Python. See Eve Online: https://community.eveonline.com/news/dev-blogs/stackless-pyt...

What frameworks/methods are you using to develop a game in Go?

sdl

> The good news is, once you've done that, you can get a pretty decent job.

And you'll likely have to.

You'll likely have to anyway :) I still make a difference between writing a side project and starting a startup. The way I see it, there is no failing on a side project.

Reply on news.ycombinator.com