Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
montanalow
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
9 ms
·
61.
▲
by
montanalow
5y ago
I've been working with machine learning in production for more than a decade. The biggest challenges I see are actually organizational rather than algorithmic when it comes to delivering value. Most of that comes down to the additional
62.
▲
Show HN: PostgresML, end-to-end machine learning in your favorite db
(github.com)
15 points
by
montanalow
5y ago
|
3 comments
63.
▲
by
montanalow
5y ago
When you remove the context around statements (thread about rust concurrency), it's easy to make a statement into overblown nonsense. You may be interested in the broader analysis contained in the link from parent comment, about the ty
64.
▲
by
montanalow
5y ago
This is actually pretty amazing. I wouldn't normally trust a single author implemented project to sit between my application and my database, since that is a rather critical single point of failure. However, a grep that fails to find `
65.
▲
by
montanalow
5y ago
As a fan of Rust, this seems like the perfect application domain for "fearless concurrency". Having gone through the bowels of a few different connection pool implementations in various languages (because they had bugs in producti
66.
▲
Programmers should learn how to benchmark, or I will kill them all
(omniref.com)
7 points
by
montanalow
12y ago
|
1 comments
67.
▲
by
montanalow
12y ago
I'll go edit the post to make it more clear that you need to follow the links through the code to get the actual answer... it's more involved than a single snippet.
68.
▲
by
montanalow
12y ago
Rubinius is neat, but for me personally (and I think most of the community) it's performance. Writing C enables optimizations by hand that still yield very significant performance gains over the best of what any other high level langua
69.
▲
by
montanalow
12y ago
Matz mentioned off hand at the last Ruby Conf that Nobu has been experimenting without the GIL. It's scary because running code without the GIL will expose a lot of existing concurrency bugs that have been safely hidden thus far. A lot
70.
▲
Ruby Threads and the Global Interpreter Lock in C
(omniref.com)
56 points
by
montanalow
12y ago
|
25 comments
71.
▲
How Efficient are Ruby Integers?
(omniref.com)
10 points
by
montanalow
12y ago
|
0 comments
72.
▲
by
montanalow
12y ago
Technical writing and programming aren't necessarily the same skill set.
73.
▲
Understanding the Ruby Garbage Collector
(omniref.com)
54 points
by
montanalow
12y ago
|
8 comments
74.
▲
by
montanalow
12y ago
Would love to have questions like this on Omniref for other code readers. VALUE is in fact a pointer, ie a raw integer, which is pass by value in C, so it's fine to return.
75.
▲
by
montanalow
12y ago
Which IDE do you use? We've been considering building extensions to common IDE's to allow teams to annotate code like this.
76.
▲
by
montanalow
12y ago
Do you happen to have an old version of Inconsolata font installed? In this case, chrome and firefox both prefer the font on disk to the google webfont specified in the css, which causes a display bug.
77.
▲
Ruby's Object.new in C
(omniref.com)
59 points
by
montanalow
12y ago
|
14 comments
78.
▲
Document, index and search your personal repositories with Omniref
(omniref.com)
8 points
by
montanalow
12y ago
|
0 comments
79.
▲
Ruby Objects in the deep C underworld
(omniref.com)
76 points
by
montanalow
12y ago
|
1 comments
80.
▲
by
montanalow
12y ago
We're planning a C memory management follow up, with a focus on Ruby GC and its recent improvements. We're also looking for authors to feature who write similar content, so if you wanted to do a series on a particular chunk of C y
81.
▲
by
montanalow
12y ago
Thanks wasd. The next thing you could do, is highlight some C and ask the community any questions you have. I intend to keep writing the series, since there's easily enough material there for a book. If you signup for an Omniref accoun
82.
▲
C for Rubyists
(omniref.com)
178 points
by
montanalow
12y ago
|
27 comments
83.
▲
by
montanalow
12y ago
As you point out, the speed at which programming is evolving makes maintaining relevant experience difficult for a human, which makes programming at least different in degree from other professions. The ultimate goal is to build a hive mind
84.
▲
Omniref Editor Integration
(omniref.com)
2 points
by
montanalow
12y ago
|
0 comments
85.
▲
by
montanalow
12y ago
I love the power of the unix shell. find | cat | grep would get the job done just as well if you had all the source in an accessible file tree, but I don't think you'd see any performance increase as the bottleneck is still random
86.
▲
by
montanalow
12y ago
About 2 hours. The regex is IO bound, on a text column with 87GB + 68GB postgres toast. It's on a new 1TB 3k iops EC2/EBS ssd volume, which seems to be able to sustain about 20MB/s.
87.
▲
Why Google is broken for debugging
(omniref.com)
38 points
by
montanalow
13y ago
|
8 comments
88.
▲
That Will Be Easy (It's Never Easy)
(omniref.com)
21 points
by
montanalow
13y ago
|
2 comments
89.
▲
by
montanalow
13y ago
The dynamism of ruby does make things difficult, if not impossible, to fully realize until runtime. Incidentally, tests are popular in ruby, and give us runtime examples to work with for stronger analysis. If we're just spitballing, as
90.
▲
by
montanalow
13y ago
Great example. A code browser is on our radar, but it would be a big enough undertaking to do "right" that it hasn't made the cut for low hanging fruit. Our next step may be to just hyperlink all methods/classes/con
More ›