came here to say similar. GGP is another great example of hn people jumping in to make comments without having even a basic understanding of what they're talking about. Frustrating as it spreads misinfo about security which is the last thing we need.
You're in a comment section where people are flipping out that there exists a computer on his desk that isn't connected to any DoD network but is connected to the public internet.
Approximately 30,000 people go to work in the Pentagon every day. There are areas in the building that are SCIFs and they don't allow cell phones and laptops. But the majority of the building is an office building used for office building type stuff. Employees and contractors bring their personal cellphones and mobile devices in there every day.
> How hard would it be to automate these iterations?
The fact that we're no closer to doing this than we were when chatgpt launched suggests that it's really hard. If anything I think it's _the_ hard bit vs. building something that generates plausible text.
Solving this for the general case is imo a completely different problem to being able to generate plausible text in the general case.
They can check their work and try again an infinite number of times, but the rate at which they succeed seems to just get worse and worse the further from the beaten path (of existing code from existing solutions) that they stray.
I'm a committed Kotlin shill and a very experienced Gradle user but I'm the first to admit that it is absolutely arcane for those new to it. Once you know all the incantations it's really flexible and performant but good luck writing a plugin for the first time.
My favorite thing about gradle is that the build file is written in the same language as your code. This gives you the great power of easily adding a little hack into your build file, so it's pretty rare you actually have to make a plugin.
The downside is that every build file is a little bit unique, but IME it's not that much worse than what happens in golang. In golang people usually slap a makefile on top of the go commands, and then you have to read the makefile to figure out what targets you need to run, and if it gets a little complicated then they start calling out to shell scripts and things like that. ech.
Very interesting. Bulk of my career has been writing Kotlin/Java and after a year of Go I am _still_ really struggling. Nice to know I'm not alone!
I see the benefits (I've have seen some absolute Java ee monstrosities that would be impossible to build in Go) but why am I getting paged at 3am because someone forgot to set a field on a struct. Similarly all the codegen to workaround the lack of inheritance - who cares how fast the compiler is if you've got to do 30s of codegen on top.
As a Java/Kotlin dev now writing Go for a living I agree with quite a bit in here and actually think both languages have things they could learn from the other.
Having said that I cannot understand where the idea that "the [Go] libraries and ecosystem are so much better" comes from. The average quality of both the JDK libs and the popular 3p libs (Jackson, Jooq, even ...Spring) are one of the things I miss most about writing for the JVM and I'm yet to come across another ecosystem that comes close.
I'm increasingly bullish on the JVM ecosystem. The runtime is amazing, performance-wise, and the third-party libraries are really good, if hard to get into. With Kotlin you can get null safety, and IntelliJ is the best code authoring experience for me.
I've written a lot of Python in my life, and it's been good. However I'm happy to leave dynamically typed langs behind for everything but prototypes/exploring a space. Life's too short to chase down prod issues caused by obscure error paths that are rarely hit.
Java has some incredible libraries with impressive performance characteristics. The ecosystem is also full of strange/unnecessary build time magic, obnoxiously verbose patterns, and horrible error handling.
I mean I think there is a philosophical divide. Go is very minimalist in terms of external dependencies. Those that are their are very good in my experience. The builtins are just the right amount of opinionated imo. I concede that that statement was grounded in my preference for Go's take on external dependencies.
I also generally am writing REST APIs and doing simple "enterprisey" stuff.
Well, that was a conscious choice of the JDK devs when they went down the path of removing things.
Raw Java is Pretty Close to being "out of the box" OK for "REST, enterprisey" stuff.
The built in HTTP server is usable and functional. Of course TLS is built in. JDBC is built in (need a driver). While XML is built in, JSON is not. Logging is built in. JMX for monitoring is built in (lots of things can talk to JMX).
Are these all "top tier" feature rich implementations? No. But they're completely usable. With some thin veneers you can make them richer and more friendly. I've been using my own trivial Logger wrapper for years (mostly to support varargs).
If you're willing to take a bit of a step, JAX-RS on Java SE works. That "single" dependency just knocks it out of the park in terms of "enterprisey" REST services.
No container, no "micro profile", just JAX-RS (but you still need a JSON library). JAX-RS really elevates the game. It'll even run on the stock HTTP server.
Add "just one more" with JPA, and you get not just the whole ORM, you also get a "free" database connection pool (otherwise, an OTS connection pool would be a nice addition).
All bottled up into a simple deployable jar, no dependencies outside of a compatible JDK. No dockers, no containers, just a jar and a JDK, a JDK that can be installed anywhere (just set JAVA_HOME and put the .../bin on your path). Drag and drop. systemd fixed the need for crafty service scripts -- it can just run the jar.
JAX-RS Jersey, JPA EclipseLink, Jackson (for JSON), and the JDK is just crazy capable tool set. You can also do MVC web stuff with Jersey. Jersey comes with Validation as well. The HK2 runtime will let you do your own injection if that's your thing (not as nice as CDI, but it's "free" with Jersey).
But, alone, (plus Jackson), the JDK will let you do anything you want, just need to write some routing logic.
Go is too minimalist in my opinion. It’s like time warping back to 2005. You want enums, nope. You want functional constructs (map, filter), nope. You want string array contains, nope. It can feel very limiting coming from newer languages designed in the last 10 years.
Functional programming is not "newer", it is as old as Lisp, which dates back to the 60s. The people who made Go simply decided that the language did not need those features.
So instead we have 10 different libraries and 100 different custom implementations to do those things in Go. Compared to almost every other major language where you can do functional stuff (and everything else the Go developers decided we didn't need) natively:
Java: Arrays.stream(nums).map(n -> n * n).toArray();
Kotlin: nums.map { it * it }
Python: list(map(lambda x: x*2, nums))
C#: nums.Select(n => n * n).ToArray();
Ruby: nums.map { |n| n*2 }
Rust: nums.iter().map(|&n| n * n).collect();
Perl: map { $_ * $_ } @nums;
Rob Pike has talked before[1] on this exact subject, about how all languages are merging into one giant PL-theory sludge where every camp is adding and stealing features from one another, and that one of purposes of Go was to avoid following in this same direction.
Fair enough. I agree with the sentiment that we need diversity in languages.
Personally, when I'm solving a problem, I like to reach for the pre-established universally understood pattern that's built into my language. Rather than using a language that doesn't have any of those things and requires me to create my own, worse, implementation that's unique to my program (or use a random 3rd-party module of dubious quality for something basic).
You could just use a for-statement, you know. I feel like there's a reactionary avoidance to iteration to the point that it doesn't really make sense.
I feel like we've jumped out of the frying pan of the 90s' OOP craze, directly into the fire of doing the same cargo cult behavior with functional programming. Always avoid loops, always use higher-order functions. It just makes sense. If you are not provided with the shotgun spread of higher-order functions out of the box, be frustrated.
I vaguely recall reactions to Haskell in the late 90s where vitriol was spewed over the lack of inheritance and classes.
In my particular example, these were of course deliberately simple snippets to illustrate the point. The power comes in chaining these things, .map.filter.reduce... . Using iteration, you end up writing a lot of boilerplate that is much harder to parallelise, and extremely difficult to lazily evaluate. Without these constructs, to express "the concept of filtering & reducing an array", the reader of your program needs to read how you implemented those things, in addition to what you're using them for. You can do that stuff yourself in goroutines, but there is no contest to having native support for these extremely common operations.
Loops are just clutter. I’d rather concentrate on the filter and transform and not be bothered with the raw mechanics of looping, creating an intermediate array and appending to it. Not to mention that some languages returns a lazy evaluated view of the original storage.
Strong, strong agree on this. That plus the verbosity really adds to the activation energy of getting things done. I reckon I end up writing (and having to read) 5x the lines of code for the same result that then ends up being less type safe and lacking null safety. I guess that's the price you pay for simplicity.
It has enums, and if you want exhaustive checking, use golangci-lint (as every good gopher should be already, considering the language ensured tooling would be easy to write) https://golangci-lint.run/usage/linters/#exhaustive
> You want functional constructs (map, filter), nope.
There are libraries for map/filter (just make sure you use one with deforestation)
Just posting an update to my original article. Should be useful for anyone who needs to get going fast with AWS on Terraform. Leave a comment/issue on the repo if anything's wrong or unclear.
