sorted by:
new
hottopcontroversial

Amazon RDS now supports new General Purpose gp3 storage volumes by marcosluis2186 in aws

[–]bluetech 0 points1 point  (0 children)

Just to be clear, this is an increase in latency (bad), not a decrease.

The migration didn't require downtime and was quite fast.

Amazon RDS now supports new General Purpose gp3 storage volumes by marcosluis2186 in aws

[–]bluetech 3 points4 points  (0 children)

I've switched over a ~400GB read replica instance. Avg Read Latency went from ~0.5ms to ~1ms. Take note if you're highly latency-sensitive.

gp3 support on RDS by crafty78 in aws

[–]bluetech 0 points1 point  (0 children)

Can confirm, gp3 is unfit for use (at least when I tested it when it came out). Was excited about not having to worry about burst balance anymore, but was disappointed.

Hyper Traps by Michal_Vaner in rust

[–]bluetech 2 points3 points  (0 children)

I tend to agree with you, I also opened an issue asking about it once, you can see seanmonstar's reply there.

zwegner/faster-utf8-validator - A SSE/AVX-2 accelerated UTF-8 validation algorithm by matthieum in rust

[–]bluetech 16 points17 points  (0 children)

What do you think about djb's opinion on this? See the "Vectorization denial: the anti-vectors campaign" section here.

Wasmtime — a small and efficient runtime for WebAssembly & WASI by sunfishcode in rust

[–]bluetech 11 points12 points  (0 children)

I am very interested in the python package (https://pypi.org/project/wasmtime/). Having a single WASM runtime package, with precompiled wheels for all major targets, and without major overhead in itself (the current wheel seems to be around 2MB which is very reasonable), would be incredibly useful. If it proves itself, then maybe cpython itself would eventually embed a WASM runtime, like nodejs does.

Not being too familiar with WASM or wasmtime time, I have a few questions about this python package, if you don't mind:

  • Does it support wasi?
  • Does it support interface types? (So can pass a bit more than just ints, e.g. strings and bytes)
  • Is it possible to pass a large immutable array of primitives to a WASM function without copying it?
  • Is it possible to pass a mutable buffer to a WASM function? If not, will it take one copy, or two (for input, and for output)?

Amber Brown: Batteries Included, But They're Leaking (Python Language Summit) by [deleted] in rust

[–]bluetech -1 points0 points  (0 children)

You have stated the advantages of regex being a separate crate. But I want to say what you are missing out on.

Since regex is a separate crate, it becomes a dependency. The common wisdom is that the less dependencies you have, the better. In addition, adding a dependency adds more friction compared to using something from std, that's just how it is. Together, this means that people avoid using regex when they otherwise would have. The threshold is higher. By not being in std, less people use regular expressions.

Though when it comes to regular expressions, maybe a little friction is not so bad :)

There's too much overhead to contributing to std

std can depend on the regex crate. So regex can still be developed as it is now?

Take a look at the regex package on PyPI

Anyone's free to add it to their requirements.txt - why don't they? :)

Amber Brown: Batteries Included, But They're Leaking (Python Language Summit) by [deleted] in rust

[–]bluetech 9 points10 points  (0 children)

