There is also gaoya ( I am the author ), which is also written in Rust and has python bindings. datasketch is great, but it is not performant enough for my use case. gaoya is used in a production system for large scale clustering
https://github.com/serega/gaoya
Altman "hadn’t been to a grocery store in four or five years". He is so out of touch with real world, people needs and desires, and fantasies about the future world based on the assumption that most people want to be free "to pursue more creative work."
I think most people don't actually dream about pursuing creative work. Being absolutely "free" of work doesn't make one more creative. Real problems and constraints force people to come up with creative solutions.
He's closer to the truth than you're letting on. People do want to be free from being forced to work to meet rent and buy food, and all the associated stress that comes with it.
Sure, some do, but this is not universal truth. Here is what ChatGPT4 has to say about the subject
"As an AI language model, I don't have personal experiences or opinions, but I can provide a general analysis of the topic. People's preferences and attitudes toward work, financial security, and stress vary greatly based on their personal beliefs, values, and experiences.
Many people do express a desire for greater financial freedom and independence, as well as relief from the stress of meeting basic needs like paying rent and buying food. The notion of a Universal Basic Income (UBI) has gained popularity in recent years, which proposes providing a fixed sum of money to every citizen regardless of their employment status. Advocates of UBI argue that it could help address issues of poverty, income inequality, and stress related to meeting basic needs.
However, people's perspectives on work and financial stress are diverse, and not everyone shares the same view on this issue. Some people may find satisfaction and purpose in their work and might not want to be completely free from it. Others may be more focused on career advancement, personal growth, or contributing to their communities through work.
Ultimately, people's preferences regarding work, financial security, and stress are influenced by a wide range of factors, including their cultural backgrounds, socioeconomic status, personal values, and life experiences."
Grayson Hoare who created Rust has been working on Swift language in the last few years at Apple. People change jobs, there is nothing wrong with that. Rust is a community driven project, and the community will keep building. IntelliJ Rust plugin has not stopped evolving since matklad left. matklad may found a new interesting project that happened to be using zig. He didn't say he left Rust community
Curious what modern schools teach in Computer Science programs. I went to Salisbury State University 17 years ago, and we had classes on assembly language, system programming and operating systems where we used C, algorithms classes with assignments in C++, computer graphics, which of course also C++.
My professional experience working in industry was primarily in Java, but also some C, Python, Ruby. Learning Rust was not without a challenge, but having a lot of programming in C/C++ in school more than 10 years ago helped a lot. My assumption that all software engineers who have university degree should have some experience in system programming.
At my university the language used for teaching was predominantly Java, with Python or C# used in some papers.
There was an optional operating systems paper which had you writing some assembly to run on an in-house RISC system [1], but a small % of CS+SE students took that paper.
I think they’re trending towards using Python for most papers now. Not unreasonable for a paper on data mining or web development, but there’s definitely something being lost where students don’t /need/ to understand how the computer’s working in order to get a passing grade, so there’s no real incentive to dig deeper for the average student.
The University I work for teaches Java in Programming I (the mandatory introductory language) for Computer Scientists, and teaches them some C in Programming II and then a functional language, typically Haskell, and potentially some Rust, Typescript, whatever by the third year as some of the students will be pursuing Theory. The Electronics students learn C at the beginning meanwhile. Students elsewhere in the university learn mostly Python and R.
I have to switch between Java Spring boot, Go and Rust. The latter two are framework less and easy to understand just by reading the code. Spring-boot development requires so much googling to figure out why I get UnsatisfiedDependencyException and what each annotation means. Even if I get it to work I still don't understand how it works.
I'm not sure that's contradicting the parent post.
A framework is an added friction to picking up a development environment but potentially a huge asset to velocity once people are up to speed. You haven't gotten properly up to speed in that framework and that site's use of the framework. Perhaps you never spend enough time in that domain to really need to pick it up, in which case you'll always pay the "WTF is this?" tax.
But it's equally likely that once a person's up to speed in the framework they're efficiency is greatly enhanced.
A programming language isn't just the syntax of the language; there's also knowing the common idioms of the language, understanding the runtime / build environment, knowing when and how to leverage the standard and extended libraries/package ecosystem, etc. Frameworks fall into the "extended package ecosystem" which is vastly different from language to language, and sometimes _within_ a language if the language is sufficiently mature.
Some of it is "just math" and some of it is understanding the culture.
Some of the pains with Spring Boot don't go away even when you understand it better. The fact that the framework relies so heavily on reflection makes debugging a pain, turns what should be compile-time errors into runtime errors (which, among other things, makes updating libraries annoying), and also leads to very slow integration tests. I also haven't yet met a developer who fully understands what @Transactional does, exactly.
I agree Spring Boot brings a lot to the table (Spring Security alone, for example), but at the cost of significant downsides.
I see the benefit for larger and more diverse teams, but personally I would choose lighter-weight frameworks and libraries, even if at the cost of having to do more plumbing myself.
> I also haven't yet met a developer who fully understands what @Transactional does, exactly.
I have found Spring Boot to be a step forwards from the old Java EE world in basically every way except for this. Transactional boundaries are somehow more difficult to analyze.
> You haven't gotten properly up to speed in that framework and that site's use of the framework.
I've been working in Spring framework for years, and don't understand it. I suspect most of the people who develop it don't understand it either, as it's so enormous it's probably impossible for any one human being to really understand it.
I'm not trying to defend this or that development environment or framework, just pointing out that there are trade-offs everywhere.
I don't understand speculative execution or any of the other deep voodoo that happens in modern CPUs that spend enormous amounts of energy presenting the "I'm a PDP-11/70 with way more memory and bigger registers" lie to programmers.
These days I'm not even sure which part of my computer is running the networking stack, or where my computer is located.
We stand on towers of abstractions, and complain about the ones we're forced to notice. I don't think many people understand "it" these days.
I mean, you sound like you try to use a tool without knowing it.. why exactly do we believe that it is okay? Would you expect to be able to use a crane at first try?
Spring boot does put a layer of abstraction over ordinary “linear” code, but it is not black magic, if you understand its DI part, you will basically understand everything (in short, spring is only allowed to generate new code, not modify existing one. So it works its whole “magic” by generating subclasses at runtime. With this requirement in place, most of its working makes clear sense. It has an internal list of available beans, and you can inject them by type only (@Autowired/@Inject) when it is the only bean of said type, or you may have to be more specific by naming the desired bean. And it is a simple graph of such injects.)
And it is a well-understood convention, above all. I can go to another spring shop and expect to see JPA entities annotated the way I’m used to (which is another very powerful feature. Can it be misused? Sure. Does it save a shitton of time, and less code means less bug? Yep. Plus, before the “ORMs considered harmful” people join us, they were always meant for OLTP, not OLAP, and as a mapping to/from db records, where they absolutely shine. Don’t try to OUTER JOIN on a subquery of whatever with them, but feel free to write your SQL and map its results to a business object).
I switch between Go, Spring, and ASP.NET (the latest one, which used to be Core, but isn't anymore). I don't think your Spring experience should be extrapolated to other frameworks — dealing with it is certainly significantly more painful than working with dotnet.
You don't get type safety for your database queries without jumping through hoops (compare anything it provides to LINQ — it's not even in the same league). Hibernate feels like a significant step-down after Entity Framework (I might be an idiot who doesn't know how to use it, that's entirely possible, but this just proves the point — it was easy to get started with EF, it didn't require a doctoral in ORM studies to become proficient with, it's dead easy to write queries for (thanks to LINQ), and the vast majority of those translate to pretty efficient SQL which is fine for 99% of my queries).
You get lots of behavior decided at runtime (while ASP.NET for the most part is very explicit in its configuration).
It also doesn't use many annotations (most of those I use are fully optional, like adding pretty names to database columns; and those can be configured through explicit method calls).
It does require DI (and IoC containers are swappable if you don't like the default), but I didn't have nearly as many issues with it as when working with Spring projects, whatever the reason may be.
From what I remember from spring boot it is (or feels like) more of a system to assemble your application from discrete modules, but which modules are used for what can be determined by configuration and various rules.
I mean the use cases of that will be limited these days; application architectures have changed to the point where what used to be a module within a Spring application can now be a microservice to be enabled or spun up depending on rules defined outside of the application.
But this is a very superficial point of view, I haven't seriously touched Spring for a decade and, thanks to some experience with Go, I feel like I won't need to either for most modern-day applications.
While Go may not be for everyone or for every application, its mindset of keeping things simple, just use the SDK or some libraries, etc does make for better developers. IMO.
> Avoid state like the plague
This really depends on the problem domain. Application state is fine in many areas, and in the case the state is non trivial managing it in the application is a lot easier that pushing to databases.
