Honestly my largest feedback is what does it integrate with? Present this on the homepage instantly. The documentation doesn't cover it, and clicking "+ database" has me sign up. I'm not going to sign up unless I can do what I need to do and I don't know if I can if I don't know how the dataset is configured or what it can pull / be streamed from.
Ultimately, it all comes down to build what you're comfortable with. Additionally, when you're managing large organizations and teams. Build with what you can hire quickly for and easily scale with.
Quick (and cheap?) hires are not necessarily good hires.
In my experience (and my theory) developer productivity can range from 0.5x to 5x and more, and those developers in the upper range tend to look for certain programming language which they enjoy, like Rust, Go, Elixir, Scala and Clojure. They are hard to get if you are on a "boring" stack like Java, NodeJS, PHP.
So if you might need to invest some time and money to find the right people, but at the end you make a better deal: Even if the salary is twice as much, the productiviy is even more. Additionally less people means less communication overhead, which is another advante.
I find the opposite to be true, that best and most productive developers tend to be more language agnostic than average, although I'm not saying they don't have their preferences.
Specifically, I find language evangelists particularly likely to be closer to .5x than 5x. And that's before you even account for their tendency to push for rewriting stuff that already works, because "<insert language du jour here> is the future, it's going to be great and bug free," often instead of solving the highest impact problems.
I've worked with language zealots and it's awful. Especially the ones with the hardcore purely functional obsession. But that can apply to almost anything: folks that refuse to use anything but $TECH (K8S, FreeBSD, etc). Zealots like this general care less about delivering and more about what they get to play with.
Then you have the folks that care about delivering. They're not language agnostic, they have strong opinions. But also: they communicate and collaborate, they actually CARE: they have real empathy for their users and their co-workers, they're pragmatic. Some of these folks have a lot of experience in pushing hard to make things work, and they've learned some valuable lessons in what (not) to do again. Sometimes that can manifest as preferences for languages / frameworks / etc.
It's a messy industry, and it can be extremely hard to separate the wheat from the chaff. But a small team with a few of those can do truly game changing work. And there's many local optima to be had. Get a highly motivated and gelled team using any of: Elixr / Typescript / Zig / Rust / Ada / Ocaml / Scala / Python / etc, and you'll see magic. Yes, you don't need fancy tech to achieve that. There's more than a few of those writing C for example, but you're unlikely to see these folks writing COBOL.
I agree with you but also agree with the above, if youre stuck permanently in some tangled codebase with a boring language/style, the really good programmers tend to find something more fun to work on - unless they can bring their new skills/experience to bear. personally I'll only go back to doing boring stuff if i can't find a job doing the fun stuff
Yeah, this has been my experience too. The mentality seems similar to "productivity hackers" who spend more time figuring out the quickest, most optimal way to do a thing than people who just do the thing.
One of the things I've noticed is that people who just do the thing, take note of what's annoying, and fix the most annoying things about a process later on tend to make the most impressive dents in a system or process, especially since they spend time mulling over the idea in their head and so by the time they implement, they aren't "zero-shotting" a solution to what's generally a complex issue.
100% agree. You have hit the nail on the head. I went from Common Lisp to Go to now Rust and find that Rust devs are the best so far on average.
There are fewer of them, they ask for more money, but they really are exceptional. Especially Rust devs right now because there are not a lot of jobs you only find the most passionate and the most brilliant in that space. A short window though which will close as Rust gets more popular to startups, take advantage of it now.
In my case, it was definitely worth becoming uncomfortable for a bit to learn Clojure because I was very uncomfortable with the experience of many of the other languages. It’s also great to have endless backwards compatibility and little reliance on changing external libraries baked in.
Having to compile every time (or at least there not being a convenient wrapper that compiles and runs at once), the boilerplate of having to define a class and main method, exception handling, and most of all having to deal with Maven.
you don't need to deal with Maven if Java standard library(which is huge) is enough for you. Also, not sure why such big resistance against maven.
Other pointers are either opinionated or minor. From another hand, if dev has experience in Java, benefit of not learning some new language/ecosystem is kinda huge.
Right, but that's because it is not obvious what they should mean or how to implement them. In particular, it seems that intolerable complications to the linker would be required. Contrast that with, say, a proposal to add a more concise syntax to Go for anonymous functions. Everyone can see exactly what that would mean and how it would be implemented.
I'm not saying that Go should never add generic methods to the language. But it's at least reasonable to hold off from doing so until these issues are clarified.
There is a concise explanation of the central problem in a comment in the issue thread:
> The crux of the problem is that with a parametric method, the generated code for the body depends on the type-parameter (e.g. addition on integers requires different CPU instructions than addition of floating point numbers). So for a generic method call to succeed, you either need to know all combinations of type-arguments when compiling the body (so that you can generate all bodies in advance), or you need to know all possible concrete types that a dynamic call could get dispatched to, when compiling the call (so you can generate the bodies on demand). The example from the design doc breaks that: The method call is via an interface, so it can dispatch to many concrete types and the concrete type is passed as an interface, so the compiler doesn't know the call sites.
Rust allows generic methods on traits but doesn't allow these traits to be instantiated as trait objects. Perhaps Go could do something similar. https://docs.rs/erased-generic-trait/latest/erased_generic_t.... But it's far from obvious to me that this would be a good idea for Go, and I'm glad the Go team haven't rushed into anything here.
