Hacker Newsnew | past | comments | ask | show | jobs | submit | raphael_kimmig's commentslogin

Wow this looks really interesting. Do you per chance have a video of you using the grinder & machine?

I’m not quite sure I understand where the hot water is added, but I like not having a boiler.


I second the request for videos. I'm primarily interested in the espresso machine and the lack of an end to end video will prevent me from giving it any really consideration.


I will upload a simple video of the workflow very soon!


Can’t you empathise? The thought of having to grade and give advice on AI generated content makes me want to run away and live in a remote forest.


Well I am not very good at empathy, indeed. Sorry.

But really. Teachers have complained about stupid or uninterested kids for ever. This does not make schools pointless. I am not good at teaching, but some people are, and manage to do it despite some setbacks. Is this AI thing really insurmontable? Did she at least attempt to fix the problem, before quitting?

Feels to me like "we've tried nothing, and we're all out of ideas".


If you always start with heads the method works out. The key is that the first and the second toss need to be independent so that HT and TH have the same probability. If you influence the second toss based on the first one it no longer works.


We have been working on something that sounds similar. It ain’t perfect yet, but we are using it quite a bit already.

https://github.com/django-beam/django-beam


That is completely false.

The numbers may vary, but any credible source you are going to find will show that the vast majority of soy is grown for animal feed.

https://ourworldindata.org/soy


Yeah, by mass. Look into the actual dollar numbers. It’s not economically viable to feed human-edible soy to cattle. There are much cheaper food sources. Cows just get the scraps (which outweigh the human-destined product). It’s not grown “for cattle” in the sense that cattle have essentially zero effect on the amount of soy that gets grown. https://www.worldwildlife.org/industries/soy


This isn't true at all. The majority of soy produced all over the world is feed grade soy which isn't destined for human consumption.

Other than that I just can't find any sources that corroborate what you say. Every single source I could find that has actual numbers contradicts your statement.

Take the US for example

Just over 70 percent of the soybeans grown in the United States are used for animal feed, with poultry being the number one livestock sector consuming soybeans, followed by hogs, dairy, beef and aquaculture. The second largest market for U.S. soybeans is for production of foods for human consumption, like salad oil or frying oil, which uses about 15 percent of U.S. soybeans. A distant third market for soybeans is biodiesel, using only about 5 percent of the U.S. soybean crop.

from https://www.usda.gov/sites/default/files/documents/coexisten...


> This isn't true at all. The majority of soy produced all over the world is feed grade soy which isn't destined for human consumption.

Yeah because that’s how soy beans work dude. I think there must be some miscommunication here - the majority of the harvested soy bean is physically not palatable to humans.

Perhaps you are misunderstanding what “70 percent of the soybeans” means. 70 percent of the harvested soy material is not salable to humans. It’s called “soy meal”, look it up. It’s not like if you count all the beans that get picked, 70% of them go to cows. Each harvest is mechanically separated into its component parts and shipped to different consumers, and only a minority of the mass is suitable for oil production or direct consumption.


No, this is not about the percentage of harvested material. I’m having trouble believing that you are having this exchange in good faith, so I’m gonna end this here.

And just so we don’t end this discussion with misinformation I’m gonna leave a final quote here:

About 85 percent of the world’s soybeans are processed, or "crushed," annually into soybean meal and oil. Approximately 98 percent of the soybean meal that is crushed is further processed into animal feed with the balance used to make soy flour and proteins.

https://web.archive.org/web/20170112075924/http://www.soyate...

Have a great day!


Literally just google “soybean meal” and you’ll understand what they’re talking about. I feel like I’ve explained this pretty thoroughly. I can’t get my head around how you feel the need to conflate percent mass with percent quantity. Is there some language or conceptual barrier here?


The effect you describe in your example is called target fixation.


There are definitely some things to be considered here, however I find that most people drastically overestimate the amount of work associated with hosting things.

Also they tend to underestimate the amount of work required when using managed solutions. For example, you'll certainly want to do secondary backups and test restores even for managed options.


100% this. The demo application I built for my book[0] that sets an entire standalone PostgreSQL server can be understood in a few hours.