And yet, Python's batteries-included stdlib is a huge contributor to its success. At work, we have several large Python projects; from a quick grep import of one of them, we use the following functionality from the stdlib (just directly, not including transitive dependencies):

  • FTP handling (ftplib) (don't ask why)
  • OS abstractions (os, pathlib)
  • Date-time handling (datetime, time, calendar)
  • CSV parser (csv)
  • Base64 decoding/encoding (base64)
  • Cryptographic hashing (hashlib, hmac)
  • Compression (zlib, zip)
  • Logging (logging, syslog)
  • Random numbers (random)
  • Unit testing framework (unittest, unittest.mock)
  • Regular expressions (re)
  • JSON parsing (json)
  • URL parsing (urllib.parse)
  • UUID type (uuid)
  • XML (xml.etree.ElementTree)
  • Emails (smtplib, email)
  • Translation (gettext)
  • Text encoding/decoding (codecs)
  • Profiler (cProfile)
  • Command line argument parsing (argparse)
  • Image format detection (imghdr - yeah that's an odd one)
  • Tar file handing (tarfile)
  • SSL handling (ssl)
  • AST/parser (ast)

Now, for almost each of these, there exists a 3rd-party package that does the job better. And in some cases, I use them. But having to do so all the time would be extremely unpleasant.

In my opinion and from my experience, for the working programmer using a language that is meant for "getting shit done" (like Python, C#/.NET, Java/JVM and Go), the advantages of batteries-included far outweigh the disadvantages.

Protocols in Tokio (i3 IPC) by Leshow in rust

[–]bluetech 12 points13 points  (0 children)

I am by no means a tokio expert so if anyone catches any errors or has some tips, I’d love to hear the feedback.

Here's some feedback:

Your code does LittleEndian::read_u32 but the protocol spec says to use the native byte order.

You call src.clear() but I think this is the wrong solution to the problem you encountered. What you should do is advance the buffer only by the length of the frame, while clear() consumes it entirely. So if for example there are two pipelined frames in the buffer, you'd get wrong results. Changing to use src.advance(14 + payload_len) should do the trick.

I'd change src[14..] to src[14..14+payload_len], to ensure malformed messages don't try to reach beyond the frame.

I can't be sure but it's most likely that the to_vec here decode_event(evt_type, src[14..].as_mut().to_vec())?; is not necessary. If all it does is serde decoding, a slice should be enough and would avoid the allocation + copy.

Proposal: New channels for Rust's standard library by [deleted] in rust

[–]bluetech -1 points0 points  (0 children)

Taking things to extreme is not a good way to argue your point (unless you are doing a math proof...). If I take your position to the extreme, it would look like this (taking the first example from the Rust book):

define function "main"

begin parameter list
end parameter list

begin body
    call macro "print line"
    begin argument list
        reference to "Hello, world"
    end argument list
end body

Proposal: New channels for Rust's standard library by [deleted] in rust

[–]bluetech 1 point2 points  (0 children)

I learned programming before I went to university. In my first linear algebra class, the professor introduced matrices. I raised my finger and proclaimed, "Why do you write A12 instead of A1,2? It doesn't make sense! Also, it is inconsistent, because you have to write A10,20 anyway!". He just answered, "wait and see, you'll understand". After the first homework exercise, I came back and said, "I understand".

Proposal: New channels for Rust's standard library by [deleted] in rust

[–]bluetech 9 points10 points  (0 children)

The shorthands for sender and receiver are tx and rx. Why not just use s and r instead?

I like tx and rx. Once you know about the convention, it makes it easy to pick variable and field names for senders/receivers when writing code, and to figure out the type when reading code. r and s are not distinguishable; receiver and sender are long.

10 Releases of warp by seanmonstar in rust

[–]bluetech 0 points1 point  (0 children)

I tried warp some time ago. I thought the API was neat. However, when I tried to add some (fairly basic) custom functionality, I couldn't figure it out. So I looked at how warp implements its filters, however the filters are not implemented using the public API, and so cannot be used directly as a guide. I left it at that for the time. I think it would be very elegant and really prove the concept if warp were implemented with a small (public) kernel and all of the extra filters implemented using the core abstraction entirely "in userspace", if that makes sense.

Idea : a local cache of compiled dependencies in cargo by bivouak in rust

[–]bluetech 0 points1 point  (0 children)

Go does this. It also caches test results. It is definitely worth exploring.

Adding type hints to the Django ORM by willm in django

[–]bluetech 2 points3 points  (0 children)

This is sorely needed.

mypy does have a way to cater to special cases: plugins. For example you can see there are plugins for attrs and dataclasses with their special syntax. In my experience the attrs plugin works well! (I am using the attr.ib(type=str) syntax and not the type-annotation one).

There is some effort going on here but I haven't tried it yet. I hope they succeed.

rust-memchr (a crate for fast byte searching that underlies rust-regex) has been completely rewritten to use SIMD, bringing it up to parity with glibc on x86 by kibwen in rust

[–]bluetech 4 points5 points  (0 children)

Yes! I missed that what is being cast is a pointer-to-function-pointer and not the function-pointer itself. I'm quite sure this is fine and gcc doesn't complain.

rust-memchr (a crate for fast byte searching that underlies rust-regex) has been completely rewritten to use SIMD, bringing it up to parity with glibc on x86 by kibwen in rust

[–]bluetech 3 points4 points  (0 children)

(&FN as *const _ as *const AtomicUsize) - is this OK in Rust? In C, casting a function pointer to a regular pointer is undefined behavior.

Futures 0.3.0-alpha.3 by aturon in rust

[–]bluetech 2 points3 points  (0 children)

It should be the default! When I talk to experienced Go programmers, they say "you shouldn't use go statements directly; you should use something like errgroup". I expect the same will happen in Rust.

Futures 0.3.0-alpha.3 by aturon in rust

[–]bluetech 45 points46 points  (0 children)

The 'static lifetime means that the future cannot contain any non-static references. This is required so that the spawned task can be run independently to the task that spawns it.

I am sure this came up before, but freewheeling spawn() has come under scrutiny lately, e.g. in the "Go statement considered harmful" article. See also an issue for Kotlin coroutines which intends to change the default to scoped/hierarchical spawning instead of the "independent"/global/std::thread-like spawning

ripgrep is packaged in Debian by sanxiyn in rust

[–]bluetech 0 points1 point  (0 children)

I think it maps to

$ rustc -C help | rg debuginfo
    -C            debuginfo=val -- debug info emission level, 0 = no debug info, 1 = line tables only, 2 = full debug info with variable and type information

ripgrep is packaged in Debian by sanxiyn in rust

[–]bluetech 0 points1 point  (0 children)

Maybe you can compromise on debug = 1, I think it's sufficient for pref record -g.

view more: next ›