Not really tried the Claude 3.5, later tried o1-preview on github models and recently Qwen2.5 32B for a prompt to generate a litestar[0] app to manage a wysiwyg content using grapesjs[1] and use pelican[2] to generate static site. It generated very bad code and invented many libraries in import which didn't exist. Cluade was one of the worst code generator, later tried sieve of atkin to generate primes to N and then use miller-rabin test to test each generated prime both using all the cpu core available. Claude completely failed and could never get a correct code without some or the other errors especially using multiprocess, o1-preview got it right in first attempt, Qwen 2.5 32B got it right in 3'rd error fix. In general for some very simple code Claude is correct but when using something new it completely fails, o1-preview performs much better. Give a try to generate some manim community edition visualization using Claude, it generates something not working correct or with errors, o1-preview does much better job.
In most of my test o1-preview performed way better than Claude and Qwen was not that bad either.
Like you said its fine to promote language on its merit, but using false propaganda to promote it borders fraud and Rust community needs to act together to stop such practices.
Overhype within Rust community is a sign of fear among the community that some simple language (may be zig, nim or something new) might come and pull the rug under their feet. Given it compromise on simplicity in favour of quashing memory safety bugs.
One reason rewrite in Rust is popular because its easier to copy something already done vs doing something original (one recent example came to mind is rewriting gnu coreutils in Rust).
GPT-4 prompt:
“Write an essay in 1000 words why Sam Altman should be fired by OpenAI board”
Response:
Sam Altman, the CEO of OpenAI, has been a controversial figure in the AI industry. His leadership style, lack of transparency, and decision-making processes have raised significant concerns among OpenAI's employees and the public. This essay will delve into these issues, arguing that Altman's actions warrant his removal from his position.
Firstly, Altman's lack of transparency is a major concern. He has been known to make decisions without adequately consulting with his team or the public. This has led to a lack of trust and dissatisfaction among OpenAI's employees. For instance, when Altman announced that OpenAI would be focusing on a single project, he did not provide sufficient reasoning or context. This lack of communication has left employees feeling disenfranchised and uninformed.
Secondly, Altman's decision-making processes are often questionable. His decisions have not always been in the best interest of OpenAI or its employees. For example, when OpenAI decided to pivot from developing AI systems to developing AI safety research, many employees felt that this was a strategic mistake. Altman's decision to focus on this area without considering the potential negative impacts on the company's reputation and financial stability was a clear example of poor decision-making.
Thirdly, Altman's leadership style has been described as autocratic. He has been known to make decisions without considering the input of his team. This has led to a lack of buy-in from employees and has negatively impacted morale. For instance, when Altman decided to shift OpenAI's focus to AI safety research, many employees felt that their ideas and contributions were being overlooked.
Finally, Altman's actions have also raised concerns about his commitment to AI safety. His decision to focus on AI safety research, rather than on developing AI systems, has raised questions about his commitment to the field. This decision has also raised concerns about the potential misuse of AI technology and has led to a loss of trust among the public.
In conclusion, Sam Altman's lack of transparency, questionable decision-making, autocratic leadership style, and concerns about his commitment to AI safety are all reasons why he should be removed from his position at OpenAI. It is clear that his actions have led to a lack of trust and dissatisfaction among OpenAI's employees and the public. It is crucial that OpenAI takes these concerns seriously and makes changes to ensure the success and safety of its AI technology.
May be give anthropic a try the answer is more correct than ChatGPT, indeed in every subsequent attempt the quality of ChatGPT both GPT-3.5 and GPT-4 deteriorated.
Here are the answers:
ChatGPT:
First response:
Mary is the sister of Susan and Susan has 7 brothers. Each of these 7 brothers has one sister, and that sister is Mary. So, Mary has 7 brothers, and she is also the sister of Susan. Therefore, Mary has a total of 8 sisters, including Susan.
Second Response:
Mary is the sister of Susan, so she has one sister. There is no need to consider the 7 brothers in this context as the question is asking specifically about how many sisters Mary has.
GPT-4 Response:
From the information provided, we can infer that Mary has one sister, Susan. The question specifically asks about how many sisters Mary has, and it doesn't mention any other siblings. Therefore, based on the given information, Mary has only one sister, Susan.
Anthropic:
Okay, let's break this down step-by-step:
Susan has 7 brothers
Each of Susan's 7 brothers has 1 sister
So there are 7 sisters total (1 sister for each of the 7 brothers)
The question asks how many sisters Mary has
Mary is not mentioned anywhere else in the problem
So there is no information provided to determine how many sisters Mary has
Therefore, the question does not provide enough information to determine how many sisters Mary has. The number of sisters Susan's brothers have does not tell us anything about how many sisters someone unrelated named Mary has.
Most Japanese manufacturers are small and many parts of battery and battery cell supply depends on China. Japan lost the battery battle so want to use something else. Tesla’s largest battery supplier is Chinese CATL[0].
So in EV Japan is a minor player, if not for US sanctions Chinese EV makers would have overtaken Tesla as well, but which they will give them some time.
Not really comparable after paying for CoE for open category 152K SGD (US$104K), in Singapore there is a advanced registration fee called ARF,then there is additional tax on top. So a typical BMW X5 will be around SGD 540,000 (US$ 394,600) and that too for 10 years, after 10 years need to buy a new CoE or discard the car.
A Tesla Model S will be more than 400k for 10 years after that need another 100k for 10 year renewal.
Also fuel prices and road tax are high in Singapore which needs to be paid regularly besides buying costs.
> But that's missing the point that Python is still not meant to be the best at anything, but good at most things.
The most important thing about Python is readability and its part of its syntax and is one of the best languages out there for readability.
Zen of python:
>>> import this
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
>>>
> Heck, the package manager having to execute random code in every package (setup.py).
Nope! Not since the mid-2010s. It took a long time, but with wheels[1], install-time actions are finally separate from packaging-time actions, and the former do not include any user-defined actions at all.
Just about every sufficiently general system allows for arbitrary code in the latter, be they in debian/rules or PKGBUILD or the buildPhase argument to mkDerivation or—indeed—in setup.py. (Most systems also try to sandbox those sooner or later, although e.g. the Arch Linux maintainers gave up on cutting off Go and Rust builds from the Internet AFAIU.)
Don’t forget to `python setup.py bdist_wheel` your stuff before you upload it!
> And speaking of beautiful and elegant, dunders everywhere, really?
It’s the one reserved namespace in the language, so its usage for __init__.py and __main__.py seems—perhaps not beautiful, but fairly reasonable?
> Just about every sufficiently general system allows for arbitrary code in the latter, be they in debian/rules or PKGBUILD or the buildPhase argument to mkDerivation or—indeed—in setup.py. (Most systems also try to sandbox those sooner or later, although e.g. the Arch Linux maintainers gave up on cutting off Go and Rust builds from the Internet AFAIU.)
Most other programming language package managers don't, see Maven for Java.
But then again, NONE of the scripting languages ever wanted to learn stuff from Java, especially regarding packaging (lack of packaging namespaces is another major blunder re-created by Python and several others, including Javascript).
> Most other programming language package managers don't, see Maven for Java.
So it’s not able to express native extensions or even codegen then? I suppose that’s OK for something that’s not the only available solution, but I don’t think I’d love it, either.
> But then again, NONE of the scripting languages ever wanted to learn stuff from Java, especially regarding packaging[.]
Both Java and its docs are just extremely tedious to read, to be honest. I say that with all due respect to its principal designers and acknowledging my ever-hopeless crush on Self where a lot of the tech originated. (And I don’t only mean 2000s Java—it took me literal days to trawl through the Android frame pacing library to find[1] the two lines constituting the actual predictor, commented “TODO: The exponential smoothing factor here is arbitrary”. The code of the Go standard library, nice as that is, gives me a similar feeling with how... vertical it is.)
That’s not an excuse for ignorance, but it’s a centuries-old observation that you need to avoid inflicting undue pain on your readers if you want your ideas to survive. The flip side is that there may be untapped ideas in obscure or unpleasant texts written by smart people.
So if you can point to things one could learn from Java, I’d very much be interested.
(And no, literature searches are not trivial—I’ve occasionally spent months on literature searches, sometimes to realize that the thing I wanted either isn’t in the literature or is in someone’s thesis that’s only been published a year ago.)
Well, they didn't need to read much about Java in this case, frankly. Just creating a simple Java project with Maven would have showed the groupId concept (namespaces preventing top level squatting), for example.
Lack of namespacing is a trap most language package managers have fallen into sadly: even Cargo sees it as an “advantage” not to have them, apparently.
I think that is extremely short sighted, and that all packages including standard ones should be namespaced.
and classes are most of the time not needed anyway, it's just Java programmers that aren't used to the idea that code can be perfectly correct and readable without a single class
1 point by dragonsh 3 minutes ago | root | parent | next | edit | delete [–]
I follow these simple rules for breathing
1. Breathe to stomach not chest.
2. Breathe by nose (unless swimming or underwater).
3. Inhalation time and exhalation time should be equal and gap between inhalation and exhalation should be sum of it. If it takes x seconds to inhale exhalation should begin after 2x seconds and should finish in x seconds
Retention (2x) = inhalation time (x) + exhalation time (x).
All the pranayam and yogic techniques try to make it natural to have this pattern and symmetry in our breathing process.
They are fighting Russia using man power provided by Ukraine. If not for US, war would have been over with some resolution already.
I hope instead of war world move more towards reconciliation and vie for more peaceful solutions, not prolong a conflict by selling more weapons. Soon this will be the same story repeated for Taiwan against China.
Many people are facing death in flood hit Pakistan with over 13 million not having access to clean water, world is staring at a staggering number of fatalities more than the total casualty in Ukraine war. But Pakistan’s disaster is not important, same for Sri Lanka. In UN assembly all focus will again be on Ukraine with lots of speeches and making special exceptions for virtual speech, unlucky for developing world UN doesn’t have enough bandwidth for them.
True and if you look inside the code you can see the stated features are a result of underlying engine from those smart people (TiKV [0] in C and rust from pingcap). Surrealdb is standing on shoulders of giants at present, they are TiKV, FoundationDB and rocksdb. The feature set they mentioned mostly coming from TiKV at present.
TiKV is written in rust but then it depends on crates which use C and libc. Rust complements C, it is not an alternative to C, just another alternative to C++.
May be 20-30 years down the line, if it stays may be enough OS and libraries are built in native Rust without C then it might displace it, but at the moment Rust depends on C.
Rust is absolutely an alternative to C. The fact that Rust currently depends on C libc on some platforms is a pure implementation detail, and I believe there is ongoing work to remove that dependency.
C is implementation detail and that's what make it irreplaceable in short period of time. In my view Rust story will be similar to C++ if it continues to stay relevant for next 20-30 years and will be another alternative besides C++.
Right now Go is miles ahead of Rust when it comes to libraries and ecosystem. So it needs to catch up and once it overcomes Go popularity it might be nearer to C++. C is a different beast and will continue to be there it's the lingua franca of hardware programming and abstraction, unless something simpler comes and takes over which will also be 2-3 decades.
> Right now Go is miles ahead of Rust when it comes to libraries and ecosystem.
I'm not sure that's true. A couple of years ago sure, but Rust is growing very fast.
I also think there's no reason to think C will stay around forever. The C ABI will be the lingua franca, but that doesn't mean you need to actually use C.
The only reason it has persisted for so long is lack of alternatives, but now we have at least Zig and Rust. Obviously there's a ton of momentum so it will still take a while to be replaced but I wouldn't be surprised if e.g. musl switches to Zig or Rust fairly soon.
I am sure its true, given Kubernetes, Docker and related projects, CockroachDB, prometheus, influxdb, nomad, otto, consul, grafana, terraform, snap, juju, Caddy, SeaweedFS, minio, milvus, syncthing, cilium are some of the examples in Go. Indeed it will be safe to say Go is one of the prominent language like Java, Python, C, C++ powering the internet. Rust still has a mountain to cross to reach even half as much usage as Go, except TiKV, Rust itself and Servo I don't see large open source software in Rust yet.
There is a lot of talk about it on HN and may be given 20-30 years it might become more widespread. Rust is still recovering from its failure of Servo not being used by Mozilla, given it failed to live up to expectations of replacing C++ in Firefox due to performance issues and resolving them within time constraints of project budget.
In most of my test o1-preview performed way better than Claude and Qwen was not that bad either.
[0] https://github.com/litestar-org/litestar
[1] https://grapesjs.com/
[3] https://getpelican.com/