If your database fits one server, you should consider it.

[0] https://gist.github.com/strzibny/4f38345317a4d0866a35ede5aba...


It's interesting that the resulting go code has 43k lines of code, while the python client for raven only has 6k lines. I don't know whether they have equivalent feature sets - but I kind of wonder how it would have turned out if the go port would have been based on the python version.


Python is a much more concise language. There are no brackets/parenthesis to surround blocks, that's 10% to 20% less lines just for that. A truckload of data classes and static declarations don't need to exist in python because of its very dynamic nature. Last but not least, python idioms like list comprehension and single line if else can replace a whole code block from another language.

Expect a python program to be half or a third of the size of java/c#/go.


go codebases are not shorter (by much) than java's.

Performance is also usually on par - unless java's equivalent is built around a lot of reflection (orm and what not).

However, go compiled binaries are usually smaller, and code IMO is much more readable.


Like with all languages the implementer matters. There's a remarkable amount of variance that I've encountered in the tersiness of both Go and Java code.

For example, Go's err != nil pattern is often cited as being ugly, but good go code will often remove errors by design.

There's a good post by Dave Cheney about this; https://dave.cheney.net/2019/01/27/eliminate-error-handling-....

I think this is equally true of Java. Most Java code I've seen disgusts me, but I've also seen some beautifully written pieces.


This pattern is known in numerical computing as NaN. It’s drawback is that when the computation produces NaN, one has no idea what triggered it. But that can be mitigated if the program prints stack trace on the first NaN. In case of Go that corresponds to logging error when it happens.

Another thing is that in many cases there is no good sentinel value to return that naturally leads to exit from loops or complex logic to check for error at the end of a function.


If anything, I’d say that due to a lack of generics, and more verbose exception handling, go codebases tend to be somewhat longer than java ones.


Go error handling is a little bit more verbose, although I find it more readable and consistent than checked exceptions in Java, that everyone seems to find a way to abuse or ignore (wrap into catch all).

Go codebases do tend to be a little shorter due to lack of getters/setters... and generics are not used that often in production codebases anyway, relative to all the rest of typical code (that’s procedural anyway).


> generics are not used that often in production codebases anyway

no.


> go codebases are not shorter (by much) than java's.

They're usually longer. See: no generics, error handling, among other things.


what do generics have to do with making it longer?

If you want to argue 'usually' then you could consider all the build scripts and XML files, class boilerplate and exception code of Java to be 'usually longer'.

Please don't troll.


> what do generics have to do with making it longer?

Code duplication, just one example: https://godoc.org/github.com/cznic/mathutil#Max

Even with exception handling code, Java is shorter. Build scripts are not part of this discussion.


Except Java's method that does the same (Math.max) does not use generics and instead has overloads for the various numeric types it supports.


They are pretty much equivalent, feature wise. However, the Python client gets away with a lot less code because of the dynamic nature.

Another reason for the difference is that the Java client is actually considered to be the primary one, which all the other ones are based off.

The Python client is missing a fair number of tests, though.


That probably has a lot to do with the error checking in Go.


I’m sure that’s a good chunk of it. Go also lacks list comprehensions, so you have a for loop instead. Go has more boilerplate, but not more complexity.


Boilerplate is complexity.


Idk, you are arguing that more lines of code equal more complexity.


No it's not, by definition. :)


It doesn’t have to be like this. Look up underwriting - by writing from below the text you can write with a relaxed grip without any fear of smudges.


I learned about this as an adult and felt like such an idiot for going through school without learning the trick. And maybe a little mad at my third grade teacher.

Paper at a 45 degree angle + hand below the line I'm writing be works like a charm.


My introduction to rollerball pens forced me to learn how to do this, otherwise, I was smearing everything I had written. I did some research and found out that curling my hand around the pen was the wrong way to hold it.


If you haven’t tried them I’d suggest getting a set of panniers for grocery hauls (I’ve got the ortlieb backroller plus). We do most of our grocery shopping by bike and having panniers makes transporting larger quantities much easier.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: